Infrastructure as Code (IAC) in DevOps Pipelines

This blog post is a chapter from the eBook From Admin to DevOps: The No-BS Way to DevOps in Azure. Be sure to check it out if you’d like to dive deep into what it takes to succeed at DevOps in Microsoft Azure by learning Infrastructure as a Code.

If you’ve ever created kind of cloud or virtual infrastructure on-prem manually, you’d know there’s either a lot of clicking or a lot of typing going on. Infrastructure as Code (Iac) takes care of that.

To provision anything in requires remembering which screen to go to or what command to run. If you’re just playing around trying to learn Azure that’s fine but once that playing turns into business-critical, production processes where time is money, something has to change.

Once your organization starts to get serious about provisioning and managing infrastructure, you’re going to face a lot of new challenges.

You’ll encounter unnecessary duplication of work, repeated cases of fat-finger syndrome, change management issues, configuration drift, and more. The larger the organization and team, the larger the problems. All of these issues can be eliminated or, at least, mitigated with a concept called Infrastructure as Code (IaC).

Infrastructure as Code (IaC): By Example

IaC is an industry term that refers to storing all of the stuff required to build infrastructure components in code. That code is typically defined in JSON or YAML files representing what your infrastructure should look like.

Once all components are defined in a structured file, another process comes along, understands the code and immediately begins using that document as instructions to build the infrastructure.

To provide a generic, pseudocode-like example, perhaps you have a VM to create. That VM has needs like compute, storage and networking. A rough IaC approach would be to describe the VM and all of its components in a template.

The Template

In the following code snippet, you can see an example of how each component is broken down by a hierarchy with attributes defined about each component. This fictional example was created in a JSON file most services would call a template.

{
	"VM": {
        "Name": "MYVM",
        "Disk": {
            "Size": "100GB"
        },
        "Networking": {
            "IPAddress" : "10.0.0.1"
        }
    }
}

This template defines the VM and all of the attributes associated with that VM. It has a specific schema that template authors adhere to define what that VM looks like. Suppose this template is then saved to a file called myvm.json.

Source Control

You now have everything that makes up a VM saved in a single file. Like any good DevOps professional, you check that file in source control. You now have a way of tracking changes to the file.

The Tool

Now that the file is created, you need a tool or service to read that file that understands what you’re trying to build. That tool uses the template as input and builds the VM to those exact specifications with no other interaction.

> [some command line tool] -File myvm.json

Good deal, right? That’s not all.

Fighting Configuration Drift

Now suppose you need to change the static IP address assigned to that VM’s NIC. You could RDP to the VM and change the IP but you don’t want to do that. Why?

1. You’re making the change manually which wastes time and is prone to human error.
2. There’s no audit trail of who changed the IP and when.
3. There’s no automated way to revert the change should you fat-finger the IP address.

Infrastructure as Code (IaC) can alleviate all of the above challenges. With, literally, a few keystrokes, you could make that change in a way your manager and auditor will love you for.

Open up myvm.json, change the IPAddress attribute, commit the change to source control and run the tool again. Done.

{
	"VM": {
        "Name": "MYVM",
        "Disk": {
            "Size": "100GB"
        },
        "Networking": {
            "IPAddress" : "10.0.0.2"
        }
    }
}

> [some command line tool] -File myvm.json

The tool will be smart enough to know what needs to change. It won’t detach the NIC or rebuild the entire VM. All IaC tools and services are smart enough to understand how to make the change. Magic!

But now you’ve just realized you used the wrong IP and need to revert back. No problem. Revert the change in source control, commit, run the tool and you’re back in business.

But wait, there’s more.

The Beginnings of Continuous Delivery

When you have infrastructure stored in templates under source control, you have a set of ingredients for the start of an automated release or continuous delivery pipeline.

Recall that you had to run that tool every time you changed the template. In an automated pipeline/workflow, that tool runs automatically. Once the process to create or make the change to the environment is automated, the moment you commit a change to the template, the infrastructure matches.

Build enough templates and eventually, your entire infrastructure could be represented in code or as code.

Conclusion

IaC is a DevOps methodology that allows operations to take a play from the software developer’s playbook. IaC brings about many advantages a software developer has been leveraging for years and puts those into the system administrator’s hands.