Post Syndicated from Akash Kumar original https://aws.amazon.com/blogs/devops/building-a-ci-cd-pipeline-for-multi-region-deployment-with-aws-codepipeline/
This post discusses the benefits of and how to build an AWS CI/CD pipeline in AWS CodePipeline for multi-region deployment. The CI/CD pipeline triggers on application code changes pushed to your AWS CodeCommit repository. This automatically feeds into AWS CodeBuild for static and security analysis of the CloudFormation template. Another CodeBuild instance builds the application to generate an AMI image as output. AWS Lambda then copies the AMI image to other Regions. Finally, AWS CloudFormation cross-region actions are triggered and provision the instance into target Regions based on AMI image.
The solution is based on using a single pipeline with cross-region actions, which helps in provisioning resources in the current Region and other Regions. This solution also helps manage the complete CI/CD pipeline at one place in one Region and helps as a single point for monitoring and deployment changes. This incurs less cost because a single pipeline can deploy the application into multiple Regions.
As a security best practice, the solution also incorporates static and security analysis using cfn-lint and cfn-nag. You use these tools to scan CloudFormation templates for security vulnerabilities.
The following diagram illustrates the solution architecture.
Multi region AWS CodePipeline architecture
Before getting started, you must complete the following prerequisites:
- Create a repository in CodeCommit and provide access to your user
- Copy the sample source code from GitHub under your repository
- Create an Amazon S3 bucket in the current Region and each target Region for your artifact store
Creating a pipeline with AWS CloudFormation
You use a CloudFormation template for your CI/CD pipeline, which can perform the following actions:
- Use CodeCommit repository as source code repository
- Static code analysis on the CloudFormation template to check against the resource specification and block provisioning if this check fails
- Security code analysis on the CloudFormation template to check against secure infrastructure rules and block provisioning if this check fails
- Compilation and unit test of application code to generate an AMI image
- Copy the AMI image into target Regions for deployment
- Deploy into multiple Regions using the CloudFormation template; for example, us-east-1, us-east-2, and ap-south-1
You use a sample web application to run through your pipeline, which requires Java and Apache Maven for compilation and testing. Additionally, it uses Tomcat 8 for deployment.
The following table summarizes the resources that the CloudFormation template creates.
||Service role for AWS CloudFormation
||Service role for CodeBuild
||Service role for CodePipeline
||Service role for Lambda function
||Service role for security analysis of provisioning CloudFormation template
||Service role for static analysis of provisioning CloudFormation template
||CodeBuild for static analysis of provisioning CloudFormation template
||CodeBuild for security analysis of provisioning CloudFormation template
||CodeBuild for compilation, testing, and AMI creation
||Python Lambda function for copying AMI images into other Regions
||CodePipeline for CI/CD
To start creating your pipeline, complete the following steps:
- Launch the CloudFormation stack with the following link:
Launch button for CloudFormation
- Choose Next.
- For Specify details, provide the following values:
||Name of your stack
||Input the target Region 1 (other than current Region) for deployment
||Input the target Region 2 (other than current Region) for deployment
||Branch name of repository
||Repository name of the project
||Input the S3 bucket name for artifact store
||Create a bucket in target Region 1 and specify the name for artifact store
||Create a bucket in target Region 2 and specify the name for artifact store
- On the Review page, select I acknowledge that this template might cause AWS CloudFormation to create IAM resources.
- Choose Create.
- Wait for the CloudFormation stack status to change to CREATE_COMPLETE (this takes approximately 5–7 minutes).
When the stack is complete, your pipeline should be ready and running in the current Region.
- To validate the pipeline, check the images and EC2 instances running into the target Regions and also refer the AWS CodePipeline Execution summary as below.
AWS CodePipeline Execution Summary
We will walk you through the following steps for creating a multi-region deployment pipeline:
1. Using CodeCommit as your source code repository
The deployment workflow starts by placing the application code on the CodeCommit repository. When you add or update the source code in CodeCommit, the action generates a CloudWatch event, which triggers the pipeline to run.
2. Static code analysis of CloudFormation template to provision AWS resources
Historically, AWS CloudFormation linting was limited to the ValidateTemplate action in the service API. This action tells you if your template is well-formed JSON or YAML, but doesn’t help validate the actual resources you’ve defined.
You can use a linter such as the cfn-lint tool for static code analysis to improve your AWS CloudFormation development cycle. The tool validates the provisioning CloudFormation template properties and their values (mappings, joins, splits, conditions, and nesting those functions inside each other) against the resource specification. This can cover the most common of the underlying service constraints and help encode some best practices.
The following rules cover underlying service constraints:
- E2530 – Checks that Lambda functions have correctly configured memory sizes
- E3025 – Checks that your RDS instances use correct instance types for the database engine
- W2001 – Checks that each parameter is used at least once
You can also add this step as a pre-commit hook for your GIT repository if you are using CodeCommit or GitHub.
You provision a CodeBuild project for static code analysis as the first step in CodePipeline after source. This helps in early detection of any linter issues.
3. Security code analysis of CloudFormation template to provision AWS resources
You can use Stelligent’s cfn_nag tool to perform additional validation of your template resources for security. The cfn-nag tool looks for patterns in CloudFormation templates that may indicate insecure infrastructure provisioning and validates against AWS best practices. For example:
- IAM rules that are too permissive (wildcards)
- Security group rules that are too permissive (wildcards)
- Access logs that aren’t enabled
- Encryption that isn’t enabled
- Password literals
You provision a CodeBuild project for security code analysis as the second step in CodePipeline. This helps detect any insecure infrastructure provisioning issues.
4. Compiling and testing application code and generating an AMI image
Because you use a Java-based application for this walkthrough, you use Amazon Corretto as your JVM. Corretto is a no-cost, multi-platform, production-ready distribution of the Open Java Development Kit (OpenJDK). Corretto comes with long-term support that includes performance enhancements and security fixes.
You also use Apache Maven as a build automation tool to build the sample application, and the HashiCorp Packer tool to generate an AMI image for the application.
You provision a CodeBuild project for compilation, unit testing, AMI generation, and storing the AMI ImageId in the Parameter Store, which the CloudFormation template uses as the next step of the pipeline.
5. Copying the AMI image into target Regions
You use a Lambda function to copy the AMI image into target Regions so the CloudFormation template can use it to provision instances into that Region as the next step of the pipeline. It also writes the target Region AMI ImageId into the target Region’s Parameter Store.
6. Deploying into multiple Regions with the CloudFormation template
You use the CloudFormation template as a cross-region action to provision AWS resources into a target Region. CloudFormation uses Parameter Store’s ImageId as reference and provisions the instances into the target Region.
To avoid additional charges, you should delete the following AWS resources after you validate the pipeline:
- The cross-region CloudFormation stack in the target and current Regions
- The main CloudFormation stack in the current Region
- The AMI you created in the target and current Regions
- The Parameter Store AMI_VERSION in the target and current Regions
You have now created a multi-region deployment pipeline in CodePipeline without having to worry about the mechanics of creating and copying AMI images across Regions. CodePipeline abstracts the creating and copying of the images in the background in each Region. You can now upload new source code changes to the CodeCommit repository in the primary Region, and changes deploy automatically to other Regions. Cross-region actions are very powerful and are not limited to deploy actions. You can also use them with build and test actions.