Here at Ansible, we recently announced a new project called Ansible Container. Its purpose is to allow users to build, deploy, and orchestrate containers at scale, all from Ansible playbooks.
It’s still a young project, barely a month old at this point -- but we’re excited by it, and we think it has a great deal of potential. Here are five reasons why.
1. Because our community has been using Ansible to manage containers for quite a while now.
Ansible has been successful, in large part, by following where our community leads, and our community has been using Ansible to help manage containers for nearly as long as Ansible has been around. Our community wrote the original Docker module in October 2013, and that module and other container modules have been among the most frequently used Ansible modules ever since. There are hundreds of community-maintained Ansible container images in Dockerhub, and there are excellent blog posts in which Ansible community members describe their own best practices for building and deploying containers. The next logical step was to start a project to bring together some of these best practices into tools that anyone could use.
2. Because the new Docker connection plug-in makes it far simpler to run Ansible against a Docker container.
Before Ansible 2.1, it was a little bit tricky to run Ansible commands inside of a Docker container, because most containers don’t run ssh. Users would even run ssh inside of Docker containers just so that they could use Ansible to manage it -- but since running ssh inside of a container isn’t exactly encouraged, that wasn’t a great option.
In Ansible 2.1, we released the Docker connection plugin, making it possible to run the same playbook against a physical machine or a virtual machine or a Docker container, simply by changing the play’s connection type. That was a big step forward, and unlocked new possibilities.
3. Because shell scripts aren’t good enough.
As we say in the project’s README file:
“A Dockerfile is not much more than a script with hand-crafted shell commands. We're well past the point where we should be managing build processes with manually maintained series of shell scripts. That's why we wrote Ansible in the first place, and it’s just as applicable to containers.”
Ansible playbooks are designed to be reusable across many different environments. Bringing that power and flexibility to the container build process makes sense to our users.
4. Because Ansible can be a great bridge to larger-scale container orchestration.
Containers are useful because they provide consistent development environments, and that’s why developers love them. But describing a container stack in a way that can be orchestrated equally well in development environments and production environments continues to be challenging.
The key is to describe and encapsulate the differences between different environments. The format of Ansible Container allows users to describe, in unambiguous terms, the differences between development and production environments -- which will, in turn, allow the Ansible Container “shipit” command to deploy directly to those environments.
5. Because we believe that communities make the best software.
Ansible Container is a very new project, and it’s moving very quickly -- but key pieces already work, and more pieces of it work every day. We believe in the philosophy “release early, release often,” because that philosophy is how Ansible was built from the very beginning.
Now it’s time to put Ansible Container into the hands of users, so that we can figure out what we got right, what we got wrong, and how we can improve it together to make it useful to as many people as possible. Try it now. Tell us what works and what doesn’t work, and help us make it awesome.