1. DNS 请求超时 原因: alpine 使用的是 musl 库，在 DNS 解析上会有一些限制[1] 解决方式： 不使用 apline 镜像，并在容器 resolv.conf 文件中增加 options single-request-reopen 配置。因为 single-request-reopen 配置项只对 glibc 库生效，但是 apline 镜像使用的是 musl 库 2. Docker 下无法解析 hosts 原因: alpine 没有 /etc/nsswitch.conf，导致依赖 hosts

1. 遇到的问题 项目介绍: 文件大小 5.6 GB 文件数量 529352 Dockerfile 1 2 3 FROM golang:1.13 COPY ./ /go/src/code 构建命令及输入如下: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 time DOCKER_BUILDKIT=1 docker build --no-cache -t test:v3 -f Dockerfile . --progress=plain #1 [internal] load build definition from Dockerfile #1 sha256:2a154d4ad813d1ef3355d055345ad0e7c5e14923755cea703d980ecc1c576ce7 #1 transferring dockerfile: 37B done #1 DONE 0.1s #2 [internal] load .dockerignore #2 sha256:9598c0ddacf682f2cac2be6caedf6786888ec68f009c197523f8b1c2b5257b34 #2 transferring context: 2B

1，接上一回，共享存储优化海外镜像的拉取 在基于 Harbor 和 Registry 的镜像管理分发方案的基础上，最近又做了一个优化。 之前的方案是，在每个区域，使用一台低配大磁盘的机器，部署一个 Mirror Cache 缓存镜像。这样带来一个问题，就是每个区域都需要拉取一个镜像，如果有 N 个区域，

1. Harbor 跨区带来的挑战 如果只是简单的存放镜像数据， Registry 作为镜像仓库会是一个很好的选择。Registry 不仅支持多种存储后端，还可以配置 HTTPS 证书，访问凭证。值得一题的是，Harbor 也是使用 Registry 存储镜像数据。 如果团队需要进行角色管理，存储控制，对接 LDAP 认

1. 全球的网络规划 很多面向全球的多区域基础设施，在设计之初并没有在网络规划上花费太多心思。当业务复杂到一定程度时，又被逼着进行网络调整和优化。而任何网络上的大调整，都将对业务产生巨大影响。最终会陷入进退两难之地，只能投入更多人力，背上历史包袱