10 ms·

Docker Misconceptions

278 points by mattjaynes 12y ago

mattjaynes 12y ago
Original comment and posting: https://news.ycombinator.com/item?id=7869831 https://news.ycombinator.com/item?id=7869831
hesdeadjim 12y ago
I'd be curious to see how CoreOS might help simplify some of the issues you mention. I'm starting to dig deep into both and the learning curve is definitely a bit high.
- mattjaynes 12y ago
  Yeah, it's nice to see projects like CoreOS tackling the issues of using Docker in production. Hoping to see the complexities continue to be reduced as Docker (and its ecosystem) matures.
- cbsmith 12y ago
  I think CoreOS + Fleet directly address many of the gaps identified in this article. It's not the only way to do it, but it does seem like a particularly good way.
wmf 12y ago
I think you're going to need serious ops fu for "orchestrating deploys & roll backs with zero downtime" whether you use containers or not. It seems like people with complex environments are flocking to Docker despite its supposed complexity, but maybe that's the echo chamber talking.
- liveoneggs 12y ago
  echo chamber, social marketing, etc are all pretty much guaranteed. You can spot a group trying to create buzz/hype on here pretty easily and docker is having a coordinated marketing blitz with a new release.
  - nickstinemates 12y ago
    Being part of the community has been in our DNA since day 1. The project doesn't exist without it, and the major feeling we all have at DockerCon today is humility. I think characterizing our involvement in the excitement of today as being nothing more than a marketing blitz is disingenuous at best.
- mattjaynes 12y ago
  Yeah, it takes a decent level of ops skills for setting those up. It's certainly doable, but it's non-trivial. If setting those up seems daunting for a team, then it's not the right time to use Docker (in production at least).
- nickstinemates 12y ago
  For what it's worth, as you mention Docker solves a piece of the puzzle extremely well that is a boon to an entire ecosystem. That's awesome. We love all of the tools and technologies that the op mentions and our message to every one is - integrating with your existing tools is a fundamental goal of the company. Telling anyway to throw away the hard work and sweat they've invested in to the current status quo is antithetical to our mission.
- cbsmith 12y ago
  It only takes a high level of ops skill if your apps aren't designed for it. ;-)
  - jafaku 12y ago
    What does that even mean?
thebyrd 12y ago
I'm so glad someone finally said this publically. Everyone always writes posts about how magical docker is, but the reality is that Docker more of a PR engine then a usable production virtualization solution.
- lifty 12y ago
  I used Puppet for about 4 years in a critical production environment and let me tell you, Docker is not only hype. The reason why a lot of people(including me) are excited about Docker is because it brings a clean architectural paradigm to the masses, the same one used at Google and Heroku, the same one that many of us struggled to build behind closed doors at various companies. People that have used configuration management tools at scale in complex environments have seen that managing state using those respective tools can quickly become tedious. Although the recommendations of the author are fair, its takes a lot of effort to manage state drift on a whole platform using a configuration management tool. But if you use Docker, you will already be forced to think and do things in this new paradigm where there is separation between your data, business logic and service state. You can theoretically achieve the same things with CM tools, but its just harder. While the whole Docker ecosystem is immature, and people dont know how to deal with things once they get past 1 machine, its getting there and there is slowly more knowledge on how to do service discovery, logging, etc. in large environments. Im sure that in a few years we will look the same way at Docker(and other container tech) like we do at "heavy" virtualization now.
  - zobzu 12y ago
    I agree the concept is sound, that said Docker is quite a bit of a PR engine as the parent comment said. It also is far from mature enough for most. When it fails, good luck finding out whats happening, they don't log stuff. It needs a lot of management around it. Itll be much more useful when stuff like Flynn takes off, or when someone rewrite this stuff/fix this stuff for average sys admins (and by average im not saying theyre bad, im saying not everyone has an idle army of sysadmins just waiting to fix stuff)
- deleted 12y ago
  [deleted]
