We've had to write (and continue to write) a lot of code to work around limitations and bugs. We've replaced the registry with custom code, written a lot of code to "manage" the Docker daemon, had to do some funny business to make logging work, are constantly integrating other components (such as weave) to work around Docker limitations, and my God the bugs...

I can deal with the limitations. It's the fundamentals that are the real problem (bugs, memory leaks, descriptor problems, aufs issues, the fucking registry). Docker, Inc. keep chasing new features over fixing the fundamentals. That's their choice, but it's unfortunate for us because, well, I have to go restart a few Docker daemons now because of that memory leak, yet again.

I expect these issues to be resolved eventually and there isn't a better alternative (the ones that exist have their own issues) so we take the pain and wait patiently for things to get better.

The usability of Docker gets so much worse as soon as you get outside the happy examples, too. Like, the one that most recently bit us: Docker is considered a "1.x product" and I have to hardcode a registry URI into the Dockerfile instead of something sane like a host-level search path--like all package managers have done for forevers now-and the suggested option by a Docker developer (and I'm not slagging him, he tried to help and I really appreciate that, it's not his fault this is stupid) was to muck around with DNS to redirect a single hostname to different places within my environment.

Couple the constant friction of usage with the security questions throughout the system (single giant garbage executable that needs root for absolutely everything instead of principle of least privilege, and--oh!--looks like user namespaces slipped to 1.7, awesome!) and I'm not feeling confident in my use of Docker. I feel like they'd rather market than fix.

- I am reminded of this article, and the dismissive replies by the author (a Docker employee and committer) here on HN: https://blog.jessfraz.com/posts/docker-containers-on-the-des... https://news.ycombinator.com/item?id=9086751

That said, this is a hard problem and it is going to take some time for all the issues to shake themselves out. Rocket also has a long way to go before they are production ready. I'm hopeful they'll provide a nice alternative in the long run, but today their platform is just as sketchy.

When I say the bugs will be fixed, I mean they will be fixed, but not necessarily by Docker, Inc. The larger community will have its way as it always does.

Binding to a physical interface is required if any of your apps will share port numbers on a host. If you don't have network ACLs that control traffic between VLANs, and you have a discovery service to manage rendezvous, then maybe you can get away without it. But many of us cannot.

I think that your use case is a lot more complex than ours or I'm misunderstanding some part, are you using bare metal servers in your own data center? I'm trying to grasp what's your architecture like so I can see what parallel can I make to ours.

Honestly, the only issue when it comes to image size is the initial developer pull either when they onboard to a team or when they bork their boot2docker install (which, disturbingly, happens way too often).

  docker -d -p 80:8000 repo/container

It's a little overkill if you're running it on a single machine, but in a real production environment, it's a pretty lightweight solution.

Compared to VMs we adopted a lot more of a "this is disposable" mindset, we persist any data that must not be destroyed in a failure in an external volume and treat the instance and service as something unreliable, pretty much it's always "Game Day", before deploying something we've already tried to cover the basics of HA (what happens if this service suddenly stops? How is the rest of the system behave? How do we make it automatically restart or reprovision?).

As I said, most of our issues regarded CoreOS (especially running with btrfs, getting out of space for metadata was a pain in the ass for months) but right now, after moving to ext4 + overlayfs we've been running without issues for a combined 28,800 hours of instance time (roughly NO issue in half a month in an environment running 30+ deploys a day).

I've not stated that we're perfect, very far from it, but Docker itself has not been a pain in production. Our private registry is currently running in an Ubuntu-based instance for more than 6 months non-stop (and we push/pull a lot of data from it everyday).

There is nothing particularly magical about Docker that means you can't consider VMs equally as disposable. It's a mindset change about how you build your product, not something inherent to Docker. It's the original concept behind AWS's EC2 - treat your VMs as disposable, and store state elsewhere.

Sure there is. Systemd will actually do this for you.

Docker recently eschewed LXC, and I'm still not sure I understand exactly why, but even after the move to libcontainer, systemd is capable of handling this.

If you mean a scenario where Docker launches systemd, we don't do that. In my view Docker is just a packaging system; each container's pid 1 is the app we're deploying.

No, systemd is actually capable of running Docker containers directly (even without Docker).

I definitely wouldn't recommend running systemd inside a container unless you're using systemd to launch the container (instead of Docker), since Docker doesn't handle init systems very well, whereas systemd has this built-in. Though you can also go with the one-app-process-per-container approach as well with systemd, which also works.

http://www.freedesktop.org/software/systemd/man/machinectl.h...