构建镜像的过程里有一段时间是要联网的:拉取基础镜像、下载依赖包、更新系统组件。这一步在国内的机器上经常慢,或者干脆拉不下来。有人会在构建阶段也接上代理IP,把这一段的网络问题解决掉。要不要这么做,取决于构建环境和依赖来源。
构建阶段为什么也要管网络
构建镜像时会按顺序执行若干条指令,其中一部分需要访问外部资源。这些访问发生在构建环境里,和运行环境是两回事。构建慢或者失败,多半出在这一步的网络,和后续运行时的配置关系不大。把构建阶段的网络先理顺,构建速度会稳定很多。
- 拉取基础镜像是第一步,网络不通后面都做不了
- 安装依赖包时访问的源如果远,耗时会拉长
- 更新系统组件会一次性下载多条记录
- 这些访问都发生在构建环境里,配置也要落在这一层
哪些情况下值得接
构建机器在境内、依赖源在境外,接入代理IP能明显缩短构建时间。构建经常因为超时中断,也是值得接的信号。如果依赖全部来自本地镜像仓库,或者构建机器本身网络通畅,接和不接的差别不大。
| 情况 | 接的做法 | 看得见的差别 |
|---|---|---|
| 依赖源在境外 | 构建阶段接入代理IP | 拉取耗时明显缩短 |
| 依赖源在本地仓库 | 可以不接 | 几乎没有差别 |
| 构建常因超时中断 | 接入并适当延长超时 | 中断次数下降 |
| 构建环境受限 | 改用本地镜像缓存 | 依赖缓存后不再联网 |
配在哪里
设置写在构建脚本的前面,让后续每一条联网指令都跟着走。也可以用构建时传入的参数,避免把配置长期写死在脚本里。参数方式更灵活,同一份脚本在不同环境里可以走不同的线路。
构建完要清掉什么
构建阶段用过的设置如果被写进了镜像,会跟着镜像发布出去。这种残留可能在运行阶段造成麻烦,也会让配置难以追踪。把设置放在构建参数里、或者构建结束时显式清除,能避免这个问题。
构建阶段的网络配置,最好不要留进最终镜像。
构建阶段和运行阶段要分开看。
判断要不要在构建阶段接代理IP,看的是依赖从哪里来、构建环境通不通。接上之后记得把设置和镜像本身隔开,别让它跟着发布出去。代理IP解决的问题是某一类可达性,构建阶段解决了,运行阶段可能还需要另配一份。两个阶段各管各的网络。
