题图摄于美国大峡谷
本篇转发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===> 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.default
TBS 会下载源代码,自动识别代码项目的类型而采用合适的编译打包工具,并编译打包成容器镜像,最终推送入指定的镜像仓库。
那么 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?),以免错过更新。