Hacker News Reader

Comment by tzaman | Hacker News Reader

That's odd, we've been using Docker for about a year in development and half a year in production (on Google Container engine / Kubernetes) and haven't experienced any of the panics, crashes yet (at least not any we could not attribute as a failure on our end).

Clearly, Docker itself has a a few annoyances, like no garbage collection and poor tagging process, but we're using it on a daily basis, and nobody complains about it (nothing a few bash scripts can't fix).

Finally, the biggest benefits of not just docker but containers in general are consistency and immutability which brings me to the final point I agree with the author: Your database shouldn't be containerized. It's not your pet (from pets vs cattle), it's your BFF.

View on HN

Yeah, for every article complaining about how Docker in production is just so terrible there's a huge group of people who have been running it for a while and have no problems at all.

Nobody writes rant posts when things work, I guess.

I definitely try to highlight the success stories, but there's a critically different way that audiences react to "here's why everything went great for me" on Hacker News, though I think that is understandable. Too many times they're customer success stories, or case studies from the marketing department, and many don't care for those.

Here's one, https://eng.uber.com/dockerizing-mysql/

What is wrong with DB in container? As long as one uses host volumes for persistent data, docker allows to isolate DB setup rather nicely.

Agreed and confused. Interested to find what would be wrong with this? (from my docker-compose.yml under the db service) volumes: - ./data/postgresql:/var/lib/postgresql/data

Reverse question that no-one seems to ask: What's the advantage of running a DB on a container?

Spinning a new db in continuous integration for integration tests.

Yeah I'm wondering this too...

Read my reply below

1) The conclusion of the article is to use Google Container Engine because Google are the only one who might have managed to get a working ecosystem around Docker and may be able to maintain it.

2) As disclosed by other comments, Google Container Engine doesn't use Docker. It uses containerization technology made by google for google, with a docker-interface added on top.

That's why you don't have problems with Docker. You're not using Docker at all! ;)

OP wasn't using orchestration.

He wasn't using orchestration, but said Docker Swarm is terrible. How did he come to that conclusion.

For the record, orchestration in Docker (1.12.x) is actually quite good. Its built-in service discovery and mesh networking make setup a breeze.

How do you host your DB on GKE? Are you saying there's something wrong w/ a DB pod that writes to a PV?

We host PostgreSQL on GCE with two separate instances (master/standby) replicated with repmgr (http://www.repmgr.org/). Then we have a service defined with custom endpoints that point to these two instances.

There's plenty wrong with a Pod that writes to PV - if your Pod/Container somehow gets corrupted, you're left with a corrupted database. It's unlikely, but as the origintal article states, Docker is young and things happen. Are you willing to risk it?

So in every case you need to ocnfigure replication and master selection. Are you willing to trust the pods to do the right thing without manual intervention on data that is the core of your business? I'm not.

What exactly do you mean by "container get corrupted"? One should always use the read-flag to run Docker containers and use explicit volumes for persistent data. With this setup a container can only get corrupted if a read-only bind mount gets corrupted, and this will be a bug in kernel, not Docker.

Reply on news.ycombinator.com