Good Ansible Support for Azure and GCP

When it comes to Azure, the picture with Ansible is very similar to the support for AWS, with the Azure modules for Ansible even supporting far more as-a-service services in Azure than their counterparts in AWS. Again, a tool exists to query and immediately use an inventory of running instances. As in the AWS example, this tool makes it easier to use Ansible within virtual instances because it has a list of those instances.

Ansible also provides a comprehensive toolkit for manipulating resources in Azure. Starting and stopping instances is no problem, nor is creating and attaching persistent, virtual storage drives. The azure_rm_resource module can even be used to create arbitrary Azure resources directly in Ansible, although the automation tool does cheat a little.

The Ansible function requires a Dictionary Server Protocol (DICT) for the instance with all the required values, which means the whole action could basically be completed with a curl or wget command. However, most of the Azure modules in Ansible do make life easier because they only need a few parameters and figure out the rest autonomously from the respective Azure environment.

Ansible also has a comprehensive feature set for Google's public cloud. The Google Cloud modules, which are also maintained by the community, are roughly on par with the scope of the Azure modules; that is, they are well developed and complete for the most part. All told, Ansible is therefore significantly more versatile than its competitors when it comes to the standard public clouds.

Even More Ansible

At this point, I have to mentioned that Ansible supports other public clouds and virtualizers with community modules. OpenStack is also included, with a large feature set, and Ansible lets you work with the Hetzner APIs or Cloudscale in Switzerland, for example. All told, Ansible clearly appeals to other target groups who enjoy making quick progress with the uncomplicated Ansible structure – or at least quicker progress than with Puppet, Chef, or Salt.

Ansible with a GUI and as a comprehensive product also exists in the form of Red Hat's Ansible Tower (Figure 2), which uses exactly the same modules under the hood that were highlighted earlier but comes with more tinsel. A free version of Ansible Tower is also available as AWX. Of course, Red Hat also offers Tower for various cloud platforms. The tool competes with products like Puppet Enterprise or SaltStack on AWS.

Figure 2: Ansible Tower and its free variant AWX use Ansible community modules to offer the best possible support for public clouds.

All told, Ansible is the most straightforward automator, with a great deal of cloud functionality and a feature set that clearly exceeds that of the other applications.

Getting Complicated with Salt

Whereas Ansible relies on simple commands and simple syntax, Salt comes with a server-agent architecture and uses Python internally, so there is no question of the syntax being simple. If you want to develop modules for Salt or understand existing modules, you must have Python skills.

Like the other solutions, Salt also has a shell application named SaltStack, which comes with its own GUI and offers more than just plain vanilla automation. Of greater interest for this article, however, is the cloud functionality, and SaltStack ends up just behind Ansible in this race. VMware acquired SaltStack in 2020 (when it was still part of Dell) to expand its own cloud automation portfolio significantly. That strategy has obviously worked, because Salt is versatile.

Although the terms Salt and SaltStack are often used as synonyms, they are not the same thing. SaltStack is a kind of counterpart to Chef Automate, Ansible Tower, or Puppet Enterprise and includes more than just automation; however, SaltStack is no longer available as a pre-packaged bundle on AWS.