Building a CICD Pipeline for deploying on Containers

2. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Marek Kuczynski
Solution Architect, AWS
@marekq
Building A CI/CD Pipeline for
Deploying Containers

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

4. Continuous Integration, Delivery,
and Deployment

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

7. The speed of innovation is based on the speed
of deployment
DEVELOP
BUILD
TEST
Secure
RELEASE
DEPLOY

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

9. Release process have for major phases
• Integration
tests with
other systems
• Load testing
• UI tests
• Penetration
testing
Source Build Test Deploy
• Check in
source code,
such as .java
files
• Peer review
new code
• Compile code
• Unit tests
• Style checkers
• Code metrics
• Create
container
images
• Deployment
to production
environments

10. Automating the release process
Source Build Test Deploy Provision Monitor
Code
Commit
CodePipeline
CodeDeploy
Cloud
Formation
Cloud
Watch
OpsWorks
Elastic Beanstalk
CodeBuild

11. AWS CodeCommit
• Secure, scalable, and managed Git source control
• Automatic encryption at rest and in transit
• Supports existing tooling
• Highly available
git pull/push CodeCommit
Git objects in
Amazon S3
Git index in
Amazon
DynamoDB
Encryption key
in AWS KMS
SSH or HTTPS

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

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

14. 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}ʺ

15. AWS CodeDeploy
• Automates code deployments to your container service
• Handles the complexity of updating your applications
• Avoid downtime during application deployment
• Deploy a container in any language and on any
operating system
• Integrates with third-party tools and AWS

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

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

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

19. Demo

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

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

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

23. AWS
CloudFormation
Amazon ECS
Amazon ECR
Developers Github Jenkins

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

25. Deployment strategies

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

27. 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%

28. 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%

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

30. 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%

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

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

33. 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%

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

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

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

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

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

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

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

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

42. Deployment – Blue/Green – Target Group Swap
Availability Zone
EXISTING EXISTING
www.myproduct.comwww.myproduct.com
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

43. Deployment – Blue/Green – Target Group Swap
Availability Zone
EXISTING EXISTING
www.myproduct.comwww.myproduct.com
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
next.myproduct.com
next.myproduct.com
Availability Zone

44. 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
www.myproduct.com
www.myproduct.com
Availability Zone
EXISTING EXISTING
next.myproduct.comnext.myproduct.com

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

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

47. Thank You!
Marek Kuczynski
@marekq