At SaltConf19, a session given by Don Vosburg, pre-sales technical specialist and Pablo Suarez Hernandez, senior software engineer, both at SUSE, walked through new functionality in the latest release (Flourine) of Salt, functionality that enables control over target nodes on a network that are managed by the Ansible network automation tool, rather than Salt.

“People are using Ansible out there,” Vosburg quipped. “Whenever you’ve done that kind of [Ansible] infrastructure, you know that effort has already been invested in developing that out and building the playbooks that go along with it. So Ansible projects and playbooks are all over the place.

“There are good sides and bad sides to that, Vosburg said. Among the challenges, he said, is that “Ansible does not really provide any real-time monitoring capability. It doesn’t have the really cool event-driven orchestration that all of us who are salty people know about. And because I don’t have minions and an already pre-defined messaging bus, scalability becomes a challenge.”

Steps to a Salty Ansible Playbook

The speakers outlined several steps that an organization with an Ansible deployment could follow to migrate to a primarily Salt-controlled scenario that could still leverage work done to create and perfect Ansible playbooks.

Hernandez talked through a progression of scenarios: “The idea behind this is, what would happen if we could consider Ansible as a subset of the functionality that Salt is providing you. That’s what the ansiblegate module is doing. It’s a new module which is included in the Salt Flourine version. It will allow you to execute your Ansible modules using Salt. Not only that, but it will allow you to run your playbooks using Salt.” The ansiblegate module was developed by Hernandez and others at SUSE.

Hernandez outlined several steps that an organization can move through in order to migrate Ansible into an overarching Salt deployment.

In the first step, the Ansible control node is loaded with a Salt minion. “Just by doing that,” Hernandez noted, “we are able to manage our Ansible from Salt. Not only that, but we can execute Salt commands using the Ansible inventory that we have on these controllers. All your groupings, your system definition, etc.”

In a further step, one might add more Salt-managed components on the network and add a Salt master. “Now I can run an Ansible playbook,” Hernandez said, “calling Salt from the master to tell the controller to run whatever playbook.” It is also possible to put calls to run Ansible network automation playbooks in Salt state (.SLS) files.

Finally, one can deploy Salt minions to the nodes that previously were only controlled by Ansible, Hernandez said.  “This will enable real-time monitoring (via beaconing) and event-driven orchestration.

“It’s really easy to operate Ansible with Salt,” he said, showing a demo in which he ran an Ansible playbook that ensured that a particular version of a web page was installed on a target system. First he deleted the file from that system, then used Salt to invoke the playbook, causing the file to be reinstalled. After that, the demo was modified to show how installing a minion on the Ansible-controlled node enabled use of the beaconing capability in Salt. In this instance, changing the web file caused the beacon mechanism of Salt to trigger the Salt master to run the Ansible playbook and restore the correct file.

Ben Carner, a Linux engineer at Progrexion who attended the session, said his own work scenario could benefit from the ansiblegate module. “Some of what our Devops department is doing—they know how to do it better in Ansible than in Salt. I like about the new Salt release that it gives me the ability to subsume Ansible into Salt so I can use it. And the stuff that they’ve done in Ansible to deploy their packages and software and I can use, but I can also use orchestration and everything else that Salt can do.

The SaltStack19 conference took place November 18-19, 2019, in Salt Lake City, Utah.