
Why Docker Is Not Yet Succeeding Widely in Production - PolandKid
http://sirupsen.com/production-docker/
======
minimaxir
While the article goes into the more technical reasons for not using Docker in
production, the practical reason "Why Docker Is Not Yet Succeeding Widely in
Production" is that _if it ain 't broke, don't fix it._ The advantages of
Docker do not necessarily outweigh the opportunity cost of rewriting the
startup's entire infrastructure.

Docker will likely be more prevalent in a few years with startups who have
built their infrastructure form the ground up.

~~~
inopinatus
Docker solves a problem that most people don't have. It's not a PaaS, rather,
it's (some of) the building blocks to create your own PaaS. Most folks don't
need that. Most folks want to put files on a server and start a process. For
those folks, Docker in the raw ends up being a whole lot of confusing &
unnecessary scaffolding.

~~~
kentonv
Moreover, Docker / Kubernetes aims to solve the problem of building services
that can easily scale to hundreds of machines and hundreds of millions of
users, "Google-style".

That's great, if that's what you need. But most people aren't building a
service like that. HN, I believe, runs on one machine, with a second for
failover purposes. And HN still has many, many more users than typical
company-internal services, community services, or at the extreme end personal
services.

When you aren't operating at absurd scale, "Google-style" infrastructure
doesn't do you any favors. But the industry sure wants to convince us that
scalability is the most important property of infrastructure, because then
they can sell us complicated tech we don't need and support contracts to help
us use it.

(Disclosure: I'm the lead developer of
[https://sandstorm.io](https://sandstorm.io), which is explicitly designed for
small-scale.)

~~~
exarch
"But the industry sure wants to convince us that scalability is the most
important property of infrastructure, because then they can sell us
complicated tech we don't need and support contracts to help us use it."

And lets not forget: replace any and all efforts at code optimization with
"just throw another rack of blades at it".

~~~
digi_owl
[http://www.commitstrip.com/en/2015/07/08/true-story-
fixing-a...](http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a-
self-ddos/)

------
therealmarv
I would be sold on Docker if that would be easy. I have e.g. this stack:

\- 1 webserver/proxy, let's say nginx

\- 1 simple Rest API server, let's say in flask

\- 1 database, let's say PostgreSQL

and I want to connect all 3 things and I want to preserve logs for the whole
time and preserve the state of the database (of course). Also not to forget
make all bulletproof for the Internet.

And here all sorts of problems arise: What underlying OS, how to connect this
containers, how to preserve state of my database and logs (it's not trivial as
the article proofs again). So overall Docker makes life not easier on this
simple use-case, it makes life (of the sysadmin) more complicated.

~~~
knicholes
docker-compose comes to save the day when it comes to how to connect
containers. Your Dockerfile will specify which underlying OS is used. Preserve
state of your database with data volumes.

~~~
pothibo
docker-compose is no magic, it only maps a YAML file to docker's command
arguments. While I think docker-compose is useful in some cases, I strongly
advise to not use it at first so you understand how docker actually works.

Once you understand how docker works, using the YAML file can become useful to
lighten your load.

~~~
so0k
agreed, I used a bash script based on glowmachine github repo[1], but
switching to docker-compose made everything much easier - as long as you have
the knowledge of the docker cli.

[1] [https://github.com/glowdigitalmedia/glowmachine-
docker/blob/...](https://github.com/glowdigitalmedia/glowmachine-
docker/blob/c21f20e7ea687dd9532fdf88337a953b810a1c81/gm-env.sh)

------
iamleppert
I've said it before and I'll say it again: pre-mature infrastructure
optimization is the root of all evil.

Do me a favor and if you got a startup, stay clear of all this. Everyone wants
to reinvent their own flavor of heroku and make your deployment and build
pipeline god-awful complex. Their tool of choice? Docker.

Before you know it you'll be swimming in containers upon containers.
Containers will save us, they'll cry! Meanwhile you have 0 rows of data before
you've paid them their first month's salary and have spent time on solving
problems of scale you'll never have.

Focus on your product, outsource the rest. And leave customized docker setups
to mid-stage startups and big corps who already have these problems, or at
least the money and people to toil on them. Not everything needs to be a
container! And most companies are not and will never be Google!!

~~~
kosma
Until a few days ago I was a DevOps engineer at a medium-sized tech company.
My primary responsibility was dockerizing their applications and
infrastructure.

I quit the job.

The scenario played out just as you said: I ended up single-handedly and
poorly re-engineering something that already existed (they did have a working
Ansible setup) for no visible gain. _" Swimming in containers upon
containers"_ is exactly what happened; they _kinda_ worked, but the farther we
got, the more kludges piled on top of each other. In four months work we
didn't even hit production - the most we got was a CI/QA service that was
actually nothing more than a loose bunch of Python scripts. Between managing
dev/test/prod differences, tracing missing logs, removing unused volumes,
networking all that stuff together and trying to provide at least a decent
level of security, I realized that I'm wasting everyone's time and money.
Developers hated it because it filled their workflows with traps and
obstacles. Admins hated it because of the lack of tooling. Business hated it
because it caused unexplainable delays. The only thing we really accomplished
was _some_ compliance with the The Twelve-Factor App - something that could've
been done in a week. Hardly a victory.

My advice? Forget about Docker unless your primary business is building
hosting systems. It will take years before Docker gets mature enough for
production, and not without a _ton_ of tooling on top of it and some major
architectural changes. Until then, go back to the old UNIX ways of doing
things... it worked perfectly since the Epoch and it will continue to work
long after the 32-bit time_t rolls over. You'll be fine.

~~~
Nyetan
Bother you for a little advice? I'm working at a mid-sized tech company and am
evaluating Docker for CI, testing and limited, internal deployment usages.

The services in question are built with a hodge-podge of shell scripts and
build tools, so getting them all to compile locally is a challenge, let alone
deploying them. My hope was that containerizing the builds would isolate any
configuration problems, and that containerizing the deployed services would
cut down on outages by permitting trivial rollbacks (say, by snapshotting all
the service containers before each deploy and merely restoring them should a
deployment fail). Of course, all of the above could be fixed by traditional
means (e.g. rewriting the build system with a single, standard tool;
streamlining the deployment process, etc.), but it seemed like Docker could
solve 80% of the problems while easing the implementation of the proper
solutions down the line.

Considering the above, do you still think Docker's a poor fit for business
that aren't building hosting systems? Oh, and any nuggets of wisdom you could
throw to a newcomer to the industry? :)

