ANSIBLE COMMUNITY – 2017 YEAR IN REVIEW

It's time again for the annual Ansible community review. Let's start again, as we do every year, with a quick look at the numbers.

Debian Popcon

Debian’s Popularity Contest is an opt-in way for Debian users to share information about the software they’re running on their systems.

As with every year, caveats abound with this graph -- but even though it represents only a small sample of the Linux distro world, it’s useful because it’s one of the few places where we can see an apples-to-apples comparison of install bases of various automation tools. Because Ansible is agentless, we compare the Ansible package to the server packages of other configuration management tools. (Chef does not make a Debian package available for Chef server.)

We see that Ansible has continued its steady growth in 2017, increasing its user base here by approximately 50% in the past year.

GitHub Metrics

2017 was a busy year for Ansible on the GitHub front, and in 2017 we caught the notice of GitHub itself. Ansible now has its own top level topic for GitHub searches, and that search reveals over 5000 repositories of Ansible content. We also made the 2017 GitHub Octoverse report, placing Continue reading

Announcing Ansible Container 0.9

The Ansible Container team is proud to announce the 0.9 release of the Ansible Container project. Key new features of the 0.9 release include:

Tighter integration with Ansible roles

Ansible roles are a great way to describe microservices; roles that are "common" between multiple services map well to container image layers and service-specific roles are easy for teams to maintain. We decided to make that concept clearer in the way Ansible Container works. We ditched the main.yml playbook and replaced it with a per-service list of roles in container.yml.

Tighter integration with Kubernetes in OpenShift Origin and Red Hat OpenShift Container Platform

We've built brand new Kubernetes and OpenShift modules for Ansible, and are already using them in Ansible Container. We've also restructured the container.yml syntax to more naturally support Kubernetes and OpenShift concepts out of the box, then fall back to the comparatively simpler Docker ecosystem. Instead of trying to bolt Kubernetes features into the Docker Compose style schema, we have dedicated OpenShift/Kubernetes configuration for resources like Persistent Volume Claims. This will allow end users to transfer existing Ansible roles into Kubernetes/OpenShift and have Ansible Container manage the deployment lifecycle.

Putting more tools into the Continue reading

Ansible Community – 2016 Year in Review

It's time again for the annual Ansible community review. Time flies. Our upward trajectory generally continued from 2014 and 2015 through 2016, and our growth continued to bring new challenges and new opportunities.

Let's start again, as we do every year, with a look at the numbers.

Debian Popcon

Debian’s Popularity Contest is an opt-in way for Debian users to share information about the software they’re running on their systems.

Caveats abound with this graph -- but even though it represents only a small sample of the Linux distro world, it’s useful because it’s one of the few places where we can really see an apples-to-apples comparison of install bases of the various tools. Because Ansible is agentless, we compare the Ansible package to the server packages of other configuration management tools. (Chef does not make a Debian package available for Chef server.)

We see that Ansible has continued its steady growth through the end of 2016, nearly doubling its Popcon install base again in 2016.

Github Stars

Ansible continued in 2016 to extend its already significant lead in GitHub Stars over other tools in the configuration management space, passing the 20k mark in December 2016.

Github Contributors

We Continue reading

5 Reasons We Started the Ansible Container Project

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 Continue reading

Six Ways Ansible Makes Docker-Compose Better

Containers are popular for many reasons. One key reason: container images are easy to build and, once built, don't change.  When Developer A says, "Hey, check out this new application, just download this container image and run it," Developer B doesn't have to ask the question, "How do I configure it?"  Developer B can just download the image and run the container, and enjoy a high likelihood that it will run exactly as Developer A intended.

Until Developer A announces the need for a second, third and fourth container, that is.  A microservices approach advocates for simple containers, sure -- but that also means more of them, all doing different things, and all connecting together... somehow.  So now Developer A needs to tell Developer B "be sure to run all of these containers together, and make sure these two containers share a data volume, and make sure these other two containers have a network link between them, and make sure the REST API for this one is exposed on these ports. Oh, also! Make sure you've got your DNS set up right, because it's all a hilarious dumpster fire if you don't."

Complexity doesn't go away in the container world; it just moves to different Continue reading

Another Good Year for Ansible Users

It seems like just yesterday that we were putting together the recap of Ansible's community growth in 2014. That was a very good year.

Here we are at the start of 2016 already -- and looking back on 2015, it was an even better year than 2014 was.

First, let's take a look at the numbers. For consistency's sake, we'll mostly compare to 2014 numbers, which can be found in last year's analysis.  Note that the same caveats from last year's analysis also apply this year.

Debian Popcon

Debian’s Popularity Contest is an opt-in way for Debian users to share information about the software they’re running on their systems.  Although it represents only a small sample of the Linux distro world, it’s useful because it’s one of the few places where we can really see an apples-to-apples comparison of install bases of the various tools. Because Ansible is agentless, we compare the Ansible package to the server packages of other configuration management tools.

For the first time in 2015, Ansible installations on this chart outnumbered Puppetmaster installations. Ansible shows continued strong growth, and appears to remain on an upward trend into 2016.

Caveats abound with this chart, but it does Continue reading

Another Good Year for Ansible Users

It seems like just yesterday that we were putting together the recap of Ansible's community growth in 2014. That was a very good year.

Here we are at the start of 2016 already -- and looking back on 2015, it was an even better year than 2014 was.

First, let's take a look at the numbers. For consistency's sake, we'll mostly compare to 2014 numbers, which can be found in last year's analysis.  Note that the same caveats from last year's analysis also apply this year.

