I have set up a docker stack with telegraf, influxdb and grafana to monitor urls using telegraf's http_request input.
When it monitors external URLs like google there is no problem, but when it launches the request for hostname mydomain. com and it resolves to the same ip the telegraf container gives a timeout.
I have tried from inside the container to launch a curl and indeed it fails, but from the host (outside the container) the curl works.
Any idea what could be going on or where I could move forward?
root#08ad708c4a09:/# curl -m 5 https://mydomain1.com:9443
curl: (28) Connection timed out after 5001 milliseconds
root#08ad708c4a09:/# ping mydomain1.com
PING mydomain1.com (itself.ip.host.machine) 56(84) bytes of data.
64 bytes from 1.vps.net (itself.ip.host.machine): icmp_seq=1 ttl=64 time=0.148 ms
64 bytes from 1.vps.net (itself.ip.host.machine): icmp_seq=2 ttl=64 time=0.138 ms
64 bytes from 1.vps.net (itself.ip.host.machine): icmp_seq=3 ttl=64 time=0.126 ms
^C
--- mydomain1.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 25ms
rtt min/avg/max/mdev = 0.126/0.137/0.148/0.013 ms
root#08ad708c4a09:/# curl -m 5 mydomain2.com
Hello world
thank you very much community.
I hope that telegraf's http_request knows how to resolve a domain that points to the same ip and does not respond with a timeout.
We've been experiencing a long-standing networking issue. In short, one container cannot ping (or ssh) another. Does anybody have an extra moment to think along with me?
Our setup:
Docker CE 18.06.03 (while trying to fix the issue, we've upgraded from 17.03, but it has not helped)
Swarm Classic (Standalone) 1.2.9
Consul as a Swarm backend, running with members on five nodes
Seven nodes in total, six of which host containers
Each container is connected to an overlay network when it is started
What we've tried so far:
This issue has largely stumped us. We've spent a lot of time on it and done much of the basic troubleshooting, and some more advanced troubleshooting (happy to elaborate). (But I don't expect that I've exhausted our options, so please don't hesitate to suggest anything you may think will work.)
It's inconsistent (happening to different images, different nodes), intermittent, and long-standing (several months). We've made two changes, one of which was a workaround for MAC address assignment (explained here: https://github.com/docker/libnetwork/pull/2380; the actual workaround: https://github.com/systemd/systemd/issues/3374#issuecomment-452718898), which did improve the situation, including removing MAC address assignment errors from the logs. We also upgraded to get this fix (https://github.com/docker/libnetwork/pull/1935), which deals with IP reuse. This also decreased the problem (at the time, no containers could communicate). I've also run through some basics tests using the netshoot container (let me know if you want more info on that).
We have a workaround for a given container that is broken: we delete the Consul data for this container and then stop and restart it. From what I can tell, it does not seem to be an issue with the Consul data per se but instead comes from Docker/Swarm resetting several network configurations when the container is started (I can say more if this seems to trigger a thought for anybody reading). Then, the container can often ping other containers, but not always.
Specific question:
It seems like there's a window of time during which this can be worse. It's not necessarily tied to starting several containers at once, but there's a somewhat clear pattern: during some windows of time, containers do not get configured properly to communicate with each other. What troubleshooting steps come to mind for you?
The content below is the output from trying to ping one container (82afb0dccbcc) from two other containers. It fails at first, but then is successful.
The first time I try to ping the container, at 2019-12-10T23:57:52+00:00:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
82afb0dccbcc: user___92397089 crccheck/hello-world
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PING 82afb0dccbcc (172.24.0.165) 56(84) bytes of data.^M
^M
--- 82afb0dccbcc ping statistics ---^M
4 packets transmitted, 0 received, 100% packet loss, time 3033ms^M
^M
PING 82afb0dccbcc (172.24.0.165) 56(84) bytes of data.^M
64 bytes from user___92397089.wharf (172.24.0.165): icmp_seq=2 ttl=64 time=0.083 ms^M
64 bytes from user___92397089.wharf (172.24.0.165): icmp_seq=3 ttl=64 time=0.072 ms^M
64 bytes from user___92397089.wharf (172.24.0.165): icmp_seq=4 ttl=64 time=0.073 ms^M
^M
--- 82afb0dccbcc ping statistics ---^M
4 packets transmitted, 3 received, 25% packet loss, time 3023ms^M
rtt min/avg/max/mdev = 0.072/0.076/0.083/0.005 ms^M
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
In this first ping test, above, we note that the packet loss from the first container is 100% and from the second container, it is 25%.
A few minutes later (2019-12-10T23:57:52+00:00), however, 82afb0dccbcc can be successfully pinged from both containers:
82afb0dccbcc: user___92397089 crccheck/hello-world
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ping from ansible-provisioner:
PING 82afb0dccbcc (172.24.0.165) 56(84) bytes of data.^M
64 bytes from user___92397089.wharf (172.24.0.165): icmp_seq=1 ttl=64 time=0.056 ms^M
64 bytes from user___92397089.wharf (172.24.0.165): icmp_seq=2 ttl=64 time=0.073 ms^M
64 bytes from user___92397089.wharf (172.24.0.165): icmp_seq=3 ttl=64 time=0.077 ms^M
64 bytes from user___92397089.wharf (172.24.0.165): icmp_seq=4 ttl=64 time=0.087 ms^M
^M
--- 82afb0dccbcc ping statistics ---^M
4 packets transmitted, 4 received, 0% packet loss, time 3063ms^M
rtt min/avg/max/mdev = 0.056/0.073/0.087/0.012 ms^M
ping from ansible_container:
PING 82afb0dccbcc (172.24.0.165) 56(84) bytes of data.^M
64 bytes from user___92397089.wharf (172.24.0.165): icmp_seq=1 ttl=64 time=0.055 ms^M
64 bytes from user___92397089.wharf (172.24.0.165): icmp_seq=2 ttl=64 time=0.055 ms^M
64 bytes from user___92397089.wharf (172.24.0.165): icmp_seq=3 ttl=64 time=0.060 ms^M
64 bytes from user___92397089.wharf (172.24.0.165): icmp_seq=4 ttl=64 time=0.085 ms^M
^M
--- 82afb0dccbcc ping statistics ---^M
4 packets transmitted, 4 received, 0% packet loss, time 3062ms^M
rtt min/avg/max/mdev = 0.055/0.063/0.085/0.015 ms^M
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
You need to create a network and connect both the containers to that network.
The Docker embedded DNS server enables name resolution for containers connected to a given network. This means that any connected container can ping another container on the same network by its container name.
From within container1, you can ping container2 by name.So, its important to explicitly specify names for the containers otherwise this would not work.
Create two containers:
docker run -d --name container1 -p 8001:80 test/apache-php
docker run -d --name container2 -p 8002:80 test/apache-php
Now create a network:
docker network create myNetwork
After that connect your containers to the network:
docker network connect myNetwork container1
docker network connect myNetwork container2
Check if your containers are part of the new network:
docker network inspect myNetwork
Now test the connection, you will be able to ping container2 from container1:
docker exec -ti container1 ping container2
I actually ran into this issue randomly, but in my case both containers were already on the same network so it was puzzling me why one container couldn't ping another.
until I ran docker network inspect myNetwork and randomly noticed that for some reason both containers were assigned the SAME mac address... no idea why that happened or even how. Obviously that would preclude pinging since on a LAN mac addresses are used by switching logic to route traffic.
I had to stop and remove the container then recreate it to change the mac address.
In case, if there is any webapp is running on any one of your container and you want to ping/call any endpoint from another container and want to use response then you can follow steps as mentioned below -
First establish inter-container communications using docker network
1. docker network create dockerContainerCommunication
Now connect containers to network dockerContainerCommunication
2. docker network connect dockerContainerCommunication container1
3. docker network connect dockerContainerCommunication container2
Now start your containers (if not started)
4. docker start container1
5. docker start container2
Inspect your network. Here you can also find out IP address of the containers.
docker network inspect dockerContainerCommunication
Now attach to any one of the container from where you want to use web application, then ping other container using curl + IP address you found out in step 6.
or
docker attach container1
OR
docker attach container2
and then run curl command
curl http://IP_ADDRESS:PORT_ON_WHICH_APP_IS_RUNNING/api/endpointPath
I hope it helps.
I have very weird problem:
I have the swarm cluster and one of my service have wrong ip:
$ docker service inspect nginx_backend | grep Addr
"Addr": "10.0.0.107/24"
From any container in the cluster:
/ # ping nginx_backend
PING nginx_backend (10.0.0.107): 56 data bytes
64 bytes from 10.0.0.107: seq=0 ttl=64 time=0.057 ms
64 bytes from 10.0.0.107: seq=1 ttl=64 time=0.061 ms
64 bytes from 10.0.0.107: seq=2 ttl=64 time=0.064 ms
64 bytes from 10.0.0.107: seq=3 ttl=64 time=0.083 ms
^C
--- nginx_backend ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.057/0.066/0.083 ms
But in the server which hosted nginx_backend container:
root#backend:~# docker inspect nginx_backend.1.myzy10psfdl9r4jljrsz5zd5t | grep IPv4
"IPv4Address": "10.0.0.87"
And when some service try connect by name it got connect error, but if I manually put record like 10.0.0.87 nginx_backend to /etc/hosts inside a container, it have successful connect.
What I did wrong?)
Docker creates (by default) a Virtual IP (VIP) for each service. That's the 10.0.0.107. It then balances requests between the backend containers. In the second example (10.0.0.87) you're seeing the IP address of one of the containers. That's routable within Docker as well (which is why hitting the IP works). However the name (nginx_backend.1.myzy10psfdl9r4jljrsz5zd5t) is not DNS resolvable so that's why that fails.
You can find a list of the 'backing' containers for a service by doing a DNS lookup on tasks.nginx_backend.
Some more background here: https://docs.docker.com/network/overlay/
I'm trying to insure the connection between the different containers and the localhost address (127.0.0.1) used with port 8040.( My web application container run using this port.)
root#a70b20fbda00:~# curl -v http://127.0.0.1
* Rebuilt URL to: http://127.0.0.1/
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* connect to 127.0.0.1 port 80 failed: Connection refused
* Failed to connect to 127.0.0.1 port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to 127.0.0.1 port 80: Connection refused
This is what I get when I want to connect to localhost from inside the container
root#a70b20fbda00:~# curl -v http://127.0.0.1:8040
* Rebuilt URL to: http://127.0.0.1:8040/
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* connect to 127.0.0.1 port 8040 failed: Connection refused
* Failed to connect to 127.0.0.1 port 8040: Connection refused
* Closing connection 0
curl: (7) Failed to connect to 127.0.0.1 port 8040: Connection refused
About iptables in each container:
root#a70b20fbda00:~# iptables
bash: iptables: command not found
Connection between the container is good
root#635114ca18b7:~# ping 172.17.0.1
PING 172.17.0.1 (172.17.0.1) 56(84) bytes of data.
64 bytes from 172.17.0.1: icmp_seq=1 ttl=64 time=0.061 ms
64 bytes from 172.17.0.1: icmp_seq=2 ttl=64 time=0.253 ms
--- 172.17.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
root#635114ca18b7:~# ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.080 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.100 ms
--- 127.0.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
root#635114ca18b7:~# ping 172.17.0.3
PING 172.17.0.3 (172.17.0.3) 56(84) bytes of data.
64 bytes from 172.17.0.3: icmp_seq=1 ttl=64 time=0.149 ms
64 bytes from 172.17.0.3: icmp_seq=2 ttl=64 time=0.180 ms
--- 172.17.0.3 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.149/0.164/0.180/0.020 ms
Ping the 127.0.0.1:8040
root#635114ca18b7:~# ping 127.0.01:8040
ping: unknown host 127.0.0.1:8040
What I need to do in this case?
So the Global image that there is two containers ,
The first container contains a tomcat server that deploy my web application and it turnes perfectly.
The second is a container that need to connect to the web application
URL. http://127.0.0.1:8040/my_app
you will have to use docker run --network host IMAGE:TAG for achieving the desired connection
further read here
example:-
docker run --network host --name CONTAINER1 IMAGE:tag
docker run --network host --name CONTAINER2 IMAGE:tag
inside container - CONTAINER2 you will be able to access other container as host CONTAINER1
And for accessing the service you will have to do CONTAINER:
Based on the information provided, looks like there are two containers. If these two containers are started by docker without --net=host then each of them get two different IP addresses. Say your first container got 172.17.0.2 and the second one 172.17.0.3.
In this scenario each container gets it's own networking stack. So 127.0.0.1 refers to it's own networking stack not the same.
As pointed out by #kakabali, it's possible to run the containers with host network, sharing the networking stack of the host.
One of the other options is to use the actual IP address of the first container in the second one.
second-container# curl http://172.17.0.2
Or another option is to run the second container as the sidekick/sidecar container sharing the networking stack of the first one.
docker run --net=container:${ID_OF_FIRST_CONTAINER} ${IMAGE_SECOND}:${IMAGE_TAG_SECOND}
Or if you use links correctly:
docker run --name web -itd ${IMAGE_FIRST}:${TAG_FIRST}
docker run --link web -itd ${IMAGE_SECOND}:${TAG_SECOND}
Note: docker --link feature is deprecated.
Another option is to use container management platforms which take care of service discovery for you automatically.
PS: You cannot ping an IP address on a different port. For more info, click here.
When I setup a network with docker create network test1 and then start a few containers, for example
docker run -d --net=test1 --name=t1 elasticsearch
docker run -d --net=test1 elasticsearch
docker run -d --net=test1 elasticsearch
I can't broadcast ping any of these containers with docker exec -ti t1 ping 255.255.255.255.
Any idea how I can change this?
This is currently followed in issue 17814
UDP broadcasts don't work in multi-host network between hosts.
UDP broadcasts only work if both containers run on the same host.
Playing with icmp broadcast by pinging on 255.255.255.255, I receive replies only from the local host:
# ping -b 255.255.255.255
WARNING: pinging broadcast address
PING 255.255.255.255 (255.255.255.255) 56(84) bytes of data.
64 bytes from 172.18.0.1: icmp_req=1 ttl=64 time=0.601 ms
64 bytes from 172.18.0.1: icmp_req=2 ttl=64 time=0.424 ms
64 bytes from 172.18.0.1: icmp_req=3 ttl=64 time=0.420 ms
64 bytes from 172.18.0.1: icmp_req=4 ttl=64 time=0.427 ms
(I made sure /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts is set to 0 on both hosts.)
It also seems impossible to set a broadcast address on the interface connected to the shared network:
# ifconfig eth0 broadcast 10.0.0.255
SIOCSIFBRDADDR: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
This ability to multicast in overlay driver is discussed in docker/libnetwork issue 552.
(help wanted)