nickstinemates 12y ago
Interesting article! There are some misconceptions I disagree with, but I believe I agree with the spirit. What Docker does is allows those who are best qualified to make the decisions mentioned (the ops guys!) to have a clear separation of concerns from application developers. It doesn't magically solve this hard problems in and of itself.
- jacquesm 12y ago
  Developers probably see this the exact opposite way. Finally they get to package their stuff in such a way the ops guys won't be able to change it after it is delivered. Are docker containers 'tamper proof'? Can they be locked?
  - nickstinemates 12y ago
    Hit the nail on the head. > Are docker containers 'tamper proof'? Not yet. :)
    - alrs 12y ago
      I've been at events where Docker people were pushing this "separation of concerns" nonsense. Really? The devs build it, hand the black box to ops, and ops has no say in how things are built or even knowledge of how to fix it? You're pushing to make it so that ops is powerless to fix your "tamperproof" container? I haven't met very many devs qualified to work as ops engineers, and I've met even fewer interested in jumping in to opsland and joining on-call rotation. Containers are cool. Docker's "separation of concerns" and "tamperproof" messaging, however, is ridiculous. Devops was supposed to be about communication and ditching silos. The vision that Docker is pushing is anti-collaborative and unrealistic. The technology is interesting, the sales pitch is horrible.
      - jacquesm 12y ago
        It all depends on your use case. I can see some deployment situations where the ops people would be the ones asking for tamper resistance. If you're running a small shop with only few people and you're not in banking or some other branch of industry where mistakes are very costly then separation of concerns is probably not your main worry. But if you're operating with some auditor looking over your back then it can become a very powerful argument for using some technology over another. As with any tool: use it where it is appropriate. This all assumes that docker will make tamper-proof an option, not mandatory.
zobzu 12y ago
Im always wondering how people pinning versions manage software updates (security or not). If you grow to a few hundred (or thousand or hundred of thousand) systems, it seems pretty hard to test and install combinations, and even if its a single combination with regular updates, you still need a very well oiled and consistent automated testing.
- alrs 12y ago
  As opposed to not pinning versions and expecting your average Python/Perl/Ruby/PHP/nodejs library author not to introduce some crazy API breakage in a minor point release?
  - zobzu 12y ago
    either way has issues, yes if you manage more than a few projects, you already run into libs that will get updates and break things, at least weekly ;)
- jafaku 12y ago
  > you still need a very well oiled and consistent automated testing I would say this is true for any professional team. Nowadays I don't even develop personal projects without continuous delivery. The idea has been out there for years, and this year in particular there have been lots of articles explaining how to do it.
TallGuyShort 12y ago
There are 2 other misconceptions I would really like to be less prevalent: 1) Linux containers are not an entirely new concept. If you didn't know about BSD jails or Solaris zones, you were missing out. If you still don't know the differences, I highly recommend you broaden your horizons. Even if you use Linux anyway, just knowing about what's out there will help you be smarter. 2) Docker is not a drop-in replacement for every current VM use case. It's just not. To HN's credit, I really haven't seen people here who seem to think that, but it's on my list nonetheless.
- Kurtz79 12y ago
  I use a chrooted environment for development daily, but I didn't know of more advanced containment tools. I was fooling around with lxc containers over the last hour and they seem to me a much simpler concept to understand that the whole Docker ecosystem. Is Docker doing basically the same thing, but offering a more structured and controlled way of doing it ?
  - TallGuyShort 12y ago
    Docker could be thought of as a wrapper to LXC, providing some additional management capabilities and tooling. It's often described as a "packaging" format for applications, and you then deploy these applications in containers. So the application is actually all of userspace that you're going to use bundled together, and then run on a sort of "partition" of a kernel.
waffle_ss 12y ago
I was ready to come in swinging in defending Docker, but I found myself agreeing with most of the points after spending a lot of time with Docker over the last month (ported my Rails application's provisioning from Ansible to it). I would add to the list that it is currently hard to even find decent images of popular services that you would trust deploying to production (e.g. Postgres). I see with the launch of Docker Hub that they have some flagged as "official" now, but for example the Postgres one is a black box (no Dockerfile source available - not a "trusted build") so I can't trust it.[1] I've had to spend time porting my Ansible playbooks over to Dockerfiles due to this. I think part of the problem is that composition of images is strict "subclass"-type inheritance, so they don't compose easily. So it's hard to maintain a "vanilla" image rather than a monolithic one that has everything you need to run your particular service - so people just keep their images to themselves. For example, if I want a Ruby image that has the latest nginx and git installed, I can't just blend three images together. I have to pick a base image, and then manually add the rest myself via Dockerfile. Also, although Vagrant 1.6 added Docker syntax, you really have to understand how Docker works in order to use it. If you're learning Docker I'd stick with the vanilla `docker` syntax first in building your images, maybe using something like fig[2] to start with. At the end of the day it's another abstraction to manage. It does bring great benefits in my opinion, but the learning curve and time investment aren't cheap, so if you already have a suite of provisioning scripts it may not be worth it to make the leap yet. [1]: https://registry.hub.docker.com/_/postgres/ https://registry.hub.docker.com/_/postgres/ [2]: http://orchardup.github.io/fig/ http://orchardup.github.io/fig/
- mwcampbell 12y ago
  I don't know why the official Docker images aren't marked as trusted builds, but you can find sources here: https://github.com/docker-library https://github.com/docker-library
- liamzebedee 12y ago
  > it is currently hard to even find decent images of popular services Very true. I've yet to find a suitable image for a simple Nginx + Unicorn + Postgres + Rails setup.
simonlebo 12y ago
Great article. My understanding of Docker is quite new, so take my remarks with a grain of salt. One thing I would emphasise in the first paragraph is that you need at least other provisioning/configuration tools to set up the servers where the docker containers will be deployed to. I know it would obvious to most, but you would still need to start/stop these machines with correct docker install, firewalls rules, and probably more. The VM layer has been flushed out, but still exists and needs attention. After spending more than a week looking into Docker, my one frustration with Docker is that I have not found a way to correctly develop with it. Most of the docs I see are about deploying established apps, but I would love to see tutorials about how to develop, and start from scratch with it. Does Docker stand in your way when developing or does it make it easier? Maybe a solution is to create docker wrappers for our favourite framework that would abstract Docker. Anyways, I'd love to see more on this.
- jafaku 12y ago
  Once you have figured all out, it doesn't stand in your way at all, I really like developing with it. Personally, I use aliases for almost all of its commands. I have also created various scripts for automating things like configuring the SSH connection to the container, etc. Another thing you have to figure out is how to edit the code. My choice was to use a volume (only in dev), and download the code into a different directory inside the container. Then on the first run, an init script inside the container will clean the volume and move the code. It has been some painful months and I haven't even finished. I'm liking where I'm going and I'm almost there, but if I had known the work it would take I think I would have avoided it. But if you are a team it's definitely worth it. Devs can now install anything they want without asking the Ops people for permission (as you can imagine by this statement, I'm more a dev/devops than an ops guy). Oh one thing that does make it awesome though is its combination with Jenkins, if you are into continuous delivery. With those two, you can easily test all kinds of environments in the same machine without wasting resources, and thanks to Docker's cache it doesn't have to reinstall everything every time, it's really fast.
jafaku 12y ago
Dammit, you are a few months late. I learnt all the things you posted the hard way, and I agree on everything.
fideloper 12y ago
I'd like to hear what the consensus on using the Phusion base-image is. It seems to "fix" some pretty important issues with an Ubuntu base image, but I'm not sure they are really even "problems". I use Phusion's base image almost all the time, especially since I tend to group services together (nginx+php-fpm, for example). https://github.com/phusion/baseimage-docker https://github.com/phusion/baseimage-docker
- sophacles 12y ago
  Some of it also depends on use case... Some people use containers like lightweight vms. Others use it as a way to ensure a solid/consistent userland per process. Others still blend the two in various ways... I tend to think of it somewhere "a little more than just a consistent userland" but not a full running os image.
- yebyen 12y ago
  There is one serious issue that it helps me fix in my experience, and that's Upstart: a) doesn't work in docker, and b) is totally opaque to me. It's an obelisk of mystery. You're not supposed to read it, or understand it. I like runit. Until Ubuntu can transition to systemd, which is supposedly more friendly toward containers, if I'm going to use Ubuntu inside of docker containers I'm going to need to manage my own inits. Even read them. The work phusion puts into runit and making services work under runit in baseimage-docker is invaluable to me.
jijojv 12y ago
Thank you, as a veteran Operations Engineer couldn't agree more.
gazarsgo 12y ago
Only thing I took issue with was "Instead, explicitly define your servers in your configurations for as long as you can." Maybe you can get away with this for a small scale deployment, but "as long as you can" sends a bit too mixed of a message. You should only defer a service discovery implementation until you get to the point where you have more than one read path in your stack. IMO, as soon as you go from load balancer -> app -> cache -> database to having a services layer you should start thinking service discovery. The simplest bandaid is to leverage DNS as much as possible until you get even bigger, and use static CNAMEs.
XorNot 12y ago
Docker is one of those things I keep installing and uninstalling. I simply can never quite make it work for me as a use-case. My current commitment is to try looking at raw LXC again, specifically because it's VM oriented (and also because the unprivileged containers look more like what I'd want to target).
VLM 12y ago
The only thing I'd add to the "You don't need to Dockerize everything" section is be careful of dependencies and what the electric power companies call black start capability. However tempting it might be, don't virtualize all your deep infrastructure like your LDAP and DHCP servers or DNS or whatever as you'll inevitably find yourself after a power failure unable to light up your virtualization system containing your kerberos servers because every single KDC is down or whatever. Its happened... Most virtualization seems to push for the customer facing "app side" not infrastructure anyway. But its something to keep in mind.
dschiptsov 12y ago
a huge leap forward for advanced systems administration. - this is the one great misconception. How a user-level virtualization technology back from mainframe's era, reincarnated as FreeBSD jails years before solves the problem of, say, optimizing a "slowed down under heavy load" RDBMS server, via re-partirioning, profiling, reindexing, optimizing client's code, which, in my opinion has something to do with "advanced administration". But ok, nowadays we have new meaningless memes "orchestration", "provisioning", "containerization". What punks cannot grasp is that it absolutely doesn't matter how quickly and by which tool you will install some set of deb or rpm packages into some virtualized environment and run it. The real administration has nothing to do with this. It is all about adaptation to reality, data-folow analysis and fine tuning.

