I want to export the complete ip connectivity (UDP and TCP) from a docker container with a Linux app (ie give it's own ip address (in the same subnet as the host), that can be accessed from the host and from other physical machines on the network).
What do I need to configure in Windows, what in docker, what inside the container?
(NB: I don NOT want to expose ports as part of the host).
I finally solved the problem (for me) by installing Ubuntu in Virtual Box and using the docker containers from there. Not the most elegant solution but working on first try.
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?
We have a system of numerous microservices, which when setup in local, refers to certain services in my local using their IP(of course resolved via Consul).
It becomes a problem when I connect my laptop from different networks, when the IP of my machine changes. Is there a way in which I can freeze the IP of my machine only for the communications from the containers and the services within my machine?
PS:
Of course, loop-back address won't work, as the loop-back address from container will refer to the container itself and not the host machine.
I can't run with network=host, as there will be many services in different containers running in same port.
I'm using Mac, but looking for generic solution, which would also work in Ubuntu.
Your containers shouldn't ever need to know the ip address of your host. For Docker on MacOS, you can use the hostname host.docker.internal to refer to the host, and this will work regardless of how your host's primary address changes.
While in the past this wasn't possible on Linux, you can now set up the equivalent alias by mapping that hostname to the magic address host-gateway:
docker run --add-host host.docker.internal:host-gateway ...
That will give you consistent behavior for your configurations under both Mac and Linux.
When using docker desktop, we would connect to the host machine from the container using the URL 'host.docker.internal'.
however container is not able to connect to the host machine (i.e my machine) when I am using nerdctl instead of docker.
I installed Rancher desktop to use nerdctl
ipconfig getifaddr en0
The above command will give the IP address of your wireless connection. Note, this will only work for MacOS. This IP can then be written to the /etc/hosts of your container against host.docker.internal as they share the same network. This can help the container communicate to the host machine by using host.dock.internal . Although, an elegant solution is expected from RancherDesktop (or its already available in the newer versions).
From lima docs.
The loopback addresses of the host is 192.168.5.2 and is accessible
from the guest as host.lima.internal.
So instead of host.docker.internal, provide 192.168.5.2
I have tested this with nerdctl distributed via Rancher and it works!
reference: https://github.com/lima-vm/lima/blob/master/docs/network.md
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.
We are implementing a CI infrastructure as Docker containers.
Development of the solution takes place on OS X machines:
The OS X physical machine (Host) has Vagrant installed on it, plus a service listening on localhost:2200.
On Host, we vagrant up a Linux machine (VM-a) on which we provision Docker.
On VM-a, we docker run a Linux container (VM-b). VM-b needs to interact with the service running on Host.
By way of well-documented port binding, we are able to reach any listening port on both VM-a and VM-b from the Host.
Yet, we cannot identify a way to have VM-b reach Host port 2200 on Host's localhost interface.
Is it possible to achieve such communication?
If so, how?
So, we found the "magic" interface on which to reach the Host from any VM, i.e. from booth VM-a and VM-b (nested in VM-a).
It is 10.0.2.2.