Infrastructure as code is currently a hot topic. It gives advantages such as faster deployment, better security and improved stability. By using AWS it becomes a lot easier to use infrastructure as code. You no longer have to be concerned about physical servers to deploy your stack.
But there are still much complexity to handle to achieve infrastructure as code. There are tools needed that convert the code to infrastructure. The main tool given to use by AWS is CloudFormation.
With CloudFormation it is possible to deploy a stack consistently. A JSON or YAML template file describes the infrastructure. This template allows you to redeploy the stack and track any changes with an version control system such as git.
CloudFormation can handle most of the services from AWS. Such as S3 buckets, RDS databases and EC2 instances. But when it comes to the EC2 instances there is more to do than to just select instance type and network. The instance needs to be configured to become a useful part of the infrastructure.
When deploying an EC2 instance with CloudFormation it is possible to add UserData. This data can be used to bootstrap the server configuration. To help out even more AWS has provided the cfn-init helper script. This is a sort configuration management tool that can be included in the CloudFormation template.
But in my opinion this is still not powerful enough. And there are already many, very good configuration management systems out there.
One of the configuration management systems that has gained in popularity is Ansible. Ansible has a low learning curve by allowing the use of powerful functions through YAML configuration files, or Playbooks.
Ansible also has some infrastructure management functions. This means that it is possible to move all infrastructure and configuration management from CloudFormation to Ansible. But just as I find CloudFormation too weak in configuration management, I also find Ansible too weak in infrastructure management.
Splitting Infrastructure and Configuration Management
The solution is then to split infrastructure management and configuration management. Let CloudFormation handle the infrastructure and Ansible (or similar) handle the configuration.
A first reaction is most likely ‘Oh, no! Now I have to learn 2 different tools!’, but hear me out. There are advantages to having infrastructure and configuration loosely coupled.
- Firstly you can choose the tool for the job. You can have CloudFormation or Terraform or something else for infrastructure. And Ansible or Puppet or Chef or even multiple systems if different teams prefer different tools.
- And because the infrastructure and configuration is split, they can be housed in different repositories and developed independently. This makes it easier and faster to develop the stack.
Here is a simple example of a CloudFormation stack that depends on an Ansible playbook. It uses an WordPress/Nginx playbook from https://github.com/ansible/ansible-examples. The repo or playbook can easily be swapped for something else.
Do you need help setting up your infrastructure? We can help you with AWS and Ansible!