Hacker News Reader

Comment by andrewfong | Hacker News Reader

Can someone comment on what I would use Docker for as opposed to what I would use Chef / Puppet / Ansible for?

You don't have to use one or the other. Docker is more about shipping around images that can be used to start containers. How you configure the image is up to you, but Docker provides a "Dockerfile" that can configure images with bash commands. You can call Chef / Puppet / Ansible from the Dockerfile to configure the image.

Once the image is created you can send it out to any machine that has docker installed and start it up.

Docker is a very lightweight VM. Or a much nicer chroot. However you want to look at it.

The underlying technology is LXC. It is very cool stuff.

But the top article is full of bullshit. It doesn't run "virtually anywhere", it runs on a few systems that support LXC or you have to build a VM that does support LXC, so you can host your Docker VM, inside that VM.

How does that "Yo Dog" meme go...?

"A few systems that support LXC", that's actually most modern Linux systems now. Anything with a 3.8 kernel is game.

> that's actually most modern Linux systems now. Anything with a 3.8 kernel is game.

So Linux systems, that started shipping just this year?

Well but even that is not true because it was backport-ed to RHEL 6/CentOS 6 which is very cool.

Not all people live dangerously and install the very latest release on their server.

Ubuntu LTS (which is a common server platform) also doesn't natively support LXC well. It has an older kernel. So instructions for installing docker is to install a new kernel. A new custom compiled kernel on a production system. Hmm, is that still Ubuntu 12.04 LTS, some devops will argue it isn't, some will say it is fine.

Skate where the puck is going. Is it a comprehensive solution today? No. But I would rather see Docker double down on making the project great for those that have bought in than spend their resources building compatibility from people that have not. It's the difference between asking your customers what features they would find most useful and asking people that aren't your customers what features they think you need to build before they buy. The latter set of feedback is almost always useless.

> No. But I would rather see Docker double down on making the project great for those that have bought in than spend their resources building compatibility from people that have not.

I would rather see that too. So we agree there. If you read my comment, it was about making ridiculous statements about compatibility, not that I want or need more compatibility.

On a more general level it is about being dishonest and how ardent fans are enemies in disguise. They make ridiculous statements about the product that then creator of the product end up having to manage the PR.

Docker is not a VM.

"Docker is a very lightweight VM. Or a much nicer chroot."

Come on, it was obviously their attempt at explaining it using familiar terminology. It's definitely closer to a VM than it is to a configuration management/orchestration tool.

Dockerfiles are basically Docker's way of doing config management. Pros: docker caches every step of your Dockerfile, so iteration is fast. Cons: Dockerfiles are basically glorified shell scripts. At Clever we basically have a single Dockerfile that calls our existing Salt setup, and so far it's worked decently well.

If your Dockerfile just calls Salt, is Docker then simply just a lightweight alternative to Vagrant + Virtualbox?

Does your Dockerfile do anything besides call Salt? If so, what's a good rule of thumb for what goes into the Dockerfile as opposed to Salt or any other config management tool?

Indeed--it's a lightweight alternative with a better deployment story IMO. A bunch of containers running on a set of hosts is easier to manage than a virtualization setup.

Here's a simplified version of the dockerfile template we use: https://gist.github.com/rgarcia/7917826. It basically outsources all of the work to a salt state.

You can call chef/puppet/ansible from your Dockerfile to provision your container, but that loses the cool caching behaviour that docker gives you.

We have a large set of well-tested ansible scripts that we use for deployment, so we thought we'd use the "run ansible within the Dockerfile" approach. However, when we started doing that, we found that the configuration of each docker is actually fairly simple so we converted to (almost) pure Dockerfile. The ansible complexity was configuring and setting up a bunch of images and their configurations on a bunch of servers.

IOW, we use ansible to schlep around & configure the environment variables for the containers rather than creating them.

Docker simplifies the setting up of a server so that it becomes a set of building blocks. And it does so regardless of which server management framework you use. This means that you can ditch the more complicated Puppet and Chef and go for a simpler solution like Ansible and still manage a large number of servers.

So it is really a different approach to the problem space that Puppet and Chef have attacked. Docker only addresses the building blocks aspect of the problem, and leverages Linux kernel features that most sysadmins have not yet tried to incorporate into their systems. You can either choose to not use a server orchestration framework with Docker and stick with ssh and bash scripts. Or you can choose a lighter framework that is easier to learn and operate like SaltStack or Ansible. Those of use who have run Solaris systems in the past, know the advantages of containerization in partitioning system resources so we tend to be attracted by Docker.

One way to think of docker is as an installation automation and management thingie. However, it is better to think of it as an encapsulation mechanism for your setup. Almost like a vm in itself. A running docker container is also assigned its own private network ip address, which helps reinforce the abstraction.

Reply on news.ycombinator.com