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

原文地址：http://www.javashuo.com/article/p-ekxhfmnt-gy.html

前言

写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；
• 拷贝/移动文件/目录；
• 定义用户；
• 暴露端口等。

1. 源代码相关

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

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

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

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

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

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

这样的分离带来了以下好处:

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