[mattmanser]

Running script 1 is harder than running script 2?

It's all the same stuff. Docker just wraps what you'd do in a VM.

For the slight advantage of deploying every server with a single line, you've still got to write the mutli-line build script, just for docker instead. Plus all the downsides of docker.

[aeldidi]

There's another idea too, that docker is essentially a userspace service manager. It makes things like sandboxing, logging, restarting, etc the same everywhere, which makes having that multi-line build script more valuable.

In a sense it's just the "worse is better" solution[0], where instead of applying the good practices (sandboxing, isolation, good packaging conventions, etc) which leads to those benefits, you just wrap everything in a VM/service manager/packaging format which gives it to you anyway. I don't think it's inherently good or bad, although I understand why it leaves a bad taste in people's mouths.

[0]: https://en.wikipedia.org/wiki/Worse_is_better

[827a]

Docker images are self-running. Infrastructure systems do not have to be told how to run a Docker image; they can just run them. Scripts, on the other hand, are not; at the most simple level because you'd have to inform your infrastructure system what the name of the script is, but more comprehensively and typically because there's often dependencies the run script implies of its environment, but does not (and, frankly, cannot) express. Docker solves this.

> Docker just wraps what you'd do in a VM.

Docker is not a VM.

> Plus all the downsides of docker.

Of which you've managed to elucidate zero, so thanks for that.