TAP 中的云原生构建服务

题图摄于美国大峡谷

本篇转发TAP系列文章之五，TAP云原生构建服务。

1

  背景  

通常的应用开发过程，是由开发人员使用某种计算机语言，比如 Java，开发特定项目然后提交到代码仓库。紧接着，源代码会被编译成二进制代码，被放置于特定的环境中运行，比如 Java 运行时或者 Web Server 等。随着容器以及容器编排技术的发展和成熟，越来越多的应用将从传统的虚拟机部署方式改为容器部署模式。

这就增加了一个关键的步骤：把应用打包成容器镜像，也称为应用容器化。

那么这个步骤还是由开发人员完成吗？开发人员的内心 os：我难道不应该专注于写业务逻辑吗？这个打包也要由我来完成？好吧，但是打包写 Dockerfile 我没有经验啊！要怎么避开里面的陷阱呢？以后源代码或者基础镜像更新了，还要由我来维护吗？

带着这些疑问，我们来仔细看看应用容器化的具体过程是怎么样的吧。

1

  从源代码到容器镜像  

当开发人员完成了一个应用项目并提交代码库之后，为了让代码能在容器环境中运行，需要把源代码转换成符合 OCI 标准的容器镜像，这个过程称为构建（build）。构建过程通常分为两个子步骤，第一步是将源代码编译成二进制文件，第二步是加上基础操作系统和相关依赖（比如 Java 运行时）合并成标准容器镜像。

第一步的编译取决于应用项目所采用的语言和框架，第二步常规的方法则是以撰写 Dockerfile 以及使用 docker build 来完成的。以使用 Spring 框架开发的项目为例，我们可以看到常规的构建过程是这样的：

·  首先，将源代码下载到本地，使用 Maven 命令对 Spring 项目进行 Java 编译：

% mvn -Dmaven.test.skip=true package
       
[INFO] Scanning for projects...
[INFO] 
[INFO] --------------------< io.buildpacks.example:sample >--------------------
[INFO] Building sample 0.0.1-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
。。。
[INFO] 
[INFO] --- maven-jar-plugin:3.1.2:jar (default-jar) @ sample ---
[INFO] Building jar: /Users/mingjiex/git/samples/apps/java-maven/target/sample-0.0.1-SNAPSHOT.jar
[INFO] 
[INFO] --- spring-boot-maven-plugin:2.1.18.RELEASE:repackage (repackage) @ sample ---
[INFO] Replacing main artifact with repackaged archive
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  1.671 s
[INFO] ------------------------------------------------------------------------

在编译过程中会自动下载大量的 Java 依赖包，如果没有编译错误，那么最终会在 target 目录下生成一个二进制可执行的 sample-0.0.1-SNAPSHOT.jar 包。

·  然后，撰写 Dockerfile 文件，声明构建的步骤和参数，样本文件如下：

FROM openjdk:8-jre
              
ADD ./target/sample-0.0.1-SNAPSHOT.jar /
               
ENTRYPOINT ["java"]               
CMD ["-jar", "/sample-0.0.1-SNAPSHOT.jar"]
               
EXPOSE 8080

其中 FROM 语句是引用的基础镜像名称，该镜像包含了底层的操作系统和依赖的 Java 运行环境，将被从公共或者私有镜像库中下拉。

ADD 语句说明在需要加入的文件，ENTRYPOINT 和 CMD 语句构成了启动命令，EXPOSE 语句说明了暴漏的端口。

这是一个最简单的 Dockerfile 样例，实际的要复杂得多。由于容器镜像采用的是 Overlay 型的文件系统，Dockerfile 中的每一个步骤将在最终镜像中产生一个层级（layer），所以 Dockerfile 撰写的好坏决定着应用镜像的运行效率。

·  最后，执行 docker build 命令，打包完成后得到最终的应用镜像。

% docker build .        
      
