<story><title>Ask HN: How do you use Docker in production?</title><text>I know what Docker is and how it works. What are some problems that get solved better when using Docker?</text></story><parent_chain><item><author>seppalala</author><text>Here&amp;#x27;s the problems we&amp;#x27;re solving with Docker:&lt;p&gt;* 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 &amp;quot;why does software X build&amp;#x2F;execute on machine A and not machines B-C?&amp;quot;&lt;p&gt;* Declarative deployments. Using Docker, Core OS, and fleet[1], this is the closest solution I&amp;#x27;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&amp;#x27;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.&lt;p&gt;* Managing Cabal dependency hell. Most of our application development is in Haskell, and we&amp;#x27;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.&lt;p&gt;* Bridging a gap with less-technical coworkers. We work with some statisticians. Smart folks, but getting them to install and configure ODBC &amp;amp; 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&amp;#x27;ll work on our side, too.&lt;p&gt;I was skeptical about Docker for a long time, but after working with it for the greater part of the year, I&amp;#x27;ve been greatly satisfied. It&amp;#x27;s not a solution to everything—I&amp;#x27;m careful to avoid hammer syndrome—but I think it&amp;#x27;s a huge step forwards for development and operations.&lt;p&gt;[1]: &lt;a href=&quot;https://coreos.com/using-coreos/clustering/&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;coreos.com&amp;#x2F;using-coreos&amp;#x2F;clustering&amp;#x2F;&lt;/a&gt;&lt;p&gt;Addendum: Yes, some of these gains can be equally solved with VMs, but I can run through &amp;#x2F;dozens&amp;#x2F; of iterations of building Docker images by the time you&amp;#x27;ve spun up one VM.</text></item></parent_chain><comment><author>nailer</author><text>In typical virtualisation + config management you specify a base image and bunch of config files and commands.&lt;p&gt;In a Dockerfile you specify a base image and commands, may often invoke a config management tool.&lt;p&gt;How is using Docker more declarative?</text></comment>
<story><title>Ask HN: How do you use Docker in production?</title><text>I know what Docker is and how it works. What are some problems that get solved better when using Docker?</text></story><parent_chain><item><author>seppalala</author><text>Here&amp;#x27;s the problems we&amp;#x27;re solving with Docker:&lt;p&gt;* 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 &amp;quot;why does software X build&amp;#x2F;execute on machine A and not machines B-C?&amp;quot;&lt;p&gt;* Declarative deployments. Using Docker, Core OS, and fleet[1], this is the closest solution I&amp;#x27;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&amp;#x27;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.&lt;p&gt;* Managing Cabal dependency hell. Most of our application development is in Haskell, and we&amp;#x27;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.&lt;p&gt;* Bridging a gap with less-technical coworkers. We work with some statisticians. Smart folks, but getting them to install and configure ODBC &amp;amp; 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&amp;#x27;ll work on our side, too.&lt;p&gt;I was skeptical about Docker for a long time, but after working with it for the greater part of the year, I&amp;#x27;ve been greatly satisfied. It&amp;#x27;s not a solution to everything—I&amp;#x27;m careful to avoid hammer syndrome—but I think it&amp;#x27;s a huge step forwards for development and operations.&lt;p&gt;[1]: &lt;a href=&quot;https://coreos.com/using-coreos/clustering/&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;coreos.com&amp;#x2F;using-coreos&amp;#x2F;clustering&amp;#x2F;&lt;/a&gt;&lt;p&gt;Addendum: Yes, some of these gains can be equally solved with VMs, but I can run through &amp;#x2F;dozens&amp;#x2F; of iterations of building Docker images by the time you&amp;#x27;ve spun up one VM.</text></item></parent_chain><comment><author>nextos</author><text>Very interesting. I&amp;#x27;m curious, have you considered nixos?</text></comment>