[tinco]

Is not running Postgres in Docker in production still a thing? What kind of problems are people running into? I love having everything managed using the same deployment techniques and I was on a team that ran Postgres in Docker in production for a couple of years and never ran into trouble. Of course that doesn't mean anything so I am curious.

[chdsbd]

How did you handle upgrading between major Postgres versions with Docker when the container only has one version (you need both for major version updates)?

There is an issue about this (from 2014), but it has yet to be resolved: https://github.com/docker-library/postgres/issues/37

[tinco]

I can't remember if we ever did this, but the solution seems straightforward, just start an upgrade container that has both versions.

We definitely did not use the container that's in the locker library though. Ours did some custom checks on startup.

[_ix]

I'd like to know, too! I'm working on a side project and aiming to run containerized docker for production – can anyone weigh in?

[XorNot]

It's advice born from people who don't quite understand docker. Postgres in containers just needs a data volume on a dedicated drive for speed, and you need to remember dockers default stop behaviour hard kills after 10s which is not long enough for a clean shutdown (use docker kill to send sigterm and wait).

[raziel2p]

I have to imagine it's about how bad a crash would affect you. If you can make hourly backups and the data loss is not a huge deal, I don't see why you wouldn't, but for more important stuff just go the extra mile and get some VMs.

[tinco]

Why would you have data loss? Why would crashes be worse than when Postgres is not run in a Docker container?

In our project we ran a master/slave Postgres setup and hourly backups. I don't fully remember the details, but as far as I know that's as safe as you can get regardless of Docker.

[mickael-kerjean]

> Why would you have data loss?

It might seem obvious to use volumes and maybe even cronjob to backup your data but a large amount of the instructions you find on the docker hub don't mention it. In any case, if you blindly copy and paste the instruction, you'll end up with data loss.

> Why would crashes be worse than when Postgres is not run in a Docker container?

because if you use docker wrong, the state of your system will leave inside the container and will be flush if you reboot your machine. If you don't use docker, the state of your system will always remain in your disk until your disk crash.

> In our project we ran a master/slave Postgres setup and hourly backups. I don't fully remember the details, but as far as I know that's as safe as you can get regardless of Docker.

It's working great for me too but the point is if you do it wrong, you'll burn yourself. I guess that's the same thing for any piece of tech but behind it's apparent simplicity, it's quite easy to do a mistake with docker and if you do so, say goodbye to your data

[chemicalnovae]

> ...state of your system will leave inside the container and will be flush if you reboot your machine.

Nope, the state of the container will survive until you remove the container. Reboots DO NOT refresh a container (you can have the docker daemon automatically bring your containers back up on reboot).