[RussianCow]

Almost none of what you just mentioned has anything to do with Docker, and you can easily have that much trouble just running a binary. (In fact, I've found that many projects have better documentation for their Docker image than for running it natively.) Yes, there are some Docker-specific things you sometimes have to debug (especially with networking), but I've had far more trouble getting software running natively on my machine due to mismatches in local configuration, installed library versions, directory conventions, etc vs what's expected. It's also far easier to blow away all the containers and volumes and start over with Docker; no need to hunt down that config file in an obscure place that's still messing with the deployment.

[enneff]

This is a strange argument to me. It’s essentially that the additional complexity of docker compose is acceptable because other things are unnecessarily complex. The problem is complexity. There are many great projects that are just “build the binary, edit config file, and run it,” and why should things be more complex than that? It’s wild to me what people will put up with.

[RussianCow]

> It’s essentially that the additional complexity of docker compose is acceptable because other things are unnecessarily complex.

Not quite. My point was that the complexity of Docker is, in many cases, worth it because it hides a lot of the complexity of running software. Yes, you trade one problem for another, but the nice thing about Docker is, if you really go all in on it, the knowledge of how to use it transfers to pretty much any software you want to run.

For example, I wanted to run a JVM-based service the other day. Having never done this before, spinning it up with Docker took two minutes—I didn't have to figure out JDK vs runtime, which version I needed to install, etc. And yet, if I want to configure it past the defaults in the future, the image exposes several environment variables that make it easy.

[xorcist]

> none of what you just mentioned has anything to do with Docker [...] > there are some Docker-specific things you sometimes have to debug

Not sure what to make of this. Networking was specifically called out as an example.

But there are stories to share about the storage layer too. Lots of driver specific things that leak through that abstraction.

One may use Docker for a lot of things but ease of operations is not one of them. There's a reason both Red Hat and Ubuntu had to make up their own formats, neither of which is trivial to use, but there was just no way they could have done it with Docker instead. They're unlikely both wrong here.