I've never used Docker, or containers, but I read about things like "Breaking changes and regressions ... a well documented problem with Docker" and "Can’t clean old images ... a well known issue" and it just seems to me like a crazy thing to try to use and depend on this thing/company. Bluntly put they seem like children.<p>So nevermind a retort, what I would like to see is a sane, sensible "business value" cost/benefit, pros v. cons breakdown of just what the heck you're actually gaining (and losing) using Docker vs. some other architecture/methodology. Because absent that it's all just hype and kool-aid drinking in my opinion.<p>What would help with the above is if people would document what they are doing with Docker <i>that works</i>, because either they are hurting but not realizing it, or the author of the article is just "doing it worng" and whining about it in public. What is really going on with Docker, et. al.!?
Docker founder here.<p>I keep reading articles stating that "the Docker API changes with every release", but the assertion is never backed by any specific examples. Has anyone here encountered an actual breaking change? If so, I would appreciate you sharing the specifics so we can fix it.<p>Docker is by no means perfect:<p>- I remember that in 1.10 the switch to content-addressed registries meant that older clients could not pull by digest (but all other commands, and even non-pinned pull, still worked). This was not an accidental breaking change: it was the result of a difficult tradeoff. In the end we decided that the benefits of the new content-addressed model outweighed the inconvenience. To guide our decision we used data from Docker Hub to assess how many clients would be affected. I forget the exact number but it was a very small minority.<p>- And in 1.12 we got bitten by a change in how Go 1.6 processes HTTP headers (it became more strict and thus rejected headers from older clients). That was quite simply a screwup on our part.<p>So we've had our share of screw-ups, no question. But lately I've been reading the "breaks at every release" meme more and more. Based on the evidence I have, it seems incredibly disconnected from reality.<p>What am I missing?
I love how the major issue, that both this article, and the original article warn about is: don't use docker on 'CORE APPS'....<p>That says all you need to know about the trustworthiness of Docker.<p>EVEN DOCKER PROPONENTS caution against using it in 'important' apps....<p>What apps are people investing time in that aren't 'important'?<p>Is there a coffee machine that is ok to use for a docker app somewhere?
> Again, well accepted principle that “thou shalt not run a database inside a container”. Don’t do it, end of story.<p>Sorry, but this is really a bad advice. We have ran and contine to run various databases inside Docker including MySQL, PostgRedis, Cassandra, Elastic Search, RethinkDB even HDFS with proper user rights and configuration. We can maintain the state just as fine. If your only problem is to move the data, all you have to do is stop, export, tar it, move to another server, just as you would do in a normal server. Docker is not a magic bullet to solve such kind of issues. Yes, Docker might have another problems, but just as you could not run someting with state inside Docker does not mean "thou shalt not run" , there are various ways to manage state. Host, IO can get crash regardless of Docker.
The HN discussion of the article being retorted: <a href="https://news.ycombinator.com/item?id=12872304" rel="nofollow">https://news.ycombinator.com/item?id=12872304</a>
Re ECR (the EC2 Container Registry), it has one downside that the author doesn't mention, which also applies to Google's own registry.<p>A Docker registry has own authentication system. So does AWS (and GCloud). So what you end up is one wrapping the other: To access the ECR, you have to run an AWS command to get a token to put into "docker login". Google has "gcloud docker login" for the same purposes. Both produce temporary credentials that time out, so can't be used for long-running things.<p>This means that any tool designed to work with a Docker registry needs to support this particular workflow. For example, this affects Drone [1].<p>It also adds complexity. GCloud is particularly heavy on the authentication complexity side already (compared to AWS's comparatively simple keypair approach), and with SSH, GCR and Kubernetes on top it starts to stack up in ways which can make users' head spin.<p>Straight Docker Hub is refreshingly straightforward by comparison.<p>[1] <a href="http://readme.drone.io" rel="nofollow">http://readme.drone.io</a> (not to be confused with drone.io)
Previous article: "This is nowhere near ready for those who just want to get the job done."<p>This article: "It'll be better in the future, you'll see!"<p>The former is verifiable, the latter is a hypothesis.
As an example of Docker in production: Expedia are moving lots of their legacy infrastructure into Docker containers. My third-party contracting team that works on projects for Expedia (we're brought in so the rules and bureaucracy don't apply to use, allowing us to rapidly iterate and experiment in ways the core teams can't) have been using Docker end-to-end (local development through to autoscaled production deploys)<p>While there were teething issues, this article does a good job of pointing out the flaws in the original article, I think. It's been easier to get our team up to speed on Docker and it's gotchas than nearly any other configuration management, server management, et al. systems that we tried!
Can anyone comment on how rkt compares to Docker regarding the issues from this article ? And how does rkt compare to Docker in production in your experience ?<p>I've been using Docker in production for a single server website and have had very few issues. I do like how easy it is to reproduce a working environnement with a "docker build" though.<p>That being said, I think that just using Ansible on a server is probably an easier and more reliable solution. Ansible is battle tested and allows to have reproducible environments too.
Related question, what happens when a docker images gets pop'd.... how do you keep it around for investigation, does it get imaged for later forensics? Every time I have asked people in IRL doing docker, they seem to focus on updating/patch... on how easy that is and moving on... but that is not always an option for every client. Do you just image all docker images before they get terminated/migrated?
> So the point is valid, but there are some big names invested in solving it, so I’m optimistic we’ll see some stability in the future<p>And it will still be valid if someone forks Docker. In fact, that would validate the criticism.
Are these breaking changes problems caused by Docker itself? I was contacted by Docker and was considering applying, but it sounds like their engineering management doesn't know what they're doing. Is this depiction accurate or is it overblown?
if I am using mount Volumens to export my data, can I bypass the aufs/overlay implementation/logic ? do I need to pay attention only if I don't mount the volumes? thx
Docker seems very limited when it's unsuitable to run databases.<p>I've never seen this limitation with other container solutions. What is it about Docker that makes it problematic?
Good retort. The original article seemed clueless, the part about aufs was just wrong, the complains about the apt repo exaggerated. Running docker on Debian ancient is kind of brave, though.
And software is finished after five years, maybe in the financial industry. Currently development has such a pace, I'd say after five years it's abandoned and replaced.
"The internet has been a wash with a well written article about ..."<p>Typo: a wash => awash<p>I know! The content is more important than the quality of the writing, but it's a little surprising to see such a mistake jumping at the reader at the start of an article. We should go back to the first days of the Internet where "updates" were possible. :) I would have loved to suggest an update quickly.