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

241–250 of 312 posts

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

#241

Post by Cpoll »

bdangubic wrote: post #209
jdw64 wrote: post #179

Earlier quoted context omitted.

I think people are using different meanings of “production environment.” I agree with gear54us and upvoted their comment, but I also understand what the author of the root comment is saying. I have also delivered systems using Docker Compose that are actually running in production. The point I want to make is that people may define “production” differently depending on the number of active users, operational requirem…

"Not just for my own projects but for $500 million dollar companies and more." Seems reasonable to assume these are serious production environments, no?!

Not necessarily. When you get to those numbers you're seeing dozens of teams with their own silos and deployment methods. So they might be responsible for the core business that's running 30 nodes and serving 100MM users a day, or they might be working on some internal portal or a WordPress site.

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

#243

Post by nijave »

TheCapeGreek wrote: post #223
nijave wrote: post #78

Earlier quoted context omitted.

I would say it's bad practice because you end up having to copy all the build dependencies (source code) to the host and you're potentially putting a bunch of extra load on the host during the build process. Also adds moving parts to your deploy which increases risk/introduces more failure modes. Couple things that come to mind - disk space exhaustion during build - I/o exhaustion esp with package managers that have…

> you end up having to copy all the build dependencies (source code) to the host > disk, i/o exhaustion This is why I mentioned specifically for ecosystems like PHP, which are interpreted. I'm specifically asking for that use case. I'm not building binaries, my "build" steps are actually deployment steps (npm build, composer install, etc) that I'd be running in exactly the same way on the host. The image I'm deployin…

>I'm specifically asking for that use case.

That's what I answered for.

>I'm not building binaries

If you were, I would have added CPU to the list.

>my "build" steps are actually deployment steps (npm build, composer install, etc)

No, those are build steps. If you weren't using Docker, you would either run all those and shove in a zip/tarball or package into a deb/rpm, etc

>The image I'm deploying by definition also contains my source code

It doesn't contain .git or need credentials to your git/SCM

>I'm not seeing the benefit of the whole "build image, pull on server" pipeline when I can just ditch the registry and added layers by doing those steps on the server as I would normally in other kinds of scenarios

You don't need a registry--you can Docker save/load to push images directly to the server. Images buy you a versioned artifact with all the code-level dependencies baked in. Some maintainer yanks their package from npm? Who cares--you have a copy in your Docker image. Your new app version doesn't work? Edit 1 line to point back to the old image tag and rollback.

>> The build process can exhaust resources on the host

>Maybe, but I've yet to have a host where that's the case for usual CRUD fare.

When the build process completes, it tears down the overlayfs which causes everything to sync which leads to a big I/O spike. Depending on the server and amount of files, it might have no impact. However, I've seen build servers become completely unresponsive for 5+ minutes due to the I/O load when this happens. One place I worked, we had to switch our build servers to NVMe--the Docker container teardown caused spikes over 100k IOPs. Can't remember the exact details--it was React either React web front end or React Native mobile app.

>There's more layers involved there than something like provisioning with Ansible and just having a deploy script to run the usual suspects.

`docker save myimage:tag | gzip | ssh user@server 'gunzip | docker load'`

Not saying creating distributable artifacts is the de-facto answer, but I'd strongly consider whether it's really that much more complicated.

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

#245

Post by pydry »

PxldLtd wrote: post #106
pydry wrote: post #47

Earlier quoted context omitted.

One of the nastiest aspects of migrating from docker to podman really is "what to do about docker compose?" coz there are three wildly divergent ways to answer that all of which really suck under certain specific circumstances. Im no fan of docker and podman by itself is a step up but orchestration headaches are enough to ruin that.

This is what stopped me from picking up Podman more, all our devs use Docker and have been writing compose files for years now. When the response at the time was "you're using Podman wrong, Quadlets are the hot stuff now" it just felt like too big a risk and commitment to jump to at the time. Have things settled more? Getting away from Docker is a bigger priority nowadays for us.

podman compose has shifted from "basically never works" to "if an existing YAML isnt too complex it works" but it's not a drop in replacement yet.

i also want to stay the hell away from quadlets or any other software which tries to make me use systemd more.

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

#246

