记一次使用docker-compose部署应用的时候踩得坑

在部署gitea的时候,用的是docker-compose起的应用，然后起完应用之后，突然发现ssh没有响应了，由于是用堡垒机上的生产机器，所以第一反应是堡垒机无法访问主机了，在外部的网络策略上研究了半天毫无进展，直到突然发现可以用安全组内的其他机器访问这台机器，那么事情就开始变得微妙了起来，于是发现了在docker-compose起来的时候，给服务分配了一个172.19.0.0的网卡，导致堡垒机能正常的访问主机，但是主机上的报文在返回的时候，由于返回给了docker的网卡，所以出的问题。

后来仔细去看了一下docker-compose的文档，发现docker-compose默认会给每个应用从172.18.0.0依次往后匹配网段，只要容器没有被删除则一直占用网络，如果删除后重启则依次采用新的网段之前的不再使用，因此很容易造成路由冲突

解决方案：

  1. 可以在单个docker-compose.yml文件中增加networks配置，设置网段为168.168.0.0/16，如下

    networks:
  default:
    name: milvus
    ipam: 
      driver: default
      config:
        - subnet: 168.168.0.0/16

  2. 或者修改全局docker网络配置，docker自动分配的网段使用168.168.0.0/16，每个子网掩码划分为 255.255.255.0

    {
      "default-address-pools":[
  			{
                "base": "168.168.0.0/16",
                "size": 24
  			}
      ]
}

    注意：daemon.json 修改完了之后记得要重启docker服务哈~