构建Docker镜像两种方式的比较－Dockerfile方式和S2I方式

前言

写Dockerfile是构建Docker镜像最通常的方式，接触过Docker的童鞋多少了解一些。前段时间研究OpenShift(paas的一种)，发现了另外一种构建Docker镜像的方式：S2I。

S2I介绍

S2I是Source-to-Image的缩写。

S2I是一套工具包和工作流程，用于从源代码构建重复性Docker镜像。

S2I是一个框架，它使写镜像变得简单。它把程序源代码作为输入，生成一个运行已组装应用程序的新镜像并作为输出。

S2I的详细介绍以及使用方法可以参考以下官方文档。本文就不复述(fan yi)了。

• Source-To-Image (S2I)
• S2I Requirements
• How to Create an S2I Builder Image

两种构建方式的过程

Talk is Cheap, Show me the Picture.
先上图。

源代码只是构建镜像的多种输入的一种，还有二进制文件等其它输入。镜像构建的过程也比较复杂。下图是为了清晰地进行对比，所以画得简单一些。

由上图可以看出，Dockerfile方式的构建过程比较直接：

• 根据Dockerfile定义的步骤，读取源代码，生成镜像(成品)。

而S2I方式的构建过程比较“曲折”：

• 根据Dockerfile定义的步骤，准备镜像环境、读取S2I脚本，构建镜像(中间)<又称构建器镜像 Builder Image>。
• 基于上一步生成的镜像(中间)，读取源代码，根据S2I脚本定义的步骤编译源代码、部署二进制程序、预备服务启动，构建镜像(成品)。

从上述过程可以看出，S2I方式比Dockerfile方式多了一步，多了两样东西：S2I脚本和镜像(中间)。

S2I脚本介绍

S2I脚本有4种。

• assemble: 负责构建程序，即编译、部署程序。
• run: 负责启动应用。
• save-artifacts: 负责增量构建(镜像)，目前尚未使用。
• usage: 负责打印构建器镜像的使用说明。

S2I方式的好处

关于引入S2I构建镜像的好处，书面类的描述可以参考官方文档，这里谈谈实践下来个人的感受和理解。

首先，要了解为什么要引入S2I。

如果一定要把构建镜像分为两部分，可以分为

1. 环境准备

   • 定义基础镜像；
   • 安装所需部件，如Maven、Java JDK；
   • 拷贝/移动文件/目录；
   • 定义用户；
   • 暴露端口等。

2. 源代码相关

   • 编译源代码；
   • 部署二进制程序；
   • 定义服务启动方式等。

引入S2I的目的就是为了分离这两部分的工作。

其中环境准备工作交给了构建器镜像，

构建器镜像一旦生成将保持不变，可理解为静态部分。

而源代码相关工作交给了S2I脚本。

在构建镜像(成品)过程中，S2I将根据S2I脚本定义的步骤进行源代码编译、二进制程序部署、服务启动预备，可以理解为动态部分。

这样的分离带来了如下好处。

1. 对于环境依赖相近、构建部署启动过程相似的程序，由于有构建器镜像的存在，构建过程不需要再次进行环境准备工作，从而节省了构建镜像(成品)的时间。
2. 分工明确。构建工作的分离允许应用程序开发人员对他们的代码进行更改，而不用知道Dockerfile或Docker镜像的细节。如果镜像构建交付给S2I或PaaS(platform as a service)平台，开发工程师不需要理解Docker来对项目作出贡献。这在一个由很多人组成的企业环境中是非常有用的，这些人都有不同的专业方向，而且并不直接涉及到他们项目的构建过程。

(注) 上述好处2引用了文章:使用Source-to-image（S2I）构建镜像的描述