Post by predkambrij »

I also configured some productions with docker compose. The biggest problem is to handle the case of machine reboot. Docker restart policy needs to be set to "no". That's also the problem if there would be dependencies between services. Solving that always lead to some type of hacks. I created a bash script that's run with SystemD on machine boot, to start all docker compose services one by one, to avoid them starting all at once (if restart policy would be set to anything except "no"). Other than that, it's awesome. Complexity reduced if high availability is not a critical requirement.

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

#247

Post by stryan »

pydry wrote: post #213
figmert wrote: post #162

Earlier quoted context omitted.

> "what to do about docker compose?" I don't understand what you're asking here. The answer to that is probably nothing. That is unless you want: - systemd to manage your containers - You want to use K8s primitives (which are mostly compatible) I'm unsure what the 3rd method is you're talking about. The nice thing about Podman's compose API is you don't have to change anything (mostly). You can point all your docker…

the three options are: * use systemd, red hat's favorite kitchen sink for handling everything from setting up sound services to mounting your home dir to logging so why not this too i guess. * docker compose where i have to run a whole separate podman service to lie to docker compose about not actually being docker. * podman compose which would be the obvious solution if it didnt just plain suck.

> * use systemd, red hat's favorite kitchen sink for handling everything

Systemd is a tool for managing services. Containers are services. Why require an entirely separate bespoke service manager when you're already running one?

> * docker compose where i have to run a whole separate podman service to lie to docker compose about not actually being docker.

This is the same system state as using docker compose with docker: you have a client program speaking to a backing daemon. Only difference here is the Podman service, being daemonless, only runs when needed (assuming you're setting up things the documented way by enabling the podman socket).

> * podman compose which would be the obvious solution if it didnt just plain suck.

Yeah I haven't had the best luck with it either. But part of the reason it's languished is that it makes more sense to just reimplement the Compose spec on the backend rather than re-invent the wheel and create a new compose client as well.

There's also the fourth option of writing Kubernetes yaml and applying that with `podman kube play`. Honestly this is probably closer to being the podman equivalent of docker compose but since it involves writing The Bad YAML (kubernetes) rather than The Good YAML (compose) most people don't use it.

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

#248

Post by dizhn »

KetoManx64 wrote: post #233
dizhn wrote: post #220

Earlier quoted context omitted.

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?

Amounts to the same thing but no. Promox servers with two bridged interfaces. One interface has a public IP, the other a 10.0.10.0/24 etc. Multiple baremetal servers are connected by wireguard and have access to each other's private subnets. Like one other might be the 10.0.20.0/24. Setup the routes and good to go. Firewall to taste. My private LAN is all open.

This is not just for docker. There are other vms and lxc containers too.

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

#249

Post by nickjj »

Cpoll wrote: post #241
bdangubic wrote: post #209

Earlier quoted context omitted.

"Not just for my own projects but for $500 million dollar companies and more." Seems reasonable to assume these are serious production environments, no?!

Not necessarily. When you get to those numbers you're seeing dozens of teams with their own silos and deployment methods. So they might be responsible for the core business that's running 30 nodes and serving 100MM users a day, or they might be working on some internal portal or a WordPress site.

When I mentioned that, it was for a company that got acquired by a bigger company. I can't give specifics with revenue / profits but it is a 10+ year old online SAAS business and all of their web apps are being served by Docker Compose with a non-trivial amount of direct customer facing traffic.

Lots of data, caching, web apps, background workers and lots of various API integrations. No fancy React front-end, no fancy crazy system architectures. Just a typical LAMP stack but running in Docker Compose, cranking away serving value to customers with very good uptime and a very low cloud cost relative to revenue. With that said, a managed database was involved but all of the web traffic was served by apps running through Docker Compose with a simple git push model of deployment that handled thousands of deployments over the years without much fuss.

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

#250

Post by mrighele »

c0balt wrote: post #239
merb wrote: post #229

Earlier quoted context omitted.

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

AFAIK volumes are nothing more than a bind mount on a private docker folder, e.g. the files for volume my-volume are stored in /var/lib/docker/volumes/my-volume/_data, so backup strategies (an problems) for bind mounts apply also to volumes
Post reply on HN