Hello! Welcome to Infrastructure as Code technologies! Now that you have an idea of what infrastructure as code is, let’s take a look at some of the more common infrastructure as code tools and technologies.

Terraform is an IaC tool that allows you to provision infrastructure as code. What you do with Terraform is you describe your infrastructure as code. Execution plans are then created. These plans outline what will happen when your code runs. It actually builds a graph of your resources and automates changes. This results in far less manual intervention and fewer errors.

Terraform uses its own domain-specific language (DSL) called Hashicorp Configuration Language (HCL). HCL is JSON-compatible and is used to create these configuration files that describe the infrastructure resources to be deployed.

Azure Resource Manager is another IaC tool. Using Azure Resource Manager, you can define your infrastructure and necessary app dependencies in templates that can be re-used. You can also group interdependent resources so they can be deployed or deleted in a single action. Azure resource manager also allows you to manage access to resources through user permissioning.

Chef is one of the more popular tools in the IaC space. It’s used in the continuous integration and delivery processes by many organizations. 

With Chef, what you do is create “recipes” and “cookbooks” using its Ruby-based language. Recipes and cookbooks are the actual terms that are used. They are used to specify the steps that are needed to achieve a desired configuration of applications on existing servers. Chef allows you to take a “procedural” approach to configuration management, because what you do, essentially, is describe a specific procedure that is necessary to produce a desired state.

Like Terraform, Chef is cloud-agnostic. This means you can use it with many different cloud service providers, including AWS, Azure, GCP, and others.

Puppet is another popular configuration management tool that is similar to Chef. It’s typically used, to continuously deliver software. Like Chef, puppet uses a Ruby-based domain specific language. With puppet, you define your infrastructures desired end state and what you want it to do. Puppet automatically enforces this desired end state and automatically fixes incorrect changes that have been identified.

Unlike Chef, which takes a procedural approach to configuration management, puppet takes a declarative approach. This means that you declare what your configuration should look like and puppet figures out how to make that happen. Another difference between chef and puppet is the target audience. While Chef is intended mainly for developers, puppet was designed with system administrators in mind.

Like Chef, Puppet integrates with many different cloud providers, including AWS, Azure, Google Cloud, and even VMware.

Saltstack is an IaC tool that takes a different approach than tools like Chef and Puppet. Instead of taking the “infrastructure as code” approach, Saltstack takes an “infrastructure as data” approach.

This means that the declarative configuration patterns in Saltstack, which are written in Python, are language-agnostic. This makes them easier to read and understand.

One other thing I want to point out about Saltstack is the fact that it supports remote execution of commands. This differs from solutions like Chef and Puppet, because the configuration code for those solutions needs to be pulled from their servers.

Ansible is another player in the infrastructure as code space. It’s actually an infrastructure automation tool from Red Hat. This IaC tool is used to model your infrastructure. You do this by describing the relationships between your components and systems, rather than by managing each system independently.

Ansible code is written in YAML. When you use Ansible, you define Ansible Playbooks. These playbooks produce easily understood configurations that are easy to deploy.

I should also mention that Ansible doesn’t require any agents.

Another entrant in the IaC space is Docker. Using Docker, you can create containers that are used to package your code and dependencies together. By packaging things together in containers, you can run your applications in virtually any environment.

The configuration files used in Docker are called Dockerfiles, and they are created using YAML. Dockerfiles are essentially blueprints that are used to build your container images. Your container images include all the components that you need to run a piece of software. These components include things like code, runtime, system tools and libraries, and settings.

Organizations that leverage hybrid clouds and even multi-cloud environments will often turn to Docker because of the portability it offers for applications. This portability allows these organizations to run their apps in whatever environments they are leveraging.

Other IaC tools and technologies include offerings like JuJu, Vagrant, Pallet, (R)?ex, CFEngine, and a few others.

JuJu, for example, is from Canonical, which is the same company that brought us Ubuntu. This tool uses “charms” and “bundles”. Charms are really just sets of scripts that are used to deploy and operate software. Bundles are collections of charms that are linked together. You use these bundles to deploy entire app infrastructures in one fell swoop.

Vagrant is an another IaC tool. It comes from the same company that makes Terraform. While most other IaC tools focus on building large infrastructures, Vagrant focuses more on the creation of smaller development environments that run on a small number of virtual machines. You can run Vagrant on top of VMs from VirtualBox, VMware, Azure, and many other cloud providers.

Pallet is used to automate infrastructure in various environments. You can use it to automate infrastructure in the cloud, on server racks, and even on virtual machines. Pallet can stop and start nodes, it can configure nodes, and it can be used to deploy projects. It can even be used to run administrative tasks.

Written in Clojure, Pallet runs in a Java Virtual Machine. Although it works with things like AWS, OpenStack, and VirtualBox, it does NOT work with Azure or GCP.

(R)?ex is an open-source infrastructure automation tool. It has its own domain specific language, or DSL, that you use to describe your infrastructure configuration. (R)?ex is agentless and uses SSH to execute commands and manage remote hosts. 

Released in 1993, CFEngine is possibly the oldest IaC tool available today. You use CFEngine and its DSL to define the desired state of your infrastructure. The CFEngine agents will then monitor your environment to ensure it remains in its desired state.

So, as you can see, there are quite a few tools available to you. Your requirements will dictate which tool or tools that you will need to leverage.