278 points by mattjaynes 12y ago

Original comment and posting: https://news.ycombinator.com/item?id=7869831 https://news.ycombinator.com/item?id=7869831

I'd be curious to see how CoreOS might help simplify some of the issues you mention. I'm starting to dig deep into both and the learning curve is definitely a bit high.

mattjaynes 12y ago
Yeah, it's nice to see projects like CoreOS tackling the issues of using Docker in production. Hoping to see the complexities continue to be reduced as Docker (and its ecosystem) matures.
cbsmith 12y ago
I think CoreOS + Fleet directly address many of the gaps identified in this article. It's not the only way to do it, but it does seem like a particularly good way.

wmf 12y ago

I think you're going to need serious ops fu for "orchestrating deploys & roll backs with zero downtime" whether you use containers or not. It seems like people with complex environments are flocking to Docker despite its supposed complexity, but maybe that's the echo chamber talking.

liveoneggs 12y ago
echo chamber, social marketing, etc are all pretty much guaranteed. You can spot a group trying to create buzz/hype on here pretty easily and docker is having a coordinated marketing blitz with a new release.
- nickstinemates 12y ago
  Being part of the community has been in our DNA since day 1. The project doesn't exist without it, and the major feeling we all have at DockerCon today is humility. I think characterizing our involvement in the excitement of today as being nothing more than a marketing blitz is disingenuous at best.
mattjaynes 12y ago
Yeah, it takes a decent level of ops skills for setting those up. It's certainly doable, but it's non-trivial. If setting those up seems daunting for a team, then it's not the right time to use Docker (in production at least).
nickstinemates 12y ago
For what it's worth, as you mention Docker solves a piece of the puzzle extremely well that is a boon to an entire ecosystem. That's awesome. We love all of the tools and technologies that the op mentions and our message to every one is - integrating with your existing tools is a fundamental goal of the company. Telling anyway to throw away the hard work and sweat they've invested in to the current status quo is antithetical to our mission.
cbsmith 12y ago
It only takes a high level of ops skill if your apps aren't designed for it. ;-)
- jafaku 12y ago
  What does that even mean?

