6 ms·

Docker is an amazing tool, but there are quite a few misconceptions about it. Nearly all the articles and examples seem super easy, but it's quite a challenge

Docker is an amazing tool, but there are quite a few misconceptions about it. Nearly all the articles and examples seem super easy, but it's quite a challenge to use in an actual multi-host production environment supporting mission-critical systems. This can send the wrong message to beginners and send newbies down the wrong path, which ends up as a disservice to Docker when they hit the complexities and become disillusioned with it. To address those misconceptions, I've just posted the article "Docker Misconceptions": https://devopsu.com/blog/docker-misconceptions/ https://devopsu.com/blog/docker-misconceptions/ I spent about a month working on setting up Docker for production scenarios and reading everything I could on it (all the docs, courses, and well over 100 articles - see Docker Weekly for a wealth of resources). My post covers the main misconceptions I see popping up and also some advice for simplifying Docker use if you do decide to use it for multi-host production. I'm sure I've probably missed some things, so please chime in if I've missed something important.

kiyoto 12y ago
Thanks for a great summary. >For logs, you can either use a shared directory with the host or use a remote log collection service like logstash or papertrail. I would not put Logstash (software) and Papertrail (SaaS) in the same bucket though. With Logstash (or any other data collectors like Flume, Fluentd, etc.) you need a backend system to go with it. Sorry to nitpick, but logging is something I work on/think about all day, so I thought to point it out.
wpietri 12y ago
Thanks, that's exactly the sort of thing I was hoping to learn from the HN comments. In the post you link above, it seems like you're mainly comparing Docker to traditional, non-virtualized setups. Do you (or does anybody) have thoughts on comparing it to virtualized environments? I recently experimented with Xen as a way to isolate services, and it seemed awfully heavy; does Docker end up being a lighter burden?
- lojack 12y ago
  It's lighter in the sense that it should require less resources to keep each container running, but comparable in the sense that you still need to orchestrate how services connect and how each container is configured.
  - geerlingguy 12y ago
    This, exactly. I've heard many people talking about how Docker will put an end to a thousand different problems, especially regarding configuration management... But it really won't. You still need to be able to configure everything inside the container (thus the need for a CM tool), and then also the environment and infrastructure inside which the containers live (thus the need for infra management tools). Docker really doesn't make infrastructure management markedly easier—just faster, more flexible, and slightly more powerful. It's one layer of abstraction over a VM, IMO, and that's a good thing, but carries with it it's own set of complexities.
    - skrebbel 12y ago
      > You still need to be able to configure everything inside the container (thus the need for a CM tool) I'm missing something, but in what scenarios would you need to do something more complex than what can be expressed in a few RUN and ADD commands in a Dockerfile? My limited experience is that indeed, orchestration is still completely needed. We underestimated that and now we have a bunch of hacky shell scripts that build and start and stop docker containers at various moments. But the docker containers themselves are pretty simple.
      - geerlingguy 12y ago
        It depends on what you're doing inside the containers themselves. If you're simply pulling from a git repo to update a code checkout, and installing one or two things via apt/yum, shell script/RUN isn't so bad. If you're approaching containers more like 'lightweight VMs', the string of RUN commands gets unmaintainable, fast. That can indicate some deeper problems, but in some circumstances (and especially when making updates to your container images), using configuration management for individual containers can be helpful for the same reasons even CM-ifying a small single-purpose standalone VM can.
- mattjaynes 12y ago
  Thanks. Yeah, most of the misconceptions seem to come from folks without previous experience with self-managed virtualized setups. Those that have had that experience usually already understand the complexities involved. I'd also love to hear more stories about Docker vs the other virtualized setups. It generally seems to be a dramatic improvement in usability, performance, etc, but I'd love to hear more about the specifics from those who have made the switch. Here's a few production users: http://www.docker.com/resources/usecases/ http://www.docker.com/resources/usecases/ http://blog.docker.com/2013/12/baidu-using-docker-for-its-paas/ http://blog.docker.com/2013/12/baidu-using-docker-for-its-pa...
  - mikko-apo 12y ago
    We used Docker for the Hello World Open coding competition. We provided CI for the 2500 teams and also ran the competition using Docker (both on top of AWS EC2 instances). I think that without Docker the implementation would have been a lot more painful and almost impossible given the time constraints we had for the project. Fast starting and fast shutdown of build and test processes allowed us to run CI builds efficiently on a fairly small amount of nodes. This saved us money and also helped to keep the infrastructure manageable. Also the additional level of security was really nice since we were running possibly malicious code from 2500 sources. The malicious part became even more evident when Kevin Mitnick tweeted that he might participate: https://twitter.com/kevinmitnick/status/446359450614378496 https://twitter.com/kevinmitnick/status/446359450614378496 The Docker image repository was also really handy when we ran the races. We needed build the bots only once and then we could just use the prebuilt images on on race nodes. Building the actual base image was fairly painful. We support about 20 different programming languages and also package in quite a few libraries. Once the base image build was fully automatized and we had the Docker related processes fully working, it was almost a revelation on how Docker could improve things over the classical virtual machine approach. I can't wait to try it out on another project :) By the way, the competition finals are today (Tuesday) and streamed live @ https://helloworldopen.com/ https://helloworldopen.com/ (in English and Finnish)
    - wpietri 12y ago
      That sounds really interesting. Please document it! I'd be especially interested to read about the revelations.
