If docker container IP and external network IP is the same, then which one will get respond if it will do telnet?
I know below configuration is the worst configuration, but I want to know the behaviour.
Give you one example
My application is running in localhost which is talking to the database inside the docker container.
Custom IP we provided - (IP : 10.0.0.1, PORT :5432)
Another database running outside the container, let say both container (IP and port) and host (IP and port) are the same.
HOST IP : 10.0.0.1, HOST PORT :5432
Which one will connect by application host/container-database or both the database?
or
If will do the telnet 10.0.0.1 5432? which one will respond and why?
Explain in Diagram
I don't think that's possible, even if you have the same IP (somehow) for the container and the host, you won't be able to map the container port 5432 to the host port 5432, because there's already an application (host dB) running on that port.
Consider a scenario where you are using the host network for the container as well, probably by using the --network host. This way your container IP will be the same as the host IP. The container will be using the 5432 port of the host to run the dB. Now, if you try to start the dB on the host using the same port, you should get an error that port is already being used.
Related
I know I can map host port to container port in Docker command or in Dockerfile or in docker-compose.yml. I have no problem there, I know how to do that too.
For example, I have the following container:
$ docker container ls
ID COMMAND PORTS
84.. "python app.py" 0.0.0.0:5000->5000/tcp
I know it means the host port 5000 is mapped to container port 5000.
My question is only on the 0.0.0.0 part. I have done some study, it is said that 0.0.0.0:5000 means map port 5000 of all interfaces on host.
I understand the 5000 port on host, but I don't get "all interfaces on host", what does it mean exactly? Could someone please elaborate for me? Does it mean all network interfaces on the host? What "all interface" this "0.0.0.0" refers to exactly?
Your physical hardware can have more than one network interface. In this day and age you likely have a wireless Ethernet connection, but you could also have a wired Ethernet connection, or more than one of them, or some kind of other network connection. On a Linux host if you run ifconfig you will likely have at least two interfaces, your "real" network connection and a special "loopback" connection that only reaches the host. (And this is true inside a container as well, except that the "loopback" interface only reaches the container.)
When you set up a network listener, using the low-level bind(2) call or any higher-level wrapper, you specify not just the port you're listening on but also the specific IP address. If you listen on 127.0.0.1, your process will be only reachable from the loopback interface, but not off-box. If you have, say, two network connections where one connects to an external network and one an internal one, you can specify the IP address of the internal network and have a service that's not accessible from the outside world.
This is where 0.0.0.0 comes in. It's possible to write code that scans all of the network interfaces and separately listens to all of them, but 0.0.0.0 is a shorthand that means "all interfaces".
In Docker, this comes up in three ways:
The default -p listen address is 0.0.0.0. On a typical developer system, you might want to explicitly specify -p 127.0.0.1:8080:8080 to only have your service accessible from the physical host.
If you do have a multi-homed system, you can use -p 10.20.30.40:80:8080 to publish a port on only one network interface.
Within a container, the main container process generally must listen to 0.0.0.0. Since each container has its own private localhost, listening on 127.0.0.1 (a frequent default for development servers) means the process won't be accessible from other containers or via docker run -p.
So I have some docker web application, when it loads using docker-compose the dhcp service chooses some ip address lets say 192.168.96.3, the webapp is located at port 6000, so connecting to the webapp I use http://192.168.96.3:6000. Is there any way, in the docker-compose.yml to assign the domain name foo.local so that when I connect to the webapp I type in foo.local:6000?
In my docker-compose.yml, can I add a domain name that my host machine can map to the dynamic ip of the container?
Note:
The container uses its own network, so attaching it to the host network will conflict with its purpose.
Forwarding container port
For me you can easily accessing from the host by exposing the port of the container. So from that host you should be able to access it as localhost:6000 by exposing the port. From other machines in your network that can access the host, use the IP of the host or its name/DNS name.
For example in docker-compose.yml
services:
myservice:
image: myImage
ports:
- "published_port:container_port"
So if you put "6000:6000" its mean that on the host port 6000 will forward to the service on port 6000.
DNS
So I would say for overall access, ensure that your company DNS match foo.local to your docker host and expose the port from the container in docker to the docker host.
If you want to be able to do that only from a given machine yoythe host you can add an entry to /etc/hosts (assuming linux)
127.0.0.1 localhost
127.0.0.1 foo.local
Here this is assuming we are on the same machine, but you can use the right IP. And if you have a different OS, check the documentation on how to do that for your os.
I have deployed a netflix hystrix dashboard with turbine on a docker container, I can access to http://ip:8081/hystrix but when I try to monitor the stream of turbine it freeze and doesn't return any information, I test using curl inside the container and execute curl http://localhost:8081/turbine.stream and curl http://containername:8081/turbine.stream, with those two command works perfectly but when I use the host ip as curl http://hostip:8081/turbine.stream the curl throws Failed to connect to hostip port 8081: No route to host, I can't found a solution, can someone help me with this issue?,
Thanks in advance.
In order to access the container through Host IP you need to ensure the following:
Port mapping is allowing through the Host/Public IP itself not only localhost.
You can check this by executing docker ps on the docker host and look for the PORTS column the default should be as the following 0.0.0.0:8081->8081/tcp which means it can accept connection from any interface either public, private or localhost.
The firewall is not blocking the connection on port 8081.
By default the firewall of the host should be managed by Docker daemon itself so the port 8081 will be allowed in the firewall but you might have a different case either Docker is not managing the firewall of the host or there is an extra layer that prevents the connection
I would like to deploy multiple applications via docker. Some of them are using the same port.
An alternative port mapping (Port 80->5080) is not an option, so my way to handle the problem is a network bridge which should allow me to assign an ip address from my internal network to each container.
The answer from this post does not work for me
Assign LAN IP address to Docker container different from host's IP address
i am able to assign an ip to the docker container, but it also gets the host ip address so i can not map ports.
I have a docker container with an apache server on port 80. Port 8000 of the docker host is being forwarded to 80 in the container. Our application needs to connect to itself to use a web service. This connection URL is determined at runtime based on the URL the user is using to access the application. However, when it tries to connect to the host's IP address on port 8000, connection fails. Debugging with telnet and tracepath indicate routing error. Any hints?
The likely root cause here, is you're listening on the wrong interface in your container.
If you bind localhost:80 then you cannot access that using "publish". You need to bind 0.0.0.0:80 (or *:80 or whatever your config supports) and then it'll work.
Fixed. Turns out issue was that there was no firewall rule on the host allowing for access to the published port from the inside network.