3 ms·

I would love to peek at some of your Dockerfiles if possible? Tried building a piece of infrastructure with Docker quite some time ago and left when it just di

I would love to peek at some of your Dockerfiles if possible? Tried building a piece of infrastructure with Docker quite some time ago and left when it just didn't click. I certainly did quite some mistakes (at that time I did try to stuff all the provisioning into the Dockerfile for example, which you agree is a bad idea?) and the official Dockerfiles were .. mixed in clarity and not quite useful as examples to me. So, I would really love reading about how people provision and manage their Docker instances The Right Way.

malexw 12y ago
Seconded! I was able to set up a toy blogging system with Docker, but it's not something I'd feel comfortable using in a production environment yet. I'd really love to know more about how robust production environments are built with Docker.
vidarh 12y ago
There are some examples in this article I wrote: http://www.hokstad.com/docker/patterns http://www.hokstad.com/docker/patterns I'll be posting a more detailed walkthrough of my process for using Docker with Ruby soon, as well as some other experiences. > (at that time I did try to stuff all the provisioning into the Dockerfile for example, which you agree is a bad idea? It's not necessarily a big deal for everything. I you have a lot of stuff that have limited build dependencies beyond Debian's "build-essential" target, you might as well create a debian:wheezy image with "build-essential" installed and work from that to begin with. The issue is that some types of apps, like any Ruby app that uses Bundler and has dependencies on stuff with native extensions, can drag in hundreds of MB of dependencies that are only needed during build, and the build is only necessary when adding dependencies. For those kinds of apps it just wastes time and bloats your images to do the builds in the same Dockerfiles that you deploy with. If you're deploying 4-5 images now on a server or two, that's no big deal. When you're deploying 500 containers, you start getting picky about anything that slows down the process... For those situations, I'd typically put together a Dockerfile with all the basic dependencies, and then "inherit" from that once for a dev/build container with the build dependencies, but without an entrypoint (so I can easily start it into bash or have it run a build script, or whatever I want), and then secondly for the final container where the latter image just adds the build artefacts. Ideally I'd want everything I deploy to just have the files that are needed. Pragmatically, the tools are not quite there yet. Not least, it's often a real pain to build apps statically (if it's even possible), and the known dependencies are too granular (e.g. dependency on a large package, with no documentation about precisely what in the package has to be present) and it will take a long time to build up a "catalog" of more minimal images and build processes.

malexw 12y ago

Seconded! I was able to set up a toy blogging system with Docker, but it's not something I'd feel comfortable using in a production environment yet. I'd really love to know more about how robust production environments are built with Docker.

vidarh 12y ago

There are some examples in this article I wrote: http://www.hokstad.com/docker/patterns http://www.hokstad.com/docker/patterns I'll be posting a more detailed walkthrough of my process for using Docker with Ruby soon, as well as some other experiences. > (at that time I did try to stuff all the provisioning into the Dockerfile for example, which you agree is a bad idea? It's not necessarily a big deal for everything. I you have a lot of stuff that have limited build dependencies beyond Debian's "build-essential" target, you might as well create a debian:wheezy image with "build-essential" installed and work from that to begin with. The issue is that some types of apps, like any Ruby app that uses Bundler and has dependencies on stuff with native extensions, can drag in hundreds of MB of dependencies that are only needed during build, and the build is only necessary when adding dependencies. For those kinds of apps it just wastes time and bloats your images to do the builds in the same Dockerfiles that you deploy with. If you're deploying 4-5 images now on a server or two, that's no big deal. When you're deploying 500 containers, you start getting picky about anything that slows down the process... For those situations, I'd typically put together a Dockerfile with all the basic dependencies, and then "inherit" from that once for a dev/build container with the build dependencies, but without an entrypoint (so I can easily start it into bash or have it run a build script, or whatever I want), and then secondly for the final container where the latter image just adds the build artefacts. Ideally I'd want everything I deploy to just have the files that are needed. Pragmatically, the tools are not quite there yet. Not least, it's often a real pain to build apps statically (if it's even possible), and the known dependencies are too granular (e.g. dependency on a large package, with no documentation about precisely what in the package has to be present) and it will take a long time to build up a "catalog" of more minimal images and build processes.