thebyrd 12y ago

I'm so glad someone finally said this publically. Everyone always writes posts about how magical docker is, but the reality is that Docker more of a PR engine then a usable production virtualization solution.

lifty 12y ago
I used Puppet for about 4 years in a critical production environment and let me tell you, Docker is not only hype. The reason why a lot of people(including me) are excited about Docker is because it brings a clean architectural paradigm to the masses, the same one used at Google and Heroku, the same one that many of us struggled to build behind closed doors at various companies. People that have used configuration management tools at scale in complex environments have seen that managing state using those respective tools can quickly become tedious. Although the recommendations of the author are fair, its takes a lot of effort to manage state drift on a whole platform using a configuration management tool. But if you use Docker, you will already be forced to think and do things in this new paradigm where there is separation between your data, business logic and service state. You can theoretically achieve the same things with CM tools, but its just harder. While the whole Docker ecosystem is immature, and people dont know how to deal with things once they get past 1 machine, its getting there and there is slowly more knowledge on how to do service discovery, logging, etc. in large environments. Im sure that in a few years we will look the same way at Docker(and other container tech) like we do at "heavy" virtualization now.
- zobzu 12y ago
  I agree the concept is sound, that said Docker is quite a bit of a PR engine as the parent comment said. It also is far from mature enough for most. When it fails, good luck finding out whats happening, they don't log stuff. It needs a lot of management around it. Itll be much more useful when stuff like Flynn takes off, or when someone rewrite this stuff/fix this stuff for average sys admins (and by average im not saying theyre bad, im saying not everyone has an idle army of sysadmins just waiting to fix stuff)
deleted 12y ago
[deleted]

nickstinemates 12y ago

Interesting article! There are some misconceptions I disagree with, but I believe I agree with the spirit. What Docker does is allows those who are best qualified to make the decisions mentioned (the ops guys!) to have a clear separation of concerns from application developers. It doesn't magically solve this hard problems in and of itself.

jacquesm 12y ago
Developers probably see this the exact opposite way. Finally they get to package their stuff in such a way the ops guys won't be able to change it after it is delivered. Are docker containers 'tamper proof'? Can they be locked?
- nickstinemates 12y ago
  Hit the nail on the head. > Are docker containers 'tamper proof'? Not yet. :)
  - alrs 12y ago
    I've been at events where Docker people were pushing this "separation of concerns" nonsense. Really? The devs build it, hand the black box to ops, and ops has no say in how things are built or even knowledge of how to fix it? You're pushing to make it so that ops is powerless to fix your "tamperproof" container? I haven't met very many devs qualified to work as ops engineers, and I've met even fewer interested in jumping in to opsland and joining on-call rotation. Containers are cool. Docker's "separation of concerns" and "tamperproof" messaging, however, is ridiculous. Devops was supposed to be about communication and ditching silos. The vision that Docker is pushing is anti-collaborative and unrealistic. The technology is interesting, the sales pitch is horrible.
    - jacquesm 12y ago
      It all depends on your use case. I can see some deployment situations where the ops people would be the ones asking for tamper resistance. If you're running a small shop with only few people and you're not in banking or some other branch of industry where mistakes are very costly then separation of concerns is probably not your main worry. But if you're operating with some auditor looking over your back then it can become a very powerful argument for using some technology over another. As with any tool: use it where it is appropriate. This all assumes that docker will make tamper-proof an option, not mandatory.

zobzu 12y ago

Im always wondering how people pinning versions manage software updates (security or not). If you grow to a few hundred (or thousand or hundred of thousand) systems, it seems pretty hard to test and install combinations, and even if its a single combination with regular updates, you still need a very well oiled and consistent automated testing.

alrs 12y ago
As opposed to not pinning versions and expecting your average Python/Perl/Ruby/PHP/nodejs library author not to introduce some crazy API breakage in a minor point release?
- zobzu 12y ago
  either way has issues, yes if you manage more than a few projects, you already run into libs that will get updates and break things, at least weekly ;)
