As we promised before, our article series inspired by V-day is continuing.
Those who are provisioning servers day by day, certainly have some doubts about their process: being time-consuming, non-repeatable, hard to test or simply just something is going wrong in the existing infrastructure during the provisioning. There are opportunities to test failover or rollback processes, but…
Through the years, a lot of providers have elaborated their own processes and solutions in order to accelerate deployment cycles. So-called provisioning scripts are everywhere, and helped with the well-known configuration management tools may have done a good service a few years ago. Things have changed since then, disadvantages of that approach came to light, it's necessary to keep some principles in mind in order to avoid a lot of other issues still coming into our every-day work.
Given a set of operations that make changes on the target infrastructure. As this well-known concept from maths says, if operations remain the same, target infrastructure have to be transformed to the same state regardless the starting state.
Infrastructure as code is like software development in many aspects. In software development, reusable code is a key. Keep components of your infrastructure definition simple, consistent, modular, small and parametrizable. Choose your configurable data and abstraction level wisely. Scripts with thousands of lines are often more brittle. Lay the basics of a consequent naming convention.
To develop something in a declarative way means that you want to describe what you want to achieve, not algorithms on how you want it. IaC does not have to contain conditional statements. In this article, Yevgeniy Brikman from Gruntwork provides you a real use case about the downsides of imperative approach (under section Procedural vs Declarative).
When defining network topology - how many servers and other resources you need, in which locations - an IaC tool like Terraform (or Cloudformation for AWS specific infrastructure) fits better to your goals than Ansible and friends. However, with some configuration management tools you can also create resources, but essentially they are for installing, configuring, maybe fine-tuning something in the provisioned resources, not for the idempotent operations. Use both approaches, but in the proper role.
At the time of writing, Terraform seems to be widely adopted despite of its version number (0.11.1 at the time of writing). Needless to say, looking at the changelog and issue list on GitHub is very important. At Virtualization & DevOps Day 2017 I’ve heard a horror story about a perished Aurora Cluster destroyed by a Terraform bug.
In case of AWS-specific infrastructure, Cloudformation can be an alternative. It’s maybe simpler than Terraform, but as I stated, it supports only AWS services. In case of interacting with a lot of non-AWS providers e.g. with Cloudflare, Terraform, may be a better choice.
As I mentioned earlier, describe your infrastructure as you would develop a software. The guide above helps only if your team accepts them. KitchenCI with the supported testing frameworks may do a good job in infrastructure testing and makes the infrastructure provisioning lifecycle complete.
