By: Atif Siddiqui
Edited by: Brad P. Adair (@bpadair)
Infrastructure as Code (IaC) is one of the salient DevOps practices. IaC is the management of infrastructure through code. This code is versioned which, resultantly, guarantees repeatability in the process of infrastructure provisioning.
In this article, I am going to talk about IaC through the prism of AWS. Focus will be on a few impressive features that AWS has released, in its IaC product, over the years.
Genesis
CloudFormation was released [1] in February 2011 as a service offering for Infrastructure as Code (IaC). This tool relies on declarative blueprint documents known as Templates. While initially, template could only be composed in JSON, several years later in 2016 [2], support for YAML was added.
Template Anatomy
Templates supports top level structure using the following sections.
1. AWSTemplateFormatVersion
2. Description
3. Metadata
4. Parameters
5. Mappings
6. Conditions
7. Transform
8. Resources
9. Outputs
Among this list, Resources is the only mandatory section. After all, the goal is to provision AWS resources. The collection of resources provisioned by a given template is called a CloudFormation Stack and area treated as a single unit.
Public Coverage Roadmap
One of the polarizing themes of CloudFormation has been the support lag with AWS aggressively rolling out products and features. Given a minimum viable product (MVP) mindset, it entails Products/Features not having Day 1 CloudFormation support, carrying the risk of customer dissatisfaction.
In light of all the heat perpetuated by the customers, AWS announced [3] Product roadmap for CloudFormation. This is meant to provide visibility and a public forum for customer feedback. It should be noted, this is not a new idea in AWS space. In fact, it is borrowed [4] from AWS Container Service team which launched it as an experimental idea last year [5].
While a roadmap is a step in the right direction, I have always felt that product teams should follow a well known timeline. For example, within three months of product or feature announcement, CloudFormation support must be made available.
Versatility
Evolution of CloudFormation, in my view, has been frustratingly slow. Only over the last couple of years have there been feature announcements that have added versatility to a tool with immense potential. In my humble opinion, the following are few of the noteworthy features that have been added.
Drift Detection
This feature was announced [6] November of last year. It provides the ability to detect if any of the underlying resources provisioned by CloudFormation have been modified outside this tool.
Drift Detection provides visibility across the entire stack (depicted above) as well as drift detail at the resource level.
In the example [7] shown below, IP on the inbound rule of the security group had been modified (outside of CloudFormation) from a value of 0.0.0.0/0 to 72.202.202.202/32.
It should be noted that Drift Detection supports a subset of resources [8]. At this time, there are a total of 16 resources being supported.
StackSet
One of the limitations Stack concept suffered from is the lack of scalability. A template would need to be run in every account and region where resources are required to be provisioned.
StackSet filled this gap by providing the capability to implement a stack across multiple accounts and regions in a repeatable fashion. Regions of interest could be selected allowing for a model where an Administrator account has ability to execute CloudFormation template across multiple target accounts.
Account numbers 12356789012 and 234567890123 are illustrations of Target account numbers.
Last month, Drift detection was announced [9] for StacksSets providing a portal view to manage it.
CloudFormation cli
Just a few weeks ago, CloudFormation cli was been released [10] as an open source project. As part of this announcement, CloudFormation registry was announced which is one of its salient value proposition.
With cli’s ability to build resource providers, it allows for extensibility through invocation of third party resources. The days of relying on user data (custom scripts) or Lambda functions to provision third party resources should be behind us.
Registry defines two types of resources: private and public. Native AWS resources (depicted above) are categorized as public while third party resources will be categorized as private. The list of currently supported third party resources is listed below.
a. Atlassian
b. Datadog
c. Densify
d. Dynatrace
e. Fortinet
f. New Relic
g. Spotinst
Import Existing Resources
Last month, another notable CloudFormation feature was announced [11]. Through this feature, resources created manually can be imported to manage them through CloudFormation. In a true MVP style, this feature is available in only select regions.
Following example depicts the example of security group being imported that had been manually created in console.
The wizard prompts for the resource name after parsing through the template. The manually created security group with id of sg-0e84f5537086128b5 was specified as the identifier value.
The template mandates that resources being imported use the Termination protection via the attribute ‘DeletionPolicy: Retain’.
Wrap up
Interestingly, while there were several CloudFormation releases announced in the weeks prior to re:Invent, conference itself was quiet on this product. Hopefully, AWS’s investment in IaC, for its customers, will continue to be prioritized as CloudFormation strives to achieve its potential.
References
[1] https://aws.amazon.com/about-aws/whats-new/2011/02/25/introducing-aws-cloudformation/
[2] https://aws.amazon.com/blogs/aws/aws-cloudformation-update-yaml-cross-stack-references-simplified-substitution/
[3] https://aws.amazon.com/blogs/aws/aws-cloudformation-update-public-coverage-roadmap-cdk-goodies/
[4] https://github.com/aws/containers-roadmap
[5] https://www.geekwire.com/2018/amazon-web-services-reveals-public-road-map-cloud-container-services/
[6] https://aws.amazon.com/blogs/aws/new-cloudformation-drift-detection/
[7] https://s3-us-west-2.amazonaws.com/cloudformation-templates-us-west-2/EC2_Instance_With_Ephemeral_Drives.template
[8] https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift-resource-list.html?icmpid=docs_cfn_console
[9] https://aws.amazon.com/about-aws/whats-new/2019/11/cloudformation-announces-drift-detection-support-in-stackSets/
[10] https://aws.amazon.com/blogs/aws/cloudformation-update-cli-third-party-resource-support-registry/
[11] https://aws.amazon.com/blogs/aws/new-import-existing-resources-into-a-cloudformation-stack/
Posts
No comments :
Post a Comment