背景
通常的利用开发过程，是由开发人员应用某种计算机语言，比方 Java，开发特定我的项目而后提交到代码仓库。紧接着，源代码会被编译成二进制代码，被搁置于特定的环境中运行，比方 Java 运行时或者 Web Server 等。随着容器以及容器编排技术的倒退和成熟，越来越多的利用将从传统的虚拟机部署形式改为容器部署模式。这就减少了一个要害的步骤：把利用打包成容器镜像，也称为利用容器化。
那么这个步骤还是由开发人员实现吗？开发人员的心田 os：我难道不应该专一于写业务逻辑吗？这个打包也要由我来实现？好吧，然而打包写 Dockerfile 我没有教训啊！要怎么避开外面的陷阱呢？当前源代码或者根底镜像更新了，还要由我来保护吗？
带着这些疑难，咱们来认真看看利用容器化的具体过程是怎么样的吧。
从源代码到容器镜像
当开发人员实现了一个利用我的项目并提交代码库之后，为了让代码能在容器环境中运行，须要把源代码转换成合乎 OCI 规范的容器镜像，这个过程称为构建（build）。构建过程通常分为两个子步骤，第一步是将源代码编译成二进制文件，第二步是加上根底操作系统和相干依赖（比方 Java 运行时）合并成规范容器镜像。
第一步的编译取决于利用我的项目所采纳的语言和框架，第二步惯例的办法则是以撰写 Dockerfile 以及应用 docker build 来实现的。以应用 Spring 框架开发的我的项目为例，咱们能够看到惯例的构建过程是这样的：
- 首先，将源代码下载到本地，应用 Maven 命令对 Spring 我的项目进行 Java 编译：
在编译过程中会主动下载大量的 Java 依赖包，如果没有编译谬误，那么最终会在 target 目录下生成一个二进制可执行的 sample-0.0.1-SNAPSHOT.jar 包。
- 而后，撰写 Dockerfile 文件，申明构建的步骤和参数，样本文件如下：
其中 FROM 语句是援用的根底镜像名称，该镜像蕴含了底层的操作系统和依赖的 Java 运行环境，将被从公共或者公有镜像库中下拉。
ADD 语句阐明在须要退出的文件，ENTRYPOINT 和 CMD 语句形成了启动命令，EXPOSE 语句阐明了暴漏的端口。
这是一个最简略的 Dockerfile 样例，理论的要简单得多。因为容器镜像采纳的是 Overlay 型的文件系统，Dockerfile 中的每一个步骤将在最终镜像中产生一个层级（layer），所以 Dockerfile 撰写的好坏决定着利用镜像的运行效率。
- 最初，执行 docker build 命令，打包实现后失去最终的利用镜像。
问题
咱们发现，在上述惯例应用 docker build 的构建过程会存在一些问题，包含但不限于：
1. 须要为每种不同类别的我的项目筹备适合的编译环境。
2. 不同的人员会撰写不同格调的 Dockerfile，一致性难以保障。
3. 撰写 Dockerfile 过于自在，可能会引入安全漏洞，包含不平安的根底镜像。
4. 如果要对安全漏洞进行修复，则须要更新 Dockerfile 为援用最新的根底镜像。
5. 须要为每个我的项目独自写一个 Dockerfile，在微服务架构中可能会有以百计的项目数，保护艰难。
6.Dockerfile 如果写的不够优化，那么最终产生的层级会很多，容器的运行效率也会打折扣。
。。。
所以咱们须要一种更为便捷，平安而且易保护的构建办法来防止以上的各种问题。
Tanzu 构建服务
基于云原生构建开源我的项目 Cloud Native Buildpacks（CNB），Tanzu 构建服务（以下简称 TBS）将为您解决以上提到的各种问题。开发人员将不再须要撰写 Dockerfile，而只须要应用一个简略的命令，就能把各种类型的源代码我的项目打包成最终的利用镜像。
而 Tanzu 构建服务，曾经集成在 Tanzu Application Platform 的平台里，作为一个要害的企业级个性提供给用户来实现构建服务。
咱们来看一个例子，还是应用下面的样例 Spring 我的项目。在上面应用的命令行里，kp 是 Tanzu 构建服务的命令行工具，–git 参数指明源代码仓库地址，–git-revision 参数指明 git 分支名称，–sub-path 参数指明源代码子目录，–tag 参数指明最终利用镜像的推送仓库地址：
TBS 会下载源代码，自动识别代码我的项目的类型而采纳适合的编译打包工具，并编译打包成容器镜像，最终推送入指定的镜像仓库。
那么 TBS 到底是如何实现这系列构建步骤的呢？咱们来看一下 TBS 的组件。
TBS 依赖于几类要害资源:
- ClusterStore：是云原生构建包的仓库，基于开源社区我的项目（Cloud Native Buildpacks，CNB）。
- ClusterStack：是用于构建和运行的操作系统镜像，须要不断更新以修复安全漏洞。
- ClusterBuilder：是 ClusterStore 和 ClusterStack 的组合所造成的构建器。
TBS 公布版自带了这些资源，以供客户开箱即用。如果客户有非凡需要，则能够依据要求定制。应用 TBS 的命令行工具 kp 查看可用资源，这些资源须要在准备就绪（Ready=True）的状态：
有了可用的构建器，就能够如同一开始应用的样例我的项目，应用 kp image create 命令创立 Image Resource，对源代码执行构建。
查看 Image Source 列表，后续能够执行更改、删除操作：
当 Image Resource 被创立后，如果源代码有新的提交，或者根底镜像产生更新，或者 Image Resource 参数发生变化的时候（各种 REASON），新的构建工作将会被触发。每次构建都会产生一个 build 号，胜利的构建会产生新的利用镜像并推送到利用镜像仓库。咱们能够应用 kp build 命令查看每次 build 生成的镜像：
为了达到优化目标，还能够对 Image Resource 施加特定参数来干涉构建过程，比方指定构建器，扭转缺省的 Java 版本，创立 cache 以减速后续的构建，等等。这些须要您在实践中去领会了。
Tanzu 构建服务和 CI/CD 集成
Tanzu 构建服务和继续集成 / 继续交付（CI/CD）工具非常容易集成。通过 CI/CD 工具设置 Image Resource，而后触发 TBS 对提交入代码库的源代码我的项目执行构建服务，最初推入容器镜像仓库。通常的集成形式如下图：
TBS 蕴含在 Tanzu Application Platform（简称 TAP）的发行版内，而且曾经作为预制件集成进了 TAP 的软件供应链 Choreograph 外面，成为了开箱即用的构建工具。如下图所示，Tanzu 构建服务是 TAP 软件供应链的第一步，而和后续的平安扫描，部署，运行等等连贯在一起组成残缺的利用平安运维过程：
Tanzu 构建服务之价值总结
对于试图在商业环境中构建和部署容器的开发人员和运维人员来说，构建容器镜像并通过所需的依赖关系（例如运行库 / 二进制文件和根本操作系统镜像）对其进行修补是一件艰难的事件。在大型企业环境中，挑战尤为严厉，在这种环境中，许多开发人员会构建各种利用，而这些利用必须严格遵守安全性和审核政策。
因为 IT 运维人员须要全面从新设计他们的零碎以对容器的保护进行治理，因而，从基于虚拟机或基于 PaaS 的部署过程迁徙到 Kubernetes 往往十分复杂。
Tanzu 构建服务在 Kubernetes 的固有对象之上增加了形象层，以进步企业开发人员和 IT 运维人员的工作效率。客户通过继续集成 / 继续交付 (CI/CD) 零碎使构建过程自动化，并可从 Tanzu Network 获取最新的堆栈和生成包版本。VMware 旨在遵循行业最佳实际，及时提供 CVE 补丁，保障客户零碎的平安。对于开发人员而言，这加重了通过新的依赖关系来更新容器所造成的累赘。对于运维人员而言，它能够集中控制所有容器的依赖关系，从而更好地满足安全性、合规性和审核需要。
作者简介：
熊铭杰，VMware 大中华区利用现代化部门高级解决方案架构师，在退出 VMware 之前，曾先后任职 BEA System、IBM、Redhat 等企业。多年来始终从事企业级软件开发、中间件和云原生相干畛域工作，对企业级软件开发和架构设计、微服务架构设计以及容器平台的架构设计、软件开发、施行和运维等工作具备丰盛的教训积攒；CNCF 认证 CKA 工程师；VMware 认证 Spring Professional 工程师。
起源|公众号：VMwareTanzu 云原生