我们优化创建Docker Image的经验以及我们从中学到的东西

上下文

我们的大多数微服务都是基于Python的容器，它们是由持续集成过程创建的。该过程描述如下：

容器生成和容器提升过程

正如您在流程中看到的，只要开发人员提出一个pull请求，集成流程就会启动。在创建镜像时，将对图像运行UT和功能测试。如果他们通过了，PR将提供给同行评审。如果同级审阅者提供了任何注释，那么开发人员将着手解决可能导致新提交的注释，如果出现了这种情况，则会重复该循环。否则，审查员还不如批准pull请求。批准后，提交被标记，再次创建映像，并将生成的映像发布到容器注册中心。

经过仔细分析，优化创建Docker Image实际上有助于我们优化整个过程。因此，我们开始了改进容器构建过程的旅程。

注意：我可以互换使用容器和镜像。我仍然习惯了这些条款

Docker镜像创建过程

让我们了解Docker镜像的创建过程。

首先，我们将看到一个Dockerfile。Docker文件示例如下所示：

#This is a example Dockerfile 
FROM ubuntu 
MAINTAINER myself@somedomain.com 

RUN apt-get update && \
    apt-get -y upgrade
CMD [“echo”,”Image created”]

在上面的Dockerfile中，第一行告诉我们应该从基本镜像创建这个镜像：docker.io/library/ubuntu:latest。

下一行添加有关谁维护由于运行docker构建过程而创建的镜像的元数据。

以下行更新容器中的包。

并且最后一行向容器添加另一个元数据，Image created一旦容器启动就回显命令。

以下是docker镜像创建过程的高级表示。

Docker镜像创建过程

当镜像创建过程开始时，docker守护程序所做的第一件事就是检查Dockerfile中指定的基本映像是否在本地计算机中。如果它不在那里，那么它从注册表中提取镜像。然后它移动到docker文件中的下一行。它读取下一行并验证构建缓存中是否存在已在Dockerfile中提及此更改的镜像。如果它有镜像，它将移动到下一行，并重复该过程，直到它遇到Dockerfile中有一条没有缓存镜像的更改的行。“ 绿色”部分描述了相同的过程。

此时或者在没有缓存中间图像的情况下，Docker守护程序创建一个容器，应用行中提到的更改，从中创建一个镜像，然后移动到下一行并重复相同的过程，直到它到达Dockerfile的结尾。这已在“ 桃色 ”盒子中描绘。

（请注意：这是Docker Image创建过程的一个非常简化的版本，我故意省略了很多细节，让我们关注）

想法

随着我们更多地了解Docker构建过程，我们开始意识到如果我们能够以某种方式最小化构建过程进入“ 桃子 ”部分的次数并最大化它进入“ 绿色 ”部分的次数在构建流程工作流程中，我们可以更快地完成镜像创建过程。

以此为出发点，我们开始分析我们的Dockerfiles。在我们的大多数情况下，Dockerfiles包含以下内容：

1. Base Image
2. Shell Scripts (Entrypoint files)
3. Dependencies (Third Party Libraries)
4. Actual Code/Artifacts related to the Microservice
5. Metadata Information(Maintainer, Ports, etc)

在分析这些内容时，我们意识到这些可归类如下：

我们的Dockerfile组件的分类

这是一个启示。我们现在需要做的就是将Dockerfiles重新组织成以下结构：

Dockerfiles的理想结构

这就是我们所做的！

结果

结果如下：

优化的Dockerfile需要45秒才能生成图像

由于更好地理解了Docker构建过程，这一小改变导致了相当大的优化。

这有什么影响？

• 优化的镜像创建
• 优化的构建机器存储，因为Docker使用了缓存的镜像
• 由于Docker仅提取非缓存层，因此整体部署镜像的速度更快
• 由于Docker层，再次相对更快地上传到注册表

翻译自:https://medium.com/better-programming/optimizing-docker-image-creation-fa06bb42733d