It's insane to build something that optimizes ease of use, and then require users to understand it in depth to avoid footgunning.
It's insane to build something that optimizes ease of use, and then require users to understand it in depth to avoid footgunning.
If https://www.portainer.io/ would do this implicitly, your argument would be more valid. But for the docker command-line it's a bit too far-fetched.
Heck, this “issue” (which, I don’t agree is an issue) only exists so that people don't have to do an additional step. Its “ease of use” which violates the principle of least surprise most commonly.
Docker does not compete with LXD which just runs containers like VMs, but with distrobuilder + LXD + including the init.yml in the deploy process.
You must explicitly expose them.
If you expose everything else too, that's no-one's fault but yours.
Furthermore, the "container networking" page (https://docs.docker.com/config/containers/container-networki...) says that Docker creates iptables rules for the purpose of creating this mapping.
The clear implication is that, say, "exposing" port 8080 should have similar behavior to simply running a program on the host that listens on port 8080. It does do that, but it also silently punches holes in your firewall, unless you make Docker-specific changes to your firewall config to work around it.
Even if a knowledgeable person reads the docs, and then sees something like "click here for the platform-specific details of how iptables rules are managed", I think it's entirely reasonable for them not to realize that those platform-specific details are in fact security-critical.