Today, we’re excited to share the story of the Ansible Container project. It is platform-agnostic, able to target the most common container orchestration engines including Kubernetes, Docker and OpenShift.
This project started just as a side project of mine, originally called Harbormaster. I hated Dockerfiles, and hadn’t written a shell script since I started with Ansible in November 2015. I started wondering whether you can build images with Ansible Playbooks. Chris “House” Houseknecht, Principal Software Engineer at Ansible who is primarily responsible for Ansible Galaxy, simultaneously and independently tried to find ways to build Kubernetes configs from Docker Compose files. These two projects merged and became Ansible Container. The resulting project is the Ansible on-ramp into containers and OpenShift.
It’s taken on a life of its own, with the intent to build container images using nothing but Ansible Playbooks. We do our production orchestration in Kubernetes and OpenShift. We released version 0.1 of our container project at DockerCon last summer and it’s taken off since then.
We were lucky in that once Ansible leadership saw our proof of concept (POC), they immediately recognized its transformative potential and began devoting paid resources internally toward its development and promotion. We had four people who really spearheaded the project, and without their efforts, Ansible Container couldn’t be where it is today.
The Ansible “role” is the perfect metaphor for a microservice to an Ansible user. Leveraging existing roles, either custom written or pulled from Ansible Galaxy, it becomes simple to stitch together microservices into a multi-container application.
Nobody else is building containers this way.
Many in the container community want to build containers truly standalone, without having to run a Docker daemon. This project provides a framework in which container building and orchestration is truly independent of any specific container technology, even the Docker ecosystem. Ansible can eliminate vendor lock-in within the container ecosystem — there are so many awesomely innovative and competitive container platforms, but it’s so early in the game that nobody knows what to place their bets on.
Rackspace’s container offering was Docker-based and now is switching to Kubernetes. Others are going to Mesos or other things like that. AWS users are being pushed toward Amazon ECS. Nobody knows which direction to go, and those are all-in solutions.
Ansible Container, like Ansible itself, is modular and pluggable and agnostic. We’re building replaceable engine components so you can locally and remotely target any container engine that you like. You can use the same orchestration and coordination and target Kubernetes, the Docker platform, OpenShift, and more. This is really powerful technology, because the same way that mobile app developers are empowered by toolkits that allow you to build apps for any mobile platform (such as Android and iOS), our project empowers developers and operators to build containers leveraging any available container platform.
Our community would not have been successful without open source. When we came out of DockerCon, within the first week we had 1000 stars on GitHub. Chris and I wrote the majority of lines of code, and then we suddenly had dozens of contributors whom we’d never heard of. The community had a huge role on driving the direction and use cases for this project.
Also, sales reps and solutions architects working with Ansible Tower customers and Ansible users in the field come back and share how existing Ansible customers are re-leveraging their Ansible content through our container project.
We did road shows to talk about the project, and that really helped us to build the project team. Having the Ansible brand behind it gave our project some good credibility, particularly because Ansible is already widely adopted and integral to managing bare metal and VM infrastructure. Containers are hard; all the tools and techniques for running systems over 30 years don’t apply to containers. Now people want to get into containers, but they have this Ansible stuff for building bare metal systems that don’t apply to containers.
Our project allows people to leverage their original investment in Ansible content to build containerized ecosystems. The Ansible language provides a simple automation language to gather system facts and enumerate a series of tasks to execute on target systems. With Ansible Container, instead of having to rewrite all of this Ansible content as shell scripts in a Dockerfile, they can re-use it, executing those tasks to build container images.
Our philosophy is based on tight feedback loops with interested community members and clear communication about directions and roadmaps. User feedback on what they need helps drive roadmaps, and frequent iterations and consistent responsiveness helps keep community members excited and engaged. We don’t have the hubris to think we automatically know the best direction for this project, and feedback from users with real world use cases is vital to the project’s enduring success.
Ansible Core is rapidly becoming the industry standard language for IT automation. We want to extend that to the container world as well. We don’t care what container platforms you want to use; we simply want to be the simplest and most powerful way to get there.
We’re doing a pretty big re-factor now, getting ready for 1.0 release this spring. We expect to release .9 in April. Once it’s out there, we’re looking forward to hearing feedback from the community and seeing what people have to say about what it can do.
The framing of Ansible “roles” as microservice is critical to an Ansible user’s understanding of container technology. It’s also the easiest way to bring existing Ansible content to containers. Ansible Galaxy is a community role sharing place, so these roles make things run better and would help give ready-made projects to run.
We’ve also introduced into Ansible Galaxy the idea of a container app: multiple containers pre-stitched together into a fully orchestrated project template. Development of this supporting content makes it easier for people to get going.
One of the really unexplored frontiers is containers for Windows developers. Since the Docker ecosystem has been historically Unix/Linux/Mac focused, being able to help Windows developers get started developing containerized apps is something I see as a huge opportunity.
Performance-wise, we’ve struggled with image rebuilds at the same speeds one can do with a Dockerfile. The caching of layers for each instruction makes for very quick rebuilds of container images, so being able to bolt into a run of playbooks with the same caching has been a challenge. The performance on this is the most-reported problem. As we move toward 1.0, we’ll be releasing a number of ways to help our build performance keep up better with user expectations
We’re really excited about building our community and the Ansible Container project in 2017. There are enormous opportunities for containers, and I think this project will make getting into containers much easier.