构建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.
先上图。

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

构建Docker镜像两种方式的比较-Dockerfile方式和S2I方式_第1张图片

由上图可以看出,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)构建镜像的描述

你可能感兴趣的:(构建Docker镜像两种方式的比较-Dockerfile方式和S2I方式)