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

Should I run plain Docker Compose in production in 2026?

distr.sh

Post reply on HN
Print view View original

231–240 of 312 posts

Re: Should I run plain Docker Compose in production in 2026?

#231

Post by n_e »

kjuulh wrote: post #75

I am using docker-compose everywhere. I really enjoy using it. I have a single thing that is annoying for normal production deployments, and that is that it isn't super easy to have a rolling deployment, I just need two replicas for zero downtime deployment, and I don't really want docker swarm. I think it is the networking which breaks at that point, and you have to have a more involved setup, and at that point I'd…

Why not use swarm? On a single node it isn't really more complicated than compose, and you get scaling and rolling deployments.

Re: Should I run plain Docker Compose in production in 2026?

#233

Post by KetoManx64 »

dizhn wrote: post #220
KetoManx64 wrote: post #132

Earlier quoted context omitted.

What would the config look like if I have my docker containers split up over multiple VMs?

I have all of mine on the same (or accessible) internal LAN so they can all talk to each other. You can get the connection going with Wireguard if they are in different places in terms of networking.

As in you have a VLAN just for the docker containers to talk to each other on?

Re: Should I run plain Docker Compose in production in 2026?

#234

Post by skydhash »

exceptione wrote: post #196
skydhash wrote: post #42

Earlier quoted context omitted.

> they are extremely conservative, and if that is all you need, then that is great You don’t need to live at the edge of new features. Do you upgrade your fridge and your oven every two months? It’s nice when you can have something running and not worry that the next update will break your software and/or your workflow.

Sure, but these are development dependencies we are talking about. Running old versions of these dependencies block your projects. But it isn't limited to self-developed software, quite often for of the shelve software you run at the same problem. To each their own, but this is the reason I advice newcomers to stay away from Debian based distro's. I don't intend a distro flamewar, it works perfect for `boring old and…

Your test system should reflect your prod system. Why run Debian if you intend to deploy on the latest ubuntu? Unless you want to use VMs. For other stuff that does not alter the system that much, you can find more recent version in the backports.

Re: Should I run plain Docker Compose in production in 2026?

#235

Post by mehackernewsacc »

calmoo wrote: post #81
nijave wrote: post #64

Earlier quoted context omitted.

Helm mostly does that. Not a huge fan of a text templating engine generating yaml but once you get your chart setup with a few variable inputs, you can continue using it for a bunch of other stuff with minimal new config. The inputs (values) are yaml so you can make it look exactly like a Docker Compose file if you want (wouldn't be surprised if there's some charts floating around that do that)

I've recently been dipping my toes into k8s / kustomize / helm, and I recently had a situation where having a base deployment yml template that I wanted to reuse across various deployments. I had a look at Helm and I was frankly shocked how bad the templating was with Go templates, it was close to unreadable and felt very brittle!

Shared up the chain, but bringing your attention to it as well: https://nixidy.dev/ solves all of these issues.

Re: Should I run plain Docker Compose in production in 2026?

#236

Post by mikestorrent »

merb wrote: post #229
nickjj wrote: post #63

Docker Compose was production ready in 2015 and it still is today. I've lost track of how many projects I've deployed with it and never really ran into a single issue where Docker Compose was at fault. It's super solid. Some time ago I've written about my experiences using it in production https://nickjanetakis.com/blog/why-i-like-using-docker-compo... . Not just for my own projects but for $500 million dollar compan…

How do I backup docker volumes? I never found a native flow for backing up docker compose projects. While not built in k8s has at least velero and kasten. However they are only possible because of snapshots https://kubernetes.io/docs/concepts/storage/volume-snapshots... and kasten has a plugin like architecture (because of k8s ) that supports application specific backups. However I never found something like that for…

Why use a docker volume? Seems like a good way to accidentally lose your files. Just volume-mount from the external filesystem and back it up the same way you would any linux application's files - maybe stop it, maybe not, depends on how it uses files.

Re: Should I run plain Docker Compose in production in 2026?

#237

Post by dlt713705 »

Docker Swarm sits between Compose and k8s and can be used on a single node if your needs are modest. I find Docker Swarm more reliable and easier to automate with a CI/CD pipeline than Compose, and it also provides health checks and other useful directives allowing you to minimize downtime, rollback when a deploy fails, and so on.

Re: Should I run plain Docker Compose in production in 2026?

#238

Post by exceptione »

skydhash wrote: post #234
exceptione wrote: post #196

Earlier quoted context omitted.

Sure, but these are development dependencies we are talking about. Running old versions of these dependencies block your projects. But it isn't limited to self-developed software, quite often for of the shelve software you run at the same problem. To each their own, but this is the reason I advice newcomers to stay away from Debian based distro's. I don't intend a distro flamewar, it works perfect for `boring old and…

Your test system should reflect your prod system. Why run Debian if you intend to deploy on the latest ubuntu? Unless you want to use VMs. For other stuff that does not alter the system that much, you can find more recent version in the backports.

It has integration with systemd, but moreover, I think the promise of Debian-derivatives is one of "we are boring and old, but also boringly stable". Now, throwing in backports undermines that promise. I think one is better of with a distro that moves faster.

Re: Should I run plain Docker Compose in production in 2026?

#239

Post by c0balt »

merb wrote: post #229
nickjj wrote: post #63

Docker Compose was production ready in 2015 and it still is today. I've lost track of how many projects I've deployed with it and never really ran into a single issue where Docker Compose was at fault. It's super solid. Some time ago I've written about my experiences using it in production https://nickjanetakis.com/blog/why-i-like-using-docker-compo... . Not just for my own projects but for $500 million dollar compan…

How do I backup docker volumes? I never found a native flow for backing up docker compose projects. While not built in k8s has at least velero and kasten. However they are only possible because of snapshots https://kubernetes.io/docs/concepts/storage/volume-snapshots... and kasten has a plugin like architecture (because of k8s ) that supports application specific backups. However I never found something like that for…

The "easiest" way is to use bind mounts to a local directory (or multiple directories) instead of volumes. Then you can just use normal backup tooling.

Docker volumes (and bind mounts) however have the minor problem of being hard to get a consistent copy to without stopping the service. You can work around this by, e. G., having ZFS or btrfs as the underlying FS and making a snapshot there. Otherwise, your software (like PostgreSQL) might also have other online backup tooling.

Re: Should I run plain Docker Compose in production in 2026?

#240

Post by pbowyer »

seniorThrowaway wrote: post #192
nickjj wrote: post #63

Docker Compose was production ready in 2015 and it still is today. I've lost track of how many projects I've deployed with it and never really ran into a single issue where Docker Compose was at fault. It's super solid. Some time ago I've written about my experiences using it in production https://nickjanetakis.com/blog/why-i-like-using-docker-compo... . Not just for my own projects but for $500 million dollar compan…

Extremely debatable. They still have never fully implemented health checks and auto healing. I have had compose itself behave in unexpected ways, weird things like not realizing the tag of an image it is running is actually in use, and letting prune commands yank it out from under the system. Other things I can't remember. I'd rather use something like Nomad or for simpler systems maybe plain systemd. But realistical…

> Extremely debatable. They still have never fully implemented health checks and auto healing.

Agree.

Plus there's the monitoring of the host that is always overlooked in articles. I've ended up chucking Monit on there to monitor disk usage et al, and also used it for monitoring compose too and restarting containers.

And then there's Healthchecks.io, and external uptime monitoring... the list goes on. Properly monitoring systems, even single server systems, is not simple.

Post reply on HN