todo docker主机无法访问容器映射的端口：Connection reset by peer

自己好像碰到过这个问题，但一直没有解决，先记录一下这个解决方案，待以后验证

主机无法访问容器映射的端口：Connection reset by peer

今天碰到一个坑，很低级，先记在这里吧。

背景是这样的

我启动一个etcd容器，里面发布了一个服务监听在端口2379，然后我把端口映射到主机了。

version: '2'
networks:
  byfn:

services:
  etcd1:
    image: quay.io/coreos/etcd
    container_name: etcd1
    command: etcd -name etcd1 -listen-peer-urls http://0.0.0.0:2380 -initial-cluster-token etcd-cluster \
                  -initial-cluster "etcd1=http://etcd1:2380" -initial-cluster-state new
    ports:
      - 2379
      - 2380
    networks:
      - byfn

然后通过docker ps也能看到端口的映射：

$ docker ps
CONTAINER ID        IMAGE                 COMMAND                  CREATED             STATUS              PORTS                                              NAMES
60877d965c67        quay.io/coreos/etcd   "etcd -name etcd1 ..."   15 minutes ago      Up 15 minutes       0.0.0.0:32769->2379/tcp, 0.0.0.0:32768->2380/tcp   etcd1

容器内的端口2379被映射到了主机的端口32769。

这个问题是什么

如果我从主机上访问端口32769，会失败：

$ curl -L http://localhost:32769/v2/members
curl: (56) Recv failure: Connection reset by peer

然后我从容器内访问端口2377，是成功的：

$ docker exec -t etcd1 curl -L http://localhost:2379/v2/members
{"members":[{"id":"ade526d28b1f92f7","name":"etcd1","peerURLs":["http://etcd1:2380"],"clientURLs":["http://127.0.0.1:2379"]}]}

这个怎么回事呢

一开始我只关注了端口的映射，好像都是正常的，而且容器内也是可以访问的，说明容器内端口是在运行的呢。

原因是什么

其实端口并没有在监听，我们进到容器内部，执行netstat命令看到：

$ docker exec -t etcd1 netstat -an | grep LISTEN | grep 2379
tcp        0      0 127.0.0.1:2379          0.0.0.0:*               LISTEN      

这就明白了，端口2379只监听在127.0.0.1这个地址上，这个地址是没有映射到主机的，我们需要让容器内把端口2379也映射到eth0这个地址上，就能访问了。

解决办法

在docker-compose.yaml修改etcd的监听地址到0.0.0.0，而不是缺省的127.0.0.1

command: etcd -name etcd1 -advertise-client-urls http://0.0.0.0:2379 -listen-client-urls http://0.0.0.0:2379 \
                          -listen-peer-urls http://0.0.0.0:2380 -initial-cluster-token etcd-cluster \
                          -initial-cluster "etcd1=http://etcd1:2380" -initial-cluster-state new

再验证监听端口：

$ docker exec -t etcd1 netstat -an | grep LISTEN | grep 2379
tcp        0      0 :::2379                 :::*                    LISTEN      

在去访问主机端口：

$ curl -L http://localhost:32769/v2/members | python -m json.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   347  100   347    0     0   9735      0 --:--:-- --:--:-- --:--:--  9914
{
    "members": [
        {
            "clientURLs": [
                "http://0.0.0.0:2379"
            ],
            "id": "ade526d28b1f92f7",
            "name": "etcd1",
            "peerURLs": [
                "http://etcd1:2380"
            ]
        }
    ]
}

docker容器与宿主机不互通

我用的是docker部署的crawlab，需要部署的还有redis和mongo，部署完成之后发现，容器之间是互通的，每个容器和宿主机之间都不通。

解决方法就是docker0换个网段，

# 删除原有配置
service docker stop  
ip link set dev docker0 down  
brctl delbr docker0  
iptables -t nat -F POSTROUTING 

# 创建新的网桥
brctl addbr docker0  
ip addr add 172.17.10.1/24 dev docker0  
ip link set dev docker0 up   

# 修改docker配置，在/etc/docker/daemon.json中追加bip如下，
# 注意json的格式，bip前面需要有,root@XXXXXX~# cat /etc/docker/daemon.json  
vim /etc/docker/daemon.json
{
  "insecure-registries":["x.x.x"],
  "bip": "172.17.10.1/24"
}  


# 重启docker
systemctl  restart  docker

我经过上面的步骤换个网段之后就好了，具体的原因可能是

之前你ping不通是因为你把veth-par中的一个设置到docker0时并不会改变docker0原来的mac，此时mac地址不一致，导致你ping不通。然后我做了一件事，我把这种情况下docker0的mac改成与加入的veth一致，然后就能ping通了…

存储驱动VFS

在使用docker部署的时候，报存储空间不足（虽然很鸡肋，但是确实发生了），然后就找大文件，就找到了/var/lib/docker/vfs/dir/，好像是将近20个G，里面存放着docker的镜像，把这些都干掉，就相当于把镜像删除了。如果你的镜像压缩包在的话，大不了再重新启动容器就是了。

转载自：
https://www.jianshu.com/p/964b268e1fc8
https://blog.csdn.net/qq_35641923/article/details/121549499