Ansible Container, still in the early stages of development, allows developers to use an Ansible playbook (the language that describes Ansible jobs) to outline how containers should be built; it uses Ansible's stack to deploy those applications as well.
By the (play)book
The big benefit of Ansible Container is a single, consistent methodology -- the Ansible playbook -- for both assembling a Docker container in the dev environment and pushing it to staging or production. Playbooks and roles can be used for both stages, instead of having one toolset -- typically shell scripting -- for assembling containers and another toolset for sending them on their way.
Another boon with its approach, Ansible claims, is it allows for orchestration during the build process. A Django project, for instance, might require a slew of static assets (images, CSS) to be added to the container.
"With Ansible Container, you can compile the static assets in your Django container and then collect them into your static file serving container," Ansible says.
You can go your own way
With Docker images, the build process for containers is typically described by a Dockerfile and built with Docker's toolchain. In theory, the open source nature of the tools and their formats means any kind of build tooling or description file could be used, as long as the result is a valid Docker image. However, Docker's build tools have been the go-to default from the beginning, so their limitations have been easy to overlook.
Ansible wants its toolset to both augment and replace the tools Docker supplies. The appeal for existing Ansible users is clear: If you've already built up a set of playbooks and roles in Ansible that you're comfortable with, you can use those.
But the larger picture is about fulfilling the promise of Docker as an open source/open standard system. Docker has taken a "batteries include but optional" approach, where developers are given everything needed to get going, as well as the ability to swap out any of the pieces at any time. The paradox is that by providing all those pieces, Docker has lessened the incentive to swap them out.
A system like Ansible's provides a way to do that within a framework that's already well known, widely used, and immediately relevant to many.