With Ansible Update, Docker Compose Files Can Configure Networks – InApps 2022

If you’re deploying containers at very large scale, there’s a very good chance that you use a variety of automation tools simultaneously.  Docker has its own, naturally, and its scripts are almost delightfully straightforward and easy for the mind to digest. But it doesn’t really matter how simple the composition may be; if you’re using two or more conductors, you may get into more trouble orchestrating the conductors than the workloads.

Last March, we asked developers for information about the way containers are being managed and orchestrated within their organizations. We gave them a list of five methods of orchestration and asked them to choose any and all that apply. Some 21 percent of respondents who use containerization in the development stage, but not in production, said they use shell scripts and customizations for the purposes of integrating multiple tools. Maybe coincidentally but maybe not, another 21 percent of respondents said they use configuration management (CM) tools, such as Chef, Ansible, and Puppet.

When containers move to the production phase, however, the numbers diminish more acutely for CM. Only 10 percent of respondents whose organizations use containers in production utilize CM tools, compared to 16 percent of respondents comfortable with rolling their own scripts.

That’s a gap that Red Hat is looking to fill.

Wednesday, just seven months after acquiring Ansible, Red Hat is formalizing major changes to the Ansible automation platform. For version 2.1, the company is adding a module that enables Ansible’s YAML automation scripts (“playbooks”) to include Docker Compose-style syntax. This way, much of the work that DevOps specialists have been devoting to manually orchestrating containers — a process that one scientific workflow developer on Reddit described as “finagling” — can be repurposed towards automation of the entire IT infrastructure.

That level of automation, starting with Ansible 2.1, will also include network infrastructure.

New Task, Same Playbook

“Both the docker-compose file and the Ansible playbook are YAML files, and the syntax is nearly identical,” wrote Greg DeKoenigsberg, Ansible’s vice president for community, in a blog post Wednesday, pointing out that both script interpreters are also written in Python.  “The key difference is that docker-compose can only do one thing: manage Docker containers. Ansible can do that too, and it can also do everything else that Ansible does, all in the same playbook.”

A complete overhaul of Ansible’s existing Docker support modules, Red Hat said Wednesday, will let Ansible consume Docker Compose scripts, essentially as though they were Ansible playbooks. At the same time, Ansible will maintain support for applications that utilize multiple containers simultaneously.

“Just call the docker_service module from any Ansible playbook,” wrote DeKoenigsberg, “and specify either an external docker-compose file or put the docker-compose syntax directly into the Ansible playbook itself.”

Here is where the network automation feature could change the picture for Docker users. Back in February, Red Hat announced its intention to integrate not just network configuration but automation into Ansible and introduced a preview of the feature in version 2.0.

While network automation in some form has already existed in Ansible (networking consultant Jason Edelman has demonstrated it since at least 2014, and wrote an extensive report on the subject for O’Reilly last March), version 2.1 now officially adds network modules that make it easier for playbooks to contact network devices directly.

Specifically, the devices Ansible 2.1 supports belong to these platforms: Arista EOS; Cisco IOS, IOS-XR, and NXOS; Cumulus Networks; HPE OpenSwitch, and Juniper Junos.

Ansible Senior Principal Engineer Peter Sprygada demonstrated the new methods in a recent company webinar. The demo showed how a DevOps professional would effectively orchestrate workloads using the actual, physical infrastructure that a data center actually owns, not a virtualized or decoupled overlay on top of that infrastructure.

What emerged from that demo could be a glimmer of hope for many DevOps professionals and developers that networks need not be reinvented just for the sake of applications — that containerization at scale can be feasible with the networks that data centers already operate.

Imperatives vs. the Desired State

The arguments against this methodology have already been written, however. First, there’s the obvious point that any automation script written for a company’s own network devices becomes effectively “married” to those devices, and ceases to be portable.

Software Defined Network (SDN) proponents, particularly of the Network Functions Virtualization (NFV) variety, have stated this type of decoupling is vitally necessary to make workloads scalable, and some have made effective arguments that explicit automation would render microservices impossible at scale.

Cloud-based CI/CD platform provider Shippable has argued that configurations should be as flexible as the networks themselves; and since SDN, by definition, makes networks flexible by design, a more desirable configuration system for the containerization era would enable DevOps to specify desired state.

Ansible would counter these arguments by pointing out that it, too, is a desired state system. As its documentation reads, “It should not be necessary to test that services are started, packages are installed, or other such things. Ansible is the system that will ensure these things are declaratively true.  Instead, assert these things in your playbooks.”

This is actually a matter of considerable argument, with opponents of Ansible’s assertion arguing that Ansible is actually an imperative system because it implements sequences of instructions, although with room for a conditional test first; and others saying that Ansible is a little of both, or a “hybrid,” because it isn’t completely abstract.

The debate has not had much significance outside of shouting matches at open source conferences, until today. If Ansible truly intends to automate real, physical network infrastructure to the extent that it becomes applicable for multi-container workloads at large scale without the use of network overlays like Weave or Flannel, then it had better be a declarative system like its new parent company says it is.   An imperative automation model will be wholly ineffective at orchestrating workloads on a network layer that’s about as firm and immutable as a certain candidate’s position on resolving the national debt.

Docker Compose, wrote Ansible’s DeKoenigsberg, is “a good tool for users who can safely rely upon a completely Docker-centric view of the world. But most users don’t live in that world — and docker-compose is not designed to solve non-Docker orchestration problems.  That’s where Ansible comes in.”

Docker is a sponsor of InApps.

Feature image: Telephone switchboard operator, circa 1975, by Joseph A. Carr, licensed through Creative Commons.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.