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

111–120 of 312 posts

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

#111

Post by przemub »

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…

I use UFW, and this config: github.com/chaifeng/ufw-docker

The only modification is that I pin containers to an IPv4 address so I can limit the forward rule to that address.

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

#112

Post by Lord_Zero »

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…

Could you elaborate on your setup? Is the docker host also your web server on which you run caddy?

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

#113

Post by yabones »

jackconsidine wrote: post #97

> Every docker compose pull keeps the previous image on disk. Every container with the default json-file log driver writes unbounded JSON to /var/lib/docker/containers/ / -json.log. On a busy host this is one of the most common reasons for an outage: the disk fills and Docker stops being able to write anything I ran docker compose in development a lot. Just an easy way to turn on / off 5 different services at once fo…

A very simple fix for that is to use the systemd log driver to send all the container logs to journald. Then you can set a size or time limit on journald.

https://docs.docker.com/engine/logging/drivers/journald/

I believe Podman can do something similar.

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

#114

Post by cheschire »

2ndorderthought wrote: post #11

Should you have a turkey sandwich for lunch in 2026? I don't know buddy just do whatever. There are ten thousand other sandwiches you could eat surely, but does turkey sound good for you?

Caffeine is healthy. Caffeine is unhealthy. Caffeine is healthy again. Eggs are healthy. Eggs are unhealthy. Etc etc etc.

There’s a reason articles like this exist. Things change.

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

#115

Post by duskdozer »

Pxtl wrote: post #88
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…

Thank you. I had been procrastinating on learning how to work with containers and finally got a handle on Docker Compose to play with self-hosting a coding agent and was worried that I'd once again procrastinated so long that I'd picked something up long after it was already dead.

It makes things amazingly simple and portable, dealing with things otherwise seems so horrible now.

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

#116

Post by gomoboo »

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…

I put a firewall ahead of the Docker host so that they aren't running on the same system. Docker can do what it wants to on the host without stepping on my firewall rules.

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

#118

Post by jiggunjer »

poly2it wrote: post #17
2ndorderthought wrote: post #11

Should you have a turkey sandwich for lunch in 2026? I don't know buddy just do whatever. There are ten thousand other sandwiches you could eat surely, but does turkey sound good for you?

Is your point that we shouldn't motivate our technological choices? I wouldn't use Docker Compose in production.

I note the absence of a motivation.

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

#119

Post by kitd »

greenicon wrote: post #61
pmig wrote: post #21

Earlier quoted context omitted.

What are the benefits of running Podman Compose instead of Docker Compose? I don't see how it helps with orphan containers, logs and mutable tags.

Docker (Compose) has some quirks compared to Podman (Compose), e.g. when using gvisor or a lot of internal networks. Depending on what you do your milage will vary, though.

Agreed. I found compose overlay files merged list values differently between the Docker and Podman versions, which was a PITA in teams running Docker & Linux dev machines.

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

#120

Post by mystifyingpoi »

TheCapeGreek wrote: post #58

Somewhat adjacent in how I look at using Docker at all in prod, here's what I always wonder: Is using Docker/Compose "just" as the layer for installing & managing runtime environment and services correct? Especially for languages like PHP? I.e. am I holding it wrong if I run my "build" processes (npm, composer, etc) on the server at deploy time same as I would without containers? In that sense Docker Composer becomes…

> if I run my "build" processes (npm, composer, etc) on the server at deploy time

It's perfectly fine, as long as you accept the risks and downsides. Your IP can get ratelimited for Docker Hub. The build process can exhaust resources on the host. Your server probably needs access to internal dev dependencies repository, thus, needs credentials it would not need otherwise. Many small things like that. The advantage is simplicity, and it's often worth the risk.

Post reply on HN