Hacker News Reader

Comment by xienze | Hacker News Reader

Bringing up a properly configured VM that stays up to date is actually a lot of work, and the more software you pile directly on top of that VM, the harder it is.

For me, my VMs are actually dead simple and relatively homogeneous. Fresh install + lock down SSH + lock down iptables + install Git + install Docker.

Then I build from the correct Dockerfile and open whichever port(s) on the VM. Bang, instant node that does [whatever]. Time to upgrade the DB/mail server/app? Build from the new Dockerfile, stop the existing container, bring up the new one. No worrying about installing/uninstalling the correct dependencies on the VM and getting into an inconsistent state.

That's what Docker does for you.

View on HN

That's also what any sane configuration management system does for you.

Don't get me wrong, I think docker is great, but this whole "I get simple idempotent machines" is a solved problem. Docker excels at bundling applications with all their dependencies as an modern analogue to statically linking, or a Linux equivalent to OSX's .app

One big difference is that if you don't declare a resource it doesn't exist anymore. With chef, puppet and friends there's a big gray area of things that are one the machine but not managed by the tool. In practice there are always things lingering on old machines that are not described by the SCM.

Solved by what, Puppet and the like? It's simply too easy to get your machine into an inconsistent state as a result of someone fiddling around, and God forbid you switch from Ubuntu to CentOS or something like that.

I find it's easier to make the OS part as simple as possible and use Docker for everything else since you can strictly enforce that your Dockerfile will always build the same way regardless of which OS you build it on.

This is my experience with Chef/Vagrant and one of the principal reasons we're moving our deployment over to Docker with CoreOS. Using etcd/skydns for service discovery and fleet to deploy containers. So far it's going very well, much easier than Chef ever was.

Most configuration management systems actually make ongoing configuration management pretty hard. You end up with your supposedly declarative configuration files littered with upgrade scripts and "please uninstall that package", unless you simply wipe your systems and install them from scratch with each change.

I think the point of Docker is that it decouples that "destroy a system and start a new one" from the VPS/cloud/server provider you're using; you can talk about "logical" systems as separate from whatever they're actually running on.

Personally, my use of NixOS means that I don't have the problem, so I don't need Docker. My systems get generated from scratch (logically speaking) whenever I upgrade without having to tear down the VM, and then some simple logic figures out which services to restart.

Reply on news.ycombinator.com