Infrastructure as code is a way to maintain infrastructure by automated processes and minimize human effort needed to configure anything from physical baremetals to services running on many virtual hosts. There are 2 ways to do this.
The first way is to have an automating software running on every host and pulling configuration from servers which have all configuration ‘recipes’. The second way is that configuration servers push configuration to host (insecure – configuration server needs to have access to all servers). Both of these ways are used, both have its benefits and disadvantages, however, the first one might be used a bit more. We are also using the first one in most cases.
Other classification could be declarative versus imperative. Declarative means that configuration software knows what the configuration should look like and changes to be the same as declared. Imperative is what needs to be done to have a working host, and the configuration software does it. Most of configuration platforms are declarative.
Popular tools to achieve this goal
There are 4 most used configuration platforms:
| Platform | Push/Pull | Declarative/Imperative |
|---|---|---|
| Puppet | Pull | Only declarative |
| Ansible | Push | Both |
| Chef | Pull | Both |
| Terraform | Push | Only declarative |
We are mostly using puppet so following text will be mostly about this platform.
All of them are similar in usage – there is a written manifest (every platform named it differently – for example, it is named ‘playbook’ in ansible and ‘recipe’ in chef) with the definition of what should be configured and some parameters.
Abilities of Infrastructure as Code
This architecture allows administrators to deploy new hosts which are similar to the existing ones in outstanding time. They can recycle already used code and only rewrite the differences. In case of creating hosts with the same configuration as the existing ones (for example creating new backends in load balanced applications) in specific environment it is not needed to actually code anything.
This architecture also helps a lot in disastrous scenarios when you lose a lot of hosts or need to recreate a lot of them as soon as possible. There is a possibility to create templates for groups which could create many hosts in one batch and they are automatically configured by platforms mentioned before, but that is a topic for another blog post.
Benefits
- Very good deploy time
- Automation
- Transparency of everything
- Code can be stored in version control tools like gitlab
- Easy changes on many hosts
- Faster disaster recovery
- Minimizing chance of human mistake
Disadvantages
- Few more hosts which are needed to make it all work
- Might be a bit more complex to set up
Recapitulation
Having an infrastructure as a code is a great strategy which can save a lot of money to the company, time for administrators and pain to anyone who needs to debug anything in manually set up infrastructure. I warmly recommend to automate as much as possible to anyone who has finished this post.
In the next article we will look deeper into Puppet configuration and its specifics.
The original autor: Jakub, DevOps Engineer, cloudinfrastack
