
Docker Misconceptions - mattjaynes
https://devopsu.com/blog/docker-misconceptions/
======
waffle_ss
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/)

~~~
ollysb
>> I think part of the problem is that composition of images is strict
"subclass"-type inheritance, so they don't compose easily.

This does seem like a pretty major limitation, is this a fundamental
constraint or is it something that might be fixed in the future?

~~~
zaroth
The "subclass"-type inheritance is due to the underlying union filesystem
(AUFS). Each command in the Dockerfile is applied as a layer and then cached,
and each resulting image can be referenced as a starting point from another
Dockerfile.

So you can branch out from a common base image, but you can't somehow co-
mingle multiple parent images into one child. If you think about it like the
filesystem giving you a snapshot at each line of the Dockerfile, you can see
how inheriting from a single snapshot is trivial, but somehow inheriting from
multiple snapshots into one would require much more awareness in order to
merge them.

The practical effect is that either you build a more one-size-fits-all "base"
image which you reference for all your services, or you have multiple base
images with different more tailored sets of dependencies built up, or you have
a very thin base image (e.g. not much more than ubuntu-latest) and just add
what you need inside each individual Dockerfile.

I ran into the same issue at first when laying out the Dockerfile hierarchy
for all my services/roles, but I think in this case it actually falls under
"less magic is better" / KISS. Dockerfiles are so easy to read and write once
you get going, you won't mind the simplistic approach.

~~~
ollysb
It sounds like you need something else to help you build the dockerfiles then
i.e. I need a dockerfile with nginx, postgres and memcached so I use something
like puppet/chef to put it together, is that possible?

~~~
nl
It's easy to build new images from Dockerfiles. And "cut-n-paste" based
"inheritance" works well when combining two or more Dockerfiles into a single
one that has everything you want.

But you can't use composition to combine the actual downloaded images
themselves.

Using Chef within Docker to build up the services is documented on the Docker
site[1], and of course puppet or whatever is essentially the same.

[1]
[http://docs.docker.com/articles/chef/](http://docs.docker.com/articles/chef/)

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

------
thebyrd
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
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
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)

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

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

------
mattjaynes
Original comment and posting:
[https://news.ycombinator.com/item?id=7869831](https://news.ycombinator.com/item?id=7869831)

------
nickstinemates
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
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?

~~~
alrs
It's awesome, now the devs have to be on 24hr call with the ops people,
because they're the ones who built the environment.

Welcome to my world!

~~~
tacticus
We are just implementing this at my work.

IT IS THE GREATEST THING FUCKING EVER!!! (at least on call related)

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

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

------
zobzu
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
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
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 ;)

------
dschiptsov
_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.

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

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

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

------
fideloper
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)

~~~
yebyen
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.

