Hacker News Reader

Comment by Godel_unicode | Hacker News Reader

It doesn’t say that it doesn’t do that, it says that it doesn’t do that by default. If you explicitly tell it to expose a port, how can you possibly be surprised when it does so?

If you don’t read the docs you don’t get to complain when you don’t understand the behavior.

Edit: the second paragraph on the first search result for “docker networking” says that because it’s trying to present things in a platform independent way the overview won’t cover iptables specifics and then links to the detailed docs of how it uses iptables. If you can’t read two paragraphs maybe don’t try to be an engineer.

View on HN

If something is designed and marketed as being usable without reading docs, it'd damn well better have defaults that "First, do no harm."

It's insane to build something that optimizes ease of use, and then require users to understand it in depth to avoid footgunning.

Who is marketing it that way? That’s insane.

It really is. I am astonished by the simple mindedness of some people in this thread. Half knowledge really is dangerous.

No need to call people simple minded, friend. It completely debases your point to the extent that it makes me question whether you understood their point. Consider the possibility that you simply misunderstood their point.

Expecting a potentially dangerous tool to "just work" when the documentation is several thousands of words long is simple minded, especially when you watched a 10 minute video on it from some random tech blogger.

By default, Docker containers are not exposed to the host's public interface.

You must explicitly expose them.

If you expose everything else too, that's no-one's fault but yours.

Just about everyone who describes Docker, including the Docker documentation itself, describes "exposing" a port as creating a "mapping" between ports in the container and ports on the host.

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.

No. This is not the case. There is a different term that does what you mean: "publishing" a port. It's different from the "EXPOSE XYZ" syntax, and is used in the docker cli with the "-p" command.

Maybe a lesson learned from this conversation is that the documentation isn't clear about what's going on and should be updated.

The documentation is incredibly clear about this and does not need to be updated. It's mentioned multiple times. The beginning of the documentation offers information about the difference of publishing and exposing. The docker networking tab explicitly mentions that publishing a port means it's visible to the outside world.

Docker is certainly not marketed that way & even the majority of tutorials / if not all on Digital ocean or similar sites don't misguide you into doing this. It is clearly not marketed as "usable without reading docs" and even though people using it as a tool to deploy prebuilt software without learning its configuration, this doesn't apply to the docker commands itself.

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.

Honestly, I am not sure if you're right with the marketing but the docker way of “doing everything needed in a tightly coupled way” does reek of a tool that is designed primarily for ease of use.

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.

The docker way is a way of using coontainers as a form of contained application building & distribution, which builds itself (optionally on top of layers from docker hub) from a Dockerfile and is configured by a docker-compose file, minimizing the need for external configuration tools that may have problems to keep up with new features. The other feature are the layered builds, which you can mix from multiple bases.

Docker does not compete with LXD which just runs containers like VMs, but with distrobuilder + LXD + including the init.yml in the deploy process.

Reply on news.ycombinator.com