Automating Blue/Green Deployments of Infrastructure and Application Code using AMIs, AWS Developer Tools, & Amazon EC2 Systems Manager
Previous DevOps blog posts have covered the following use cases for infrastructure and application deployment automation:
- Deploy to Production Using AWS CodeBuild and the AWS Developer Tools Suite: Deploying a simple Java application in an in-place deployment model using AWS CodeCommit, AWS CodeBuild, and AWS CodeDeploy orchestrated by AWS CodePipeline.
- Performing Blue/Green Deployments with AWS CodeDeploy and Auto Scaling Groups: Extending the CI/CD model by using the CodeDeploy blue/green deployment feature to create a production environment and make it easier to roll back to the previous environment if problems arise.
- Streamline AMI Maintenance and Patching Using Amazon EC2 Systems Manager | Automation: Using EC2 Systems Manager and automation to patch, update agents, or bake applications into an Amazon Machine Image (AMI) and avoid the time and effort associated with manual image updates.
An AMI provides the information required to launch an instance, which is a virtual server in the cloud. You can use one AMI to launch as many instances as you need. It is security best practice to customize and harden your base AMI with required operating system updates and, if you are using AWS native services for continuous security monitoring and operations, you are strongly encouraged to bake into the base AMI agents such as those for Amazon EC2 Systems Manager (SSM), Amazon Inspector, CodeDeploy, and CloudWatch Logs. A customized and hardened AMI is often referred to as a “golden AMI.” The use of golden AMIs to create EC2 instances in your AWS environment allows for fast and stable application deployment and scaling, secure application stack upgrades, and versioning.
In this post, using the DevOps automation capabilities of Systems Manager, AWS developer tools (CodePipeLine, CodeDeploy, CodeCommit, CodeBuild), I will show you how to use AWS CodePipeline to orchestrate the end-to-end blue/green deployments of a golden AMI and application code. Systems Manager Automation is a powerful security feature for enterprises that want to mature their DevSecOps practices.
Here are the high-level phases and primary services covered in this use case:
You can access the source code for the sample used in this post here: https://github.com/awslabs/automating-governance-sample/tree/master/Bluegreen-AMI-Application-Deployment-blog.
This sample will create a pipeline in AWS CodePipeline with the building blocks to support the blue/green deployments of infrastructure and application. The sample includes a custom Lambda step in the pipeline to execute Systems Manager Automation to build a golden AMI and update the Auto Scaling group with the golden AMI ID for every rollout of new application code. This guarantees that every new application deployment is on a fully patched and customized AMI in a continuous integration and deployment model. This enables the automation of hardened AMI deployment with every new version of application deployment.
We will build and run this sample in three parts.
Part 1 of the AWS CloudFormation template creates the initial Java-based web application environment in a VPC. It also creates all the required components of Systems Manager Automation, CodeCommit, CodeBuild, and CodeDeploy to support the blue/green deployments of the infrastructure and application resulting from ongoing code releases.
Part 1 of the AWS CloudFormation stack creates these resources:
- A Java-based web application running on EC2 instances loaded with CodeDeploy agents in an Auto Scaling group behind an Elastic Load Balancing load balancer.
- A Systems Manager Automation document that patches the supplied base AMI and creates the golden AMI.
- A CodeCommit repository to securely store code and files for your application.
- A CodeBuild project with configuration details about how AWS CodeBuild builds your source code.
- A CodeDeploy deployment group with Auto Scaling group details about the web application EC2 instances.
- A CodeDeploy application with a deployment group configured with the Automatically copy Auto Scaling group setting.
- The following Lambda functions:
- A function to get the Amazon-provided source AMI ID based on region and architecture.
- A function to update the Systems Manager parameter with the golden AMI ID.
- A function to update the CodeDeploy deployment group with required blue/green configurations. (Currently AWS CloudFormation does not support creating a deployment group with blue/green deployment configurations.)
After Part 1 of the AWS CloudFormation stack creation is complete, go to the Outputs tab and click the Elastic Load Balancing link. You will see the following home page for the base web application:
Make sure you have all the outputs from the Part 1 stack handy. You need to supply them as parameters in Part 3 of the stack.
Part 2: Setting up your CodeCommit repository
In this part, you will commit and push your sample application code into the CodeCommit repository created in Part 1. To access the initial git commands to clone the empty repository to your local machine, click Connect to go to the AWS CodeCommit console. Make sure you have the IAM permissions required to access AWS CodeCommit from command line interface (CLI).
After you’ve cloned the repository locally, download the sample application files from the part2 folder of the Git repository and place the files directly into your local repository. Do not include the aws-codedeploy-sample-tomcat folder. Go to the local directory and type the following commands to commit and push the files to the CodeCommit repository:
git add . git commit -a -m "add all files from the AWS Java Tomcat CodeDeploy application" git push
After all the files are pushed successfully, the repository should look like this:
Part 3 of the AWS CloudFormation template creates the pipeline in AWS CodePipeline and all the required components.
a) Source: The pipeline is triggered by any change to the CodeCommit repository.
b) BuildGoldenAMI: This Lambda step executes the Systems Manager Automation document to build the golden AMI. After the golden AMI is successfully created, a new launch configuration with the new AMI details will be updated into the Auto Scaling group of the application deployment group. You can watch the progress of the automation in the EC2 console from the Systems Manager –> Automations menu.
c) Build: This step uses the application build spec file to build the application build artifact. Here are the CodeBuild execution steps and their status:
d) Deploy: This step clones the Auto Scaling group, launches the new instances with the new AMI, deploys the application changes, reroutes the traffic from the elastic load balancer to the new instances and terminates the old Auto Scaling group. You can see the execution steps and their status in the CodeDeploy console.
After the CodePipeline execution is complete, you can access the application by clicking the Elastic Load Balancing link. You can find it in the output of Part 1 of the AWS CloudFormation template. Any consecutive commits to the application code in the CodeCommit repository trigger the pipelines and deploy the infrastructure and code with an updated AMI and code.
If you have feedback about this post, add it to the Comments section below. If you have questions about implementing the example used in this post, open a thread on the Developer Tools forum.
About the author
Ramesh Adabala is a Solutions Architect in Southeast Enterprise Solution Architecture team at Amazon Web Services.