本文介绍优化镜像构建策略的方法，帮忙您缩短镜像构建的时长，提升镜像推拉的效率。

使用 Docker 1.10 及以上版本

Docker 镜像由多个镜像中间层构建而成。Dockerfile 文件中的每一行指令都会构建一个镜像层。Docker 1.10 及以上版本中，您推送送镜像时，Docker 会默认尽可能多的，同时 推送多个镜像层至镜像仓库，有效提升镜像推送的速率。

精简基础镜像

精简镜像的容量可以有效减少镜像拉取的时长，提升镜像运行的效率。DockerHub 中存储的镜像文件可能包含应用不必要的依赖数据。您可以考虑使用社区中其他更小的镜像文件，或者基于 Docker 的最小架构，构建您自己最小可用的基础镜像。

镜像构建的说明参见 Docker 官网文档 Base images。

为基础镜像设置标签

引用基础镜像，但是不设置镜像标签（Tag）时，默认使用 latest （最新）版本的镜像文件。 随着时间的推移， latest 版本极大可能会发生变更，从而导致您在后续的推拉镜像时，整个镜像的重构，提升了镜像构建的时间成本。

• 优化前

  FROM nginx
  
  ADD . /app  
  RUN cd /app && booking install
  
  CMD booking start
  
  

• 优化后

  FROM nginx:1.1.0
  
  ADD . /app  
  RUN cd /app && booking install
  
  CMD booking start
  
  

后置高频变化的指令

为了尽可能的缩短重构镜像并上传镜像层所需的时间，可以将最稳定的依赖保存在 Dockerfile 中。将变更频率较高的依赖（例如您应用程序的原始代码）靠后存放。

Docker 会缓存镜像分层文件，以便加速镜像的构建。如果本次的构建的镜像相较上次没有变化，Docker 不会重构镜像，而是直接使用已缓存的镜像版本，有效节省了镜像构建的时间。但是，每个镜像层都依赖于前一个镜像层。如果前一个镜像层发生了变化，即使当前镜像层未发生变化，当前镜像层也会被重构。将变更频率较高的依赖靠后放置可以减少镜像重构的层数。

例如示例中 booking 模块的变更的频率比较 nodejs 高，那么执行 booking 的指令应该放置在后方。

• 优化前

  FROM nginx
  
  ADD . /app
  RUN cd /app && booking install  
  RUN apt-get update && apt-get install -y nodejs
  
  CMD booking start
  
  

• 优化后

  FROM nginx
  
  RUN apt-get update && apt-get install -y nodejs  
  ADD . /app
  RUN cd /app && booking install
  
  CMD booking start
  
  

使用合并的指令

通过合并的指令可以将不需要的中间产物文件有效的删除，精简镜像的容量。

上一行指令创建的文件，即使在后续的指令行中删除，依然会作为镜像的一部分，占据镜像文件的容量，只是在 Docker 容器中不可见。

• 优化前

  WORKDIR /tmp
  RUN wget http://booking.com/booking.tar.gz 
  RUN wget tar -xvf booking.tar.gz 
  RUN mv booking/binary /opt/bin/myapp
  RUN rm booking.tar.gz
  

• 优化后

  WORKDIR /tmp
  RUN wget http://booking.com/booking.tar.gz &&\
      wget tar -xvf booking.tar.gz &&\
      mv booking/binary /opt/bin/myapp &&\
      rm booking.tar.gz
  

选择最近的地域

选择距离您最近的火山引擎镜像仓库地域，可以有效的降低您从火山引擎镜像仓库推送或拉取镜像所需的时延。镜像仓库支持的地域查看 开服地域。

如果您有跨境推送、拉取镜像的需求，可以通过柔佛地域作为中转站，然后通过实例同步功能实现镜像的快速同步。详情步骤参见
跨境推送镜像至火山引擎镜像仓库。