Automation and orchestration tools
2025 Update
Today, there are two broad classifications of computer systems Automation and Orchestration - those that fall under the Kubernetes realm and those that can be classified as major cloud vendor's products. Of course there is crossover among them. Another way to broadly distinguish between the various automation solutions is whether they are primarily concerned with provisioning resources, or applications and operations. In this sense, HashiCorp's Terraform is the classic tool for provisioning cloud resources, while Ansible is the tool for provisioning applications and managing "Day 2" operations like security, configuration, and software updates on those provisioned resources.
Ansible, now owned by RedHat/IBM, has grown into a full complement of products and services (now called Ansible Automation Platform) and a full commercial ecosystem that span operations and automation across all the enterprise domains of Networking, Security, Service Managemnt, IT Infrastructure, Software Development, DevOps, Storage, Edge and Hybrid Cloud.
| Infrastructure as Code Automation | |||
|---|---|---|---|
| Provisioning | Config Mgmt / Operations | ||
| Vendor | Product | Vendor | Product |
| Hashicorp | Terraform | IBM / RedHat | Ansible |
| AWS | Cloud Formation | ||
| Microsoft | Azure Resource Manager | ||
| Google Cloud Platform | Cloud Deployment Manager | ||
| Docker | Docker | ||
| Oracle | OCI | ||
| Consortium | ||
|---|---|---|
| Linux Foundation | Kubernetes | |
| Linux Foundation | OpenTofu | fork of Terraform |
One thing Red Hat did was launch a Red Hat Ansible Certified Content Collection for Terraform. This Red Hat-supported collection automates the management and provisioning of IaC using Terraform in an Ansible Automation Platform execution enviornment. You can find that in Ansible Galaxy at https://galaxy.ansible.com/ui/repo/published/cloud/terraform/docs/ or on GitHub at https://github.com/ansible-collections/cloud.terraform (Red Hat customers can find it in the Ansible Automation Hub)
One gripe I have about Terraform is that you need to use HashiCorp Configuration Language (HCL) whereas Ansible is run by standard Yaml. One clear distinction between the two is that while Terraform is declarative and immutable, Ansible is imperative and allows the flexibility to be mutable so that you can change complex infrastructure without needed to fully destroy and re-build it. They work well together in your toolbox because you can call Terraform (and other declarative / immutable IaC tools like AWS CloudFormation) from your Ansible execution environment.
Sources
2016
We surveyed many automation and orchestration tools to get a sense for which tool was the most widely adopted or recent and powerful with a combination of good community and support.
Vagrant
Vagrant is not the same tool as Ansbile. It started life as a wrapper around VirtualBox and although it now supports other providers for virtualization (ie. cloud providers), it's still just a tool for quickly spinning up environments. Although Vagrant can be used to modify or manage the minutiae of the environment, configs of individual applications, Vagrant typically hands this off to ruby or some other scripting. Vagrant is good at serving as a platform for local development environments because you can spin up a local machine with a Vagrantfile assuming you have VirtualBox installed.
Vagrant is more closely aligned with older provisioners like Chef and enterprise providers like VMWare and AWS. I don't want either old provisioners (yes you can use Ansible as a provisioner); nor do I want (only) expensive enterprise providers. Another limitation of Vagrant to serve as the 'only' orchestration tool is that you can't deploy a single machine to multiple providers. In other words, it's difficult to provision to both 'localhost' and into the cloud with the same Vagrantfile.
Ansible
Ansible turns out to be an excellent choice for automation of DevOps
Public users of Ansible include/included Twitter, eBay, Rackspace, Electronic Arts, Atlassian, Evernote, NASA, Red Hat, Splunk, Go Pro, Care.com, edX (Stanford/MIT/etc), Carnegie Mellon, Harvard University, Industrial Light & Magic, Riot Games, and others.
They are trying hard to sell Ansible Tower and the video is actually disturbing: "all your infrastructure is point and click" - yeah, right. Just what I don't want is to have to assign various permissions to allow PHB to click through infrastructure.
Using Ansible, there is a script called digital_ocean.py in /contrib/inventory that does dynamic inventory. When you install Ansible locally using git clone, you'll have this script on your local system.
BUG: For whatever reason, the script can't see my local installation of dopy, but works just fine on my DO host.
JuJu
I don't want to use a Juju charms approach to virtualization because the simplicity is actually a misfeature, but their install script is one more example of things to make sure are in the QualityBox playbook. Note how they use the packaged mediawiki which is not what I want at all... I want a specific release (probably HEAD or a named release version)
Docker
With Docker as the provider in Vagrant, you do not need a 'base box'. However, I'm not sure that I want to use Docker as a solution because one of the main points that I want to ensure is that the resulting environment should look as 'normal' as possible (e.g. mediawiki is installed in /var/www/example.com/_site/w)
Cobbler
Michael DeHaan originally wrote Cobbler, then worked at Puppet Labs (to bring Cobbler and Puppet more in line), and finally started and led the Ansible project, until it was bought by RedHat. The Cobbler project is now led by James Cammarata, who works for Ansible, Inc. In short, you can use both, but Cobbler is not 'better' than Ansible. Ansible literally grew out of Cobbler's early roots.