~~~
boundlessdreamz
I think you will get more bang for the buck by using something like ansible or
salt (I have only used ansible and love it and I have heard salt is
comparable)

You don't have a standard repeatable way to set up an environment now. You
need to do that first before jumping on docker I think. Once you have that,
you can start replacing parts of the setup with docker and see if it fits your
needs.

The advantage of ansible is that it is idempotent and the changes it makes to
the system are the same ones you make manually or via bash scripts. So it is
quite easy to debug

~~~
Nyetan
Aah, brilliant -- and they even have a book :D thanks for the recommendation!

~~~
xorcist
The big pro with Ansible and similar tools is that the scripts are actually
very readable, with clear best practices.

If you come to a new place and "there's an error in here somewhere", the
difference between layers of images held together with shell scripts and a
Ansible/Puppet/Chef script is like night and day.

------
rubiquity
I think the reason is because the tooling and the companies (CoreOS, Joyent,
Weave, etc.) building all of the tools, are only focusing on grabbing Fortune
500 customers. Nobody is building Docker tools for the "Blue Collar Apps" of
the world. And those companies might be completely justified because the
benefits of Docker versus Amazon AMIs/RPMs/DEBs/etc. aren't that big enough to
make us go crazy for Docker and switch everything over and fork over cash to
these companies.

If I have less than 50 (maybe even 100) EC2 instances for my applications
there is no way in hell I am going to run 3 service discovery instances, a few
container scheduler instances and so on and so forth.

~~~
bcantrill
Disclaimer: I'm the CTO at Joyent.

For whatever it's worth, we completely agree with the sentiment (and I like
your "blue collar apps" term) -- and we deliberately have designed Triton[1]
for ease of use by virtualizing the notion of a Docker host. I think that the
direction you are pointing to (namely, ease of management for very small
deployments) is one that the industry needs to pay close attention to; the
history of technology is littered with the corpses of overcomplicated systems
that failed because they could not scale down to simpler use cases!

[1] [https://www.joyent.com/blog/triton-docker-and-the-best-of-
al...](https://www.joyent.com/blog/triton-docker-and-the-best-of-all-worlds)

------
filereaper
I think Simon nailed it with the points under this heading "Reliance on edgy
kernel features"

Officially Docker is only supported on RHEL 7 and up, and most systems I've
seen are still on RHEL6.

I think its just a matter of time before Docker goes into Production, where
I'm working we're seriously looking at "Dockerizing" lots of things, but OS
support keeps popping up.

~~~
e40
This, a thousand times. I'm on CentOS 6 and have switched to docker for some
services that don't easily run on that OS. However, I found out the hard way
that docker isn't supported on CentOS 6, by having some crashes when building
containers (due to bugs in devicemapper). Painful.

I really wish RH had found the time to fix RHEL 6 and support docker.

RHEL 7/CentOS 7 is a big step for many. RHEL 6 isn't even near EOL and many
people (including myself) wanted to get more mileage out of CentOS 6.

------
geerlingguy
Some of the points mentioned in the article are in my top hitlist (for
decidedly smaller production infrastructure than Shopify): Image building,
Logging, Secrets, and Filesystems.

But really, the most painful aspect of using Docker in production, at least in
environments where you need multiple physical servers (or VMs) is overall
orchestration of the containers, and networking between them.

Things are much better today than they were a year (or 6 months!) ago... but
these are two parts of Docker configuration that take the longest to get
right.

For orchestration: there are currently at least a dozen different ways to
manage containers on multiple servers, and a few seem to be gaining more
steam, but it feels much like the JS frameworks era, where there's a new
orchestration tool every week: flynn, deis, coreos, mesos, serf, fleet,
kubernetes, atomic, machine/swarm/compose, openstack, etc. How does one keep
up with all these? Not to mention all the other tooling in software like
Ansible, Chef, etc.

For networking: if you're running all your containers on one VM (as most
developers do), it's not a big deal. But if you need containers on multiple
servers, you not only have to deal with the servers' configuration,
provisioning, and networking, but also the containers inside, and getting them
to play nicely through the servers' networks. It's akin to running multiple
VMs on one physical machine, but without using tools like VMWare or VirtualBox
to manage the networking aspects.