[+] Building 4.5s (7/7) FINISHED                                                                                        
 => [internal] load build definition from Dockerfile                                                               0.0s
 => => transferring dockerfile: 37B                                                                                0.0s
 => [internal] load .dockerignore                                                                                  0.0s
 => => transferring context: 2B                                                                                    0.0s
 => [internal] load metadata for docker.io/library/openjdk:8-jre                                                   4.4s
 => [internal] load build context                                                                                  0.0s
 => => transferring context: 82B                                                                                   0.0s
 => [1/2] FROM docker.io/library/openjdk:8-jre@sha256:59c47099aed504b2987fb5eea4376f96cf0f53d2c9081c30fd6a554c7a6  0.0s
 => CACHED [2/2] ADD ./target/sample-0.0.1-SNAPSHOT.jar /                                                          0.0s
 => exporting to image                                                                                             0.0s
 => => exporting layers                                                                                            0.0s
 => => writing image sha256:8335af64e29a7e69a047e424863ef3706349d5c5d325ff4f84447fa21a9fc496

1

  问题  

“

我们发现，在上述常规使用 docker build 的构建过程会存在一些问题，包括但不限于：

1.  需要为每种不同类别的项目准备合适的编译环境。

2.  不同的人员会撰写不同风格的 Dockerfile，一致性难以保证。

3.  撰写 Dockerfile 过于自由，可能会引入安全漏洞，包括不安全的基础镜像。

4.  如果要对安全漏洞进行修复，则需要更新 Dockerfile 为引用最新的基础镜像。

5.  需要为每个项目单独写一个 Dockerfile，在微服务架构中可能会有以百计的项目数，维护困难。

6.  Dockerfile 如果写的不够优化，那么最终产生的层级会很多，容器的运行效率也会打折扣。

·······

所以我们需要一种更为便捷，安全而且易维护的构建方法来避免以上的各种问题。

1

  Tanzu 构建服务  

基于云原生构建开源项目 Cloud Native Buildpacks（CNB），Tanzu 构建服务（以下简称 TBS）将为您解决以上提到的各种问题。开发人员将不再需要撰写 Dockerfile，而只需要使用一个简单的命令，就能把各种类型的源代码项目打包成最终的应用镜像。

而 Tanzu 构建服务，已经集成在 Tanzu Application Platform 的平台里，作为一个关键的企业级特性提供给用户来实现构建服务。

我们来看一个例子，还是使用上面的样例 Spring 项目。在下面使用的命令行里，kp 是Tanzu 构建服务的命令行工具，--git 参数指明源代码仓库地址，--git-revision 参数指明 git 分支名称，--sub-path 参数指明源代码子目录，--tag 参数指明最终应用镜像的推送仓库地址：

% kp image create my-image --tag registry.tanzu.online:5000/tbs/test-app --git http://124.222.5.35:8888/mingjiex/samples.git --git-revision master --sub-path ./apps/java-maven --wait
      
Creating Image Resource...
Image Resource "my-image" created
===> PREPARE
Build reason(s): CONFIG
CONFIG:
resources: {}
- source: {}
+ source:
+   git:
+     revision: 1bf16cdcce9454d4922f20000efa1650c195b53b
+     url: http://124.222.5.35:8888/mingjiex/samples.git
+   subPath: ./apps/java-maven
Loading secret for "registry.tanzu.online:5000" from secret "my-registry-creds" at location "/var/build-secrets/my-registry-creds"
Cloning "http://124.222.5.35:8888/mingjiex/samples.git" @ "1bf16cdcce9454d4922f20000efa1650c195b53b"...
Successfully cloned "http://124.222.5.35:8888/mingjiex/samples.git" @ "1bf16cdcce9454d4922f20000efa1650c195b53b" in path "/workspace"
===> ANALYZE
Previous image with name "registry.tanzu.online:5000/tbs/test-app" not found
===> DETECT
7 of 34 buildpacks participating
paketo-buildpacks/ca-certificates   2.4.2
paketo-buildpacks/bellsoft-liberica 8.9.0
paketo-buildpacks/maven             5.7.0
paketo-buildpacks/executable-jar    5.3.1
paketo-buildpacks/apache-tomcat     6.4.0
paketo-buildpacks/dist-zip          4.3.0
paketo-buildpacks/spring-boot       4.7.0
。。。
。。。
。。。
Paketo Executable JAR Buildpack 5.3.1
  https://github.com/paketo-buildpacks/executable-jar
  Class Path: Contributing to layer
    Writing env/CLASSPATH.delim
    Writing env/CLASSPATH.prepend
  Process types:
    executable-jar: java org.springframework.boot.loader.JarLauncher (direct)
    task:           java org.springframework.boot.loader.JarLauncher (direct)
    web:            java org.springframework.boot.loader.JarLauncher (direct)
          
