freshidea - Fotolia
IT teams who have installed and configured physical server hardware to deploy a new application know it's a time-consuming...
process. They first must find or procure server and network infrastructure, which can take weeks or even months, and that's before beginning installation.
This is one of the reasons businesses are flocking to cloud platforms like AWS to run their applications. In the cloud, customers can treat their infrastructure like software and provision complex server environments in a matter of seconds.
The approach is called infrastructure as code (IAC), and it applies common software development practices to the world of infrastructure. This allows teams to iterate on projects quickly. Developers and IT operations personnel can roll out new versions on infrastructure built through automation. And, like application code, IAC can be used in version control through AWS CloudFormation templates and tested automatically to ensure reliability.
Using AWS CloudFormation templates for IAC
AWS CloudFormation is a tool for teams looking to embrace infrastructure as code in AWS. Teams can automate the deployment of complex environments by writing declarative JSON-formatted templates and feeding them into the service via an API call or an interactive Web-based console. CloudFormation uses a declarative template model, so infrastructure developers don't need to do low-level programming; they simply state the resources they need within the JSON template.
Authors can model complex environments in these templates, which include network infrastructure, Elastic Compute Cloud (EC2) instances and load balancers. CloudFormation supports most AWS resources, but template developers can also use custom resources that use more complex programming logic.
AWS CloudFormation templates are written as plain text JSON files, so it's easy to understand their intent by reading through the code. These templates can be checked into public or private version control repositories. AWS version control is recommended, as it allows teams to collaborate during the development process and easily understand what revisions took place from one change to the next.
For advanced teams, template changes checked into version control can automatically trigger a build process within a continuous delivery pipeline. The pipeline can include test stages, ensuring the template uses valid JSON, and post build tasks to make sure the infrastructure is properly provisioned and functioning as expected.
To help IT teams get started with CloudFormation, AWS provides a number of starter templates they can use as inspiration for their projects.
Provide customization through parameters
CloudFormation allows users to pass in values at launch time through template parameters. This provides customization capabilities, and eliminates the need to hard-code information in a template. Input parameters are often used to specify the key pair name used in SSH for EC2 instances or for the Central Identities Data Repository ranges used by Amazon Virtual Private Cloud (VPC) subnets. These are common examples, but template developers often create and use parameters for a variety of use cases.
Parameters also prevent embedding credentials in a template. You do not want passwords stored within a plain-text JSON template, and CloudFormation parameters support a number of advanced attributes that can help. To accept a password, developers decorate the parameter with a "NoEcho" attribute. This masks the password field when the template is being used interactively in the CloudFormation Web console.
There are a number of ways to add constraints to parameters. As a best practice, constraints like minimum and maximum length, allowed patterns and allowed values should be used to ensure the proper values are being provided to the template.
Build a template brick by brick
The end result of CloudFormation templates are called stacks, which are sets of related resources that make up an application. For example, a template might launch a set of Web and database servers. Together, those servers make up a complete Web application stack. AWS recommends organizing stacks based on lifecycle and ownership.
Smaller teams might opt to build discrete parts of an overall stack. In this example, database administrators may be responsible for a database template, and Web developers or operators might handle a Web server template. In either case, these smaller stacks can be nested or stacked horizontally to build a larger stack. It is also easier to manage, maintain and troubleshoot segmented templates of a complex environment.
IT teams can also use this modular building block approach to eliminate code duplication. Repetitive blocks of code, or significant code snippets that are duplicated, should be moved into their own reusable template. For example, every stack may need its own VPC with the same network settings. In this case, the developer creates a template that builds the VPC, and remaining stacks share the VPC template as a base for the network portion of the infrastructure.
Apply security and management controls
The AWS Identity and Access Management (IAM) service allows IT teams to tightly control users and their permissions. These access controls can be very granular about who can create, update, view or delete stacks. It is recommended that administrators create IAM policies for their CloudFormation developers and operators to ensure they have only the permissions they need.
After a stack has been built, operators can modify a template and issue an update, as long as they've been given permission through IAM. Stack updates can make organizations nervous, as they can impact running systems. The "change sets" feature allows operators to see how changes to a stack could impact existing resources before executing the change. Stack policies can also protect critical resources from unintentional updates.
Integrate configuration management tools
CloudFormation supports complex bootstrapping scenarios using client-side agents and initialization instructions within the template. When EC2 instances are launched, configuration files may need to be set up, artifacts may need to be downloaded and packages may need to be installed. This can all be done through template metadata and helper scripts. Developers can also use these features to invoke configuration management tools -- such as Chef, Puppet and Ansible -- to apply configurations to servers. The specific configuration management tool isn't important, but needs to be supported by the instance's operating system.
As with the infrastructure as code templates, server configurations defined within Chef cookbooks, Puppet manifests and Ansible playbooks should also be checked into AWS version control to provide a clear blueprint of how the entire stack should be configured.
AWS configuration management tools tidy up the cloud
Take advantage of AWS DevOps tools
Chef helps IT teams achieve infrastructure automation