Infrastructure as Code

Here we had a glance on configuration management, a huge topic on its own and impossible to cover all in one go. Let's quickly look at the principles of Infrastructure as Code (IaC), because both go hand in hand.

Modern IT infrastructure consists of many different areas:

• networking: to connect the various devices through package switching and routing, LAN / WAN, as well as making applications accessible to clients
• storage: provide network disk space through protocols like Fibre channel, iSCSI, NAS / SAN
• compute resources to process data
• server landscapes for user applications and support infrastructure
• applications to cover use cases, allow payments, as well as managing and monitoring the infrastructure

Problem

Traditionally, many if not all of of those areas would require experts each, for instance network and database administrators. Almost always, the technical language those area of expertise would not really be compatible. Thus the people using the various technical languages do often not collaborate very well for that lack of common understanding. Time-constraints often does not allow quick resolution of the various tasks at hand.

Solution

In Infrastructure as Code you work with a base of source code living in a centralized versioned software repository, i.e. git. Primarily it contains your configuration management source code. You also define a CICD pipeline ( i.e. gitlab.ci or Jenkins), which will run various automated system tests, i.e. checking for correct syntax. Once all tests have passed and quality requirements are met, the pipeline deploys the code to your environment.

This way you can collaborate directly in that repository with those various experts we spoke above. For instance, avoid discussing technical aspects in lengthy meetings with your DB administrator. Instead, you rather have him maintain 'his' sections of code, as long as it follows previously agreed standards. You can do peer reviews of the code changes and discuss it online in the project. This way all the aspects of the code changes are available within your software repository. That is assuming you use something like gitlab / github etc., which supports online discussions.

You should define tickets with clear tasks (what to achieve), and acceptance criteria (what and how to deliver). Also set a time frame for delivery. If you happen to work with agile methods like SCRUM or KANBAN, this could be the number of the sprint. This way, all team members can coordinate appropriately without putting themselves top much into constraints.

The CICD pipeline should execute automatically all required testing, once code is committed or a Merge Request(MR) is submitted. This depends heavily on how your team or company is working. Most of the time MR is the more effective way. Since those tests are defined in the same software repository, quality assurance is part of the collaboration scheme.

You also should include a useful README, which explains the details, perhaps also the rules of collaboration etc, unless you have that well defined in a wiki of sorts. In the latter case you still can add links to the wiki space.

How it works

So you have your software repo in place, some code written to define your desired state (see also here) . The CICD pipeline works and tests and deploys your code to your environment (in my example to the puppet catalogue, where Puppet then rolls it out). How does IaC now make a difference?

in the "traditional" world, there will be a sort of handbook (if you are lucky) with plenty of procedures to run through, perhaps screenshots and steps to execute. Most of the time those "run-books" are incomplete, outdated and do not ensure accurate execution. Depending on who executes them, the results are often different. This is a real problem.

What you really need is the following:

• desired state: correct, good and up-to-date documentation about your infrastructure
• automated: no manual steps, regularly executed, fixing issues when found
• independent: no matter "who" executes it, it must be always the same result. typically a service account of sorts
• versioned: trace every change of the source code for their author, date and time of change
• peer reviewed: changes of the code are verified by multiple team members for logical correctness
• tested: code quality, syntax, spelling, linting etc.
• executable: let the tool of choice ( i.e. Puppet, Ansible, Chef etc.) put things into place.

"All you do" is editing your code to contain the desired state, and things fall into place. Well, you still need to have the technical understanding about the requirements for your infrastructure in place, a decent architecture, site reliability plan, maintenance plan etc. But your experts will and can collaborate together in the source code, typically even with simple lightweight text editors, and CICD will do a lot of magic on the testing, while the configuration management tool will keep it all in place.