The Ansible Container project is targeting mid-January for its next release, and so we thought now would be a good time to check in and look at the features actively under development and anticipated to ship.
With only a glance at the roadmap page, the casual visitor may think it seems a bit smallish, having only three items. However, the items represent features that are important to the project, and require a level of effort that’s anything but small, as we’ll see.
Building container images
The first item up is an image build cache. Building container images is of course a core function of the tool, and having a caching mechanism can improve the speed at which images are built.
If you’re not familiar with container images and how they’re built, think of an image as a tall building with dozens of floors, where each floor is layered on top of the previous floor, starting with the building’s foundation, and adding one floor or layer at a time until you reach the top. In the same way, a container image is a file system built in layers.
The build process starts with a base image, say Fedora 25, and then adds layers on top of it, with each layer containing a set of changes to the file system. In Docker’s build system, each set of changes is the result of executing a command. For example, executing a run command that calls dnf to install a package results in new files and directories being added to the file system. The new files and directories form a new layer that gets added on top of the stack of layers representing the image.
Because an image is built in layers it’s possible to create a cache of layers and have the process executing commands match a command to a layer. If a match is found, then there’s likely no need to execute the command. The process can simply add the layer to the image, and move to the next command. By skipping commands, the time it takes to rebuild an image can decrease, making it more efficient to iterate on the development of a new image.
Keep in mind that build caches are not perfect. The cache has to not only track the command, but also changes made to the file system. If it looks even a little bit like the command or the potential file system changes do not match to an existing cache layer, the command will have to be executed, and the layer rebuilt. Order is also important, as the layers can depend on one another. Once a command introduces a new layer, all subsequent commands may have to be executed in order to build new layers that incorporate the changes.
Ansible Container builds images by executing an Ansible Playbook against a base image. Today the playbook execution becomes a layer, which is designed to limit the possibility for caching. Each time an image is built, the entire playbook has to be executed. And so the goal is to introduce a build cache that can map portions of the playbook to image layers, and reduce the amount of time it takes to rebuild an image.
The team’s plan is to map plays, roles, and includes (all components of a playbook) to individual layers by developing a custom execution strategy plugin for Ansible. The plugin can insert the steps to create layers, perform cache lookups, and update the cache as a playbook executes. Playbooks can be complex, performing many different actions on the file system, which means creating the execution strategy is no small task.
Support for Docker Compose v2
The next item is adding support for Docker Compose version 2. Integral to defining an application in Ansible Container is the container.yml file. It’s comprised mostly of compose directives, and follows the same YAML structure as a docker-compose.yml file. The team recently added to the project’s documentation site an Ansible Container Compose Specification page to serve as a reference guide to the container.yml file. It details supported directives, including those from version 2, and provides implementation notes, and examples.
The biggest change that comes with the implementation of version 2 is the additional support for named volumes. Both version 1 and version 2 supported the concept of named volumes, but now in version 2 a named volume at the service level must be defined in the top-level volumes section.
In 0.3 Ansible Container is anticipated to accept the top-level volumes directive and map named volumes to Persistent Volume Claims (PVC) in the cloud, making it possible to impact how the PVC is created. For each volume it is anticipated that the user can set a value for Kubernetes and OpenShift PVC attributes including the amount of space to allocate, access modes, the persistent volume to attach to, matching expressions, and meta data.
Support for Docker 1.12 and Docker for Mac
The third item on the road map is adding support for Docker 1.12 and Docker for Mac, the replacement for Docker Toolbox. The team plans to upgrade to version 1.9 of docker-compose and 1.10 of docker-py, the Python modules the project uses to communicate with the Docker API when building images and orchestrating containers. It’s been frustrating telling users they have to downgrade to 1.11, and remain on Docker Toolbox. So far our testing with the upgraded modules and using Docker for Mac during development has been successful.
Team expansion
Aside from features, the team is also adding a new member - Ryan Scott Brown (@ryansb on GitHub). Ryan joined Red Hat’s Ansible team after the acquisition from OpenStack Heat — another YAML-driven orchestration tool — to work on Ansible’s cloud modules. As part of the Ansible core team he's been building Ansible modules for serverless computing platforms like AWS Lambda and helping community members merge their cloud modules faster. Ansible Container is a change of pace, but Ryan’s been using Docker for testing Ansible roles since the dawn of the Docker connection plugin. He's most interested in adding features to make it easier to run complex builds, and adding new targets for `ansible-container shipit`. Welcome aboard, Ryan!
Try Ansible Container
As I mentioned at the start, release 0.3.0 is anticipated to land in mid-January. In the meantime, if you’re interested in getting a closer look at the changes already committed to the new release, visit our installation guide, and follow the Running from Source instructions. Testing help and feedback are always welcome, as well as pull requests. And as always, you can reach out to us by opening an issue, joining the mailing list, or joining the #ansible-container channel on irc.freenode.net.