Networking is challenging, but at least we have a lot of experience with VMs,
which are conceptually similar. Orchestration may take more time to nail down
and standardize.

~~~
mbrock
On these points, what are you comparing Docker to? Using bridged networking,
you have pretty much the exact same situation with Docker as without. And just
because you're running processes with Docker doesn't mean you have to keep up
with dozens of tools for automatic clustering and whatnot. If you want to just
start your processes manually, or with Ansible or Makefiles or whatever, you
can do that.

~~~
danesparza
Agreed -- "Logging, Secrets, and Filesystems" would be interesting problems to
solve in any architecture. Docker might shine a clearer light on any
inconsistencies -- but wouldn't make these any easier or harder.

------
zaargy
TL;DR It's too damn complicated if you're not Google/Twitter/Netflix. Most
people would be fine just deploying OS packages and keeping their stacks as
simple as possible.

~~~
zaargy
I still love Docker and do think it solves a genuine problem. But yes, where
to put your logs, how to manage state, how to schedule containers on machines,
how to coordinate processes, how to inspect an app when something goes wrong,
how to measure performance, how to manage security, how to keep consistency
across your docker containers... are all problems you need to solve from the
get go with Docker and they are all non-trivial! Ain't nobody got time for
that.

~~~
joslin01
I'm not sure how much you know about docker, so to anyone in whom this list
scares:

> Where to put logs

Well, I just throw them aside and use `docker logs [container]`

> How to manage state

One container should perform one service. I haven't run into a problem here.

> How to schedule containers

ECS :) But honestly, I subscribe to the approach that containers = services
and thus should just always be running.

> How to inspect app

`docker exec -it [ container id ] bash` ("ssh" into container)

`docker logs`

`docker -f logs` (follow logs)

> How to measure performance

Probably same way you measure system performance

> How to manage security

Everything of mine is in a VPN; some services can talk to certain services
over certain ports... Personally, I don't really understand all this talk
about security. Protect your systems and that should protect your containers.
Why is it that isolated processes are causing people to throw up their arms
like security is an unimaginable in such a world? There are ways..

> Consistency across docker containers

This can be a pain if you need this, yea. They see to be adding better &
better support to allow containers to talk to one another (and ONLY to one
another).

> Ain't nobody got time for that.

Hmm, personally I don't have time to go thru what Puppet, Chef, and even
Ansible require to get your systems coordinated. I see this as far more work
than creating a system specification within a file and finding a way to run it
on some system.

All comes down to requirements though and where your technical stack currently
is at. To any newcomers who are also plowing into the uncertain fields of a
dockerized stack, fear not! You are in good company and if I can make it work,
you can too.

~~~
TheDong
If this is your advice then you shouldn't give advice.

1) 'docker logs' relies on using the json logdriver which means the log file
is stored in /var/lib/docker/..... and grows forever. No rollover. No
trimming. _FOREVER_.

2) What if your container dies? What if your host dies? Do you have any state
at all or have you abstracted that out? Are your systems distributed

3) Always running does not answer finding where to run them

4) That only works if the container is running. What if it died? Also, docker
logs is a fool's game

5) bingo, that's right at least

6) ....

~~~
lucaspiller
> 1) 'docker logs' relies on using the json logdriver which means the log file
> is stored in /var/lib/docker/..... and grows forever. No rollover. No
> trimming. FOREVER.

Even without that issue, I'd prefer my logs to be centralised. So as well as
my app should I be running a logging daemon, process monitoring, etc for each
docker instance?

~~~
hibikir
What we do at work is that we have our containers be in charge of talking
'out' on a given address and format for logs, and have things configured so
that entire sets of machines end up speaking with the same log server (an ELK
stack, in our case). The process monitoring is done per host: There are
docker-aware tools that look at the host, and can peer into the container, to
do this basic tracking.

People are not kidding through, when they say that everything gets very
complicated. All the things that we did by convention and manual configuration
in regular VMs that are babysat manually have to be codified and automated.

Docker is going to be a great ecosystem in 3 years, when the entire ecosystem
matures. Today, it's the wild west, and you should only venture forth if
having a big team of programmers and system administrators dedicated just to
work on automation doesn't seem like a big deal.

------
saosebastiao
I'm pretty disillusioned with docker so far. Haven't put in too much time with
it, but the little time I have put into it has produced nothing of value. I'm
surprised we're still talking about it to be honest, with so much progress in
unikernels like OSv, HalVM, Mirage, and Ling.

In the two hours I've spent with OSv, I've gotten _much_ lighter weight VMs
that boot my large scala app extremely quickly (a few seconds, max), with less
configuration and more predictable performance.

------
technofiend
Just my personal opinion but Docker still reflects the developer-centric
culture that inspired it and by that I mean security is still getting more
mature but isn't quite there yet.

For instance there's still work being done to add native PAM and by extension
Kerberos support, and the daemon runs as root, thus requiring extra caution
about who may run docker commands.

If you're (for example) in an enterprise where developers may never have root
access under any circumstances, you end up with a chicken and egg scenario: if
developers don't have the ability to test container creation (because doing so
might grant them root access in a container), who does?

~~~
Smushman
This is why it is not yet adopted by DevOps and IT 'in the wild'.

In summary from a person in that scenario:

