TAP 中的云原生构建服务
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:8335af64e29a7e69a047e424863ef3706349d5c5d325ff4f84447fa21a9fc4961
问题
“
我们发现，在上述常规使用 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===> PREPAREBuild reason(s): CONFIGCONFIG:resources: {}- source: {}+ source:+ git:+ revision: 1bf16cdcce9454d4922f20000efa1650c195b53b+ url: http://124.222.5.35:8888/mingjiex/samples.git+ subPath: ./apps/java-mavenLoading 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"===> ANALYZEPrevious image with name "registry.tanzu.online:5000/tbs/test-app" not found===> DETECT7 of 34 buildpacks participatingpaketo-buildpacks/ca-certificates 2.4.2paketo-buildpacks/bellsoft-liberica 8.9.0paketo-buildpacks/maven 5.7.0paketo-buildpacks/executable-jar 5.3.1paketo-buildpacks/apache-tomcat 6.4.0paketo-buildpacks/dist-zip 4.3.0paketo-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.defaultTBS 会下载源代码，自动识别代码项目的类型而采用合适的编译打包工具，并编译打包成容器镜像，最终推送入指定的镜像仓库。
那么 TBS 究竟是如何完成这系列构建步骤的呢？我们来看一下 TBS 的组件。
TBS 依赖于几类关键资源:
· ClusterStore：是云原生构建包的仓库，基于开源社区项目（ Cloud Native Buildpacks，CNB）。
· ClusterStack：是用于构建和运行的操作系统镜像，需要不断更新以修复安全漏洞。
· ClusterBuilder：是 ClusterStore 和 ClusterStack的组合所形成的构建器。
TBS 发布版自带了这些资源，以供客户开箱即用。如果客户有特殊需求，则可以根据要求定制。使用 TBS 的命令行工具 kp 查看可用资源，这些资源需要在准备就绪（Ready=True）的状态：
% kp clusterstore list NAME READYdefault True
% kp clusterstack list NAME READY IDbase True io.buildpacks.stacks.bionicdefault True io.buildpacks.stacks.bionicfull True io.buildpacks.stacks.bionictiny True io.paketo.stacks.tiny
% kp clusterbuilder listNAME READY STACK IMAGEbase true io.buildpacks.stacks.bionic registry.tanzu.online:5000/tbs/build-service:clusterbuilder-base@sha256:f7600c5e5864fa14bc1a6ba31fdd932cb2cec128d3d42cf0537f7d29e63c09d0default true io.buildpacks.stacks.bionic registry.tanzu.online:5000/tbs/build-service:clusterbuilder-default@sha256:f7600c5e5864fa14bc1a6ba31fdd932cb2cec128d3d42cf0537f7d29e63c09d0full true io.buildpacks.stacks.bionic registry.tanzu.online:5000/tbs/build-service:clusterbuilder-full@sha256:bb9b938e5534fe06279bfdeafb351d1c0466af50c2082495eeed258a7cb580f7tiny 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 --githttp://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 listNAME READY LATEST REASON LATEST IMAGE NAMESPACEmy-image True CONFIG registry.tanzu.online:5000/tbs/test-app@sha256:5fabc1e1f968f5ad09566ce1cf74a28a67d65815b7e6518604160daa8abcd86a default当 Image Resource 被创建后，如果源代码有新的提交，或者基础镜像发生更新，或者 Image Resource 参数发生变化的时候（各种 REASON），新的构建任务将会被触发。每次构建都会产生一个 build 号，成功的构建会产生新的应用镜像并推送到应用镜像仓库。我们可以使用 kp build 命令查看每次 build 生成的镜像：
% kp build listBUILD STATUS BUILT IMAGE REASON IMAGE RESOURCE1 SUCCESS registry.tanzu.online:5000/tbs/test-app@sha256:0b660ee0af25b0bba80a76b31d82537eafd649c15bcb0ff08b0c06f8f6d40317 CONFIG my-image2 SUCCESS registry.tanzu.online:5000/tbs/test-app@sha256:72a19a7c37158a8fc56da7c4a36cc78bd33336a91d0b220cef17a7282d167eef COMMIT my-image3 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 )，以免错过更新。
腾讯云开发者
