I understand that docker desktop creates a VM host for my containers to run.
When I run docker inspect {container_name}, I can see my container has an address of 172.x.x.x.
I use a subnet 172.16.0.0/13 for lab networking, and so I've found that any time I try to ping the container from my windows host, the traffic goes out my lab nic, as I would expect.
I'm aware I could add a route to send traffic to the virtual nic that is created to contact the VM host, but this would conflict with my custom subnet.
How can I make docker use IPs outside of my local subnet? I believe if I could get my containers to use 172.24.0.0/16, then I could add a custom route to funnel traffic from my windows host to the virtual docker host.
Related
If I run Docker locally and I bind the containers' ports, I usually connect with them through localhost and not through the dynamically created IP address. I might start a MySQL container, bound with 3306:3306 and can then connect with it to localhost:3306.
If I am using a virtual machine in Windows to run Docker in (e.g. with VirtualBox), the VM has its own interface (e.g. VirtualBox Host-Only Network) which might have an IP address of 192.168.50.1. I can now connect to a MySQL container via 192.168.50.1:3306.
Using a different interface/network for my containers is useful during development because I free up my localhost ports for other things and many browsers treat localhost differently than it does other addresses.
However, Docker Desktop also has advantages over a VM:
Not having to manage the VM
Testcontainers out-of-the-box
Docker Desktop is nice
Should it not be possible to get Docker to bind to ports on a virtual interface instead of localhost, e.g. by creating a Windows virtual switch or even by using the existing VirtualBox network? And is it possible to do this for Docker Desktop (on Windows) for all containers by default?
This answer indicates there's an --ip option available when starting the Docker daemon, but:
Which IP address do I use here? The gateway is the only IP address that I have configured for a virtual switch.
What is the equivalent for Docker Desktop?
I have an headless server with VirtualBox. It run multiple virtual machines. One of them is a web proxy. It redirect external access to the right VM in function of the subdomain. Those VMs are communicating between them with internal network (intnet).
I would like to add some docker container to this configuration. How could I successfully create a network shared between my docker containers and this proxy VM ?
I tried to create a bridge network with docker docker network create my_net and then connect the VM with a additional network card in 'bridged' mode.
With this config ping works but not the actual connection. It isn't impossible to display the web page into a browser.
Am I missing some configuration here ? Also, is it a good practice to connect one VM to a docker network ?
Run the containers on one of the VMs. Use a totally normal Docker setup here: create a network for inter-container communication but don't configure it, and completely ignore the container-private network details and IP addresses.
When you use the docker run -p option, that will publish a container's port on its VM's network interface(s). From that point, other VMs can call the published port using that VM's IP address, just as if it were a non-container process running on the VM. Conversely, containers should be able to make outbound calls to the other VMs without special setup.
For regular docker containers (say the hello world example), after you run it, it is accessible thought localhost, where you can make a request it through your browser.
But sometimes it seems to access a container you need a special IP address. I'm wondering what's this behavior of docker container networking called and where is it defined/documented.
Let's say my local ip address is 10.0.75.1 (got from Network properties in Windows settings named, vEthernet (DockerNAT)). But in order to connect to a container running I had to use ip address 10.0.75.2. Why is this?
If try to inspect existing docker networks using docker network [cmd], the containers seem to be on different subnets, for example '172.17.0.0/16'
I am using Docker desktop, I have a couple of docker containers running using docker-compose and port forwarding. I can access the containers from my mac using localhost. On the second container, I am exposing on different ports. I can see ip addresses are associated to both containers by using docker inspect, but I cannot access using the ip address.
I would like access the container from my local mac by
dns domain
ip address
Any help appreciated.
Thanks
You cannot directly connect to the container-private IP addresses on MacOS. You also can't connect to them using a VM-based Docker implementation like Docker Toolbox or Kubernetes' minikube, or from a different host. Looking up and using these IP addresses, or trying to manually set them, usually isn't a best practice.
Instead you can use the docker run -p option to publish a port from your container to the host. Programs running directly on the host can access the container using localhost as a host name and the published port number. This works on all platforms; on VM-based solutions use the VM's IP address instead of localhost; from a different host, use the Docker host's DNS name or IP address.
i want to expose the container ip to the external network where the host is running so that i can directly ping the docker container ip from an external machine.
If i ping the docker container ip from the external machine where the machine hosting the docker and the machine from which i am pinging are in the same network i need to get the response from these machines
Pinging the container's IP (i.e. the IP it shows when you look at docker inspect [CONTAINER]) from another machine does not work. However, the container is reachable via the public IP of its host.
In addition to Borja's answer, you can expose the ports of Docker containers by adding -p [HOST_PORT]:[CONTAINER_PORT] to your docker run command.
E.g. if you want to reach a web server in a Docker container from another machine, you can start it with docker run -d -p 80:80 httpd:alpine. The container's port 80 is then reachable via the host's port 80. Other machines on the same network will then also be able to reach the webserver in this container (depending on Firewall settings etc. of course...)
Since you tagged this as kubernetes:
You cannot directly send packets to individual Docker containers. You need to send them to somewhere else that’s able to route them. In the case of plain Docker, you need to use the docker run -p option to publish a port to the host, and then containers will be reachable via the published port via the host’s IP address or DNS name. In a Kubernetes context, you need to set up a Service that’s able to route traffic to the Pod (or Pods) that are running your container, and you ultimately reach containers via that Service.
The container-internal IP addresses are essentially useless in many contexts. (They cannot be reached from off-host at all; in some environments you can’t even reach them from outside of Docker on the same host.) There are other mechanisms you can use to reach containers (docker run -p from outside Docker, inter-container DNS from within Docker) and you never need to look up these IP addresses at all.
Your question places a heavy emphasis on ping(1). This is a very-low-level debugging tool that uses a network protocol called ICMP. If sending packets using ICMP is actually core to your workflow, you will have difficulty running it in Docker or Kubernetes. I suspect you aren’t actually. Don’t worry so much about being able to directly ping containers; use higher-level tools like curl(1) if you need to verify that a request is reaching its container.
It's pretty easy actually, assuming you have control over the routing tables of your external devices (either directly, or via your LAN's gateway/router). Assuming your containers are using a bridge network of 172.17.0.0/16, you add a static entry for the 172.17.0.0/16 network, with your Docker physical LAN IP as the gateway. You might need to also allow this forwarding in your Docker OS firewall configuration.
After that, you should be able to connect to your docker container using its bridge address (172.17.0.2 for example). Note however that it will likely not respond to pings, due to the container's firewall.
If you're content to access your container using only the bridge IP (and never again use your Docker host IP with the mapped-port), you can remove port mapping from the container entirely.
You need to create a new bridge docker network and attach the container to this network. You should be able to connect by this way.
docker network create -d bridge my-new-bridge-network
or
docker network create --driver=bridge --subnet=192.168.0.0/16 my-new-bridge-network
connect:
docker network connect my-new-bridge-network container1
or
docker network connect --ip 192.168.0.10/16 my-new-bridge-network container-name
If the problem persist, just reload docker daemon, restart the service. Is a known issue.