![]() This socket can be used by anyone on the host (or with access to the host's network) to send data to the container.The process on the host system starts acting as a user space proxy and opens a socket using the specified address.Summarizing, when you publish a port in Docker Desktop: It can be verified using a privileged container running in the VM's network namespace (the -net host flag because for Docker Engine the VM is the host): $ docker run -privileged -net host -it -rm alpineĪnd the mysterious vpnkit-bridge (part of the VPNKit project) helps cross the borders between the host and the VM systems. Inside the VM, the implementation of port publishing seems to be no different from the one described in the Docker Engine section of this article. $ sudo lsof -i -P | grep LISTEN | grep :8080Ĭom.docke. You can pinpoint this process with lsof: $ docker run -d -p 8080:80 -name nginx-1 nginx When you start a container that publishes a port, a proxy process on the host (e.g, on macOS) opens a real socket using the specified IP address and port. To cut a long story short, in the case of Docker Desktop, it's a combination of user space-based and traditional iptables-based port forwarding. Evidently, it's not routable from the host system (macOS, in my case). Therefore, the above 172.17.0.3 address is an address from a bridge network that exists only inside that virtual machine. So, Docker Desktop for Mac (and likely for Windows and Linux as well) sneakily starts a full-blown virtual machine running a custom Linux distro with pre-installed Docker Engine. Docker containers require a Linux kernel. Being able to access that IP address allows you to call any services running inside of the container (assuming they listen on the container's public interface).įor instance, with Docker Engine on Linux (not to be confused with Docker Desktop that also supports Linux since May 2022), you can create an nginx container and curl it from the host: $ docker run -d -name nginx-1 nginxĭocker inspect -f '' nginx-1 Normally, a container has its own network stack and IP address. So, port forwarding or, as it's also called, port mapping is just a fancy way to say that data addressed to one socket is redirected to another by an intermediary (for instance, by a network router or a proxy process).īecause I think that understanding the idea behind port forwarding and the most common ways to implement it is vital for the in-depth discussion of why and how to publish container ports. Sockets are meant to represent the participants of a network data exchange. ![]() When we say port we usually refer to a certain socket address defined by a pair of IP address and port number. I'll also take a look under the hood of different "single-host" container runtimes (Docker Engine, Docker Desktop, containerd, nerdclt, and Lima) to compare the port publishing implementations and capabilities.Īs always, the ultimate goal is to gain a deeper understanding of the technology and get closer to becoming a power user of containers. In this article, I'll try to connect the dots between port publishing, the term apparently coined by Docker, and a more traditional networking technique called port forwarding. Easy-peasy!īut have you ever wondered what actually happens when you ask Docker to publish a port? The next thing you do is docker run -p 8080:80 app and then open localhost:8080 in the browser. A typical need for publishing arises like this: you're developing a web app, locally but in a container, and you want to test it using your laptop's browser. If you're dealing with containers regularly, you've probably published ports many, many times already.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |