Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker in Production: A retort

patrobinson.github.io

Post reply on HN
Print view View original

11–20 of 132 posts

Re: Docker in Production: A retort

#11

Post by sheeshkebab »

nickthemagicman wrote: post #9

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

AWS was also considered not a fit for running "core" apps and databases... look where we are now.

Docker is certainly having some teething issues - and things like kubernetes are certainly WIP. But I wouldn't be as skeptical - plenty of companies use it in production already, for "core" apps.

Re: Docker in Production: A retort

#12

Post by chousuke »

ben_jones wrote: post #7
carapace wrote: post #6

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. 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 Do…

I'm not sure if I qualify as a docker expert, but I feel like I need to comment on these...

Firstly, I think it is correct that docker encourages disposable infrastructure, because your docker setup basically must be able to recover from the loss of a container. I think it would not be sane to expect your containers to "just keep working".

Regarding security, I don't think Docker provides much other than the illusion of better security at the moment. At least on Linux containers don't add security that you can't get with traditional services.

I suppose if you use authenticated images you can at least be sure that you're running the code you think you are, but then again package managers have had signing for ages.

You're always going to have to test your software in the environment you will be deploying it in, because driver bugs and weird interactions still exist. Docker doesn't really let you ignore the hardware

I have no opinion of kubernetes and such at the moment.

What docker does grant is an easy method of "packaging" software... Pretty much anyone can just throw everything together in a big bundle and distribute that. For certain use-cases, this can give a development team much more speed, since setting up a workable environment is much faster. There is also a nontrivial amount of software that simply does not bother with OS packaging where containers can help you deploy it in a more controlled fashion.

Re: Docker in Production: A retort

#13

Post by toomuchtodo »

kstenerud wrote: post #10
otterley wrote: post #8

Earlier quoted context omitted.

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.

Unnecssesary complexity. A VM would've sufficed for what you described.

Re: Docker in Production: A retort

#15

Post by cuillevel3 »

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.

Re: Docker in Production: A retort

#16

Post by cs02rm0 »

toomuchtodo wrote: post #13
kstenerud wrote: post #10

Earlier quoted context omitted.

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.

Unnecssesary complexity. A VM would've sufficed for what you described.

I find VMs are super slow for development purposes (I mean setup, starting up and shutting down rather than actual processing), where docker's made a massive difference. YMMV especially if you're not spinning up new projects frequently.

They might be a better solution in production, but I have a strong preference for production mimicking development.

Re: Docker in Production: A retort

#17

Post by wickedlogic »

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?

Re: Docker in Production: A retort

#18

Post by CSDude »

otterley wrote: post #8
CSDude wrote: post #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,…

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…

> Or, to put it more bluntly, just because you've gotten away with it (thus far) doesn't make it a good idea.

What is your typical server infrastructure? We use bare machines and had kernel panics very rarely (only with experimental MACVLAN). We did not 'get away' with anything. We have been using Docker for over 2 years, and LXC much more and know how to handle mounted directories, it is not a rocket science. We used LXC, now Docker to provide quick isolated mini linux environments. They are just different type of Virtual Machines when you abstract it in your head, and do not expect it to do magical stuff like saving your data and send it to another host upon crash.

> Native storage software packages are available for mainstream OSes that handle dependencies via the native package manager.

They are often outdated, we mostly get one of the latest builts, and in some cases Snapshot builds, where they are not available anywhere. So ability to run versioned instances of some software independently and isolated is a huge win for us. We do not want to distrub people using the old version. Yes it can be solved with VMs. We use our own bare metal servers. We do not like to "pay" to open VMs, so we turned to OpenStack. It is very complicated for our use case, we like to use bare metal on our own. But, we still need isolation, this is where containers; LXC and Docker came to help and saved us a burden.

Re: Docker in Production: A retort

#20

Post by ascendantlogic »

cs02rm0 wrote: post #16
toomuchtodo wrote: post #13

Earlier quoted context omitted.

Unnecssesary complexity. A VM would've sufficed for what you described.

I find VMs are super slow for development purposes (I mean setup, starting up and shutting down rather than actual processing), where docker's made a massive difference. YMMV especially if you're not spinning up new projects frequently. They might be a better solution in production, but I have a strong preference for production mimicking development.

Precisely the point. It's fine in dev but once you are running in prod and need rock solid stability the generally accepted dogma is that containerizing your DB is playing with fire. As you said, YMMV.
Post reply on HN