7 ms·

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 experien

by tzaman 10y ago

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.

user5994461 10y ago
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! ;)
all_the_things 10y ago
OP wasn't using orchestration.
- finid 10y ago
  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.
- deleted 10y ago
  [deleted]
chrisfosterelli 10y ago
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.
- eskil 10y ago
  Here's one, https://eng.uber.com/dockerizing-mysql/ https://eng.uber.com/dockerizing-mysql/
- benballjr 10y ago
  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.
fpoling 10y ago
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.
- eggie5 10y ago
  Yeah I'm wondering this too...
- blorenz 10y ago
  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
- tzaman 10y ago
  Read my reply below
- adenot 10y ago
  Reverse question that no-one seems to ask: What's the advantage of running a DB on a container?
  - etherealG 10y ago
    Spinning a new db in continuous integration for integration tests.
eggie5 10y ago
How do you host your DB on GKE? Are you saying there's something wrong w/ a DB pod that writes to a PV?
- tzaman 10y ago
  We host PostgreSQL on GCE with two separate instances (master/standby) replicated with repmgr (http://www.repmgr.org/ 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.
  - fpoling 10y ago
    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.

by tzaman 10y ago

user5994461 10y ago

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! ;)

all_the_things 10y ago

OP wasn't using orchestration.

finid 10y ago
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.
deleted 10y ago
[deleted]

chrisfosterelli 10y ago

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.

eskil 10y ago
Here's one, https://eng.uber.com/dockerizing-mysql/ https://eng.uber.com/dockerizing-mysql/
benballjr 10y ago
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.

fpoling 10y ago

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.

eggie5 10y ago
Yeah I'm wondering this too...
blorenz 10y ago
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
tzaman 10y ago
Read my reply below
adenot 10y ago
Reverse question that no-one seems to ask: What's the advantage of running a DB on a container?
- etherealG 10y ago
  Spinning a new db in continuous integration for integration tests.

eggie5 10y ago

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

tzaman 10y ago
We host PostgreSQL on GCE with two separate instances (master/standby) replicated with repmgr (http://www.repmgr.org/ 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.
- fpoling 10y ago
  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.