Docker in Production: A retort
patrobinson.github.io
Docker in Production: A retort
1–10 of 132 posts
Re: Docker in Production: A retort
#2> 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
And it will still be valid if someone forks Docker. In fact, that would validate the criticism.
Re: Docker in Production: A retort
#3The HN discussion of the article being retorted: https://news.ycombinator.com/item?id=12872304
Re: Docker in Production: A retort
#4This seems less of a "retort" and more of a validation that most of the issues brought up in the original article are valid complaints.
Re: Docker in Production: A retort
#5> Again, well accepted principle that “thou shalt not run a database inside a container”. Don’t do it, end of story.
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.
Re: Docker in Production: A retort
#6I'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.
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.
What would help with the above is if people would document what they are doing with Docker that works, 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.!?
Re: Docker in Production: A retort
#7I'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. So nevermind a retort, what I would like to see is a sane, sensible "business value" cost/benef…
As someone considering using Docker for production infrastructure I'd love to hear from a docker expert what their thoughts are on the following observations:
* Docker encourages fully disposable infrastructure
* Docker containers can be more secure then traditional environments
* Docker provides for indempotent environments agnostic of hardware concerns etc
* Container management software (Kubernetes, etc.) makes Docker much more powerful/useful and is only going to get better
Specifically, I'm curious if my observations are correct, and if they are why they are correct and why are they SO much better (vs current docker alternatives including non-container based approaches).
Re: Docker in Production: A retort
#8> Again, well accepted principle that “thou shalt not run a database inside a container”. Don’t do it, end of story. 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,…
What problem does containers solve for you for this particular part of your infrastructure? Native storage software packages are available for mainstream OSes that handle dependencies via the native package manager. And since the storage they manage is usually directly attached, nodes that run this software are infrequently migrated. And this software is infrequently upgraded under the maxim "if it ain't broke, don't fix it." It's there to store data on behalf of the applications you write; it is not a thing to upgrade or migrate for its own sake unless there is a bug to quash or a new feature that your application will depend upon; and even then, migrations must be carefully planned to preserve availability for users.
Docker and the like seem like a solution in search of a problem for this particular part of a typical service infrastructure.
Or, to put it more bluntly, just because you've gotten away with it (thus far) doesn't make it a good idea.
Re: Docker in Production: A retort
#9I love how the major issue, that both this article, and the original article warn about is: don't use docker on 'CORE APPS'....
That says all you need to know about the trustworthiness of Docker.
EVEN DOCKER PROPONENTS caution against using it in 'important' apps....
What apps are people investing time in that aren't 'important'?
Is there a coffee machine that is ok to use for a docker app somewhere?
Re: Docker in Production: A retort
#10> Again, well accepted principle that “thou shalt not run a database inside a container”. Don’t do it, end of story. 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,…
What problem does containers solve for you for this particular part of your infrastructure? Native storage software packages are available for mainstream OSes that handle dependencies via the native package manager. And since the storage they manage is usually directly attached, nodes that run this software are infrequently migrated. And this software is infrequently upgraded under the maxim "if it ain't broke, don't…
I'm still not sure I follow. If you're not setting up a DB that will have such heavy usage that it needs bare metal access, what's wrong with setting it up such that it stores data on a NAS, or via mounted volumes? Then when it comes time to upgrade due to a security issue, you can create a new container, spin it up, and if it barfs, relaunch the old one.