背景
通常的应用开发过程，是由开发人员使用某种计算机语言，比如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云原生