[nameless912]

Serious question: while I totally agree with most of this, why bother building e.g. RPMs or DEB packages when you can just stamp out a docker container? I've had a lot of success using docker as _just_ a packaging mechanism and nothing else. Is there some fundamental bit I'm missing for why that's a bad idea?

At my last company we implemented a couple of different services as just an AWS provided AMI with a small init script that would install docker if necessary, pull our container, and run it with the ports mounted properly. That worked great in ASGs and totally obviated the need to think about machine provisioning beyond 3 or 4 simple steps that everyone understood. I feel like Docker gets a bad rap _because_ of Kubernetes, when in fact Docker on its own solves a real problem in a pretty elegant way.

[bradstewart]

Docker isn't just a packager--it adds a whole nother layer of runtime to your app.

Access to network/disk/other IO, logging, init systems, configuration, etc are all different under Docker. There's more pieces of software which can crash (docker engine, etc). Not to mention potential performance issues and/or other subtle differences which may occasionally occur.

This isn't to say Docker has no value--it does, and we use it in production on a number of applications. But it is certainly more than just a package.

[user5994461]

The strength from having a reusable medium (docker or otherwise) is when there are integrations on top to manage deployment, failover, DNS, load balancing, certificates, etc... none of which is handled by docker. You must have noticed since you had to implement some of these.

Kubernetes is getting adoption because it's helping with that. That's where the hard work and the value is.

Docker by itself is not notable, it's a fancy zip/rpm file.