How to Automate Infrastructure Provisioning: A Step-by-Step Guide

To automate infrastructure provisioning, describe the setup you want in files and keep them in version control. Then review every change, hold the record of what exists in one shared place, and apply changes from a pipeline. This guide gives nine steps in that order, as well as the set-up mistake to avoid at each.

Infrastructure as code means describing servers, networks and storage in files that a tool applies, instead of clicking through a console. A cloud provider’s prescriptive guidance, Example: Automating system provisioning, defines it as using code and software development techniques, such as version control and continuous integration, to provision and manage infrastructure. The readers in mind plan this work and hand it to a team, such as an IT manager, infrastructure lead or CTO in India or the GCC. It covers the order of work and the set-up mistakes, but it leaves out why building by hand hurts, scored reviews and tool choice. Signisys delivers this work, and you can read how Signisys builds environments from code.

How Do You Automate Infrastructure Provisioning, Step by Step?

You do it in nine steps that build on each other, and the first target should be one small environment instead of the whole estate. The order is:

Each step has an owner. We recommend one person who owns the files and a second person who reviews every change, with a named approver for the pipeline. Leaders can also use that split to ask who does what at each step. This guide does not cover tool choice. To pick the tool, work through four questions that narrow the choice of tool. Your own team picks the tool that applies the files.

Step 1: Which Target Should You Pick, and What Setup Do You Want?

Pick one environment for one service, and write the setup you want before any tool opens. A new environment, or one that is due for a rebuild, is a better first target than a system that runs well today.

Before any writing starts, name an owner and a reviewer for the target. Then write the wanted setup in plain words, starting from what the workload needs. The e-book on infrastructure automation explains why each workload’s needs come first, because each workload has requirements that decide where it should run. For example, cover performance, availability, cost, storage, network and security for the one service.

Next, list what exists today for that service, such as servers, networks, storage and who may reach them, so that nothing is missed. In short, the output is a one-page description that the owner, the reviewer and the service team agree. If it is missing, the files in the next step have nothing to check against.

Steps 2 and 3: How Do You Describe the Setup in Files and Keep Them in Version Control?

Step 2 is to write files that state the end result, instead of the clicks that lead to it. Step 3 is to keep every file in version control from the first day.

For Step 2, use one file set per target. Create the setup first, and then configure what runs on it, as two stages. Put repeated patterns, such as a standard server or network, into small reusable parts, and use variables for the values that change. Also write the files so that a second run changes nothing when nothing has changed. That property is called safe to re-run, and it lets the team apply the files again without creating duplicates, for example after a failed run.

For Step 3, keep the files in one place, and add a short message when you save each change. Version control then shows who changed what and when, and it lets the team go back to an earlier version. Also, the live setup should change only through the files. If someone changes the console by hand, the files fall out of date, and the team stops trusting them.

Steps 4 and 5: How Do You Review Changes and Keep the State in One Shared Place?

Step 4 is for a second person to read each change, together with the preview of what it would do, before it applies. Step 5 is to keep the state in one shared, access-controlled store.

For Step 4, the reviewer reads the preview of additions, changes and removals, as well as the files. A removal of storage or a network rule, for example, deserves the closest look. The reviewer says no when the preview shows more than the change was meant to do. We recommend a short rule on who may approve. Specifically, the author does not approve their own change, and production changes go to the named approver. Whether production needs a second approver is a decision for your own change policy, but one named approver is the minimum we recommend.

For Step 5, the state is the tool’s record of what it built, such as servers and networks. Kept on one person’s laptop, it blocks the rest of the team, because no one else can apply a change safely. Keep it in a shared store with locking, which stops two people from writing to it at the same time. Tool documentation says that if anyone can read the state, they can read the sensitive values in it. Limit who may read it. We also recommend backups and encryption at rest. Not every storage option supports locking, and the exact set-up differs by tool, so check your tool’s documentation for it.

Steps 6 and 7: How Do You Automate Infrastructure Provisioning Across Environments?

Step 6 gives each environment its own variables, state and access, from one set of files. Step 7 runs every change through the same pipeline steps.

For Step 6, one set of files serves development, test and production. A separate variable set and state for each environment keep a test change away from production. Separate access also limits who can reach each one. Also keep secrets out of the files and in a managed store that the pipeline reads. Secrets get only this mention, because this guide does not treat them in full. Matching the environments to each other is a separate topic, and it gets one sentence here.

For Step 7, a pipeline is a fixed list of steps that runs the same way each time. It checks the files and previews the change. Before it applies anything, it waits for a named approver, and then it keeps the record. A shared pipeline also connects the tasks of several teams into one run. To automate infrastructure provisioning this way, we recommend that the approver is a person and that the pipeline applies only the change that person approved. We also recommend scoped, short-lived credentials for the pipeline. The builds, tests and releases of application code have their own path, covered in how to build a release pipeline. The glossary entry on what DevOps means also explains the wider practice.

Steps 8 and 9: How Do You Check the Live Setup and Hand Over the Work?

Step 8 compares the live setup with the files on a schedule. Step 9 hands the work over so that no step depends on one person. For why that matters, see what the hand work costs a team and when that cost shows up.

For Step 8, schedule the comparison, and decide before it runs what happens to a difference. Either update the files to match a wanted fix, or restore the live setup to what the files say. In practice, the infrastructure lead owns that decision. If it is left undecided, a difference, also called drift, stays until it causes a fault.

For Step 9, write a short run guide, and give access to a second person. That person should have run a change from start to end. Then name an owner for the files. We recommend treating the handover as complete only when that second person has done a real change without help. The e-book’s authors argue that automation built by each team in isolation limits collaboration across teams. A named owner for the files also gives the work one point of contact. If your team wants to offer this as an internal service, read about running these practices as a platform service for developers.

What Set-Up Mistakes Should You Avoid When You Automate Infrastructure Provisioning?

We recommend avoiding one mistake at each step. The table lists them as a working view from Signisys, but it is not a finding from any study. Each step gets its own guard, such as the ones the rows below show.

Where Can You Start This Week, and When Should You Ask for Help?

Start with Step 1 for one small target. Ask for help when the work spans several accounts or regions, needs strict access rules, or lacks a second person to review. Three actions fit this week:

• Choose one target and name its owner and reviewer.
• Write the one-page description of the wanted setup.
• Put an empty file set in version control and give the reviewer access.

This guide also leaves out why building by hand hurts, scored reviews, tool choice and release pipelines. Use it for the order of work only. Automated infrastructure provisioning is a larger subject than nine steps can cover. If part of your setup is already in files, a nine-check score for a setup that already exists shows what is still missing.

Signisys provides infrastructure automation work, but this guide is written to be followed without it. If you want a specialist to plan the first build with you, read about the code-based infrastructure and configuration automation solution and the DevOps and IT automation services behind it.

How to Automate Infrastructure Provisioning FAQ: Questions Answered