This document discusses building a continuous integration/continuous delivery (CI/CD) pipeline for deploying containerized applications to Amazon ECS. It covers using Docker images, Amazon ECS, and Amazon ECR for CI/CD. Deployment strategies like blue/green deployments and rolling deployments are described. The document also discusses using AWS CodeBuild to build Docker images, AWS CodePipeline to orchestrate pipelines, and demonstrates a sample pipeline.

1. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
John Pignata, Startup Solutions Architect
May 24, 2017
Building a CICD Pipeline for
Container Deployment to
Amazon ECS

2. What To Expect from This Session
• Review continuous integration, delivery, and deployment
• Using Docker images, Amazon ECS, and Amazon ECR for
CI/CD
• Deployment strategies with Amazon ECS
• Building Docker container images with AWS CodeBuild
• Orchestrating deployment pipelines with AWS CodePipeline
• Demo

3. Continuous Integration, Delivery,
and Deployment

6. How can we quickly and reliably
deliver good ideas to our
customers?

7. Learnings
• Frequency reduces difficulty
• Latency between check-in and production is
waste
• Consistency improves confidence
• Automation over toil
• Empowered developers make happier teams
• Smaller batch sizes are easier to debug
• Faster delivery improves software
development practices

8. Source Build Test Production
• Version Control
• Branching
• Code Review
• Compilation
• Unit Tests
• Static Analysis
• Packaging
• Integration Tests
• Load Tests
• Security Tests
• Acceptance
Tests
• Deployment
• Monitoring
• Measuring
• Validation

9. Continuous Integration
Continuous Delivery
Continuous Deployment
Source Build Test Production
Feedback

10. Docker Images

11. Packaged Application
Code and Runtime
Dependencies
Reproducible
Immutable
Portable

12. 1c2acd7c
8ab2ba66
91bd52b7
d2cccfda
Image Layers
microservice:latest

13. 1c2acd7c
8ab2ba66
91bd52b7
d2cccfda
microservice:latestDockerfile
FROM amazonlinux:2017.03
RUN yum install –y nginx
COPY ./app /bin/app
CMD [”/bin/app”]

14. microservice:1.0.0
microservice:1.1.0
microservice:1.1.1
microservice:1.2.0

15. Development CI UAT Production

16. Best Practices
• Pin external dependencies to specific
versions for reproducibility
• Package only the runtime requirements for
production
• Minimize changes in each layer to maximize
cache-ability
• Maintain a .dockerignore file to exclude
unneeded files from the image

17. Building Docker Images

19. AWS CodeBuild
Build and test code with continuous
scaling with pay-as-you-go pricing
• Build and test projects across platforms and runtimes
including Java, Ruby, Python, Android, Docker, etc.
• Never pay for idle time
• Fully extensible to other platforms through custom build
environments

20. Build Specification – Phases
Phase Description Examples
install Installation of packages into the
environment
Install testing frameworks
e.g. RSpec, Mocha
pre_build Commands to run before the build
such as login steps or installation of
dependencies
Log in to Amazon ECR.
run Ruby bundler or npm
build Sequence to run the build such as
compilation and/or running tests
Run go build, sbt, Mocha,
RSpec
post_build Commands to run after a build on
success or failure
Build a JAR via Maven or
push a Docker image to
Amazon ECR

21. Build Specification – Docker
version: 0.2
phases:
pre_build:
commands:
- $(aws ecr get-login)
build:
commands:
- docker build –t ʺ${REGISTRY}/${IMAGE_NAME}:${IMAGE_TAG}ʺ .
post_build:
commands:
- docker push ʺ${REGISTRY}/${IMAGE_NAME}:${IMAGE_TAG}ʺ

22. Best Practices
• Minimize your spend on build resources
• AWS CodeBuild
• EC2 Spot Instances
• Tag output artifacts to source control
revisions (e.g. git SHA, semantic version)
• Avoid using a “latest” or “production” tag
• Optimize for build speed
• Collocate build process with its artifact
repository

23. Deploying Docker Containers

26. Amazon EC2 Container Service (ECS)
EC2 INSTANCES
ECS
AGENT
ECS
AGENT
Amazon
ECS
ECS
AGENT
DEPLOYMENT
AUTOMATION

27. Deployment – In Place – Doubling
Availability Zone Availability Zone
Scenario
Service’s task definition is
updated to a new revision with
parameters:
Desired Count = 2
Minimum Healthy Percent = 100%
Maximum Percent = 200%
These settings permit the service
to grow to double its desired size
during deployment
EXISTING EXISTING

28. Deployment – In Place – Doubling
Availability Zone Availability Zone
Two new tasks are started
growing the number of tasks to
200% of its desired count which is
the maximum permitted
EXISTING EXISTINGNEW NEW
Desired Count = 2
Minimum Healthy Percent = 100%
Maximum Percent = 200%

29. Deployment – In Place – Doubling
Availability Zone Availability Zone
After the new tasks are verified to
be healthy by the Elastic Load
Balancer health check, the two
previous tasks with the older task
definition are drained and stopped
NEW NEW
Desired Count = 2
Minimum Healthy Percent = 100%
Maximum Percent = 200%

30. Deployment – In Place – Rolling
Availability Zone Availability Zone
Scenario
Service’s task definition is
updated to a new revision with
parameters:
Desired Count = 2
Minimum Healthy Percent = 50%
Maximum Percent = 100%
These settings constrain the
service to not exceed its desired
size but allows it to halve the
number of tasks during
deployment
EXISTING EXISTING

