[dead]
Should I run plain Docker Compose in production in 2026?
251–260 of 312 posts
Re: Should I run plain Docker Compose in production in 2026?
#252I 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 startin…
I use unless-stopped and containers come back up fine after reboot
Re: Should I run plain Docker Compose in production in 2026?
#253Earlier quoted context omitted.
I desperately WANT to like podman quadlets and keep trying to find a use case for them. But I always got the impression that the developers who implemented quadlets never actually had to manage multiple containers in a real production environment. Having your whole application with its containers, volumes, and networks all defined together in one easy-to-read YAML file is a way better experience. Deployment is two st…
> Having your whole application with its containers, volumes, and networks all defined together in one easy-to-read YAML file is a way better experience. Deployment is two steps: 1. `git clone foo` 2. `docker compose up -d`. You can see the state of the application containers with `docker compose ps`. You can run multiple compose applications on the same host and manage them separately by putting them in different di…
Parent complaint sounds like they are just unfamiliar in general with managing regular system services using unit files/systemctl.
Re: Should I run plain Docker Compose in production in 2026?
#254Earlier 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…
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.
Docker volumes still exist on the filesystem. Wouldn't one be able to point the backup solution at that directory?
Re: Should I run plain Docker Compose in production in 2026?
#255Earlier quoted context omitted.
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 doc…
>Systemd is a tool for managing services
It's a tool for user age verification that happens to be something you can use to manage services.
Did you miss my point about it being a filthy kitchen sink?
>This is the same system state as using docker compose with docker
One of the major selling points of podman is that you dont need a daemon. except maybe yes you do because podman compose sucks so toss that selling point in the trash.
This shit is also incredibly fiddly. Ever had "docker compose" and "docker-compose" do subtly different things which drive your team mate to pull their hair out? I have.
Podman should stop trying to piggyback off docker if it's trying to be an alternative.
>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
Personally I suspect it languished because Red Hat simply cant abide the idea that somebody out there might avoid using systemd for something.
They happily built a docker compose to quadlets converter but they cant bring themselves to make podman compose not be a piece of shit even though it wouldnt be a lot of work.
Re: Should I run plain Docker Compose in production in 2026?
#256Earlier quoted context omitted.
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…
Very interesting way to set things up. Thanks for the breakdown! It's given me some ideas for our non-prod Proxmox cluster.
Re: Should I run plain Docker Compose in production in 2026?
#257SRE here, my thought is "Sure, Docker Compose is great for production assuming your needs are light and Docker Compose works well for you." K8s as small time is overkill for sure but make sure you don't fall into this trap. https://www.macchaffee.com/blog/2024/you-have-built-a-kubern...
I spun k3s up with a config that I used an LLM to write. It's been almost 2 years. Thing just works for the most part. Even useful on a single node.
Re: Should I run plain Docker Compose in production in 2026?
#258Who are we to judge? It's whatever Claude decides.
Re: Should I run plain Docker Compose in production in 2026?
#259Earlier quoted context omitted.
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…
Very interesting way to set things up. Thanks for the breakdown! It's given me some ideas for our non-prod Proxmox cluster.
Sure thing. Let me know if you need more details.
Re: Should I run plain Docker Compose in production in 2026?
#260Earlier quoted context omitted.
> * 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 doc…
>Systemd is a tool for managing services It's a tool for user age verification that happens to be something you can use to manage services. Did you miss my point about it being a filthy kitchen sink? >This is the same system state as using docker compose with docker One of the major selling points of podman is that you dont need a daemon. except maybe yes you do because podman compose sucks so toss that selling point…
> It's a tool for user age verification that happens to be something you can use to manage services.
Good talk buddy.
> Did you miss my point about it being a filthy kitchen sink?
I suspect there's not really a point in responding to this since you've already made up your mind.
Nevertheless, yes I am aware the systemd project contains many modular components. Some of which are good (systemd-the-service-manager that is what I was referring to), some of them are bad, and some of them are just odd (still haven't wrapped my head around systemd-homed's purpose). Podman integrates with the systemd service manager, not the rest of the project, so I'm really not concerned about that: there is no point where I am unable to use quadlets because I don't have, say `systemd-timesyncd` installed.
On the gripping hand, Quadlets are just a systemd-generator so there's nothing stopping you from getting that exact same benefits of Quadlets with some other service manager. You'd just have to write that implementation (and probably your own bespoke service manager) and will probably miss out on some of the niceties systemd provides to anything it manages.
> One of the major selling points of podman is that you dont need a daemon. except maybe yes you do because podman compose sucks so toss that selling point in the trash.
You skipped the second part of my sentence where I reminded you that Podman is daemonless. There is no long-running Podman daemon/service/etc, it is spun up on demand and then stops when the action is done. Having a second process instance is not a daemon, and I'm not sure how you would have expected this to work otherwise.
> Ever had "docker compose" and "docker-compose" do subtly different things which drive your team mate to pull their hair out? I have.
..Take this up with docker?
> Personally I suspect it languished because Red Hat simply cant abide the idea that somebody out there might avoid using systemd for something. > They happily built a docker compose to quadlets converter but they cant bring themselves to make podman compose not be a piece of shit even though it wouldnt be a lot of work.
I don't think `podman-compose` was ever an official Red Hat project. I don't think there was every really much interest in ironing out all the corner cases, especially before compose was actually fully specced, and once Podman itself implemented the spec the interest has been drying up.
Assuming you're referring to podlet[0] for the latter, that was never a Red Hat project.