1\. Not known of and too short of time horizon - People still run Windows XP
in the real world. Changes where the rubber meets the road (IT and DevOps)
take years of hard evidence, infrastructure cost, justifications, etc. to
catch on. It does not behove these groups to be an early adopter.

2\. Not flexible enough yet - I have a ton of use for this if I could run it
more like a VM but faster and easier to deploy. I devop with a product that
uses its own kernel... I tried to talk Dev in to compiling a kernel with
Docker for a use case I have - you can guess where that went.

Docker is great, but I can only use it with my devs in its current state and
for myself in specific cases.

------
benjaminwootton
"However, for many production users today, the pros do not outweigh the cons.
Docker has done fantastically well at making containers appeal to developers
for development, testing and CI environments—however, it has yet to disrupt
production."

I keep hearing about people putting Docker in dev and test environments and
not production. This use case makes no sense to me as you would throw away the
entire point of containers and have a wildly inconsistent path to production.

~~~
superuser2
Not necessarily. If you're in a microservice architecture, it can be very
attractive to "docker run" all the services you're developing against on your
development VM.

Relying on Puppet (as with prod) means development VM setup/change time is
measured in hours. My company's Puppet catalog takes 15 minutes to _compile_ ,
6 hours to run. Entire days of developer productivity are lost trying to get
development VMs working. Docker would make that instantaneous. It's also very
hard to manage and synchronize data (i.e. test fixtures) across all those
services. With Docker you could have a consistent set of data in the actual
images and revert to it at will.

------
limaoscarjuliet
I work in a place which, in order to solve the dependency nightmares, had some
highly paid people do magic tricks manually in order to save the day... every
day. Every upgrade was hell. Yes, we have Director of Upgrades.

Simple tools (rpm + yum + docker) allowed us to replace these people with a
simple shell script. Literally.

I agree with the article Docker is missing some things. Two that I would like
to see: \- Auto cleanup \- Clean and easy proxying

------
DannoHung
Hey, cool, trough of disillusionment!

That means we're like a year away from it being boring and just working,
right?

------
scurvy
I still haven't been sold on Docker. Why would an otherwise competent company
that runs things just fine, ditch it all and adopt Docker? Just because it's
the shiny new thing? What do we actually gain here in production?

~~~
stdbrouw
Because "running things just fine" across production, continuous integration
and on dev machines is actually quite a hard thing to do.

But then, if you don't feel like you need it, that's probably because you
don't need it.

(If people are downvoting your question, it's probably because you're giving
off a bit of a "I don't understand Docker so it must be crap" vibe, which is
not helpful.)

~~~
scurvy
OK, now we're getting somewhere. What is difficult about getting things right
across production and CI? What are the pain points? What are the exact
problems we're being asked to solve here? I don't think dev environments need
to be harmonized the same as production. If your tests are good, you should
catch _most_ of the "it worked on my laptop" problems.

Sorry if my initial question came across with a weird vibe. I'm generally
curious. I have colleagues working at places and they actually are being asked
to drop everything and implement Docker. I asked why and what's driving this
and got the predictable response of "management/dev/someone wants something
new".

~~~
zaphar
Most "it worked on my laptop" problems get caught somewhere between commit and
push to production. What docker helps with is catching them "early" rather
than "later". Because a failed push emergency push with reason "Doesn't work
in production environment" as a reason is a really stressful way to work.

Catching it before pushing your changes is _far_ more preferable.

There are a lot of different methods and processes to fix this. Docker is a
new one that simplifies a number of the pieces of the puzzle by constraining
the environment is useful ways.

However, if you already have a process worked out and aren't experiencing pain
then you probably don't need to switch for the sake of switching.

------
AaronFriel
I thought the obvious reason was storage. I don't see it mentioned here, but
storage is a huge pain point. How do you store your critical data "with
Docker" is a labyrinthine set of steps.

Docker's answer to storage so far has been "don't use Docker". That's their
answer. Use volumes to map some other storage, but then you have to have some
way of mapping storage to containers outside of Docker. Now you're really
stuck.

Containers are awesome, but unless your product doesn't do work, you'll need
to store data at some point. And that's when the magic stops.

------
x5n1
This tutorial shows how to deploy a micro docker container with WordPress.
Each microcontainer has its own instance of Nginx and PHP-FPM. An Nginx server
as a proxy sits on the front end serving connections to one or more sites
hosted in the containers. It uses Alpine Linux and persists all data on the
host's file system. The logging is also available on the host system. The
benefit of doing it this way is that each site sits in its own container, so
if it is compromised, no harm comes to any other site or services running on
the host system.

It also does not link containers, instead opting to attach the database to the
first IP address of the network Docker sets up, thereby avoiding the need for
complicated service discovery. It also includes instructions on how to deploy
Redis on the same box and use that with WordPress. Also includes instructions
on how to do SSL for each site. It's being used in production.

