Ansible and Containers: Why and How

April 2, 2015 by Greg DeKoenigsberg

Untitled_design

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-docker-lolwut

So why are people using Ansible with Docker and other container formats?  A few reasons:

* 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, or on bare metal.

* Ansible playbooks are composable. Ideally, containers should be as simple as possible, but as the complexity of a container grows, defining that container with a single Dockerfile can become complex and unwieldy. Ansible playbooks can be built up using roles, so that even complex playbooks are easily read, and different roles can be reused across many environments.

* Ansible can manage full environments. With Ansible, you can manage not only the containers, but the environments around the containers. Docker instances still need to run on hosts, and those hosts need to be launched, configured, networked, and coordinated.

* Ansible can model containers and non-containers at the same time. This is especially important, as containerized applications are nearly always talking to components -- storage, database, networking -- that are not containerized, and frequently not even containerizable.  

* Ansible is a hedge against container format churn.  There are many container formats. Docker is the clear leader, and there are many contenders: LXC, LXD, Rocket, Drawbridge, and more all the time. Building with portability in mind now means being protected from potential container wars in the future.

Don't take our word for it.  There are plenty of people out in the real world who are not only using Ansible and Docker together, but also talking about why they've chosen this path, with hundreds of presentations on SlideShare to explore.  

Ask around; a lot of people will be happy to tell you why Ansible is their preferred way to move towards a more containerized world.

Share:

Topics:
Docker, Ansible


 

Greg DeKoenigsberg

Greg is the Director of Ansible Community with Red Hat, where he leads the project's relationship with the broader open source community. Greg has over a decade of open source advocacy and community leadership with projects like Fedora and One Laptop Per Child, and on the executive teams of Ansible and of open source cloud pioneers Eucalyptus Systems. Greg lives in Durham NC and is on twitter at @gregdek.


rss-icon  RSS Feed

Ansible Tower by Red Hat
Ansible In-Depth Whitepaper
Ansible Tower by Red Hat
Learn About Ansible Tower