Debian Popcon

Debian’s Popularity Contest is an opt-in way for Debian users to share information about the software they’re running on their systems.  Although it represents only a small sample of the Linux distro world, it’s useful because it’s one of the few places where we can really see an apples-to-apples comparison of install bases of the various tools. Because Ansible is agentless, we compare the Ansible package to the server packages of other configuration management tools.

For the first time in 2015, Ansible installations on this chart outnumbered Puppetmaster installations. Ansible shows continued strong growth, and appears to remain on an upward trend into 2016.

Caveats abound with this chart, but it does Continue reading

Red Hat and the Ansible Community

Now that Ansible is a part of Red Hat, some people may wonder about the future of the Ansible project. Specifically, a few people have expressed concerns that Ansible may become more Red Hat-centric at the expense of other platforms or open source projects.  Here is the good news: the Ansible community strategy has not changed.

As always, we want to make it as easy as possible to work with any projects and communities who want to work with Ansible. Now that we have the resources of Red Hat behind us, we plan to accelerate these efforts. We want to do more integrations with more open source communities and more technologies.

One of the reasons that Red Hat purchased Ansible in the first place was because Red Hat understands the importance of a broad and diverse community. Google “Ansible plus <open source project>” for nearly any project and you will find Ansible playbooks and modules and blog posts and videos and slide decks and all kinds of other information, all intended to make working with that project easier.  We have thousands of people attending Ansible meetups and events all over the world.  We have millions of users.  We Continue reading

Deploy to Metal? No sweat with RackN new Ansible Dynamic Inventory API

At Ansible, we’ve been talking quite a bit with our friends at RackN about the work they’ve been doing to make things easier to stand up complex system configurations from bare metal. We’re happy to share some of what they’ve accomplished.

Deploy to Metal? No sweat with RackN new Ansible Dynamic Inventory API: by Greg DeK + Dan Choquette

The RackN team takes our already super easy Ansible integration to a new level with added SSH Key control and dynamic inventory with the recent OpenCrowbar v2.3 (Drill) release. These two items make full metal control more accessible than ever for Ansible users.

The platform offers full key management.  You can add keys at the system, deployment (group of machines) and machine levels. These keys are operator settable and can be added and removed after provisioning has been completed.  If you want to control access to groups on a servers or group of server basis, OpenCrowbar provides that control via our API, CLI and UI.

We also provide a API path for Ansible dynamic inventory.  Using the simple Python client script (reference example), you can instantly a complete upgraded node inventory of your system.  The inventory data includes items Continue reading

#Simple OpenStack Collaboration Day Recap

We were excited to announce our Simple OpenStack Initiative earlier this week which kicked off with our Collaboration Day in Vancouver at the OpenStack Summit.

The weather, the setting and the conference overall have been just fantastic. I wanted to recap some of the discussions we had in during our collaboration day as it was the perfect jumpstart to this already great week.

We had solid participation from across the board -– networking and hardware leaders, consultants, cloud providers, etc. -- and it reinforced to me how much interest there is in Ansible, and how many angles there are to consider while trying to remain true to our mission of simplicity.

Ansible’s goal is to help everyone move faster to make OpenStack more viable. We really don’t have a horse in the race; we are not in the business of betting on who will get there first, or better.  We just want OpenStack to work, for all of us.

There were two high-level themes to the day --  undercloud and overcloud -- and lots of listening, learning and active discussions.

The Undercloud Discussion: OSAD and friends

Kevin Carter of Rackspace, PTL of the OS-Ansible-Deployment (OSAD) project, opened the day with Continue reading

Ansible Collaboration Day at OpenStack Summit

OpenStack has long had a reputation for being difficult to install and manage. This reputation may be a bit overblown, but it's not entirely unwarranted.

The plain truth is that OpenStack has a lot of components, all of which must be working in concert to be successful. A simple misconfiguration in one component can lead to cascading failures throughout the system, which can then be difficult to diagnose and correct.

It's one of the essential problems of managing any distributed system: one must effectively manage both individual components (i.e. configuration) and the relationships between those components (i.e. orchestration).

Ansible is a simple tool that excels at both -- which helps to explain Ansible's surging popularity in the OpenStack ecosystem. Over the past year, several OpenStack projects have emerged to take full advantage of Ansible's power and simplicity.

We've been watching with great interest. Now we think it's time to get more directly involved.

On Monday, May 18th, we will hold an Ansible Collaboration Day at the OpenStack Summit. Our collective goal is simple and ambitious: to make the installation and management of OpenStack as simple as we can possibly make it.

The first part of the day will Continue reading

Ansible and Containers: Why and How

Everyone loves the promise of containers.  

More specifically: everyone loves the promise of a world where they can build an application on their laptop, and have that application run exactly the same way in every environment -- from their laptop all the way to production, and at every step in between.

That's still a holy grail, though.  In the meantime, people seem to be looking for practical ways to get all of the advantages of containers -- consistency, lightweight environments, application segregation, and so on -- while still maintaining the flexibility required to work with the many environments that are not amenable to containerization.

Which may explain why so many people... wow, just a lot of people... seem to be talking about Ansible and containers together:

* Ansible playbooks are portable. If you build a container with a pure Dockerfile, it means that the only way you can reproduce that application is in a Docker container. If you build a container with an Ansible playbook, you can then reproduce a very similar environment in Vagrant, or in a cloud instance of your choice, Continue reading