- Alupis 12y ago
  My gripes: * half git-syntax/half package manager-syntax is cumbersome to me. * Inability to compile Docker from source without using the Docker Project's provided "black box" binary Docker. * No formal explanation of how to create your own base image from scratch (ie. not using a Docker Project provided base image). * Defaults to storing images in the Docker "cloud" repo. (would have preferred a git-like setup where pushing my images to a repo of my choice was more "normal") * GO Lang is still pretty obscure for most developers, and an interesting choice given the language's youth and likely-hood to change rapidly as it matures. * Docker is built on-top of existing Linux technologies, mainly LXC, making it more-or-less disposable in the future (as someone else figures out how to abstract/manage LXC better) * Docker is mainly built by Dotcloud - a for-profit company. Dotcloud has been very generous in their effort... but, being for-profit, what is their take out of it? (It can't be "just for the goodness of Linux").
  - lolo_ 12y ago
    > * GO Lang is still pretty obscure for most developers, and an interesting choice given the language's youth and likely-hood to change rapidly as it matures. The go authors have committed to keeping major versions stable since v1 and are unlikely to massively change anything. I'm sure much of google's infrastructure is coming to rely on go (and docker!) so they will be as unhappy about such drastic change as others.
    - Alupis 12y ago
      Fair enough point about GO Lang, however, should note Docker as a project was started way back when GO's future was... perhaps iffy. Maybe good foresight on the Docker project regarding GO Lang. However, this doesn't excuse the remaining gripes listed above.
      - nl 12y ago
        Fair enough point about GO Lang, however, should note Docker as a project was started way back when GO's future was... perhaps iffy. You mean 14 months ago?
  - 12y ago
zabcik 12y ago
I think CoreOS solves a number of these problems. It's no walk in the park to set up but it's a really nice stack.
fideloper 12y ago
Great article! Is it general consensus that Phusion's base image is a good way to go? It's what I've used so far, but I've yet to hear any consensus. I agree with the Docker Misconceptions article for the most part, but that might just be because it what makes the most sense to me (and I'm still likely ignorant of some important configuration to consider :D )
FooBarWidget 12y ago
Thank you for writing that article! I've been telling similar things to people over and over, but now I can just link to your article.

kiyoto 12y ago

Thanks for a great summary. >For logs, you can either use a shared directory with the host or use a remote log collection service like logstash or papertrail. I would not put Logstash (software) and Papertrail (SaaS) in the same bucket though. With Logstash (or any other data collectors like Flume, Fluentd, etc.) you need a backend system to go with it. Sorry to nitpick, but logging is something I work on/think about all day, so I thought to point it out.

wpietri 12y ago

Thanks, that's exactly the sort of thing I was hoping to learn from the HN comments. In the post you link above, it seems like you're mainly comparing Docker to traditional, non-virtualized setups. Do you (or does anybody) have thoughts on comparing it to virtualized environments? I recently experimented with Xen as a way to isolate services, and it seemed awfully heavy; does Docker end up being a lighter burden?

lojack 12y ago
It's lighter in the sense that it should require less resources to keep each container running, but comparable in the sense that you still need to orchestrate how services connect and how each container is configured.
- geerlingguy 12y ago
  This, exactly. I've heard many people talking about how Docker will put an end to a thousand different problems, especially regarding configuration management... But it really won't. You still need to be able to configure everything inside the container (thus the need for a CM tool), and then also the environment and infrastructure inside which the containers live (thus the need for infra management tools). Docker really doesn't make infrastructure management markedly easier—just faster, more flexible, and slightly more powerful. It's one layer of abstraction over a VM, IMO, and that's a good thing, but carries with it it's own set of complexities.
  - skrebbel 12y ago
    > You still need to be able to configure everything inside the container (thus the need for a CM tool) I'm missing something, but in what scenarios would you need to do something more complex than what can be expressed in a few RUN and ADD commands in a Dockerfile? My limited experience is that indeed, orchestration is still completely needed. We underestimated that and now we have a bunch of hacky shell scripts that build and start and stop docker containers at various moments. But the docker containers themselves are pretty simple.
    - geerlingguy 12y ago
      It depends on what you're doing inside the containers themselves. If you're simply pulling from a git repo to update a code checkout, and installing one or two things via apt/yum, shell script/RUN isn't so bad. If you're approaching containers more like 'lightweight VMs', the string of RUN commands gets unmaintainable, fast. That can indicate some deeper problems, but in some circumstances (and especially when making updates to your container images), using configuration management for individual containers can be helpful for the same reasons even CM-ifying a small single-purpose standalone VM can.
mattjaynes 12y ago
Thanks. Yeah, most of the misconceptions seem to come from folks without previous experience with self-managed virtualized setups. Those that have had that experience usually already understand the complexities involved. I'd also love to hear more stories about Docker vs the other virtualized setups. It generally seems to be a dramatic improvement in usability, performance, etc, but I'd love to hear more about the specifics from those who have made the switch. Here's a few production users: http://www.docker.com/resources/usecases/ http://www.docker.com/resources/usecases/ http://blog.docker.com/2013/12/baidu-using-docker-for-its-paas/ http://blog.docker.com/2013/12/baidu-using-docker-for-its-pa...
- mikko-apo 12y ago
  We used Docker for the Hello World Open coding competition. We provided CI for the 2500 teams and also ran the competition using Docker (both on top of AWS EC2 instances). I think that without Docker the implementation would have been a lot more painful and almost impossible given the time constraints we had for the project. Fast starting and fast shutdown of build and test processes allowed us to run CI builds efficiently on a fairly small amount of nodes. This saved us money and also helped to keep the infrastructure manageable. Also the additional level of security was really nice since we were running possibly malicious code from 2500 sources. The malicious part became even more evident when Kevin Mitnick tweeted that he might participate: https://twitter.com/kevinmitnick/status/446359450614378496 https://twitter.com/kevinmitnick/status/446359450614378496 The Docker image repository was also really handy when we ran the races. We needed build the bots only once and then we could just use the prebuilt images on on race nodes. Building the actual base image was fairly painful. We support about 20 different programming languages and also package in quite a few libraries. Once the base image build was fully automatized and we had the Docker related processes fully working, it was almost a revelation on how Docker could improve things over the classical virtual machine approach. I can't wait to try it out on another project :) By the way, the competition finals are today (Tuesday) and streamed live @ https://helloworldopen.com/ https://helloworldopen.com/ (in English and Finnish)
  - wpietri 12y ago
    That sounds really interesting. Please document it! I'd be especially interested to read about the revelations.
Alupis 12y ago
My gripes: * half git-syntax/half package manager-syntax is cumbersome to me. * Inability to compile Docker from source without using the Docker Project's provided "black box" binary Docker. * No formal explanation of how to create your own base image from scratch (ie. not using a Docker Project provided base image). * Defaults to storing images in the Docker "cloud" repo. (would have preferred a git-like setup where pushing my images to a repo of my choice was more "normal") * GO Lang is still pretty obscure for most developers, and an interesting choice given the language's youth and likely-hood to change rapidly as it matures. * Docker is built on-top of existing Linux technologies, mainly LXC, making it more-or-less disposable in the future (as someone else figures out how to abstract/manage LXC better) * Docker is mainly built by Dotcloud - a for-profit company. Dotcloud has been very generous in their effort... but, being for-profit, what is their take out of it? (It can't be "just for the goodness of Linux").
- lolo_ 12y ago
  > * GO Lang is still pretty obscure for most developers, and an interesting choice given the language's youth and likely-hood to change rapidly as it matures. The go authors have committed to keeping major versions stable since v1 and are unlikely to massively change anything. I'm sure much of google's infrastructure is coming to rely on go (and docker!) so they will be as unhappy about such drastic change as others.
  - Alupis 12y ago
    Fair enough point about GO Lang, however, should note Docker as a project was started way back when GO's future was... perhaps iffy. Maybe good foresight on the Docker project regarding GO Lang. However, this doesn't excuse the remaining gripes listed above.
    - nl 12y ago
      Fair enough point about GO Lang, however, should note Docker as a project was started way back when GO's future was... perhaps iffy. You mean 14 months ago?
- 12y ago

zabcik 12y ago

I think CoreOS solves a number of these problems. It's no walk in the park to set up but it's a really nice stack.

fideloper 12y ago

Great article! Is it general consensus that Phusion's base image is a good way to go? It's what I've used so far, but I've yet to hear any consensus. I agree with the Docker Misconceptions article for the most part, but that might just be because it what makes the most sense to me (and I'm still likely ignorant of some important configuration to consider :D )

FooBarWidget 12y ago

Thank you for writing that article! I've been telling similar things to people over and over, but now I can just link to your article.