How Docker Fits Into The Current DevOps Landscape

When it comes to DevOps tooling and configuration management, there's still a lot of confusion as to which tools do what, and how they play with each other, if it all. For the second part of our interview with Docker, we got some more clarity on how Docker fits into people's current toolset and discussed some use cases in which Docker is most useful as a primary tool vs. as a complimentary tool.

LS: So one of the common questions that people have about Docker is that you have some of these other tools like Puppet and Chef...I think there's some confusion as to, is this going to replace Puppet and Capistrano, for instance? Or there's this question of why should I be using Docker as opposed Puppet or with Chef? I just wanted to get your thoughts and how you guys view the whole world of configuration management. Are these other tools separate, or is it all part of one workflow?

J: Docker doesn't want to replace configuration management tools like Chef, Puppet, Salt, or Ansible. The usual answer is very practical and down-to-Earth: if you already have a big investment in Chef, Puppet, or any other kind of configuration management system, Docker has very nice ways to integrate with that.

If you have very nice Chef cookbooks to build and deploy your application, you can use those same cookbooks to do the same thing inside Docker containers. Of course, if you want to take advantage of Docker specific features, you will have to do some little tweaks. But basically, you can reuse most of the work here. You don't have to start from scratch.

Likewise, if you are using something like Puppet to manage hundreds or thousands of machines, and want to start using Docker containers, you can use Puppet to manage the installation of Docker, orchestrate containers, and build images. The integration works both ways.

If you have absolutely no commitment with a specific configuration management tool, and don't want to learn one, you can also use Docker instead. You won't get exactly the same things, but it's reasonable to say that you will get 90% of the goodness for only 10% of the effort, or something like that.

LS: Right, because you would have to learn Puppet, for instance.

J: Yes. You won't have to learn a domain-specific language. We strive to make Docker, Dockerfiles, the registry, and the whole ecosystem, easy enough so that it's easier to learn that than to learn the specifics of a configuration management system. Of course, when your environment mixes applications with and without containers, and you want to manage that in a coherent way, something like Puppet makes a lot of sense. So they really complement each other. I wouldn't say that Docker will make those tools obsolete or irrelevant. Docker lowers the difficulty of obtaining repeatable builds and deployments, in containers. Outside of containers, you will still need to invest into configuration management systems.

But you no longer have to make that investment super early and face that steep learning curve. Instead of saying, "I'm just going to write some shell scripts because Puppet is so complicated!" you can use Docker because it won't be harder than those shell scripts. Instead of saying, "I don't want to use Puppet for that small, little deployment I'm working on," you say, "OK, now I have one hundred servers, so it makes sense to use Puppet." You're happy to use it instead of seeing it as a burden.

LS: Got you. So here's a specific example that maybe you can address. Let's say you're an individual developer working on a number of different projects. Let's say I'm using Puppet, Capistrano, and Vagrant. Is there a reason for me to start using Docker, given that I'm already using these other tools?

J: Yeah, I think it can make sense. I'm going to make a few assumptions here. Generally you'll be using Vagrant and the other tools in a development environment. Then, when you go to production, you'll use something else.

LS: Right. So I'd be using Capistrano to deploy to a VPS on Linode or wherever.

J: Right, that makes sense. With Docker, you would still use Vagrant, or any kind of VM, to run Docker itself. You deploy to Docker, and have a bunch of containers on your dev VM, or even directly on your machine if you're running Linux. Then you ship those containers to production.

Capistrano does that by running a bunch of commands on the target machine. That target could be a local machine, a remote server, a cluster of remote servers... But there will still be some differences between those environments. You have to make sure that you are using the same distro, the same libraries. Making sure that all those environments are perfectly aligned can be a lot of work. Docker solves that because you are starting with a given base image, and it's guaranteed to be the same image everywhere.

I need to sidetrack a little bit here. Often, good configuration management is difficult because the point of configuration management is to install and change certain things without touching the rest. If I instruct Puppet or Chef to install a specific version of a given library, it will do it. But if, at a later point, I remove that part from my manifest (or cookbook), the library won't be uninstalled. It will stay as it is. This is a situation where the same manifest, when applied on different machines, can result in different environments.

That's one thing that Docker tries to abstract. You start with a common base. You're just running simple actions. You're not trying to do anything fancy, like resolving dependencies. You're just applying simple rules, but since you start from a very well-known starting point, you will end up with something predictable and reproducible.

LS: Somewhat unrelated: I know you guys moved away from officially recommending Vagrant in favor of boot2docker. And when was that, by the way? Because that was really recent right?

J: Yeah, it's really recent. I think we officially said to people, it's still fine to use Vagrant obviously, but you will be more likely to get help within the community if you use boot2docker because we are shifting to boot2docker, because it's simpler. It has less moving parts.

It's lightweight. It's the first time that I can actually have a one-liner that downloads a VM image and runs it in less than a minute. Usually, downloading the VM image takes forever, because it's like 500 MB. That one is just 25 MB. Of course, if you have Vagrant for other purposes, it's fine to keep it to run Docker. But if you're considering to use Vagrant just because you need Docker, then no. Go straight to boot2docker because the experience will be more polished and more straight forward.

Then came the boot2docker wrapper on the Mac, as a kind of experiment. The idea was to get something that feels like the native experience, when I'm on my local machine and I do "docker something", and it runs locally. Except that here, when I do "docker something", it talks to a Docker demon running in a VM on the Mac.

The result is very impressive. It works as well as a native Linux machine. The next step might be to do that for Windows developers. Or Linux developers who don't want to run Docker natively for some reason. Someone came up with the wording "headless hypervisor", to say that it's a VM in which you run containers. It's a kind of hypervisor for containers, and it's headless because you don't care at all about the virtual display, the screen, the console of this VM. Because the only interaction will be through the Docker API anyway.

LS: Right. That's interesting. It seems like the common thread here is that you're basically saying, if there are these other tools that you're using to automate your workflow, in terms of the configuration and even deployment, you can still use those. But if you're just now thinking about automating, you can actually start off with Docker and things like boot2docker. You don't need to learn Puppet, Chef, etc.

J: Exactly.

Check out Part 1: How Docker Was Born and Part 3: How Docker Manages Its Massive Open Source Project