Are Docker Users Migrating to Ansible and Away from Puppet and Chef?
Docker is a natural addition to the DevOps tooling movement, occupying mindshare with orchestration technologies like Chef and Puppet. Visit the the Docker registry and search for “Chef” images: at the time of this writing, there were 80 repositories created by 57 users. Searching for “Puppet” yields almost as many: 57 repositories uploaded by 41 users. The investment community believes in the long term potential of these technologies, with VCs investment of over $85 million into Puppet Labs (with a recent $40 million investment in June) and almost $65 million into Chef (formerly OpsCode).
There is another popular orchestration tool: Ansible. The Ansible automation technology is different from Chef and Puppet. It operates strictly over SSH and requires no server side daemon process. Ansible as a technology does not have the massive backing behind it that these other companies do (Ansible has raised only $6 million raised so far). But, according to research I did for The New Stack, within DevOps toolsets, Ansible is the preferred tool for Docker contributors. This is arguably a much stronger indicator of future success and relevance to Docker users than the numbers we pulled from the Docker registry.
The New Stack Analysis of the Docker Community
I started analyzing the Docker repository hosted on GitHub with the following questions in mind:
- What other repositories are Docker contributors interested in?
- Who are the Docker contributors?
This article details the most interesting answer to the first question: what other things are Docker contributors interested in? Another article in the series attempts to answer the second question.
Interests?
To answer the first question, we looked at the contributors to the Docker repository. Being a contributor makes you a special person in the Docker community. Contributing code into a project as popular as Docker takes deep technical knowledge, but also requires persistence and adherence to process. A change is submitted as a pull request, which then is reviewed, commented upon, might be accepted, but could also be rejected, restarting the entire process. Commits must not break the test suite. Alignment with the core design principles (which might not be clearly stated or as static as stated) can be tricky when contribution happens in an open source project managed by a startup. Finally, with all the activity and hype around Docker, getting a commit accepted still requires some clout and recognition within the community, and building this trust right now is more challenging within a dynamic and fast growing community like Docker. There are many barriers to getting a code contribution into a project like Docker; the people who have managed to make a contribution are a rare breed.
We looked at these contributors to the Docker repository, and asked: what else are these coders working on? One way to look at this is to pull a list of all the other repositories they have worked on, and look to see if there are commonalities between them. Commonalities can indicate that two developers are making contributions to the same central repository if both the repositories are “forks” of the same source repository. To make a contribution to a repository on GitHub, you “fork” the repository, creating a new repository with the same name inside your account. This new repository is a derivative of the original repository and ties back to it. Once your changes are complete and added to your repository, you can merge your changes into the original source repository. We analyzed what these developers were doing in concert by working on the same source repositories.
Ansible and Docker: a Perfect Match?
The most interesting trend we found was related to DevOps tools like Ansible, which was forked 26 times. We verified that at least 23 of these developers had made a contribution back into the Ansible repository. In comparison, there were eight developers with forks of the Chef repository; and Puppet did not make our Top 15 list of shared forks. We also looked at stargazers: 27 developers from within the Docker contributor list “starred” Ansible, five starred the Chef repository and there were 14 people from the Docker contributor list who starred Puppet.
None of this is particularly surprising when you look at the GitHub stargazer counts for each of the repositories containing the code for these technologies. The Ansible repository has 6,612 people “starring” it (the equivalent of a bookmark). For Chef, there are only 2,798 stargazers, while the Puppet repository has 2,320 stargazers.
Joining all this data from the Docker repository tells us that, for Docker power users, the tastemakers of the DevOps community, Ansible is popular and growing.
Why Ansible?
We wanted to know why Ansible was popular with developers. We asked John Minnihan from ModernRepo.com and he raved about Ansible and Docker together.
Using Ansible to build containers is so fast, easy + reliable that I can’t imagine doing it any other way. This is perhaps a given, but I can’t overstate the value of a process that produces the same results no matter where or when I run it. The highest compliment I can pay to Ansible is that it has simply disappeared into the background – it does its job of orchestrating Docker work so well that it’s become invisible.
Aater Suleman from Flux7 confirmed this with me at DockerCon. He said that he can put a new engineer on Ansible and get results within a few hours. With other DevOps tools onboarding can take days.
We spoke to Chef (formerly OpsCode) about these questions. Colin Campbell from Chef noted that there is an importance difference between the responsibilities Chef performs and those that Ansible provides. He said there are two responsibilities these tools handle: creation of a container and configuration of a container. He said that Ansible does the first well, but not the second. According to Campbell, Chef excels in configuration of containers; for example, credential exchange, which should be kept outside of container images. Ansible uses SSH to orchestrate images, and SSH daemons don’t typically run on containers. The Chef server runs inside the container, and pulls configuration into the container, which according to Campbell is a superior way of handling configuration.
Other Observations: Not Just for Ops People
Another trend of note was that there is a lot of activity from Mac developers: the next most popular repository (beyond Docker itself and the Docker-registry repository) other Docker contributors were contributing to was Homebrew, a Mac OSX package management system. A total of 21 developers out of the 375 we sampled had made contributions to Homebrew. There were 13 forks of boot2docker, the OSX tool for running a Docker host using VirtualBox. Again, this means that this many developers have actively made a code change to these projects; the actual usage of these tools within the Docker community might be an order of magnitude greater.
One of the main promises of Docker is that it helps migrate complex ops tasks into doable tasks for developers. The fact that many alpha developers running OSX are using Docker, and not just operations people running Linux, shows that Docker is solving a pain point for developers.
Python
We also saw a clear preference around Python usage. The docker-py repository (An API client for docker written in Python: 14 forks), the django repository (a web app framework written in Python: 11 forks), and the boto repository (Python interface to Amazon Web Services: 8 forks) were other repositories represented in the Top 15 list of shared forks. It was surprising not to see any Go projects inside the top 15 list, given that Docker is written in Go, but Go is a relatively new language compared to Python and there are many more mature and active projects built on Python than those that are built on Go.
One of the most interesting and difficult trends to quantify was the rate of change within the Docker community. When we started doing this analysis back in April, the number of contributors stood at 373. As of this writing, there are 500. I believe that the barrier to contribution should increase as a project gains popularity, and there is almost no new technology experiencing more interest growth than Docker is right now. This rapid increase in contributors shows the speed at which things are evolving in Docker. It also shows the quality of the codebase, as a project that can scale and still maintain a level of quality must have a strong test suite and continuous integration story, as Docker does.