Comment by seppalala | Hacker News Reader

Comment by seppalala | Hacker News Reader

Here's the problems we're solving with Docker:

* Sanity in our environments. We know exactly what goes into each and every environment, which are specialized based on the one-app-per-container principle. No more asking "why does software X build/execute on machine A and not machines B-C?"

* Declarative deployments. Using Docker, Core OS, and fleet[1], this is the closest solution I've found to the dream of specifying what I want running across a cluster of machines, rather than procedurally specifying the steps to deploy something (e.g. Chef, Ansible, and the lot). There's been other attempts for declarative deployments (Pallet comes to mind), but I think Docker and Fleet provide even better composability. This is my favorite gain.

* Managing Cabal dependency hell. Most of our application development is in Haskell, and we've found we prefer specifying a Docker image than working with Cabal sandboxes. This is equally a gain on other programming platforms. You can replace virtualenv for Python and rvm for Ruby with Docker containers.

* Bridging a gap with less-technical coworkers. We work with some statisticians. Smart folks, but getting them to install and configure ODBC & FreeTDS properly was a nightmare. Training them in an hour on Docker and boot2docker has saved so much frustration. Not only are they able to run software that the devs provide, but they can contribute and be (mostly) guaranteed that it'll work on our side, too.

I was skeptical about Docker for a long time, but after working with it for the greater part of the year, I've been greatly satisfied. It's not a solution to everything—I'm careful to avoid hammer syndrome—but I think it's a huge step forwards for development and operations.

[1]: https://coreos.com/using-coreos/clustering/

Addendum: Yes, some of these gains can be equally solved with VMs, but I can run through /dozens/ of iterations of building Docker images by the time you've spun up one VM.

In typical virtualisation + config management you specify a base image and bunch of config files and commands.

In a Dockerfile you specify a base image and commands, may often invoke a config management tool.

How is using Docker more declarative?

If you take the steps for, say, AWS, of building a new AMI for every role you have, then it's pretty much the same.

(but in my experience with building AMI's, that process is way too slow compared to Docker)

Docker becomes closer to declarative when you build static Docker images for every role and rebuild for every change and re-deploy. Even more so when your deployment is based on a tool like Fleet that declaratively specifies your cluster layout.

The point is to avoid ever having situations where you say "install package foo on all webservers". Instead you say "replace all webservers with a bit-by-bit identical copy of image x".

The benefit is that you can have already tested a container that is 100% identical, and know that the deployed containers will be 100% identical, rather than hope the commands you pass to the config tool handles every failure scenario well enough.

Thanks, that's a good answer.

I blogged on automating deployment to AWS with Docker here:

http://zwischenzugs.wordpress.com/2014/08/09/using-shutit-an...

http://zwischenzugs.wordpress.com/2014/09/15/using-shutit-an...

For configuration, we separate the application and the config files into two separate containers. The config files are provided through a shared volume to the application. This model is definitely odd. However, it's allowed us to decouple our application and our configuration and to swap out configurations. With this in mind, it's more declarative because we specify "run this application with this configuration unit" rather than "here's how you get yourself started". See the Radial project for our inspiration[1]

We've found that this approach has generalized so far. For example, setting up a Cassandra cluster is often a real PITA to configure since you need the seed IPs up front. Our configuration container manages the dance by registering and pulling the IPs from Consul (etcd would work fine too). Perhaps a bit of smoke-and-mirrors, but it's achieved being able to spin up a properly-configured Cassandra cluster without needing to manually specify who's in the cluster.

[1]: http://radial.viewdocs.io/docs

Great explanation. If possible, I'd love to see/know more about how the statistician training step was accomplished. I also work with many nontechnical folks and haven't found success getting training on docker to 'stick'.

The Docker folks get a point for bootstrapping a familiar user interface: git. Our non-dev coworkers are competent enough with git, and they felt comfortable drawing analogies between the two. They pull the image (from our private Docker registry), run the container, make some changes, build, run, repeat. Very similar to pull, check out, commit, etc in git.

The only pain I've had is the silly flags for 'docker run'. Ugh. Before I told them to make aliases, there were all sorts of complains when they forgot '-it' and '--rm'. I think '-it' should be the default, and possibly '--rm' as well, with switches to toggle them off. Oh well.

Very interesting. I'm curious, have you considered nixos?

Yes, very much so. In fact, our goal is to have NixOS based containers. Right now, we're using Debian as the base image, and there's /no/ guarantee that the versions of software installed are consistent (since Docker caches based on the line in a Dockerfile, rather than what's actually installed).

With Nix, we can have version guarantees in all of our Docker images--including the cached images.

I blogged about this the other day and would love to hear about your experience!

http://gregoryszorc.com/blog/2014/10/13/deterministic-and-mi...

This is spot-on what I'd like to do, and I have the exact same concerns. Thanks for sharing!

Well sure there can be a guarantee.

`RUN apt-get install some_package=<version>` If you want a newer version, update the Dockerfile with the version you want.

That package could install some other dependencies, and those dependencies aren't pinned down.

That depends on how the package is specified doesn't it? You can snapshot the full chain of versions with dpkg and explicitly specify them all. It should be too hard to wrap this into something like Gemfile.lock

Great. I have a major complaint about Nix. Their packages are built with all sorts of dependencies included. So you install mutt and you end up getting python. Or you install git and you also get subversion.

I understand all their philosophy, but they should allow for flexible runtime dependencies without the need for rebuilding packages. Perhaps with a second hash or something, to sign dependencies.

I'd recommend you guys look into Stackage to relieve some of the cabal hell pain, if not most of it.

Reply on news.ycombinator.com