General AWS CodeDeploy Concepts
CodeDeploy is a deployment service that automates application deployments to Amazon EC2 instances, on-premises instances, serverless Lambda functions, or Amazon ECS services.
You can deploy a nearly unlimited variety of application content, including:
- Serverless AWS Lambda functions.
- Web and configuration files.
- Multimedia files.
CodeDeploy can deploy application content that runs on a server and is stored in Amazon S3 buckets, GitHub repositories, or Bitbucket repositories.
CodeDeploy can also deploy a serverless Lambda function.
You do not need to make changes to your existing code before you can use CodeDeploy.
Can be used to automatically deploy applications to many EC2 instances.
Similar open source tools include Ansible, Terraform, Chef, Puppet etc.
Integrates with various CI/CD tools including Jenkins, GitHub, Atlassian, AWS CodePipeline as well as config management tools like Ansible, Puppet and Chef.
CodeDeploy is a fully managed service.
There’s lots of flexibility to define any kind of deployment.
CodeDeploy can be connected to CodePipeline and use artifacts from there.
CodeDeploy can use re-use existing setup tools, works with any application, auto scaling integration.
An AWS CodeDeploy application contains information about what to deploy and how to deploy it.
Need to choose the compute platform:
- AWS Lambda.
- Amazon ECS.
- Amazon EC2 cloud instances, on-premises servers, or both.
- Deployments that use the EC2/On-Premises compute platform manage the way in which traffic is directed to instances by using an in-place or blue/green deployment type.
- Used to deploy applications that consist of an updated version of a Lambda function.
- You can manage the way in which traffic is shifted to the updated Lambda function versions during a deployment by choosing a canary, linear, or all-at-once configuration.
- Used to deploy an Amazon ECS containerized application as a task set.
- CodeDeploy performs a blue/green deployment by installing an updated version of the application as a new replacement task set.
- CodeDeploy reroutes production traffic from the original application task set to the replacement task set.
- The original task set is terminated after a successful deployment.
- You can manage the way in which traffic is shifted to the updated task set during a deployment by choosing a canary, linear, or all-at-once configuration.
Each deployment group belongs to one application and specifies:
- A deployment configuration – a set of deployment rules as well as success / failure conditions used during a deployment.
- Notifications configuration for deployment events.
- Amazon CloudWatch alarms to monitor a deployment.
- Deployment rollback configuration.
CodeDeploy provides two deployment type options – in-place and blue/green.
- The application on each instance in the deployment group is stopped, the latest application revision is installed, and the new version of the application is started and validated.
- You can use a load balancer so that each instance is deregistered during its deployment and then restored to service after the deployment is complete.
- Only deployments that use the EC2/On-Premises compute platform can use in-place deployments.
Exam tip: AWS Lambda and Amazon ECS deployments cannot use an in-place deployment type.
Blue/green on an EC2/On-Premises compute platform:
- The instances in a deployment group (the original environment) are replaced by a different set of instances (the replacement environment) using these steps:
- Instances are provisioned for the replacement environment.
- The latest application revision is installed on the replacement instances.
- An optional wait time occurs for activities such as application testing and system verification.
- Instances in the replacement environment are registered with an Elastic Load Balancing load balancer, causing traffic to be rerouted to them.
- Instances in the original environment are deregistered and can be terminated or kept running for other uses.
Note: If you use an EC2/On-Premises compute platform, be aware that blue/green deployments work with Amazon EC2 instances only.
Blue/green on an AWS Lambda compute platform:
- Traffic is shifted from your current serverless environment to one with your updated Lambda function versions.
- You can specify Lambda functions that perform validation tests and choose the way in which the traffic shifting occurs.
- All AWS Lambda compute platform deployments are blue/green deployments.
- For this reason, you do not need to specify a deployment type.
Blue/green on an Amazon ECS compute platform:
- Traffic is shifted from the task set with the original version of an application in an Amazon ECS service to a replacement task set in the same service.
- You can set the traffic shifting to linear or canary through the deployment configuration.
- The protocol and port of a specified load balancer listener is used to reroute production traffic.
- During a deployment, a test listener can be used to serve traffic to the replacement task set while validation tests are run.
Deployment on Amazon EC2:
EC2 instances are identified by CodeDeploy by using tags or an Auto Scaling Group name.
Each Amazon EC2 instance must have the correct IAM instance profile attached.
The CodeDeploy agent must be installed and running on each instance.
The agent continuously polls for work to do.
CodeDeploy sends the appspec.yml file (which must be at the root of your source code).
The application code is pulled from GitHub or S3.
EC2 will run the deployment instructions.
CodeDeploy agent will report of success / failure of deployment on the instance.
EC2 instances are grouped by deployment group (e.g. dev, test, prod).
Note: CodeDeploy does not provision the resources – it deploys applications not EC2 instances.
The application specification file (AppSpec file) is a YAML-formatted or JSON-formatted file used by CodeDeploy to manage a deployment.
The AppSpec file defines the deployment actions you want AWS CodeDeploy to execute.
The name of the AppSpec file for an EC2/On-Premises deployment must be appspec.yml. The name of the AppSpec file for an Amazon ECS or AWS Lambda deployment must be appspec.yaml.
The following code sample shows the format of an appspec.yml file for an Amazon EC2 instance with WordPress:
version: 0.0 os: linux files: - source: / destination: /var/www/html/WordPress hooks: BeforeInstall: - location: scripts/install_dependencies.sh timeout: 300 runas: root AfterInstall: - location: scripts/change_permissions.sh timeout: 300 runas: root ApplicationStart: - location: scripts/start_server.sh - location: scripts/create_test_db.sh timeout: 300 runas: root ApplicationStop: - location: scripts/stop_server.sh timeout: 300 runas: root
The files section specifies how to source and copy from S3 / GitHub to the filesystem.
hooks are a set of instructions to be run to deploy the new version (hooks have timeouts).
AppSpec.yaml for ECS
The Amazon ECS task definition file must be specified with its ARN in the TaskDefinition instruction in the AppSpec file.
The container and port in your replacement task set where your Application Load Balancer or Network Load Balancer reroutes traffic during a deployment must be specified with the LoadBalancerInfo instruction in the AppSpec file.
Here is an example of an AppSpec file written in YAML for deploying an Amazon ECS service
version: 0.0 Resources: - TargetService: Type: AWS::ECS::Service Properties: TaskDefinition: "arn:aws:ecs:us-east-1:111222333444:task-definition/my-task-definition-family-name:1" LoadBalancerInfo: ContainerName: "SampleApplicationName" ContainerPort: 80 # Optional properties PlatformVersion: "LATEST" NetworkConfiguration: AwsvpcConfiguration: Subnets: ["subnet-1234abcd","subnet-5678abcd"] SecurityGroups: ["sg-12345678"] AssignPublicIp: "ENABLED" Hooks: - BeforeInstall: "LambdaFunctionToValidateBeforeInstall" - AfterInstall: "LambdaFunctionToValidateAfterTraffic" - AfterAllowTestTraffic: "LambdaFunctionToValidateAfterTestTrafficStarts" - BeforeAllowTraffic: "LambdaFunctionToValidateBeforeAllowingProductionTraffic" - AfterAllowTraffic: "LambdaFunctionToValidateAfterAllowingProductionTraffic"
Note: The hooks are different for each type of compute platform and not all available hooks are shown. For more information on the available hooks for each compute platform please read the AWS documentation here.
AppSpec.yaml for AWS Lambda
The format of the AppSpec.yaml file for use with AWS Lambda is as follows:
version: 0.0 Resources: - myLambdaFunction: Type: AWS::Lambda::Function Properties: Name: "myLambdaFunction" Alias: "myLambdaFunctionAlias" CurrentVersion: "1" TargetVersion: "2" Hooks: - BeforeAllowTraffic: "LambdaFunctionToValidateBeforeTrafficShift" - AfterAllowTraffic: "LambdaFunctionToValidateAfterTrafficShift"
The following hooks are available for use:
- BeforeAllowTraffic – used to specify the tasks or functions you want to run before traffic is routed to the newly deployed Lambda function.
- AfterAllowTraffic – used to specify the tasks or functions you want to run after the traffic has been routed to the newly deployed Lambda function.
When updating to a new version a Revision includes everything needed to deploy the new version: AppSpec file, application files, executables and config files.
In-place deployment (EC2 only)
Here’s how it works:
- First, you create deployable content on your local development machine or similar environment, and then you add an application specification file (AppSpec file). The AppSpec file is unique to CodeDeploy. It defines the deployment actions you want CodeDeploy to execute. You bundle your deployable content and the AppSpec file into an archive file, and then upload it to an Amazon S3 bucket or a GitHub repository. This archive file is called an application revision (or simply a revision).
- Next, you provide CodeDeploy with information about your deployment, such as which Amazon S3 bucket or GitHub repository to pull the revision from and to which set of Amazon EC2 instances to deploy its contents. CodeDeploy calls a set of Amazon EC2 instances a deployment group. A deployment group contains individually tagged Amazon EC2 instances, Amazon EC2 instances in Amazon EC2 Auto Scaling groups, or both.
Each time you successfully upload a new application revision that you want to deploy to the deployment group, that bundle is set as the target revision for the deployment group. In other words, the application revision that is currently targeted for deployment is the target revision. This is also the revision that is pulled for automatic deployments.
- Next, the CodeDeploy agent on each instance polls CodeDeploy to determine what and when to pull from the specified Amazon S3 bucket or GitHub repository.
- Finally, the CodeDeploy agent on each instance pulls the target revision from the Amazon S3 bucket or GitHub repository and, using the instructions in the AppSpec file, deploys the contents to the instance.
CodeDeploy keeps a record of your deployments so that you can get deployment status, deployment configuration parameters, instance health, and so on.
A blue/green deployment is used to update your applications while minimizing interruptions caused by the changes of a new application version. CodeDeploy provisions your new application version alongside the old version before rerouting your production traffic.
AWS Lambda: Traffic is shifted from one version of a Lambda function to a new version of the same Lambda function.
Amazon ECS: Traffic is shifted from a task set in your Amazon ECS service to an updated, replacement task set in the same Amazon ECS service.
EC2/On-Premises: Traffic is shifted from one set of instances in the original environment to a replacement set of instances.
Note: All AWS Lambda and Amazon ECS deployments are blue/green. An EC2/On-Premises deployment can be in-place or blue/green.
For Amazon ECS and AWS Lambda there are three ways traffic can be shifted during a deployment:
- Canary: Traffic is shifted in two increments. You can choose from predefined canary options that specify the percentage of traffic shifted to your updated Amazon ECS task set / Lambda function in the first increment and the interval, in minutes, before the remaining traffic is shifted in the second increment.
- Linear: Traffic is shifted in equal increments with an equal number of minutes between each increment. You can choose from predefined linear options that specify the percentage of traffic shifted in each increment and the number of minutes between each increment.
- All-at-once: All traffic is shifted from the original Amazon ECS task set / Lambda function to the updated Amazon ECS task set / Lambda function all at once.
For Amazon EC2 you can choose how your replacement environment is specified:
Copy an existing Amazon EC2 Auto Scaling group:
- During the blue/green deployment, CodeDeploy creates the instances for your replacement environment during the deployment.
- With this option, CodeDeploy uses the Amazon EC2 Auto Scaling group you specify as a template for the replacement environment, including the same number of running instances and many other configuration options.
Choose instances manually:
- You can specify the instances to be counted as your replacement using Amazon EC2 instance tags, Amazon EC2 Auto Scaling group names, or both.
- If you choose this option, you do not need to specify the instances for the replacement environment until you create a deployment.