(Part 2) Best practices when automating your deployments with AWS CloudFormation

Đã cập nhật: 17 Th11 2020

If you’re automating your workload deployments on the Amazon Web Services (AWS) Cloud using AWS CloudFormation, you can take steps to save time during and after initial development. In addition to saving time, you can prevent your templates from becoming obsolete. In this blog post, I cover some best practices for AWS customers and AWS Partners to follow when developing infrastructure as code with AWS CloudFormation. The post also covers best practices for testing and maintaining AWS CloudFormation templates.

About AWS CloudFormation

AWS CloudFormation streamlines the deployment of key workloads on the AWS Cloud. With AWS CloudFormation, you model and provision all the resources needed for your applications across multiple Regions and accounts in an automated and secure manner. You can use programming languages or simple text files. AWS CloudFormation templates are text files, written in YAML or JSON format, that define the AWS resources to be deployed.

You can integrate automation tools, such as AWS Lambda and AWS Systems Manager, into your AWS CloudFormation templates. With automation tools, you can automate the provisioning of custom workloads on top of the defined AWS infrastructure.

The AWS Quick Start program provides over 170 examples of AWS Partner and AWS native deployments, all of which use AWS CloudFormation templates.

Best practices

  1. Start with existing AWS CloudFormation templates

  2. Create modular templates

  3. Use existing repositories as submodules

  4. Use an integrated development environment with linting

  5. Use parameters to define paths to your external assets

  6. Use the same names for common parameters

  7. Automate AWS CloudFormation testing with TaskCat

  8. Maintain your templates

We have covered the first four best practices in this post.

5. Use parameters to define paths to your external assets

Future-proof your AWS CloudFormation templates by avoiding hardcoded paths to external assets. For example, imagine that you have developed a template that deploys an EC2 instance that downloads installation media from an S3 bucket. You could hardcode the path to the installation media as something like https://customerbucket.s3.us-east-1.amazonaws.com/install.tar.gz. If you did, though, future changes to the S3 bucket (in this case, customerbucket)—such as removing public access or deleting the bucket entirely—would cause the deployment to fail.

Instead of hardcoding the path to the installation media, define it as a parameter, and set the URL as the default.

Another way to future-proof access to your external assets is to store them in the same repository as your AWS CloudFormation templates. You can store external assets that are called by the AWS CloudFormation template in the same repository as the template, decreasing external dependencies. Common repositories include AWS CodeCommit, GitHub, and GitLab. Assets that are commonly stored alongside the AWS CloudFormation templates that call them include Lambda functions, Bash or PowerShell scripts, and installation media.

6. Use the same names for common parameters

When you use a modular approach with complex deployments, you may find yourself working with a large number of AWS CloudFormation templates. The Amazon EKS Quick Start, for example, has 15 templates. In the Amazon EKS Quick Start, outputs from one template are passed as parameter values to other templates. Keeping parameter names consistent across all AWS CloudFormation templates makes it easier to troubleshoot and iterate.

For example, take the parameter VPCID (the ID of VPC into which the Quick Start is deployed). If you were to deploy the Amazon VPC Quick Start as a submodule, then you would deploy assets into the new VPC by passing the VPCID output from the submodule as a parameter value to your other templates. Using the parameter name VPCID in all your templates simplifies keeping track of your outputs and parameter values.

Here are some other common parameter names to keep the same:

  • VPCCIDR – Classless Inter-Domain Routing (CIDR) block of the VPC into which the Quick Start is deployed

  • PrivateSubnet1ID – ID of the first Availability Zone’s private subnet

  • PrivateSubnet2ID – ID of the second Availability Zone’s private subnet

  • PublicSubnet1ID – ID of the first Availability Zone’s public subnet

  • PublicSubnet2ID – ID of the second Availability Zone’s public subnet

7. Automate AWS CloudFormation testing with TaskCat

When you build AWS CloudFormation templates, you must test them. Testing typically involves the following steps:

  1. Upload your templates to an S3 bucket.

  2. Sign in to the AWS Management Console.

  3. Open the AWS CloudFormation console.

  4. Enter the S3 path to your parent template.

  5. Manually enter parameter values.

  6. Launch the stack.

  7. Wait to see if the deployment succeeds or fails.

It’s time-consuming to manually deploy AWS CloudFormation templates across multiple AWS Regions and then clean up the assets you deployed during testing. In addition, you may lose track of the assets you deployed. So when you clean up the test environment manually, you may overlook assets that remain active in your account. These overlooked assets can lead to unexpected charges on your next AWS billing statement.

To address these issues, the AWS Quick Start team has developed a process to automate AWS CloudFormation testing using an open-source tool called TaskCat. You enter Regions and parameter values into a YAML-formatted file called taskcat.yml in the root of your repository. TaskCat uses these values to automatically deploy your AWS CloudFormation templates. It then logs the results of the deployment—whether it succeeded or failed (and, if it failed, the reason)—and deletes any assets that were deployed.

When you use TaskCat to test your AWS CloudFormation templates, you can focus on other things while waiting for the deployment to complete. You can also prevent resources that were deployed during testing from lingering in your AWS accounts.

8. Maintain your templates

Since AWS CloudFormation templates are used to automate deployments, they are often reused for months or years. As a result, they can get out of date. For example, EC2 instance types may become deprecated, Amazon Machine Images (AMIs) may be removed from general availability, and new functionality may be added to a database service.

Test your AWS CloudFormation templates periodically to ensure that they continue to work as expected. Incorporate new service functionality as it becomes available.

Contact us to get started with automating your deployments with AWS CloudFormation

26 lượt xem0 bình luận

Bài đăng gần đây

Xem tất cả