Paketo Spring Boot Buildpack 4.7.0
  https://github.com/paketo-buildpacks/spring-boot
  Launch Helper: Contributing to layer
    Creating /layers/paketo-buildpacks_spring-boot/helper/exec.d/spring-cloud-bindings
  Spring Cloud Bindings 1.8.0: Contributing to layer
    Reusing cached download from buildpack
    Copying to /layers/paketo-buildpacks_spring-boot/spring-cloud-bindings
  Web Application Type: Contributing to layer
    Servlet web application detected
    Writing env.launch/BPL_JVM_THREAD_COUNT.default

TBS 会下载源代码，自动识别代码项目的类型而采用合适的编译打包工具，并编译打包成容器镜像，最终推送入指定的镜像仓库。

那么 TBS 究竟是如何完成这系列构建步骤的呢？我们来看一下 TBS 的组件。

TBS 依赖于几类关键资源:

·  ClusterStore：是云原生构建包的仓库，基于开源社区项目（ Cloud Native    Buildpacks，CNB）。

·  ClusterStack：是用于构建和运行的操作系统镜像，需要不断更新以修复安全漏洞。

·  ClusterBuilder：是 ClusterStore 和      ClusterStack的组合所形成的构建器。

TBS 发布版自带了这些资源，以供客户开箱即用。如果客户有特殊需求，则可以根据要求定制。使用 TBS 的命令行工具 kp 查看可用资源，这些资源需要在准备就绪（Ready=True）的状态：

% kp clusterstore list  
NAME       READY
default    True


% kp clusterstack list  
NAME       READY    ID
base       True     io.buildpacks.stacks.bionic
default    True     io.buildpacks.stacks.bionic
full       True     io.buildpacks.stacks.bionic
tiny       True     io.paketo.stacks.tiny


% kp clusterbuilder list
NAME       READY    STACK                          IMAGE
base       true     io.buildpacks.stacks.bionic    registry.tanzu.online:5000/tbs/build-service:clusterbuilder-base@sha256:f7600c5e5864fa14bc1a6ba31fdd932cb2cec128d3d42cf0537f7d29e63c09d0
default    true     io.buildpacks.stacks.bionic    registry.tanzu.online:5000/tbs/build-service:clusterbuilder-default@sha256:f7600c5e5864fa14bc1a6ba31fdd932cb2cec128d3d42cf0537f7d29e63c09d0
full       true     io.buildpacks.stacks.bionic    registry.tanzu.online:5000/tbs/build-service:clusterbuilder-full@sha256:bb9b938e5534fe06279bfdeafb351d1c0466af50c2082495eeed258a7cb580f7
tiny       true     io.paketo.stacks.tiny          registry.tanzu.online:5000/tbs/build-service:clusterbuilder-tiny@sha256:0c8c05b28fb57e69c0fe7c821d22634dc9fe42cd5368a02dc7f619560e44a69a

有了可用的构建器，就可以如同一开始使用的样例项目，使用 kp image create 命令创建 Image Resource，对源代码执行构建。

% kp image create my-image --tag registry.tanzu.online:5000/tbs/test-app --git
http://124.222.5.35:8888/mingjiex/samples.git --git-revision master --sub-path ./apps/java-maven --wait

