Automation and orchestration tools: Difference between revisions
m →Ansible: link |
updating |
||
Line 1: | Line 1: | ||
== 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 "second day" operations on those provisioned resources. | |||
[[Ansible]], now owned by RedHat/IBM, has grown into a full complement of products and services and a full commercial ecosystem. | |||
{| class="wikitable" | |||
|+ | |||
! colspan="4" |Infrastructure as Code Automation | |||
|- | |||
! colspan="2" |Provisioning | |||
! colspan="2" |Management / Operations | |||
|- | |||
!Vendor | |||
!Product | |||
!Vendor | |||
!Product | |||
|- | |||
|Hashicorp | |||
|Terraform | |||
|IBM / RedHat | |||
|Ansible | |||
|- | |||
|AWS | |||
|Cloud Formation | |||
| | |||
| | |||
|- | |||
|Microsoft | |||
|Azure Resource Manager | |||
| | |||
| | |||
|- | |||
|Google Cloud Platform | |||
|Cloud Deployment Manager | |||
| | |||
| | |||
|} | |||
{| class="wikitable" | |||
!Consortium | |||
! | |||
! | |||
|- | |||
|Linux Foundation | |||
|Kubernetes | |||
| | |||
|- | |||
|Linux Foundation | |||
|OpenTofu | |||
|fork of Terraform | |||
|} | |||
== 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. | 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. | ||
Revision as of 23:56, 2 February 2025
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 "second day" operations on those provisioned resources.
Ansible, now owned by RedHat/IBM, has grown into a full complement of products and services and a full commercial ecosystem.
Infrastructure as Code Automation | |||
---|---|---|---|
Provisioning | Management / Operations | ||
Vendor | Product | Vendor | Product |
Hashicorp | Terraform | IBM / RedHat | Ansible |
AWS | Cloud Formation | ||
Microsoft | Azure Resource Manager | ||
Google Cloud Platform | Cloud Deployment Manager |
Consortium | ||
---|---|---|
Linux Foundation | Kubernetes | |
Linux Foundation | OpenTofu | fork of Terraform |
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.