本文接续前文《wydevops——微服务直上K8S云就是这么简单(续2)》, 继续介绍wydevops的docker镜像的构建类型、作用、配置以及结果验证。

       1. wydevops的Docker镜像构建类型介绍

       wydevops支持以下几种构建方式：

•  single——为一个微服务生成一个docker镜像。
• double——为一个微服务生成两个docker镜像。一个是应用基础镜像，一个是应用业务镜像。
• base——仅生成应用基础镜像
• business——仅生成应用业务镜像
• thirdParty——第三方镜像打包，仅完成从公网拉取目标镜像，保存到本地镜像缓存目录、推送到镜像私库中等后续过程，确保可在离线状态下仍能使用这些镜像。
• customize——自定义打包，指定docker镜像打包目录，wydevops完成镜像构建、推送到私库等后续过程。这个模式为用户提供了完全自定义docker镜像的能力。

      在本地工作模式下，docker构建类型参数是配置在wydevops-run.sh脚本中的，如下下图红框处：  

2.  wydevops构建docker镜像的原理简介

       wydevops依赖内置的Dockerfile、Dockerfile_base、Dockerfile_business这三个模板文件来完成Docker镜像的构建。 

Dockerfile——single构建类型下使用的模板文件

Dockerfile_base——double或base构建类型下使用的模板文件

Dockerfile_business——double或business架构类型下使用的模板文件

       为了向项目开发人员提供Dockerfile扩展能力，wydevops会优先使用项目（例如：java-sample）中wydevops/templates/docker目录下配置的与当前设置的构建类型匹配的Dockerfile文件；如果不存在才会使用wydevops源码中script/templates/docker/{语言类型}/目录下的匹配的Dockerfile模板文件，如下图。

       wydocker的docker阶段的主流程会从这个模板文件中提取出所有的模板变量，然后从ci-cd.yaml文件（前文已有说明，是具体的某个项目的全参数配置文件）中读取这些模板变量的值并替换之，最终生成Docker镜像构建需要的Dockerfile文件（存储位置:具体项目的wydevops/docker-build目录下），其内容如下图：

        Dockerfile模板文件的模板变量（占位符），格式规则：头尾都是下划线"_"，中间是大写字母、数字或中杠"-"构成。内置的模板变量有以下几个：

_PLATFORM_ : docker镜像的目标架构占位符。

_FROM-IMAGE0_ ：docker镜像的基础镜像占位符。wydevops会自动识别并初始化_FROM-IMAGE1_、_FROM-IMAGE2_ ...等这类占位符。

_TZ_ ：docker镜像内部时区占位符。

_ARCH_ ：用来标记不同架构的文件存储路径，后面有具体应用的例子。

_WORK-DIR-IN-CONTAINER_ ：docker镜像内部服务的工作根路径。

_EXPOSE_ ：docker镜像需要开放的端口占位符，多个端口间使用空格分隔。

_APP-DIR-IN-CONTAINER_ ：用于双镜像构建模式下的应用基础镜像（Dockerfile_base）和应用业务镜像模板文件中（Dockerfile_business），用来指定业务程序在容器内的存放位置，后续会讲解到。

       这些模板变量对应的配置参数在_ci-cd-template.yaml文件的docker配置节中。如下图：

      上图中，${...} 类型的变量引用的是同一文件中globalParams配置节下同名（...）参数的值。

       源码中对这些模板变量赋值的代码如下:

