by Asif Khan, Solutions Architect, AWS

1. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Deep Dive on CI/CD and Docker
SRV412

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
cachability
• 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.1
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
• 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 – 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

40. 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

41. 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

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

43. 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

44. 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

45. 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

46. 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

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. Amazon ECS
Developers AWS CodeCommit AWS CodePipeline
AWS CodeBuild Amazon ECR
AWS CloudFormation
AWS CodeBuild

54. Demo

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

56. Thank You!
Q&A