You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Often when running a web service, you'll have your instances behind a load balancer. But when
4
-
deploying new code to these instances, you don't want the load balancer to continue sending customer
5
-
traffic to an instance while the deployment is in progress. Lifecycle event scripts give you the
6
-
ability to integrate your AWS CodeDeploy deployments with instances that are behind an Elastic Load
7
-
Balancer or in an Auto Scaling group. Simply set the name (or names) of the Elastic Load Balancer
8
-
your instances are a part of, set the scripts in the appropriate lifecycle events, and the scripts
9
-
will take care of deregistering the instance, waiting for connection draining, and re-registering
10
-
after the deployment finishes.
3
+
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.
11
4
12
5
## Requirements
13
6
14
-
The register and deregister scripts have a couple of dependencies in order to properly interact with
15
-
Elastic Load Balancing and AutoScaling:
16
-
17
-
1. The [AWS CLI](http://aws.amazon.com/cli/). In order to take advantage of
18
-
AutoScaling's Standby feature, the CLI must be at least version 1.3.25. If you
19
-
have Python and PIP already installed, the CLI can simply be installed with `pip
20
-
install awscli`. Otherwise, follow the [installation instructions](http://docs.aws.amazon.com/cli/latest/userguide/installing.html)
21
-
in the CLI's user guide.
22
-
1. An instance profile with a policy that allows, at minimum, the following actions:
Note: the AWS CodeDeploy Agent requires that an instance profile be attached to all instances that
35
-
are to participate in AWS CodeDeploy deployments. For more information on creating an instance
36
-
profile for AWS CodeDeploy, see the [Create an IAM Instance Profile for Your Amazon EC2 Instances]()
37
-
topic in the documentation.
38
-
1. All instances are assumed to already have the AWS CodeDeploy Agent installed.
7
+
The register and deregister scripts have a couple of dependencies in order to properly interact with Elastic Load Balancing and AutoScaling:
8
+
9
+
1. The [AWS CLI](http://aws.amazon.com/cli/). In order to take advantage of AutoScaling's Standby feature, the CLI must be at least version 1.3.25. If you have Python and PIP already installed, the CLI can simply be installed with `pip install awscli`. Otherwise, follow the [installation instructions](http://docs.aws.amazon.com/cli/latest/userguide/installing.html) in the CLI's user guide.
10
+
11
+
2. An instance profile with a policy that allows, at minimum, the following actions:
**Note**: the AWS CodeDeploy Agent requires that an instance profile be attached to all instances that are to participate in AWS CodeDeploy deployments. For more information on creating an instance profile for AWS CodeDeploy, see the [Create an IAM Instance Profile for Your Amazon EC2 Instances](http://docs.aws.amazon.com/codedeploy/latest/userguide/how-to-create-iam-instance-profile.html) topic in the documentation.
24
+
25
+
3. All instances are assumed to already have the AWS CodeDeploy Agent installed.
39
26
40
27
## Installing the Scripts
41
28
42
29
To use these scripts in your own application:
43
30
44
31
1. Install the AWS CLI on all your instances.
45
-
1. Update the policies on the EC2 instance profile to allow the above actions.
46
-
1. Copy the `.sh` files in this directory into your application source.
47
-
1. Edit your application's `appspec.yml` to run `deregister_from_elb.sh` on the ApplicationStop event,
48
-
and `register_with_elb.sh` on the ApplicationStart event.
49
-
1. Edit `common_functions.sh` to set `ELB_LIST` to contain the name(s) of the Elastic Load
50
-
Balancer(s) your deployment group is a part of. Make sure the entries in ELB_LIST are separated by space.
51
-
1. Deploy!
32
+
2. Update the policies on the EC2 instance profile to allow the above actions.
33
+
3. Copy the `.sh` files in this directory into your application source.
34
+
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.
35
+
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.
36
+
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.
37
+
6. Optionally set up `HANDLE_PROCS=true` in `common_functions.sh`. See note below.
38
+
7. Deploy!
39
+
40
+
## Important notice about handling AutoScaling processes
41
+
42
+
When using AutoScaling with CodeDeploy you have to consider some edge cases during the deployment time window:
43
+
44
+
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.
45
+
2. If you have a scale down event, instances are going to be terminated, and your deployment will (probably) fail.
46
+
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.
47
+
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.
48
+
49
+
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`.
50
+
51
+
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.
52
+
53
+
Disclaimer: There's a small chance that an event is triggered while the deployment is progressing from one instance to another. The only way to avoid that completely whould be to monitor the deployment externally to CodeDeploy/AutoScaling and act accordingly. The effort on doing that compared to this depends on the each use case.
52
54
55
+
**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.
0 commit comments