上图中的_setFromImage方法，其内对_FROM-IMAGE[0-9]+_格式的参数进行了赋值，内容截图如下：

       另外，我们在实际项目中准备docker构建目录时，常常需要把某些文件或目录复制到该目录中，并在Dockerfile文件中写有复制到容器中语句。这些文件如果有更新就需要手动复制到docker构建目录中，或者这些文件是可执行的工具，此时还需要针对当前构建的架构类型的不同替换这些文件，这类重复性的或易出错的工作wydevops为你提供了两个参数来完成这类任务：copyDirs和copyFiles。copyFiles参数关注的是没有架构差异的文件集合；copyDirs更进一步可提供架构敏感的文件的复制功能。看看如下图的例子：

        通过对_ARCH_模板变量的使用，wydevops可以很轻松的帮你在镜像构建前准备好架构匹配的文件。处理copyFiles参数的方法名称为：_copyFilesIntoDockerBuildDir，处理copyDirs参数的方法名称为：_copyDirsIntoDockerBuildDir，感兴趣的朋友可自行去源码中查看。

        如果内置模板不能满足的项目需求，则可以在项目的wydevops/templates/docker目录下自定义Dockerfile模板文件，上图例子就是一个自定义的模板文件。wydevops会优先使用项目配置的同名模板文件。

        如果你对这部分源码掌握的很好，你也可以自由实现各种模板。

3. 本地第三方镜像缓存机制简介

        wydevops还有一个设计目标，即支持脱网环境下的微服务开发。这在军工行业很常见，在客户现场是无法连接外围的，也没有私库给你用。这种场景下wydevops为你提供了本地第三方镜像缓存机制，只要你在本地构建中使用了第三方镜像（默认只缓存从公网拉取的，私库拉取的不会缓存），则wydevops会在指定的目录中保存这些第三方镜像的导出文件，并且在拉取镜像时会优先查询本地镜像缓存目录中是否存在目标镜像，如果存在则直接使用docker load命令加载到本地docker环境中。thirdParty构建类型就是专门为这个目的实现的。这个缓存机制在Jenkins工作模式下默认是关闭的。这个参数配置在项目的wydevops-run.sh文件中，见下图红框位置：

此例中，本地镜像缓存目录是d盘上的cacheImage目录。该目录内容截图如下：

4. single构建类型

        这是最常用的，最容易配置和理解的构建类型。在此之前例子中使用的都是single构建类型。这种构建类型仅生成一个业务功能完整的Docker镜像。wydevops默认是按double构建类型进行设计的，在_ci-cd-template.yaml文件docker配置节下面没有专门用于single类型配置节（只有base和business），而是与base构建类型共用base配置节。因此选择single构建类型时，在docker阶段初始化过程中对base配置节进行了调整，使其适配single构建类型。

        一旦构建完毕，我们打开项目（java-sample）wydevops目录，如下图：

       红框标记出了single构建类型唯一生成的Docker镜像的导出文件，以及执行docker build时使用的文件名称是Dockerfile（即single构建类型对应的模板文件名：Dockerfile）。

        single构建类型就介绍到这里

5. double构建类型

        single构建类型将整个微服务构建成了一个Docker镜像。这个镜像一般都比较大，以Java-sample为例，其导出文件的大小约为：327M。如此简单的一个微服务就有这么大！可以想象一下,场景1：

我们给客户部署一个包含50个微服务的系统，每个微服务Docker镜像导出文件平均为500M，这样我们就需要复制25G的安装文件到客户现场去安装。

首先从私库下载这些镜像并导出成文件

接着将这25G复制到USB盘中（慢）

在客户现场将25个G的数据复制到服务器上（慢）

再再服务器上逐一安装所有的微服务（慢）

...

过段时间，有10个微服务升级了，我们又需要复制5G的数据（忽略chart镜像文件的大小）...

场景2：

我们给客户部署一个包含50个微服务的系统，每个微服务都采用double方式构建的Docker镜像，其中base镜像平均大小为450M，business镜像平均大小为：50M。这样我们同样需要复制25G的数据到客户现场去安装，但是流程却有差异。

首先，准备base镜像U盘，这个U盘里有22.5G数据，这个U盘是可以预先准备好的。

接着，从私库下载所有服务的business镜像到USB盘中，只有2.5G数据。

在客户现场上传base镜像和business镜像，总计25G数据。

...

过段时间，有10个微服务升级了，我们仅需要更新business镜像，也即500M数据（同样忽略chart镜像文件的大小）。

