It is not necessary. You probably achieve similar results with ansible+selinux+vpn I suppose.

But it has its uses. For instance, putting all your services in a private network and only expose port 80 and 443. Images gives your reproducibility even when your build system is not. The image validated is the one deployed. Disencentive hand editing in prod ...

Basically nothing you can not do you yourself. It just simplify (and potentially accelerate) some deployment processes.

I test and deploy in Docker containers because the artifact that's produced is simpler to deal with. I don't have to specify packages in a Chef cookbook or Ansible playbook, then figure out how to best automate the running of those, then figure out how to do it fast enough to support rapid deploys. And while I run Fedora locally, it presents an abstraction layer that's sufficient, in the 99% case, that developers on a Mac can test predictably; as a trivial example, the Dockerfile specifies an informal but strong interface with regards to environment variables, configuration files, and network ports. (That goes down to like 95% with Windows, but I haven't worked on it with WSL2 yet.)

Treating Docker containers as artifacts--as Configurable, Better Tarballs--by itself is a significant improvement for much of the non-JVM world, and even does have some benefits for the JVM world as well.

Trying to do local dev in it is silly, IMO, but there's real value to shipping Docker containers to wherever you want to actually run the thing.

Because it's easy to devops-manage it. Your docker image is built by ci during automated tests and that image is versioned and immutable from that point. It'll appear the same on staging enviornments and production environments. It's easy to deploy it on multiple hosts/clusters, manage upgrades/downgrades etc. Involving docker during development in most cases just adds friction without any benefits. There are cases where you need to work in development with docker, but those are very rare.