我有一个简单的python应用程序,它在Elasticsearch实例中存储和搜索它的数据。就像Elasticsearch一样,python应用程序在其自己的容器中运行。Elasticsearch公开其默认端口9200和9300,而python应用程序公开其默认端口5000。Docker使用的networktype是用户定义的桥接网络。当我同时启动两个容器时,应用程序可以很好地启动,两个容器可以通过容器名称相互查看,并且可以正常通信。
但是无法从Docker主机(Linux)连接到公开的端口5000。因此,一个简单的curl http://localhost:5000/
渲染会超时。该文档中的Docker技巧:https : //docs.docker.com/network/bridge/未能解决此问题。
经过很多努力后,我尝试了完全不同的尝试,然后尝试从docker主机外部连接到python应用程序。我无所适从,在世界上任何地方都能做得到,curl http://<fqdn>:5000/
并得到了该应用程序的服务。这样一来,真正的问题就解决了,因为我能够将应用程序服务于外部世界。(因此,是的,容器内的应用程序侦听0.0.0.0,这是其他人报告的90%网络问题的解决方案。)
但这仍然让我感到困惑,是什么导致这种奇怪的行为?在我的开发机器(Windows 10,WSL,Docker桌面,Linux容器)上,我能够连接到本地主机上的服务:5000、127.0.0.1:5000等。在我的Linux(生产)机器上,除了从docker连接外,其他所有东西都可以正常工作托管到容器。
我希望有人可以阐明这一点,我想理解为什么会这样。
一些相关信息
Docker主机:
# ifconfig -a
br-77127ce4b631: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.18.0.1 netmask 255.255.0.0 broadcast 172.18.255.255
[snip]
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
[snip]
ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 1xx.1xx.199.134 netmask 255.255.255.0 broadcast 1xx.1xx.199.255
# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1e7f2f7a271b pplbase_api "flask run --host=0.…" 20 hours ago Up 19 hours 0.0.0.0:5000->5000/tcp pplbase_api_1
fdfa10b1ce99 elasticsearch:7.5.1 "/usr/local/bin/dock…" 21 hours ago Up 19 hours 0.0.0.0:9200->9200/tcp, 0.0.0.0:9300->9300/tcp pplbase_elastic_1
# docker network ls
NETWORK ID NAME DRIVER SCOPE
[snip]
77127ce4b631 pplbase_pplbase bridge local
# iptables -L -n
[snip]
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:5000
Chain FORWARD (policy ACCEPT)
target prot opt source destination
DOCKER-USER all -- 0.0.0.0/0 0.0.0.0/0
DOCKER-ISOLATION-STAGE-1 all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
DOCKER all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
DOCKER all -- 0.0.0.0/0 0.0.0.0/0
Chain DOCKER (2 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 172.18.0.2 tcp dpt:9300
ACCEPT tcp -- 0.0.0.0/0 172.18.0.2 tcp dpt:9200
ACCEPT tcp -- 0.0.0.0/0 172.18.0.3 tcp dpt:5000
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- 0.0.0.0/0 0.0.0.0/0
DOCKER-ISOLATION-STAGE-2 all -- 0.0.0.0/0 0.0.0.0/0
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target prot opt source destination
DROP all -- 0.0.0.0/0 0.0.0.0/0
DROP all -- 0.0.0.0/0 0.0.0.0/0
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Docker撰写文件:
version: '3'
services:
api:
build: .
links:
- elastic
ports:
- "5000:5000"
networks:
- pplbase
environment:
- ELASTIC_HOSTS=elastic localhost
- FLASK_APP=app.py
- FLASK_ENV=development
- FLASK_DEBUG=0
tty: true
elastic:
image: "elasticsearch:7.5.1"
ports:
- "9200:9200"
- "9300:9300"
networks:
- pplbase
environment:
- discovery.type=single-node
volumes:
- ${PPLBASE_STORE}:/usr/share/elasticsearch/data
networks:
pplbase:
driver: bridge
经过更多的挖掘,谜题变得越来越大。使用netcat时,我可以建立连接
Connection to 127.0.0.1 5000 port [tcp/*] succeeded!
没有客户端连接时,请使用netstat进行检查:
tcp6 0 0 :::5000 :::* LISTEN 27824/docker-proxy
尝试从dockerhost连接时,建立了连接:
tcp 0 1 172.20.0.1:56866 172.20.0.3:5000 SYN_SENT 27824/docker-proxy
tcp6 0 0 :::5000 :::* LISTEN 27824/docker-proxy
tcp6 0 0 ::1:58900 ::1:5000 ESTABLISHED 31642/links
tcp6 592 0 ::1:5000 ::1:58900 ESTABLISHED 27824/docker-proxy
所以我现在怀疑docker主机上有一些networkvoodoo。
因此,当我在解决这个问题时,慢慢地找到一个解决方案,我发现我的最后建议毕竟是正确的。在防火墙(iptables)中,我记录了所有丢弃的数据包,是的,iptables丢弃了docker-bridge(不是docker0,但br-和容器(veth)之间的数据包。添加一条规则,允许来自接口的流量流解决了问题。
就我而言:sudo iptables -I INPUT 3 -s 172.20.0.3 -d 172.20.0.1 -j ACCEPT
172.20.0.0/32是Docker生成的桥接网络。