![]() Man in black jacket standing in front of red and blue intermodal containers © Pat Whelen, Unsplash License. ![]() Then you can have docker port confirm that it is indeed only available on localhost: $ docker port my_container_nameĬompare before-and-after with access both through and around the proxy and you should find that direct requests now go unanswered. The docker port command reveals… $ docker port my_container_nameīut if you make it explicit that you want publish-to-local, like so (yes, they’re are two colons in that line, apparently docker knows which means what): ports: If your “port” section is set up to forward port 80 on the container to port 8080 on the host, like so: ports: A fair bit faster than learning iptables, if you haven’t gotten round to it yet. Even so, this solution is simple and elegant and takes five minutes to implement. Which may explain why there is so little said about it. It goes without saying that this should probably be covered by firewall rules anyway. Some simply suggest a misconfiguration, others start spilling errors and revealing configuration settings. In addition, many applications won’t react well to being called with a not-configured-for scheme or port and maybe an IP address instead of a host name. if I use the proxy’s log as the main indicator of what traffic I’m seeing. It certainly creates opportunities for evasion, e.g. ![]() Is that a concern? Short answer: I don’t know. If the published ports are on 0.0.0.0 (and not shielded by firewall rules), the option is there for visitors to sidestep the proxy and talk directly to the application. If you use a reverse proxy in front of the applications being published, you only really want the application to be accessed via the proxy. Why does it matter? When would you use this? Isn’t the entire point of publishing ports to make what you’re publishing accessible to the world? Please check that dummy kernel module is loaded before running the above command: sudo lsmod grep dummy. If you’re shaky on publish, expose and what exactly one or the other entails, see Lou Martin Caraig’s excellent explanation. This lines add another loopback named loop1, loop2, loop3: sudo ip link add name loop1 type dummy sudo ip link add name loop2 type dummy sudo ip link add name loop3 type dummy. Which makes me think I might be off on a strange tangent but I can’t find any fault with my thinking, so for what it’s worth, I’m sharing. In fact, the only way to tell, is to look at the examples given. Very little is made of this fact on the docker-compose file documentation. if only a port is specified on the host side of the equation, the port is published on all interfaces, and so accessible from both the host itself and from the network. When you use the “ports” setting – whether in docker-compose or docker run – to publish ports to the host, you actually have a choice between publishing those ports on the loopback interface (127.0.0.1) or all interfaces (0.0.0.0).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |