Ansible Container: Playbooks as the Sole Build and Management Tool
Red Hat-owned IT automation software provider Ansible continues to focus on expanding its portfolio of management tools for building and deploying containers, both with Docker containers and without.
Ansible version 2.1, released last May, added the Docker plugin, as well as a module that enables Ansible’s YAML automation scripts or “playbooks” to include Docker Compose-style syntax. That allow much of the work that had been done manually to orchestrate containers to be repurposed toward automating the entire IT infrastructure.
It also launched Kubernetes modules, which allow the creation of Kubernetes templates directly from an Ansible playbook. And it extended automation to include network infrastructure, enabling users to manage Docker machine environments and automate their network layers simultaneously.
This work has since evolved into Ansible Container, an open source project for building Docker images and orchestrating containers using only Ansible playbooks.
The project’s goal is to enable people to use and reuse Ansible content to build containers instead of just VMs, according to Greg DeKoenigsberg, director of the Ansible Community at Red Hat, which bought the automation technology company in 2015.
“A lot of people use Ansible roles to define things their systems might do: web server roles, database roles. And we had the idea that an Ansible role overlaps with the idea of a microservice, so it seemed like a good idea to turn those roles into containers and take those containers and move them around in an Ansible-y way,” he said.
Modules in Ansible have allowed users to manipulate Docker itself and other tools. The difference here, he says, is it provides the ability to do all this in a single tool where you can actually manipulate the inside of containers, save those containers to a registry, then publish those containers and do actual container management.
“They were community tools before, and we brought some of those tools and ideas together into a more opinionated project about how we think you should do those things with Ansible,” he said.
As an example, he said, they would start up a container, then put SSH into the container so they could use Ansible to manage it. The Docker Connection plugin was the piece that made it possible not to have to put SSH into the container to use Ansible. You just write a playbook to connect.
The Marketing Layer
While Ansible Container enables you to build Docker images and orchestrate containers using only Ansible playbooks, it doesn’t use Dockerfile.
Explained DeKoenigsberg: “Dockerfiles are basically shell script. And one of the reasons we wrote Ansible in the first place is that shell script gets pretty ugly pretty fast. Ansible is the main definition language that goes into the containers themselves. Those containers are Docker underneath by default. We just need to decide what other engines we need to support.
“At the deployment phase, we also have a mechanism to build Kubernetes and OpenShift artifacts out of the Ansible description files so you can roll right into an OpenShift and Kubernetes deployment. It helps automate all the way from the build to the deployment process.”
The project’s goal is not to replace Docker altogether, he said. OpenShift is Red Hat’s supported edition of Kubernetes, a container orchestration engine.
“Ansible assumes you have Docker today, but we built Ansible to be pluggable, so if one day someone wants to use some of the Open Container Initiative pieces, we just need to build the bits behind the scenes to do that,” he said.
In a more overt move away from Docker, Red Hat engineers are among those behind another project, called simply OCID (OCI daemon) to enable Kubernetes — not Docker — to launch and manage containers at scale. Red Hat makes no bones about its backing for Kubernetes rather than the orchestration in Docker Swarm.
DevOps market analyst Chris Riley said he sees term “Ansible Container” as “a marketing thing,” but not Red Hat actually taking on Docker.
“What Red Hat is doing, I see as a toe in the water: ‘What would it look like if we had our own container technology?’ he said.
That makes sense when you own the OS, but he expects initiatives around, for example, CloudForms, to be more fruitful.
“In my opinion if someone is going to take on containers, it’s going to be Azure, AWS, or Google, or someone who usurps it with serverless code.”