从上述两个场景的对比可以看出，将微服务按double构建类型进行生成，具备非常明显的优势。

wydevops以double为默认构建类型，并为其提供了与之匹配的完整的Chart镜像生成能力。

仍以java-sample为例，打开项目中wydevops-run.sh文件，将-B参数的值修改为dobule,并保存。

如下图：

然后打开项目中pom.xml文件，修改服务版本为1.0.1，如下图：

最后在wydevops-run.sh文件所在目录打开git bash命令行，执行：bash wydevops-run.sh

特别说明：执行前请先删除ci-cd.yaml文件。

成功执行完毕后，我们打开浏览器访问http://localhost/wydevops/v1/sample/hello，返回如下内容：

说明微服务已经发布成功。

        现在打开项目中wydevops/build-out目录，截图如下：

        上图1处，我们看到出现了两个新文件，名称中包含-base-串的是应用基础镜像，名称中包含-business-串的是应用业务镜像。上图2处，我们可以看到最后使用的Dockerfile文件名称是Dockerfile-business。wydevops先构建的是应用基础镜像，然后才构建应用业务镜像，因此Dockerfile-base此时已经被删除了。

        接下来，我们在资源管理器中看看他们的大小，截图如下：

其中应用基础镜像的导出文件约306M，而应用业务镜像仅约22M。当前wydevops内置的Java语言的Dockerfile_base文件（在script/templates/docker/java目录中）时按语言级通用模板定义的，其内容如下：

从中可以看到，该镜像中没有包含具体项目相关任何代码，这样的应用基础镜像是某个语言的通用应用基础镜像的Dockfile模板文件，wydevops默认推荐语言级通用Dockerfile_base模板文件作为应用基础镜像模板文件。显而易见，项目相关程序代码都在应用业务镜像中，我们看看在script/templates/docker/java目录中的Docker_business文件内容：

内容非常简单，就是指定在构建时将四个目录中的文件拷贝到_APP-DIR-IN_-CONTAINER_目录中，运行时将该目录下文件复制到_WORK-DIR-IN-CONTAINER_ 目录中。

        (更进一步，如果将上述四个目录中的前两个打包到base镜像中，则business镜像还会更小，约1-3M，这样的base镜像我们称为项目级应用基础镜像)

特别说明一下：Java语言springboot SDK提供了一个spring-boot-jarmode-layertools-2.7.8.jar文件, 调用方式：java -Djarmode=layertools -jar "{jar文件名称}" extract。通过这条命令可将jar包中的文件按上述截图中四个目录进行归类存储。前两个是服务依赖的第三方库和springboot自己的相关Jar文件（这两个一般不会改动，但可能会引入新的第三方包导致需要更新项目级应用基础镜像）；第三个目录是自己开发的snapshot版本的公共Jar包，这个可能会面临时常修改，不应放入应用基础镜像；最后一个目录中存放的就是应用本身的代码了，这个是不能放入基础镜像的，改的就是它。

        最后我们来看看，K8S中实际运行的服务中这两个镜像的情况。

在ubuntu on windows命令窗口中执行：kubectl get deployment java-sample -n develop

在输出中可以看到如下内容：

        可以看到这两个镜像被放置到了一个Pod中。

最后综述一下：

• 如果运行时，构建类型为dobule,并且架构类型两种都设置了，则会生成4个镜像，每种架构两个镜像。
• 上述例子中生成的应用基础镜像就是Java语言级的通用应用基础镜像。
• base构建类型不常用，只在重新构建应用基础镜像时才会用到。
• business构建类型用于为double构建类型发布的微服务打包业务功能升级安装包。
• thirdParty构建类型，主要用来为本地镜像缓存目录添加新的第三方镜像缓存。
• customize构建类型，用于自定义docker镜像打包。

今天就写到这里了，下一篇打算写一下业务参数配置相关问题。

原创不易，需要你的关注和收藏！