查看 Image Source 列表，后续可以执行更改、删除操作：

mingjiex@mingjiex-a01 java-maven % kp image list
NAME        READY    LATEST REASON    LATEST IMAGE                            NAMESPACE
my-image    True     CONFIG           registry.tanzu.online:5000/tbs/test-
app@sha256:5fabc1e1f968f5ad09566ce1cf74a28a67d65815b7e6518604160daa8abcd86a    default

当 Image Resource 被创建后，如果源代码有新的提交，或者基础镜像发生更新，或者 Image Resource 参数发生变化的时候（各种 REASON），新的构建任务将会被触发。每次构建都会产生一个 build 号，成功的构建会产生新的应用镜像并推送到应用镜像仓库。我们可以使用 kp build 命令查看每次 build 生成的镜像：

% kp build list
BUILD    STATUS     BUILT IMAGE                                                REASON    IMAGE RESOURCE
1        SUCCESS    registry.tanzu.online:5000/tbs/test-app@sha256:0b660ee0af25b0bba80a76b31d82537eafd649c15bcb0ff08b0c06f8f6d40317    CONFIG    my-image
2        SUCCESS    registry.tanzu.online:5000/tbs/test-app@sha256:72a19a7c37158a8fc56da7c4a36cc78bd33336a91d0b220cef17a7282d167eef    COMMIT    my-image
3        SUCCESS    registry.tanzu.online:5000/tbs/test-app@sha256:5fabc1e1f968f5ad09566ce1cf74a28a67d65815b7e6518604160daa8abcd86a    CONFIG    my-image

为了达到优化目的，还可以对 Image Resource 施加特定参数来干预构建过程，比如指定构建器，改变缺省的 Java 版本，创建 cache 以加速后续的构建，等等。这些需要您在实践中去体会了。

1

  Tanzu 构建服务和 CI/CD 集成

Tanzu 构建服务和持续集成/持续交付（CI/CD）工具非常容易集成。通过 CI/CD 工具设置 Image Resource，然后触发 TBS 对提交入代码库的源代码项目执行构建服务，最后推入容器镜像仓库。

通常的集成方式如下图：

TBS 包含在 Tanzu Application Platform（简称 TAP ）的发行版内，而且已经作为预制件集成进了 TAP 的软件供应链 Choreograph 里面，成为了开箱即用的构建工具。如下图所示，Tanzu 构建服务是 TAP  软件供应链的第一步，而和后续的安全扫描，部署，运行等等连接在一起组成完整的应用安全运维过程：

1

Tanzu 构建服务之价值总结

对于试图在商业环境中构建和部署容器的开发人员和运维人员来说，构建容器镜像并通过所需的依赖关系（例如运行库/二进制文件和基本操作系统镜像）对其进行修补是一件困难的事情。在大型企业环境中，挑战尤为严峻，在这种环境中，许多开发人员会构建各种应用，而这些应用必须严格遵守安全性和审核政策。

由于 IT 运维人员需要全面重新设计他们的系统以对容器的维护进行管理，因此，从基于虚拟机或基于 PaaS 的部署过程迁移到 Kubernetes 往往十分复杂。

Tanzu 构建服务在 Kubernetes 的固有对象之上添加了抽象层，以提高企业开发人员和 IT 运维人员的工作效率。客户通过持续集成/持续交付 (CI/CD) 系统使构建过程自动化，并可从 Tanzu Network 获取最新的堆栈和生成包版本。

VMware 旨在遵循行业最佳实践，及时提供 CVE 补丁，保障客户系统的安全。对于开发人员而言，这减轻了通过新的依赖关系来更新容器所造成的负担。对于运维人员而言，它可以集中控制所有容器的依赖关系，从而更好地满足安全性、合规性和审核需求。

---

要想了解云原生、机器学习和区块链等技术原理，请立即长按以下二维码，关注本公众号亨利笔记 （ henglibiji )，以免错过更新。