Last updated on 11 November 2020
Infrastructure As Code is a paradigm that consists of describing our infrastructure (servers and their configuration) as code that is understood by automation software like Ansible, Puppet, Terraform, and so on. Automation software can then be used to recreate the infrastructure we described or, more commonly, to fix differences between code current version and the way the infrastructure is now. Which means that, for example, we can upgrade our MariaDB version in the code, run Ansible, and have MariaDB upgraded in the relevant servers.
But what are the benefits of Infrastructure As Code? In this article I will list one of them.
How much time do you need to setup a MariaDB replica? Hint: I bet that your first answer is too optimistic. Consider you need to feed the server, setup replication, maybe a job for backups, monitoring, let proxies know about the new server, find out what the hell you did wrong in a previous step, etc.
Automation software will do it in no more than half minute, plus the time needed to import a backup (I never said it’s magic). When you have to setup or modify several servers, automation is precious. Even with 5-10 servers, it makes the difference between a reasonable activity and a miserable life. With 20 servers, it makes the difference between being able to deploy or not.
Avoiding human mistakes
Depending on which tools we use, the code could describe the configuration we want to have or the steps to reach the result we want. But whichever approach we use, deployments can be tested on staging before applying them to production. The software we use will always apply configuration in the same way. It will not forget a variable and will not mistype a command. Automation is much more reliable than humans, when it comes to repetitive tasks.
Applying a series of commands automatically instead of doing it manually is important, but it’s not all. The commands themselves can also be tested. We can run our automation against staging servers and see the results. We can also automate some tests. For example, an Ansible task can make the whole playbook fail if mysqld is not running when it should.
Think declarative, think idempotent
Automation technologies are, in general, declarative. You describe what you want, you don’t write the steps to reach the goal. For example, you state that a certain directory should exist, and specify its owner, group, and mode, but you don’t write the system commands to make it happen. When you setup a new system, the two approaches are more or less equivalent. But when you modify an existing system, the declarative approach is incredibly simpler. You don’t have to check if the directory exists, who its owner is, and so on. Your code will be shorter, quicker to write, easier to understand.
Idempotent means that you can run the same code twice and obtain exactly the same result. This is very important. You can apply your code again to a production system to update something. You state that mysqld should be running? If it’s not, it will be started. If not, nothing will happen. This avoid a lot of problems.
The code that describes your infrastructure also serves as a form of documentation. If you want to know the Xtrabackup version in your servers, Infrastructure As Code probably allows you to know it by just checking a variable. Even if it’s not so clear because your code is less than optimal, a tool like Ansible allows you to run
xtrabackup --version against a group of servers with a simple command. Once you get used to this way of working, connecting to servers via SSH to check their configuration will appear as a waste of time.
Vettabase highly recommends having proper automation in place for your database infrastructure. We discussed the reasons that seem to us most important reasons.
- Automation saves you plenty of time every day.
- Automation is more reliable than humans.
- Automation makes operations testable.
- You describe your goal, not how to achieve it. You can safely apply your code twice.
- The code serves as documentation.
If you disagree with us, or on the contrary if you have more reason to recommend proper automation, please comment. We’ll be happy to discuss.