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

31–40 of 132 posts

Re: Docker in Production: A retort

#31

Post by dozzie »

fh973 wrote: post #26
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…

A good reason for running a database in a container is fault tolerance without setting up database replication. Put your database in a container, let it store its data on a network storage system (like a distributed file system). The container scheduler makes sure it gets rescheduled when the node goes down.

And what does it do any better than doing the same (keeping database on an NFS/iSCSI/AoE share) on physical or virtual machines?

Re: Docker in Production: A retort

#32

Post by user5994461 »

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…

Author from the original article here.

>>> * Docker encourages fully disposable infrastructure => I'd consider that incorrect and/or misleading

Docker is meant to manage disposable (i.e. stateless) applications. They are expected to be killed/stopped/restarted at any time, no persistent state, no data.

An application is either disposable OR not disposable by its design, docker doesn't change that. (For instance, don't try to dockerize databases).

Docker gives you a quick, nice and easy way to package your applications with dependencies (as Docker image) AND deploy them. [This is valuable]

It's especially great for development and test environments because you can run many containers (i.e. applications) on a dev/test machine, without dependency/deployment hell. [This is very valuable]

>>> * Docker containers can be more secure then traditional environments => No. Just No.

Docker has nothing to do with security.

>>> * Docker provides for idempotent environments agnostic of hardware concerns etc

Docker gets to ignore the hardware. You do not.

You get to buy, setup and manage servers. Maintain a full environment that can run docker.

It can be an undertaking full of dangers, as told by this article and mine :D

>>> * Container management software (Kubernetes, etc.) makes Docker much more powerful/useful and is only going to get better

Docker allows to package and deploy an application. It doesn't do anything about infrastructure at all (i.e. machines, load balancers, DNS, discovery), which you still have to manage and it's a HARD problem.

The orchestration systems is supposed to help you manage all of that. As a result, it will be able to automatically kill/restart/move/add containers across a cluster and make the necessary [physical or virtual] infrastructure changes.

Container + Orchestration will be a [r]evolution to manage entire giant fleets of hosts and applications. [This will be infinitely valuable (allowing me to automate the work of 10 people, all freeing all my time to enjoy unlimited free drinks and foods)]

IMO: In the current state of affairs. Having docker without orchestration is like having cars without roads.

Re: Docker in Production: A retort

#34

Post by otterley »

CSDude wrote: post #18
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…

> 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 use…

I can't imagine what your use case is that requires running bleeding edge database servers in production and that cannot be managed via native OS packaging. Would you please enlighten us?

Otherwise it really sounds like you're using a non-best practice (running a DB in a container) to paper over another non-best practice (treating your DB as a non-sacrosanct piece of infrastructure by introducing intentional instability through frequent needless upgrades).

Re: Docker in Production: A retort

#35

Post by otterley »

paulddraper wrote: post #30
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 update my database servers for the same reason I update my proxy servers: more features, security fixes, better performance, increased stability.

How frequently? And can you quantify those benefits relative to the risk and amount of work involved? How do you know it passes the cost/benefit ratio test?

Re: Docker in Production: A retort

#36

Post by justincormack »

wickedlogic wrote: post #17

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?

All the containers are available after termination, yes, so you can investigate.

Re: Docker in Production: A retort

#37

Post by fh973 »

dozzie wrote: post #31
fh973 wrote: post #26

Earlier quoted context omitted.

A good reason for running a database in a container is fault tolerance without setting up database replication. Put your database in a container, let it store its data on a network storage system (like a distributed file system). The container scheduler makes sure it gets rescheduled when the node goes down.

And what does it do any better than doing the same (keeping database on an NFS/iSCSI/AoE share) on physical or virtual machines?

Less downtime and automatic recovery, I'd say. When the host machine goes down, the scheduler will pretty quickly start the container on a new machine. There the container will startup much quicker than a VM would.

Re: Docker in Production: A retort

#38

Post by paulddraper »

otterley wrote: post #35
paulddraper wrote: post #30

Earlier quoted context omitted.

I update my database servers for the same reason I update my proxy servers: more features, security fixes, better performance, increased stability.

How frequently? And can you quantify those benefits relative to the risk and amount of work involved? How do you know it passes the cost/benefit ratio test?

The same as all my other software?

Is this your first time working with it?

Re: Docker in Production: A retort

#39

Post by dozzie »

fh973 wrote: post #37
dozzie wrote: post #31

Earlier quoted context omitted.

And what does it do any better than doing the same (keeping database on an NFS/iSCSI/AoE share) on physical or virtual machines?

Less downtime and automatic recovery, I'd say. When the host machine goes down, the scheduler will pretty quickly start the container on a new machine. There the container will startup much quicker than a VM would.

> Less downtime and automatic recovery, I'd say.

How? By magic dust sprinkled by Docker Inc?

> When the host machine goes down, the scheduler will pretty quickly start the container on a new machine. There the container will startup much quicker than a VM would.

You seem to forget that a) container's filesystem needs to be downloaded in the first place, and b) that VMs can work in a standby mode, not running the service (database) when not needed. Starting a container seems to be much more fragile solution.

There are already well-developed mechanisms for things like that, and we (sysadmins) were using them for dozens years already.

The question still stands: what do containers do better than the mechanisms we had for a long time?

Re: Docker in Production: A retort

#40

Post by otterley »

paulddraper wrote: post #38
otterley wrote: post #35

Earlier quoted context omitted.

How frequently? And can you quantify those benefits relative to the risk and amount of work involved? How do you know it passes the cost/benefit ratio test?

The same as all my other software? Is this your first time working with it?

You didn't answer any of the questions expect the one about frequency. I'm left to assume that your usage is so irrelevant or your user base so small that you haven't needed to spend time thinking really hard about operational difficulties, SLAs, or calculating risk tolerance relative to value. Or gotten yourself into trouble yet which every DBA/SRE of a database of substantial size gets into eventually.
Post reply on HN