@inthehands no, that’s pretty much it.

IIRC compose was a separately-built tool that got bought by Docker and though the command is now integrated the configuration remained completely separate. So e.g., there’s a ‘port’ option in the Dockerfile that does nothing, it’s just indicative or something? You have to do it in compose, and there’s no requirement for the Dockerfile to have been set up to expect it even.

@inthehands nope, that’s the actual state of the art. Compose is clearly bolted on, and it was never redesigned as a system.

Compose itself is a pretty shitty tool, too. And it has changed enough over the years that lots of guides are wrong.

@inthehands No, you're getting it. The correct way to use docker in production is: don't.

Docker is a reasonably useful dev tool. Docker compose, even more so. But it's wildly unsuited to production usage. If you want just a few containers on a relatively small and fixed number of hosts, podman or just containerd are better. If you want a lot of containers on a changing number of hosts, that's why people use k8s.

@inthehands Which "docker"? 🤣

@inthehands and the answer is an even scarier place to go - kubernetes.

That said, I'm using Google cloud run everyday as a user-friendly k8s and it's very good.

@inthehands Me, hearing about docker: Cool, yeah, a structured declaration of runtime dependencies does seem like a useful development.

Me, looking into docker: ...

@inthehands Docker is not art, IMHO

🙂

I’ve felt for a decade like I’m a fool for deploying on either self-managed Linux VMs or (for small projects) free tier Heroku, and now I feel like I was accidentally doing it the smart way the whole time and didn’t know it.

…or maybe I’m still in the familiarity bias phase of learning a new tool?

@inthehands but we can fix it with AI…

No, the state the art is actually that bad. We have lost the major leadership entirely.