[http://www.dockerwordpress.com/](http://www.dockerwordpress.com/)

------
amouat
For a forum like this, it should go without saying that many of these problems
are really opportunities for successful businesses.

Containers are only going to grow in uptake; companies like Weave and
ClusterHQ have a very bright future if they can solve real pain points like
the ones in this article.

------
mariusmg
Maybe because Docker isn't really needed ?

I mean if your app needs the entire fucking OS to provide isolation from other
apps, then you are clearly doing it wrong.

~~~
mrweasel
Don't underestimate the amount of people doing things wrong.

Docker could be much more successful in the Windows world, the ability to
package very precise versions of databases, libraries, weird obsolete
application into one image that can be deployed easily would be extremely
helpful in many companies. It would be the wrong solution, but an easy work-
around for broken upgrade paths.

~~~
stephengillie
As a Windows admin, this sounds like a recipe for disaster. My networks are
already getting crowded with Appliances and Appliance VMs that are provided to
us as black boxes, and we have to depend on a 3rd party for security patches
and a durable security implementation.

Having containers able to package weird obsolete (unpatched) applications,
specific (out-of-date) versions of libraries, and poorly-written homespun code
is a recipe for exploits. The out-of-date version of the library (e.g. Java 7)
likely has exploits out in the wild that have been patched in more recent
versions. The weird obsolete application (e.g. DTS) likely not only has
exploits patched in the active codepath, but has multiple bugs and integration
issues. The homespun code likely reimplements something done better in another
application or library, and introduces more bugs and vulnerabilities to the
network.

Sorry for going off on this, but being able to repackage unsupportable
applications would be a nightmare in places I've worked before.

------
nailer
The security question (it's possible to break out of containers) isn't solved,
and the workaround (use VMs) eliminates many of the advantages of containers
and adds a massive burden.

~~~
amouat
> it's possible to break out of containers

Prove it. I'm not saying it's impossible, but it's certainly not trivial.

Also, take a look at what Joyent are doing with Triton.

~~~
jgrowl
I was going to mention Triton/SDC. It does solve the security issues though it
does it by running SmartOS. SDC is pretty cool but docker really needs to be
secure in its own right.

It is also worth mentioning that since Joyent has implemented their own docker
client, not all features are there yet. Last time I tried docker-compose
didn't really work right yet. There is a full list of divergences on their
github page. It has a lot of potential though.

~~~
lloydde
> since Joyent has implemented their own docker client

Not our own docker client, our own Docker engine,
[https://github.com/joyent/sdc-docker](https://github.com/joyent/sdc-docker) ,
which was necessary for the whole DC to be the host. For a taste of the
details see [https://www.joyent.com/developers/videos/bryan-cantrill-
virt...](https://www.joyent.com/developers/videos/bryan-cantrill-virtualizing-
the-docker-remote-api-with-triton) .

Your larger point is correct, we're still working hard every day to add
increase the support particularly for the newer docker apis and extensions.
Now, docker-compose 1.2 is working in the production datacenters with docker-
compose 1.3 in the east-3b (beta) dc.

[https://www.joyent.com/developers/triton-
faq](https://www.joyent.com/developers/triton-faq)

[https://github.com/joyent/sdc-
docker/blob/master/docs/api/di...](https://github.com/joyent/sdc-
docker/blob/master/docs/api/divergence.md)

------
morgante
Where's the evidence that Docker _isn 't_ succeeding widely in production? In
the past week alone I've talked to a dozen or so companies who are all using
it in production.

------
markbnj
I agree with many of the points expressed, and as someone who has used docker
in production I have run into many of these issues myself. At the same time, I
value composability and I don't want docker to have a single monolithic
approach to everything. Garbage collecting old images, fine, even though its
not that hard to deal with the issue. Logging and distribution of secrets
don't feel like docker-level concerns to me. There are good solutions for
both.

------
novaleaf
I run a tiny startup, and honestly don't see a benefit to using docker.

Every service I deploy gets it's own VM (which is automatically
provisioned/locked-down by a bash script), and they automatically update when
a new revision is pushed to our production git branch.

It seems that docker is more useful when you have physical hardware? and/or
lots of under-utilized infrastructure?

~~~
boomzilla
Yes, and even when you run your own hardwares, it's still far easier to just
KVM up your virts and "bash bootstrap.sh". For your developers, tell them to
"vagrant up" with the same "bootstrap.sh". This setup and a Jenkins server for
build artifacts solves all my devops needs.

------
davexunit
I like Linux containers, but Docker's image layering system and imperative
Dockerfiles have got to go. A lot of pain points can be fixed by using
declarative, functional package management and not relying on COW file system
hacks to sort-of deduplicate files amongst many containers.

------
joslin01
I wrote about my experience with deploying Docker & ECS here:
[https://news.ycombinator.com/item?id=9759639](https://news.ycombinator.com/item?id=9759639)

I'm frustrated though because I keep pinging them about adding branch
information to their (dockerhub) webhooks so I can actually deploy
environments via branches.. It's crazy vital in my opinion and seems like it
should be an easy fix, but 2 months later and still doesn't seem to be
scheduled in.

Nevertheless, I'm sure Docker has its technical shortcomings but really, I
wouldn't say it's not succeeding.. it's just young. Adoption takes time.

~~~
loki77
Just up front: I'm one of the folks developing Empire.

That said, what we do is we have our CI system build our docker images, push
them to dockerhub (private registry) if the tests all go great, and then we
deploy using
[https://github.com/remind101/deploy](https://github.com/remind101/deploy). We
also tag all our images with the git SHA that they were created from, so we
have immutable identifiers for each image, which has been useful.

We just recently put direct github deployment support in Empire, so that's
been really nice (before we had to use another service that pulled deployments
and put them into Empire).

Anyway, not quite the workflow you're talking about, but it's really worked
well for us, so maybe it'd help you as well :)

------
icedchai
It's not succeeding because it's usually not necessary.

------
hangonhn
From my experience it is still buggy. For example, this bug:

[https://forums.docker.com/t/docker-export-intermediate-
size-...](https://forums.docker.com/t/docker-export-intermediate-size-
multiple-times-container-size/2537)

No one seems to know anything about it.

Also, when we upgraded from 1.6.3 to 1.7, devicemapper started having issues.

On top of the bugs, the limited networking support is very, well, limiting.

I would be very hesitant about using it in production at the moment. That
said, I can also see the potentials and it seems to be heading in the right
direction. It's just not ready at this moment.

~~~
scjody
Yes indeed. I'll trust Docker in production when I can go 6 months without
hitting any weird bugs like that, or having to wipe out `/var/lib/docker` and
restart the daemon to get it out of some inexplicable state.

------
gusfoo
> Configuration management software like Chef and Puppet is widespread, but
> feel too heavy handed for image building. I bet such systems will be phased
> out of existence in their current form within the next decade with
> containers.

Hmm, I don't think so. My reason is that, in addition to the maturation and
feature growth of containers, there will also be feature growth in Puppet et
al.

------
Animats
Docker is part of the first generation of a good idea - containerization. The
problem is that there's too much stuff in the box. Each application doesn't
need its very own copy of everything. You get portability at the expense of
maintaining your own distro. There will be a second generation of this,
hopefully not so bulky.

------
siliconc0w
Just to oppose the pessimism here - we use docker in production and so far it
has worked pretty well. We do run into the problems mentioned in article but
they aren't insurmountable. We also built a tool around cluster/deploy
management just like we had to do with chef.

IMO any tool that does procedural run-time configuration like
chef/ansible/puppet will generally be inferior to an image based infra
management solution. (unless you're using said tools to build images - which
is another ball of wax that will likely end up looking like a reimplemented
docker)

The problem with procedural run-time config is that unless you blow away the
VM, build from scratch, and run a test suite you don't really have good
assurances your infrastructure is in a good state. With images, you have a bit
for bit copy of what was built and tested in CI or QA. This is, for us, worth
the price of admission.

------
pjotrp
Docker for reproducible Science is an intermediate solution. While a Docker
image can be moved and rerun (with some luck) the content of a Docker image is
actually _not_ transparent.

Reproducibility implies being able to regenerate the full container including
software version control and visibility of the full dependency chain all the
way down to BLAS and glibc! You can't do that by using apt, rpm, Perl CPAN,
rubygems, Python pip and the like. None of these package managers have been
designed for true isolation of packages and full reproducibility. That is why
today people go with Docker. The shortcomings of these package managers drive
people to Docker.

The technology for regenerating exact Docker containers exists in the form of
GNU Guix and/or Nix packages. The fun fact is that when using GNU Guix, Docker
itself is no longer required.

Watch GNU Guix.

------
peterwwillis
Am I the only person noticing that these problems only exist because you're
using containers, and that maybe by not using a container model you can
simplify everything except running 10 different versions of an app at once?
Maybe containers provide more headaches than they solve.

------
dcosson
The security point here is something that confuses me about the current state
of the ecosystem.

The article mentions that "most vendors still run containers in virtual
machines", presumably since if someone hacks an app in a container they might
be able to break out of the container and access other apps running on that
host. But clustering systems like Kubernetes, CoreOS, AWS Container Service,
etc. seem to be all the rage these days and they seem fundamentally at odds
with this. The cluster might schedule multiple containers on the same host at
which point somebody who hacks one can hack all of them.

How do you reconcile this? Do people running these clusters in production
typically run tiers of separate clusters based on how sensitive the data they
have access to is?

~~~
Leon
Once you've automated the entire process of bringing up a container cluster
with monitoring, metrics, logging, etc then it becomes trivial to make as many
as you want. The same is done with separate virtual networks for security
concerns.

It becomes as simple as asking what name the cluster should have.

It also makes sense from managing resource concerns to some extent, such as a
cluster with cheap instances for low priority applications but need HA support
or a cluster with beefy instances in a subnet that has fewer hops should be
used for edge tier applications.

------
oldmantaiter
Using Docker as a local development system (especially with boot2docker on OSX
creating a bunch of containers with different major versions of OS (el6/el7
for example) and being able to develop/test multiple apps at the same time is
the only benefit I can justify for Docker.

But that's as far as I will take it, Docker is mainly used (from what I've
seen) as a nice way to package something without having to write an actual
package (RPM/deb) that will work across multiple platforms (for the most
part). If you take the time to learn how to properly package your application,
docker is unnecessary in almost every case.

------
emergentcypher
My application compiles to a jar that runs on a server and expects an
accompanying config file. I've tried giving Docker a whirl a few times and I
never fully understood what need I had that it was solving.

~~~
why-el
Is your application just a jar? In the yes case your conclusion is correct.

Throw in a database, a cache server, couple of versioned libraries your jar
file needs, and more developers, and suddenly a reproducible image with all
this packaged will make a lot of sense.

~~~
emergentcypher
Our build process already includes the application's dependencies inside the
jar, and packages it into an installable deb file that places the app, its
config, and the init file in the right locations.

I have a database and a cache server. They don't run on the same server as the
application jar... they run on separate machines tuned to their purpose. Why
would I want them packaged together? So my team doesn't have to run "apt-get
install postgresql" on their dev machines? Or to maintain an exactly
consistent dev environment?

------
shepardrtc
I think containers are the future, but I think this generation is still a bit
early for widespread use. Once they get polished a bit and are made easier to
use, then I think companies will begin adoption.

------
mc_hammer
the comments nailed it here too ;d

ill highlight the website is off by one... reading the website i have no idea
how it works and what technical debt im adding to my teams stack by using it.
"Build/Run/Ship", I'm doing that already. I have no idea if its using VMs or
something else for containers. no idea if my hardware works on it. and no idea
if the distros used for images are 1 year old or -nightly, so whos security
issues am i inheriting?

------
reidrac
So far my experience with Docker has been quite exciting, but I'm still to
find a real good use case for it.

Also moving around a 700MB+ image when you can deploy some Debian package (or
even setup a virtualenv, I do mostly Python), sounds a waste of resources. Add
to that that moving volumes around is still an issue and... well, Docker has a
lot of potential, but I doesn't fit very well in any of the projects that I'm
involved in.

------
DyslexicAtheist
docker security issues[0] should really be listed as #1. The
overhead/complexity of getting it secure (using SELinux) outweigh its benefits
in production.

[0] [http://blog.valbonne-consulting.com/2015/04/14/as-a-goat-
im-...](http://blog.valbonne-consulting.com/2015/04/14/as-a-goat-im-skeptical-
of-dockers-hype/)

~~~
mixmastamyk
I don't think its a good choice if security is a main concern. I wouldn't put
multi-tenant apps on it either.

------
cyansmoker
Regarding the author's point on reaping children, it is a well know issue. I
wrote (and I'm sure I'm not alone) a replacement 'process 1' for that:
[https://github.com/Fusion/cfr_reaper](https://github.com/Fusion/cfr_reaper)

------
peu4000
I'd really love to include docker in our puppet testing framework, so we can
do actual meaningful tests without deploying to real environments.

But, dealing with all of the problems of deploying docker to production
doesn't look worth the time investment for a medium sized company IMO(we're at
~1700 vms)

~~~
omni
What does vms stand for?

~~~
Synroc
Virtual Machines

------
krzrak
"it has yet to disrupt production" This overused buzzword in context of
production looks ridiculous.

------
crb002
I would venture to say that Packer/Mesos is far more important than Docker.
You get automated full infrastructure builds from source or trusted binaries,
and full cluster management. Docker is useful when you have many layers of
apps turtled together as snowflake configurations.

------
altcognito
It is still early, and it took nearly half a decade to get companies to use
cloud services and that has a well defined API for orchestrating resources. It
will take similarly long for containers to have well tread paths for
discovery, logging, failover, image building etc... etc..

~~~
omouse
_it took nearly half a decade to get companies to use cloud services and that
has a well defined API for orchestrating resources_

There's lots of stragglers; sometimes it's a struggle to get people to even
consider AWS for development boxes.

------
stephengillie
I'm confused by this paragraph

> _Every major deployment of Docker ends up writing a garbage collector to
> remove old images from hosts. Various heuristics are used, such as removing
> images older than x days, and enforcing at most y images present on the
> host. ..._

More specifically, I'm confused by this sentence, from the above paragraph in
TFA:

> _Most people discover their need by accident when their production boxes
> scream for space._

When did Docker become a replacement for Ops or Devops which are aware of
their servers, monitoring systems that let you know when you're getting close
to the "Yellow Alert" warning, and some sort of plan for growth and expansion?

Hardware isn't free, but it seems like some want Docker to make hardware free;
delivering on the promise that full-OS VMs couldn't realize, which was trying
to deliver on the promise that HT couldn't make happen. I'm sorry, but if you
have 24 cores and 64GB of RAM, there's only so many ways to schedule and swap
to maximize use of those resources.

\---

Copy on Write (COW) sounds like Thin Provisioning. Thin Provisioning is known
for 2 things: 1. Slower performance than "Thick Provisioning" where the entire
allocated space is zeroed on allocation, instead of on write. And 2. Ease of
overallocation - you can take a 100GB disk and create 10 virtual disks of
100GB each; this is like reserve banking, and it's only a problem if someone
actually wants to use the entire resource that you say they can access.

I'm curious if they'll have an NTFS option. Actually, with Microsoft's recent
open sourcing, I'd be interested to see NTFS open up a bit; maybe get an
official Linux driver of some sort.

Will there be other write methods? Perhaps one that's more similar Thick
Provisioning?

\---

I'd hate to see VMs die. The flexibility and value they provide to the
Microsoft world is unparalleled. I could see Dockers replacing Linux etc VMs
-- no need to run CentOS(?) to host your LAMP stack when you can just have
each letter in its own cluster of containers.

Maybe if each Windows component was rerolled as a container image; we could
have Domain Controller (DNS/AD/LDAP/Kerberos/ACL) containers, IIS containers,
SQL containers, DFS containers that were backed by SAN or NAS, FTP containers,
TFS containers, etc. And there would have to be RDP/VDI containers, where
users could remotely connect, and work in the environment with a desktop and
GUI tools, since that is such a core part of the Microsoft ecosystem.

\---

Looking at the Security and Image Layers and Transportation sections makes me
realize how young this technology is. In a few more years, a few more
iterations, and this could definitely replace numerous VM Appliances and
Middleware devices. The time for Dockers and containers isn't quite today, but
it's very close.

~~~
danesparza
"The time for Dockers and containers isn't quite today, but it's very close."

Hmmm ... tell that to AirBnb ([http://nerds.airbnb.com/future-app-
deployment/](http://nerds.airbnb.com/future-app-deployment/)), New Relic
([https://blog.newrelic.com/2014/08/12/docker-
centurion/](https://blog.newrelic.com/2014/08/12/docker-centurion/) ) and
Spotify ([https://blog.docker.com/2014/06/dockercon-video-docket-at-
sp...](https://blog.docker.com/2014/06/dockercon-video-docket-at-spotify-by-
rohan-singh/))

It is a young technology, but moving quickly. Just 10 years ago, YouTube
wasn't owned by Google yet and we didn't have the first iPhone.

Hell, 17 years ago VMware (arguably the king in the virtual machine software
market) was founded. If it was a kid, it wouldn't have graduated from high
school yet!

~~~
vezzy-fnord
I don't understand how "Companies are using containers." suddenly translates
to containers being ready for prime time.

------
Moter8
Offtopic: [http://i.imgur.com/E3UyqFO.png](http://i.imgur.com/E3UyqFO.png)
Well, that was weird. A refresh fixed it. Chrome 44.

------
kitwalker12
I think the author missed orchestration. docker-swarm/docker-machine is still
not production ready and kubernetes is too damn complicated to setup outside
GCE

~~~
brendandburns
(acknowledgement, I'm a contributor to Kubernetes)

It is well supported on AWS as well, and a variety of bare-metal solutions
(e.g. Red Hat Atomic, CoreOS)

However, concretely, it is a challenge to maintain good support for N
different platforms without an owner who is willing to stand up and ensure
that it works, and continues to work for that platform.

We have gotten a number of drive-by contributions of "how to" guides that
(sadly) bit-rot over time. As always, we're working on improving the
situation, but it is complicated and requires a great deal of time and access
to infrastructure (e.g. Rackspace) that the core team simply doesn't have.

~~~
brendandburns
(which is a long-winded way of saying: PRs welcome, please help us make it
better ;)

------
ksec
I always think Docker is just another layer of complexity. Which most people
dont need or shouldn't have

------
biturd
>Developing the public mental model of containers is integral to Docker’s
success and they’re rightly terrified of damaging it.

I guess you can all call me a moron or close to it, to this day, I don't know
what a container is good for.

I'm reading this now:
[https://www.docker.com/whatisdocker](https://www.docker.com/whatisdocker)

Is this server level, user level, both? Something else? I saw a Hacker Con
video and someone was basically containerizing all their apps so that the
underlying OS basically did nothing but run the hardware and containers.

Does this mean, one day, instead of monitoring my installs on Mac OS X to see
what files were put where so when something breaks I can find those files? I
could simply install to a container, my OS would not be touched, and I could
delete the container and be back to a stable state?

Can you even get OS X to run on a container? Would it be a good idea or even
feasible to install PhotoShop in a container, or not even possible, as that
app tosses stuff all over my OS.

Or, is this more like a different way to do things, but it is still AWS and
their AMI's or Digital Ocean or any of the others.

I feel I am completely falling behind and have no idea why I would need one of
these. Hell, if I made an iOS app, I have no idea if there are Apple servers
you pay them to use for stuff, or if you deploy your own servers, or you use
something like AWS, and how does that scale on demand, do you have to build
that into your s=infrastructure, or is there a "auto scale as demand dictates"
checkbox?

Is AWS, Docker, all the rest, in the end, is this just like in the old days
where I would have 42U of rack space, put in a DNS server, put in a few http
servers, use this as round robin image load balancers, DB servers, backup DB
servers, replication DB servers. And when I needed to grow for heavy demand
for a day, that was an issue. I fail to see how you can scale based on demand
when a database is involved.

Databases scare me, one thing never talked about... We have git for code, what
about databases. How does a dev team work that out? If you need a new field,
drop some data, alter a table, add an index, etc. How do you get what you have
on your local machine in test out to live? How is every little database change
tracked and rolled back if need be. How do the DBA guys communicate with the
coders to make sure a name change to a table gets updated in the code. Is
there git for postgres and others?

All this made sense to me 5 yeas ago when the cloud was called the internet
and email, ftp, http, etc were all part of the "cloud" or as I call it "the
internet". But now, things are confusing, wrapped up in terms like "cloud"
that make no sense to me. I have been, as we all have been, using "the cloud"
for over a decade, the first time I logged into a slip account and got on some
gopher server or similar, that was cloud to me and I believe it still is. POP
email is cloud, the internet is cloud. It is now just convoluted to the
developer so end users understand something that really only developers need
to understand. Am I making the same mistake with containers, and they are
nothing special and have been around for ages like the cloud and it is just a
buzzword now? Apple has sandboxing and something called containers in their
OS, is this similar in principle?

Auto makers don't burden their end users with engine shop talk, nor dumb it
down for them into simple terms, but we seem to with tech. This should be it's
own post but I just kinda got on a roll, sorry.

------
JustSomeNobody
Can I Dockerize Windows?

~~~
ZenoArrow
The next release of Windows Server (Windows Server 2016) supports native use
of Docker.

[http://www.tomsitpro.com/articles/windows-
server-2016-contai...](http://www.tomsitpro.com/articles/windows-
server-2016-containers,2-940.html)