jafaku 12y ago
> you still need a very well oiled and consistent automated testing I would say this is true for any professional team. Nowadays I don't even develop personal projects without continuous delivery. The idea has been out there for years, and this year in particular there have been lots of articles explaining how to do it.

TallGuyShort 12y ago

There are 2 other misconceptions I would really like to be less prevalent: 1) Linux containers are not an entirely new concept. If you didn't know about BSD jails or Solaris zones, you were missing out. If you still don't know the differences, I highly recommend you broaden your horizons. Even if you use Linux anyway, just knowing about what's out there will help you be smarter. 2) Docker is not a drop-in replacement for every current VM use case. It's just not. To HN's credit, I really haven't seen people here who seem to think that, but it's on my list nonetheless.

Kurtz79 12y ago
I use a chrooted environment for development daily, but I didn't know of more advanced containment tools. I was fooling around with lxc containers over the last hour and they seem to me a much simpler concept to understand that the whole Docker ecosystem. Is Docker doing basically the same thing, but offering a more structured and controlled way of doing it ?
- TallGuyShort 12y ago
  Docker could be thought of as a wrapper to LXC, providing some additional management capabilities and tooling. It's often described as a "packaging" format for applications, and you then deploy these applications in containers. So the application is actually all of userspace that you're going to use bundled together, and then run on a sort of "partition" of a kernel.

waffle_ss 12y ago

