As we discovered in the first installment of this two-part series, the folks at Ansible reacted to a recent report claiming that enterprises like it must work to maintain significance given the advancements of microservices and containers. In a message to ContainerJournal, an external PR agency answered these claims on Ansible’s behalf, which lead to this Q&A with Ansible’s VP of Community, Greg DeKonigsberg. We have based our questions on the communication from the PR representative. We continue now with part two of Ansible’s defense.
ContainerJournal: You say that with Ansible you can manage not only the containers, but the environments around the containers as well. Docker instances still need to run on hosts and you need to launch, configure, network, and coordinate those hosts. Please explain what keeps containers from being able to do these things for themselves?
Greg DeKonigsberg: It’s still widely agreed that there need to be hosts that these containers run on, and those hosts are still systems that you need to manage and maintain. So the rise of containers doesn’t mean that the mundane tasks of managing the systems underneath them go away.
It may be that you choose a large-scale system like Kubernetes to do container fleet management. But even if you do, you still have to make sure that you have a set of physical hosts or virtual hosts that Kubernetes is running on, and you still need something to configure all of those hosts. People use Ansible for all of those things.
One of the reasons for moving to containerization is that it allows you greater ease of horizontal scale across systems. But the more of that you have, the more that you want. The easier it is to spin up a bunch of containers, the more you’re going to want to do that, and the more you’re going to need something to manage those pieces. We think Ansible is becoming a great default choice for that.
CJ: You say that as the complexity of a container grows, defining that container with a single Dockerfile can become complex and unwieldly. You can compose Ansible playbooks. You can build them up using roles so that you can read even complex playbooks in different roles. Please discuss.
GD: The best Docker container for most users is the simplest possible Docker container. That’s what Docker designs Dockerfiles for. They design them to be very simple. Shell script and Docker containers inherit from one another, too.
In the best case for users, that means that they’ll have a few Dockerfiles that are their base files and then they’ll have some Dockerfiles that have some simple additions. When that works, that works really well. But many users end up building much more complex container structures. For them, it can be difficult to look at a container at any one time and see all of the pieces that have gone into it.
One of the behaviors that we’re seeing users adopt is, rather than using the Dockerfile as the entity that describes what’s in the Docker container, they use Ansible to describe what is ultimately going to go into that Docker container. Then they use some kind of simple bridge that essentially turns that Ansible playbook into the target Docker container. The advantage our users tell us that they get from that is that they can use the same exact build processes to build a Docker container as they might to build a VM.
So if they aren’t sure whether they’re going to be using Docker in this environment or that environment, they can then give themselves the option of either using a Docker container, or if, for whatever reason, the Docker container isn’t right for that environment yet, they can simply deploy to a cloud instance, or to bare metal.
CJ: You say that Ansible can model containers and “non-containers” at the same time and that this is especially important as containerized applications are nearly always talking to components, storage, databases, and networking that are not containerized and frequently not even “containerizable”. What are the reasons it is important for Ansible to be able to do this?
GD: Containers don’t exist in a vacuum. They exist to do something that’s valuable for the business. When you’re deploying a container, you’re deploying that container in the context of all the IT assets of your business. Having a tool and language like Ansible that allows you to describe potentially what goes into that container, definitely what that container’s job is, where it fits in your infrastructure, and the other tasks that you need to kick off when you deploy that container is vital.