31. Deployment – In Place – Rolling
Availability Zone Availability Zone
First, an existing task is stopped
which brings the healthy
percentage of the service to 50%
and makes room on the cluster for
new tasks
EXISTING
Desired Count = 2
Minimum Healthy Percent = 50%
Maximum Percent = 100%

32. Deployment – In Place – Rolling
Availability Zone Availability Zone
A task using the new task
definition is started bringing the
service back to 100%
EXISTING
Desired Count = 2
Minimum Healthy Percent = 50%
Maximum Percent = 100%
NEW

33. Deployment – In Place – Rolling
Availability Zone Availability Zone
After the new task is verified to be
healthy by the Elastic Load
Balancer health check, the next
existing task with the older task
definition is drained and stopped
Desired Count = 2
Minimum Healthy Percent = 50%
Maximum Percent = 100%
NEW

34. Deployment – In Place – Rolling
Availability Zone Availability Zone
The second new task is started on
the cluster bringing the service
back to 100%
NEW NEW
Desired Count = 2
Minimum Healthy Percent = 50%
Maximum Percent = 100%

35. Deployment – Canary
Availability Zone Availability Zone
Scenario
The new revision runs as a small
subset of production by deploying
a canary service in the same
target group
Deployment is completed by
updating the primary service’s
task definition and scaling down
the canary service. EXISTING EXISTINGEXISTING

36. Deployment – Canary
Availability Zone Availability Zone
A standalone service with the new
task definition is deployed using
the same Application Load
Balancer target group of the
existing service
EXISTING EXISTINGEXISTING CANARY

37. Deployment – Canary
Availability Zone Availability Zone
After some period of monitoring
the metrics from the canary
instance, the existing service’s
task definition is updated to the
new revision
NEW NEWNEW CANARY

38. Deployment – Canary
Availability Zone Availability Zone
After the deployment, all tasks are
running the same task definition
with the new revision of the
application and the canary can be
destroyed
NEW NEWNEW

39. Deployment – Blue/Green – DNS Swap
Availability Zone
EXISTING EXISTING
www.myproduct.com
Scenario
Two services are defined each
with their own Application Load
Balancer
Deployment is completed by
swapping the Route 53 alias
record between the two
Application Load Balancers
Availability Zone

40. Deployment – Blue/Green – DNS Swap
Availability Zone
EXISTING EXISTING
www.myproduct.com
An identical Application Load
Balancer and a service with a task
definition using the new revision is
deployed
Availability Zone
NEW NEW
next.myproduct.com

41. Deployment – Blue/Green – DNS Swap
Availability Zone
EXISTING EXISTING
next.myproduct.com
After automated or manual
testing, the deployment is
completed by swapping the Route
53 alias record between the two
Application Load Balancers
Availability Zone
NEW NEW
www.myproduct.com

42. Deployment – Blue/Green – DNS Swap
Availability Zone
The previous service and its
Application Load Balancer can
then be destroyed
Availability Zone
NEW NEW
www.myproduct.com

43. Deployment – Blue/Green – Target Group Swap
Availability Zone
EXISTING EXISTING
Scenario
Two services are defined each
with their own target group
registered in the same Application
Load Balancer using Host-based
routing
Deployment is completed by
swapping the listener rules
between the two target groups
Availability Zone

44. Deployment – Blue/Green – Target Group Swap
Availability Zone
EXISTING EXISTING
The second service is deployed
with a new target group and
registered to the same Application
Load Balancer
Using Host-based routing, requests
to www.myproduct.com are
directed to our blue service while
requests to next.myproduct.com
are directed to our green service NEW NEW
Availability Zone

45. Deployment – Blue/Green – Target Group Swap
Availability Zone
After automated or manual testing,
the deployment can be completed
by swapping the listener rules on
the Application Load Balancer and
sending traffic to the green service
NEW NEW
Availability Zone
EXISTING EXISTING

46. Deployment – Blue/Green – Target Group Swap
Availability Zone
The previous service and its target
group can then be destroyed
NEW NEW
Availability Zone

47. Best Practices
• Use Elastic Load Balancing health checks to
prevent botched deploys
• For higher confidence, integrate automated
testing against a new environment or
monitoring of a canary before cutover
• Ensure your application can function against
the same backend schema for adjacent
releases

48. Building a Deployment Pipeline

49. The automated manifestation
of the process for getting your
software from version control
and into the hands of your
customers
Deployment Pipeline

50. Source Build Test Production

51. AWS CodePipeline
Model deployment pipelines through a visual workflow
interface which build, test, and deploy new revisions on
code changes
• Integrates with AWS services, open source and third
party tools for building, testing, and deploying code
• Extend deployment pipelines with custom logic through
AWS Lambda functions or custom actions
• Allows operators to block transitions to “stop the line”
and manual approval steps

52. Source
Source
GitHub
Build
Build
AWS CodeBuild
Deploy
Deploy
AWS CloudFormation
Action
Stage
Pipeline
Transition

53. Developers Version Control
Repository
Test &
Deployment
Manager
Image Build
Service
Infrastructure
Provisioning
Container
Scheduling &
Orchestration
Container Image
Repository

54. Developers AWS
CodeCommit
AWS
CodePipeline
AWS CodeBuild
AWS
CloudFormation
Amazon ECS
Amazon ECR

55. Developers Github Jenkins
Infrastructure
Provisioning
Container
Scheduling &
Orchestration
Container Image
Repository

56. AWS
CloudFormation
Amazon ECS
Amazon ECR
Developers Github Jenkins

57. Demo

58. Reference Architecture
https://github.com/awslabs/ecs-refarch-continuous-deployment

59. Thank You!
Q&A