Home » AWS Certification Cheat Sheets » AWS Certified Developer

Associate Cheat Sheets » AWS Developer Tools » AWS CodeDeploy

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.
Executables.
Packages.
Scripts.
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.

CodeDeploy Application
An AWS CodeDeploy application contains information about what to deploy
and how to deploy it.

Need to choose the compute platform:

EC2/On-premises.
AWS Lambda.
Amazon ECS.

EC2/On-Premises:

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.
AWS Lambda:

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.

Amazon ECS:

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.
Deployment Group
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.

Deployment Type
CodeDeploy provides two deployment type options – in-place and
blue/green.
In-place deployment:

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.

AppSpec File
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 or appspec.yml.

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.

Revision
When updating to a new version a Revision includes everything needed to
deploy the new version: AppSpec file, application files, executables and
config files.

Deployment Configuration
In-place deployment (EC2 only)

Here’s how it works:

1. 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).
2. 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.
3. 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.
4. 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.

Blue/green deployments
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.

Get Started Find Answers

AWS Certification Path Latest Blog Articles

Free AWS Certication Guide FAQ

AWS Training Courses Join our Slack Channels

AWS Practice Exams Join our Facebook Group

AWS Books for Offline Study Join our LinkedIn Group

Connect Follow

About us Facebook

Connect with Neal LinkedIn

Contact us Youtube

Submit Feedback Twitter

Join our Team Instagram

AWS Training Resources

AWS Cloud Practitioner

AWS Solutions Architect

AWS Developer Associate

AWS SysOps Administrator

AWS Solutions Architect PRO

AWS Certification Training - Master Amazon Web Services

© 2021 Digital Cloud Training | Privacy Policy | Terms of Service | Sitemap