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

101–110 of 312 posts

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

#101

Post by freedomben »

pmig wrote: post #65
stevefan1999 wrote: post #52

I really want something that is Docker Compose but for Kubernetes. I mean that I can have a simple way to declaring resources in just like Docker Compose, but I run the environment in Kubernetes so that I can get to test the behaviors when there are multiple copies of the softwares running together. I do rely on Kubernetes heavily for distributed and networked software deployment, so it is even better if we can emula…

This is a problem we, as a company, have thought about a lot, but we always concluded that Kubernetes is already the simplest abstraction of a distributed system that is feasible for the diverse needs that the biggest companies out there have. We previously built a package manager for Kubernetes to abstract it in the simplest way possible `glasskube install app` but we failed because every abstraction needs to follow…

Same, I've tried three or four times to make it work, including one attempt that just translated compose.yaml into k8s yaml, and every time I came away thinking, "just use k8s". K8s yaml looks complex, and can start to feel very boilerplate, but attempts to hide the complexity often just lead to something not-flexible-enough because it encodes convention over configuration, and inevitably some project runs into limitations and pretty soon you've just built an abstraction layer that leaks or is equally complex/verbose and now you have to learn something new.

Just use k8s and follow similar patterns is the conclusion I've arrived at personally.

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

#102

Post by freedomben »

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!

I did that too, and ended up just skipping helm and using envsubst to interpolate the values I need at runtime from env vars. Nearly everyone preferred that approach. YMMV of course.

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

#103

Post by hkpack »

dizhn wrote: post #93
merpkz wrote: post #57

How do you guys, who run Docker in production deal with managing nftables firewall on hosts running containers? By design docker daemon creates and manages a set of firewall rules to forward traffic between containers and ingress traffic into containers as well as masquarades the outgoing container traffic. That is all well until admin needs to alter hosts firewall to allow and deny other traffic unrelated to docker…

My containers run in dedicated "docker host" VMs. And I never expose ports on 0.0.0.0, just the private internal IP. Most (all) of my docker hosts do not have a public IP anyway. I use wireguard to access them myself. If they need to be public I reverse proxy with caddy from my web server (or use Authentik's embedded proxy). These servers have access to the same private LAN which could be hardened without having the…

This is the way, ended up using identical setup.

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

#105

Post by chatmasta »

tontony wrote: post #46

Compose is great, but a couple things always created friction for me when using it for non-local setups: * Lack of a user-friendly way of managing a Docker Compose installation on a remote host. SSH-forwarding the docker socket is an option, but needs wrappers and discipline. * Growing beyond one host (and not switching to something like Kubernetes) would normally mean migrating to Swarm, which is its own can of worm…

For remote installation, use the `docker context` command. You create a context with a named SSH host and then it connects via SSH to that host (as configured in your local ssh_config) and uses its docker daemon. Everything works flawlessly apart from local bind mounts (for obvious reasons).

If you remember `docker machine`, this is basically the modern version of that.

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

#106

Post by PxldLtd »

pydry wrote: post #47
figmert wrote: post #43

Earlier quoted context omitted.

I'm not OP, but the whole podman compose topic gets quite confusing, as initially Podman didn't seem to know what they were trying to do. I've given some more context around it in previous comments. You shouldn't be using podman compose. It's flimsy and doesn't work very well (at least it was last time I used it prior to Podman v3), and I'm pretty sure it doesn't have Red Hat's direct support. Instead, activate Podma…

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.

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

#107

Post by throw5 »

vincentkriek wrote: post #104
faangguyindia wrote: post #89

I am using systemd + go binary deploy. Running 10 years+ in production. Meanwhile docker based setup fail every now and then. And kubernetes? well forget about it.

How does this work? Can you show it?

I mean no disrespect. This is more of a rant at how things are today. It is telling that over-complicated solutions have become so common that, for the current generation of devs, Kubernetes is the obvious way of doing stuff and a simple systemd service is the obscure one. I am sure there are good reasons for this, but it still feels like a loss when simplicity is no longer obvious.

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

#108

Post by lorenzohess »

nathanmills wrote: post #62
gchamonlive wrote: post #30

Earlier quoted context omitted.

> does turkey sound good for you? What if you can't by yourself objectively evaluate if turkey sandwich sounds good? It's not a matter of giving a universal answer to whether docker compose in production is fine, but how to evaluate it. Which features or safeguards necessary for a healthy production environment you forfeit when choosing plain docker compose? What's the tradeoff?

Then you either need to try it or research it. Other people can't tell you if you like turkey or not.

The user plausibly isn't asking others to tell him what he "likes" -- a subjective preference -- but rather the user could be asking for objective research and information.

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

#109

Post by stirfish »

gchamonlive wrote: post #68
nathanmills wrote: post #62

Earlier quoted context omitted.

Then you either need to try it or research it. Other people can't tell you if you like turkey or not.

So we agree people shouldn't write off these posts with "does turkey sandwich sounds good to you" like it's some deep insight to default to the trivial answer?

Does a turkey sandwich sound good to you?

Yes: okay try it

No: okay you don't have to try it

Unsure: okay you can read about it some more and decide if it sounds good to you

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

#110

Post by INTPenis »

Sure why not, it just never fits into my model of how I design infrastructure.

Docker compose assumes all your services can reach each other over docker, which I find horribly insecure.

I separate all my services by user account at least, maybe even by VM, and I run them all in rootless podman containers. So it just doesn't fit my style, but I'm sure it works fine.

Post reply on HN