Plenty of people are aware of and use Ansible to manage systems. Whether you need to provision, configure, deploy, or orchestrate systems, at scales small or large, Ansible makes it simple.
As Ansible Director of Community Greg DeKoenigsberg describes it, Ansible is “basically distributed SSH with some other goodness on top. You describe a list of plays, and Ansible uses them to accomplish tasks you’d otherwise have to do yourself.” DeKoenigsberg teamed up with Matt Micene, solution architect from DLT Solutions, to discuss how Ansible is rapidly moving beyond host management into corralling containers.
Ansible is written in Python, with a small, functional core and a huge variety of modules for almost every imaginable function. DeKoenigsberg showed off some simple examples of Ansible playbooks, which are easy to understand descriptions of tasks. Combine an inventory of systems, variables to distinguish between them, and a set of these Playbooks, and you have a recipe to easily recreate infrastructure on demand.
So Ansible works well to manage the traditional operating system. But what about an OS like Red Hat Enterprise Linux Atomic Host? Some tasks often seen in Playbooks don’t apply. “Mostly,” said Micene, “because we need to reset our fundamental understanding of what the Atomic Host is, versus the general purpose RHEL 7.”
Unlike the traditional RHEL system, Atomic Host features a set of immutable objects as its file system. These are accompanied by special writable areas for system configuration and logging. This immutability makes the Atomic Host excellent for application containers using Docker. Micene was bullish on the future of containers as a more efficient software delivery system: “Docker will do to RPM what RPM did to tarballs.”
However, Micene also cautioned that to take containers to the level of grouping, abstraction, and other enterprise patterns expected at scale, “we need to stop thinking about containers as mini-VMs.” Case in point: Docker container images carry layers, each capturing content change.
Each opportunity for such change, though, also brings risk to an infrastructure at scale, especially where precisely duplicated containers are important. Micene posed an example where, in the middle of building out app containers, some of their source content is updated, such as a Node.js NPM or a Ruby gem. “The more layers you carry around,” Micene said, “the more uncertainty you carry around.”
Fortunately, Ansible also simplifies the orchestration of containers on an Atomic Host OS. Thanks to Ansible’s modular design, the SSH transport used to communicate with hosts can be swapped out for a Docker transport for containers. Rather than trying to resolve hosts via traditional networking, the Docker transport uses the standard docker exec command to identify and connect to the appropriate container.
The most exciting recent development to build on Ansible’s flexibility is Ansible Container. This is a relatively young but quickly maturing project that gathers patterns and best practices for building, configuration, and deployment of containers into an easy-to-use tool. Ansible Container features the simplicity of Ansible Playbooks, without leaving stray Ansible artifacts or excess layers in your container images.
It seems Ansible Container is poised to do for container orchestration what it’s done for traditional IT.
You can find demos from Micene and DeKoenigsberg’s talk showing some of these tools at work on Github. DeKoenigsberg noted due to the framework used for recording the demos, they work on Mozilla Firefox but not on Google Chrome.