Made suspension of processes optional (default to false) and added clarification to README.md

Author: default50

load-balancing/elb/README.md

@@ -2,8 +2,6 @@
 
 Often when running a web service, you'll have your instances behind a load balancer. But when deploying new code to these instances, you don't want the load balancer to continue sending customer traffic to an instance while the deployment is in progress. Lifecycle event scripts give you the ability to integrate your AWS CodeDeploy deployments with instances that are behind an Elastic Load Balancer or in an Auto Scaling group. Simply set the name (or names) of the Elastic Load Balancer your instances are a part of, set the scripts in the appropriate lifecycle events, and the scripts will take care of deregistering the instance, waiting for connection draining, and re-registering after the deployment finishes.
 
-*Please note that this scripts will suspend some AutoScaling processes (AZRebalance, AlarmNotification, ScheduledActions and ReplaceUnhealthy) while deploying, in order to avoid wrong interactions.*
-
 ## Requirements
 
 The register and deregister scripts have a couple of dependencies in order to properly interact with Elastic Load Balancing and AutoScaling:
@@ -36,4 +34,20 @@ To use these scripts in your own application:
 4. Edit your application's `appspec.yml` to run `deregister_from_elb.sh` on the ApplicationStop event, and `register_with_elb.sh` on the ApplicationStart event.
 5. If your instance is not in an Auto Scaling Group, edit `common_functions.sh` to set `ELB_LIST` to contain the name(s) of the Elastic Load Balancer(s) your deployment group is a part of. Make sure the entries in ELB_LIST are separated by space.
 Alternatively, you can set `ELB_LIST` to `_all_` to automatically use all load balancers the instance is registered to, or `_any_` to get the same behaviour as `_all_` but without failing your deployments if the instance is not part of any ASG or ELB. This is more flexible in heterogeneous tag-based Deployment Groups.
-6. Deploy!
+6. Optionally set up `HANDLE_PROCS=true` in `common_functions.sh`. See note below.
+7. Deploy!
+
+## Important notice about handling AutoScaling processes
+
+When using AutoScaling with CodeDeploy you have to consider some edge cases during the deployment time window:
+
+1. If you have a scale up event, the new instance(s) will get the latest successful *Revision*, and not the one you are currently deploying. You will end up with a fleet of mixed revisions.
+2. If you have a scale down event, instances are going to be terminated, and your deployment will (probably) fail.
+3. If your instances are not balanced accross Availability Zones **and you are** using these scripts, AutoScaling may terminate some instances or create new ones to maintain balance (see [this doc](http://docs.aws.amazon.com/autoscaling/latest/userguide/as-suspend-resume-processes.html#process-types)), interfering with your deployment.
+4. If you have the health checks of your AutoScaling Group based off the ELB's ([documentation](http://docs.aws.amazon.com/autoscaling/latest/userguide/healthcheck.html)) **and you are not** using these scripts, then instances will be marked as unhealthy and terminated, interfering with your deployment.
+
+In an effort to solve these cases, the scripts can suspend some AutoScaling processes (AZRebalance, AlarmNotification, ScheduledActions and ReplaceUnhealthy) while deploying, to avoid those events happening in the middle of your deployment. You only have to set up `HANDLE_PROCS=true` in `common_functions.sh`.
+
+A record of the previously (to the start of the deployment) suspended process is kept by the scripts (on each instance), so when finishing the deployment the status of the processes on the AutoScaling Group should be returned to the same status as before. I.e. if AZRebalance was suspended manually it will not be resumed. However, if the scripts don't run (failed deployment) you may end up with stale suspended processes.
+
+**WARNING**: If you are using this functionality you should only use *CodeDepoyDefault.OneAtATime* deployment configuration to ensure a serial execution of the scripts. Concurrent runs are not supported.

load-balancing/elb/common_functions.sh

@@ -40,6 +40,9 @@ MIN_CLI_VERSION='1.3.25'
 # Create a flagfile for each deployment
 FLAGFILE="/tmp/asg_codedeploy_flags-$DEPLOYMENT_GROUP_ID-$DEPLOYMENT_ID"
 
+# Handle ASG processes
+HANDLE_PROCS=false
+
 # Usage: get_instance_region
 #
 #   Writes to STDOUT the AWS region as known by the local instance.
@@ -224,11 +227,13 @@ autoscaling_enter_standby() {
         return 0
     fi
 
-    msg "Checking ASG ${asg_name} suspended processes"
-    check_suspended_processes
+    if [ "$HANDLE_PROCS" = "true" ]; then
+        msg "Checking ASG ${asg_name} suspended processes"
+        check_suspended_processes
 
-    # Suspend troublesome processes while deploying
-    suspend_processes
+        # Suspend troublesome processes while deploying
+        suspend_processes
+    fi
 
     msg "Checking to see if ASG ${asg_name} will let us decrease desired capacity"
     local min_desired=$($AWS_CLI autoscaling describe-auto-scaling-groups \
@@ -351,8 +356,10 @@ autoscaling_exit_standby() {
         msg "Auto scaling group was not decremented previously, not incrementing min value"
     fi
 
-    # Resume processes, except for the ones suspended before deployment
-    resume_processes
+    if [ "$HANDLE_PROCS" = "true" ]; then
+        # Resume processes, except for the ones suspended before deployment
+        resume_processes
+    fi
 
     # Clean up the FLAGFILE
     remove_flagfile