I was ready to come in swinging in defending Docker, but I found myself agreeing with most of the points after spending a lot of time with Docker over the last month (ported my Rails application's provisioning from Ansible to it). I would add to the list that it is currently hard to even find decent images of popular services that you would trust deploying to production (e.g. Postgres). I see with the launch of Docker Hub that they have some flagged as "official" now, but for example the Postgres one is a black box (no Dockerfile source available - not a "trusted build") so I can't trust it.[1] I've had to spend time porting my Ansible playbooks over to Dockerfiles due to this. I think part of the problem is that composition of images is strict "subclass"-type inheritance, so they don't compose easily. So it's hard to maintain a "vanilla" image rather than a monolithic one that has everything you need to run your particular service - so people just keep their images to themselves. For example, if I want a Ruby image that has the latest nginx and git installed, I can't just blend three images together. I have to pick a base image, and then manually add the rest myself via Dockerfile. Also, although Vagrant 1.6 added Docker syntax, you really have to understand how Docker works in order to use it. If you're learning Docker I'd stick with the vanilla `docker` syntax first in building your images, maybe using something like fig[2] to start with. At the end of the day it's another abstraction to manage. It does bring great benefits in my opinion, but the learning curve and time investment aren't cheap, so if you already have a suite of provisioning scripts it may not be worth it to make the leap yet. [1]: https://registry.hub.docker.com/_/postgres/ https://registry.hub.docker.com/_/postgres/ [2]: http://orchardup.github.io/fig/ http://orchardup.github.io/fig/

mwcampbell 12y ago
I don't know why the official Docker images aren't marked as trusted builds, but you can find sources here: https://github.com/docker-library https://github.com/docker-library
liamzebedee 12y ago
> it is currently hard to even find decent images of popular services Very true. I've yet to find a suitable image for a simple Nginx + Unicorn + Postgres + Rails setup.

simonlebo 12y ago

Great article. My understanding of Docker is quite new, so take my remarks with a grain of salt. One thing I would emphasise in the first paragraph is that you need at least other provisioning/configuration tools to set up the servers where the docker containers will be deployed to. I know it would obvious to most, but you would still need to start/stop these machines with correct docker install, firewalls rules, and probably more. The VM layer has been flushed out, but still exists and needs attention. After spending more than a week looking into Docker, my one frustration with Docker is that I have not found a way to correctly develop with it. Most of the docs I see are about deploying established apps, but I would love to see tutorials about how to develop, and start from scratch with it. Does Docker stand in your way when developing or does it make it easier? Maybe a solution is to create docker wrappers for our favourite framework that would abstract Docker. Anyways, I'd love to see more on this.

jafaku 12y ago
Once you have figured all out, it doesn't stand in your way at all, I really like developing with it. Personally, I use aliases for almost all of its commands. I have also created various scripts for automating things like configuring the SSH connection to the container, etc. Another thing you have to figure out is how to edit the code. My choice was to use a volume (only in dev), and download the code into a different directory inside the container. Then on the first run, an init script inside the container will clean the volume and move the code. It has been some painful months and I haven't even finished. I'm liking where I'm going and I'm almost there, but if I had known the work it would take I think I would have avoided it. But if you are a team it's definitely worth it. Devs can now install anything they want without asking the Ops people for permission (as you can imagine by this statement, I'm more a dev/devops than an ops guy). Oh one thing that does make it awesome though is its combination with Jenkins, if you are into continuous delivery. With those two, you can easily test all kinds of environments in the same machine without wasting resources, and thanks to Docker's cache it doesn't have to reinstall everything every time, it's really fast.

jafaku 12y ago

Dammit, you are a few months late. I learnt all the things you posted the hard way, and I agree on everything.

fideloper 12y ago

I'd like to hear what the consensus on using the Phusion base-image is. It seems to "fix" some pretty important issues with an Ubuntu base image, but I'm not sure they are really even "problems". I use Phusion's base image almost all the time, especially since I tend to group services together (nginx+php-fpm, for example). https://github.com/phusion/baseimage-docker https://github.com/phusion/baseimage-docker

sophacles 12y ago
Some of it also depends on use case... Some people use containers like lightweight vms. Others use it as a way to ensure a solid/consistent userland per process. Others still blend the two in various ways... I tend to think of it somewhere "a little more than just a consistent userland" but not a full running os image.
yebyen 12y ago
There is one serious issue that it helps me fix in my experience, and that's Upstart: a) doesn't work in docker, and b) is totally opaque to me. It's an obelisk of mystery. You're not supposed to read it, or understand it. I like runit. Until Ubuntu can transition to systemd, which is supposedly more friendly toward containers, if I'm going to use Ubuntu inside of docker containers I'm going to need to manage my own inits. Even read them. The work phusion puts into runit and making services work under runit in baseimage-docker is invaluable to me.

jijojv 12y ago

Thank you, as a veteran Operations Engineer couldn't agree more.

gazarsgo 12y ago

Only thing I took issue with was "Instead, explicitly define your servers in your configurations for as long as you can." Maybe you can get away with this for a small scale deployment, but "as long as you can" sends a bit too mixed of a message. You should only defer a service discovery implementation until you get to the point where you have more than one read path in your stack. IMO, as soon as you go from load balancer -> app -> cache -> database to having a services layer you should start thinking service discovery. The simplest bandaid is to leverage DNS as much as possible until you get even bigger, and use static CNAMEs.

XorNot 12y ago

Docker is one of those things I keep installing and uninstalling. I simply can never quite make it work for me as a use-case. My current commitment is to try looking at raw LXC again, specifically because it's VM oriented (and also because the unprivileged containers look more like what I'd want to target).

VLM 12y ago

The only thing I'd add to the "You don't need to Dockerize everything" section is be careful of dependencies and what the electric power companies call black start capability. However tempting it might be, don't virtualize all your deep infrastructure like your LDAP and DHCP servers or DNS or whatever as you'll inevitably find yourself after a power failure unable to light up your virtualization system containing your kerberos servers because every single KDC is down or whatever. Its happened... Most virtualization seems to push for the customer facing "app side" not infrastructure anyway. But its something to keep in mind.

dschiptsov 12y ago

a huge leap forward for advanced systems administration. - this is the one great misconception. How a user-level virtualization technology back from mainframe's era, reincarnated as FreeBSD jails years before solves the problem of, say, optimizing a "slowed down under heavy load" RDBMS server, via re-partirioning, profiling, reindexing, optimizing client's code, which, in my opinion has something to do with "advanced administration". But ok, nowadays we have new meaningless memes "orchestration", "provisioning", "containerization". What punks cannot grasp is that it absolutely doesn't matter how quickly and by which tool you will install some set of deb or rpm packages into some virtualized environment and run it. The real administration has nothing to do with this. It is all about adaptation to reality, data-folow analysis and fine tuning.