building a cicd pipeline for container deployment to amazon ecs - may 2017 aws online tech talks

© 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

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

Continuous Integration, Delivery,

and Deployment

How can we quickly and reliably

deliver good ideas to our

customers?

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

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

Continuous Integration

Continuous Delivery

Continuous Deployment


Feedback

Docker Images

Packaged Application

Code and Runtime

Dependencies

Reproducible

Immutable

Portable

1c2acd7c

8ab2ba66

91bd52b7

d2cccfda

Image Layers

microservice:latest

1c2acd7c

8ab2ba66

91bd52b7

d2cccfda

microservice:latestDockerfile

FROM amazonlinux:2017.03

RUN yum install –y nginx

COPY ./app /bin/app

CMD [”/bin/app”]

microservice:1.0.0

microservice:1.1.0

microservice:1.1.1

microservice:1.2.0

Development CI UAT Production

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

Building Docker Images

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

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

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

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

Deploying Docker Containers

Amazon EC2 Container Service (ECS)

EC2 INSTANCES

ECS AGENT

ECS AGENT

Amazon

ECS

ECS AGENT

DEPLOYMENT AUTOMATION

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



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





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



Deployment – In Place – Rolling


Scenario

Service’s task definition is

updated to a new revision with

parameters:

Desired Count = 2



These settings constrain the

service to not exceed its desired

size but allows it to halve the

number of tasks during

deployment

EXISTING EXISTING



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





A task using the new task

definition is started bringing the

service back to 100%

EXISTING

Desired Count = 2



NEW



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



NEW



The second new task is started on

the cluster bringing the service

back to 100%

NEW NEW

Desired Count = 2



Deployment – Canary


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



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



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



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

Deployment – Blue/Green – DNS Swap

Availability Zone

EXISTING EXISTING

www.myproduct.com

Scenario

Two services are defined each

with their own Application Load

Balancer


swapping the Route 53 alias

record between the two

Application Load Balancers

Availability Zone


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


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


Availability Zone

The previous service and its

Application Load Balancer can

then be destroyed

Availability Zone

NEW NEW

www.myproduct.com

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


swapping the listener rules

between the two target groups

Availability Zone


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


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


Availability Zone

The previous service and its target

group can then be destroyed

NEW NEW

Availability Zone

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

Building a Deployment Pipeline

The automated manifestation

of the process for getting your

software from version control

and into the hands of your

customers

Deployment Pipeline

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

Source

Source

GitHub

Build

Build

AWS CodeBuild

Deploy

Deploy

AWS CloudFormation

ActionStage

Pipeline

Transition

Developers Version Control

Repository

Test &

Deployment

Manager

Image Build

Service

Infrastructure

Provisioning

Container

Scheduling &

Orchestration

Container Image

Repository

Developers AWS

CodeCommit

AWS

CodePipeline

AWS CodeBuild

AWS

CloudFormation

Amazon ECS

Amazon ECR

Developers Github Jenkins

Infrastructure

Provisioning

Container

Scheduling &

Orchestration

Container Image

Repository

AWS

CloudFormation

Amazon ECS

Amazon ECR

Developers Github Jenkins

Reference Architecture

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

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

Thank You!

Q&A

building a cicd pipeline for container deployment to amazon ecs - may 2017 aws online tech talks

Technology