5 ms·

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 b

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/ 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.

nextos 12y ago
Very interesting. I'm curious, have you considered nixos?
- seppalala 12y ago
  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.
  - indygreg2 12y ago
    I blogged about this the other day and would love to hear about your experience! http://gregoryszorc.com/blog/2014/10/13/deterministic-and-minimal-docker-images/ http://gregoryszorc.com/blog/2014/10/13/deterministic-and-mi...
    - seppalala 12y ago
      This is spot-on what I'd like to do, and I have the exact same concerns. Thanks for sharing!
  - cpuguy83 12y ago
    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.
    - joevandyk 12y ago
      That package could install some other dependencies, and those dependencies aren't pinned down.
      - mentat 12y ago
        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
      - deleted 12y ago
        [deleted]
  - nextos 12y ago
    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.
nailer 12y ago
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?
- vidarh 12y ago
  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.
  - nailer 12y ago
    Thanks, that's a good answer.
  - zwischenzug 12y ago
    I blogged on automating deployment to AWS with Docker here: http://zwischenzugs.wordpress.com/2014/08/09/using-shutit-and-docker-to-play-with-aws-part-one/ http://zwischenzugs.wordpress.com/2014/08/09/using-shutit-an... http://zwischenzugs.wordpress.com/2014/09/15/using-shutit-and-docker-to-play-with-aws-part-two/ http://zwischenzugs.wordpress.com/2014/09/15/using-shutit-an...
- seppalala 12y ago
  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 http://radial.viewdocs.io/docs
bladev2 12y ago
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'.
- seppalala 12y ago
  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.
deleted 12y ago
[deleted]
akurilin 12y ago
I'd recommend you guys look into Stackage to relieve some of the cabal hell pain, if not most of it.

nextos 12y ago

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

seppalala 12y ago
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.
- indygreg2 12y ago
  I blogged about this the other day and would love to hear about your experience! http://gregoryszorc.com/blog/2014/10/13/deterministic-and-minimal-docker-images/ http://gregoryszorc.com/blog/2014/10/13/deterministic-and-mi...
  - seppalala 12y ago
    This is spot-on what I'd like to do, and I have the exact same concerns. Thanks for sharing!
- cpuguy83 12y ago
  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.
  - joevandyk 12y ago
    That package could install some other dependencies, and those dependencies aren't pinned down.
    - mentat 12y ago
      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
    - deleted 12y ago
      [deleted]
- nextos 12y ago
  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.

nailer 12y ago

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?

vidarh 12y ago
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.
- nailer 12y ago
  Thanks, that's a good answer.
- zwischenzug 12y ago
  I blogged on automating deployment to AWS with Docker here: http://zwischenzugs.wordpress.com/2014/08/09/using-shutit-and-docker-to-play-with-aws-part-one/ http://zwischenzugs.wordpress.com/2014/08/09/using-shutit-an... http://zwischenzugs.wordpress.com/2014/09/15/using-shutit-and-docker-to-play-with-aws-part-two/ http://zwischenzugs.wordpress.com/2014/09/15/using-shutit-an...
seppalala 12y ago
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 http://radial.viewdocs.io/docs

bladev2 12y ago

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'.

seppalala 12y ago
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.

deleted 12y ago

[deleted]

akurilin 12y ago

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