Using AWS CloudFormation we can define and configure infrastructure as code, this allows us to provision and update infrastructure in a consistent and repeatable way. If our developers need to spin up a test environment that matches our production environment it can be done in minutes using a CloudFormation template. If we’re expanding into a new region we can use CloudFormation templates to rapidly deploy new infrastructure whilst still maintaining consistency with existing infrastructure. If we have compliance requirements, CloudFormation templates can ensure infrastructure is configured in way that matches those requirements. Once your infrastructure has been deployed you can manage the code definition in the same way you would manage your applications enabling you to version control your infrastructure.
Using CloudFormation with AWS CodeCommit and CodePipeline we can go even further than this and build a Continuous Delivery Pipeline for the deployment and update of our CloudFormation templates. Continuous Delivery allows us to provision and update infrastructure automatically, carry out any testing and seek approval from stakeholders prior to releasing them into production. Manual handovers, build times and approval times are all reduced to ensure the rapid deployment of infrastructure and implementation of changes.
In this post we’ll use AWS CodeCommit and CodePipeline to build a sample pipeline that will deliver a multi-AZ web application via CloudFormation Template. The pipeline detects new or updated CloudFormation templates in CodeCommit and automatically builds a test stack for review, we’ll then add an approval step to choose whether we release the new or updated stack into our production environment.
AWS CodeCommit provides highly scalable and secure Git repositories; we’re going to use it to store and maintain our CloudFormation templates and as the source of our pipeline.
To create a new repository select the ‘Get Started’ link or select ‘Create Repository’. Give the repository a unique name and select create repository.
We can connect to the new repository using SSH or HTTPS, we’re going to use HTTPS. We need an IAM user with Git Credentials , details for configuring the IAM user are detailed in the CodeCommit User Guide. We’ll also need to install Git (1.7.9 or later supported) on our local machine. Once those pre-reqs are met we can clone new repository to create a local repo, from the command line we type:
Now we’ve got a local repo we can add the CloudFormation template. I’m going to use a sample template that will deploy a multi-AZ, load balanced and scalable application available here. We’re also adding a configuration file that will complete the necessary parameters for the CloudFormation template The following commands commit the files to the local repo and push the commit to the AWS CodeCommit repository
git add AutoScalingMultiAZWithNotifications.template MSP-configuration.json
git commit -m “Added CloudFormation Template and Configuration File”
git push -u origin master
If we check our CodeCommit repository now we can see the CloudFormation template and the configuration file.
Now we’ve configured our source we can build our pipeline. AWS CodePipeline is a continuous delivery service we can use to automatically build, test and deploy applications and infrastructure into the cloud. Using CodePipeline we can automate the release process and ensure consistent deployments and updates of applications and infrastructure. By delivering infrastructure in this rapid, safe and consistent way we allow our developers to focus on application development without the long wait times associated with traditional release methodologies.
The first step in building our pipeline is to configure a source. We are going to use the CodeCommit repository we set up, but you could also use AWS S3 or GitHub.
We’re then going to configure a deployment stage, this is where we define how the CloudFormation template is deployed.
At this point we have a basic pipeline that will detect updates and changes to the CloudFormation template and automatically deploy that CloudFormation template. We can build out our pipeline by adding additional stages and actions. In this example I have added stages to build the CloudFormation template as a test stack then email stakeholders for review of the test stack and approval of deployment. If approved the test stack will be deleted and a CloudFormation Change Set created. We use the Change Set to make sure any existing Production Stacks and resources are not removed without our knowledge or consent.
The pipeline will run anytime it detects a change to the CloudFormation template. We’ll manually release the change to run through the deployment process. First of all the test stack and instances are created and we’re sent an email prompting us to review and approve the changes, we can see here an EC2 instance has been started and it is hosting our WebApp accessible via our load balancer.
If we’re happy with the test infrastructure and the application we can approve the release, at this point the test stack will be deleted and a Change Set will be created for review. The Change Set details all changes the template will make and its potential impact on existing resources, we’ll be prompted by the pipeline to review and approved those changes.
If we’re happy with the changes and approve the Change Set the infrastructure and application will be deployed into Production. Any future updates to the template will be automatically detected, a test environment created for reviewng those changes and then the deployment to production automated as well; and that’s it, we’ve just built a pipeline that repeatedly and reliably provisions and updates are infrastructure allowing our developers to quickly begin work on the development and testing of applications.