论文部分内容阅读
为了充分利用容器所带来的敏捷性，团队必须重新设计他们的软件交付工作流程。
容器正迅速成为企业应用程序的打包和部署工具。然而，许多IT人员仍然只是将容器视为从物理服务器向虚拟机迁移进程中的一个逻辑环节而已，他们认为，相对于运行在物理服务器上的虚拟机数量而言，容器在计算密度上又增加了一个量级。
虽然这种观点认识到了容器意味着IT部门需要管理的事物在数量级上又将出现一次爆炸，但他们没有认识到容器生态系统带来的最重要的变化，即容器将导致软件交付工作流程发生根本性变革。
在传统的软件交付工作流程中，两个独立的团队负责堆栈的不同层：运维团队负责操作系统镜像，开发团队负责应用程序构件。在这一工作流程中，应用程序构件和相关性将通过操作系统打包方式，如RPM（红帽打包管理器）、MSI（Windows打包管理）等等……由开发转至运维。运维团队会将这些构件部署在符合公司策略且包含有监测和日志记录软件的操作系统镜像上。随后，这一复合镜像会在生產中运行。开发团队会通过将新软件包交给运维团队的方式来不断推动应用程序的发展，同时运维团队会通过使用脚本或配置管理软件的方式部署这些更新以及任何其他的更新（例如解决操作系统漏洞的补丁）。
基于容器的软件交付方式不同于传统方式
容器交付工作流程完全不同于传统的软件交付工作流程。开发团队和运维团队将合作创建一个由不同层组成的单一容器镜像。这些层从操作系统开始，然后添加相关性（每个都在自己的层中），最后是应用程序构件。更重要的是，容器镜像在软件交付过程中被视为不可变的镜像：对底层软件的任何改动都需要重建整个容器镜像。通过使用联合文件系统将基本操作系统镜像与应用程序及相关性组合在一起，容器技术和Docker镜像比虚拟机镜像结构等早期方法更具实用性。对每个层的修改只需要重建该层即可。这使得每个容器镜像的重建比重新创建一个完整的虚拟机镜像要便宜许多。此外，架构出色的容器只运行一个前台进程，这也与将应用程序分解为众多微服务的实践完全相符。因此，与传统的操作镜像相比，容器镜像更小且更容易重建，这也使得后者的部署和启动时间大幅降低。
不可变性和微服务架构的一个重要影响是，运维团队用于进行配置管理、监视和日志记录的软件代理通常无法在容器镜像中找到。相反，如果软件必须进行修改，那么容器化应用要重建整个镜像。日志记录和监视同样要外部化到容器编排系统。换言之，代理不会在运行时进行软件修改，因为它们是在构建时创建的。通过使用自动化的构建/测试/部署周期（通常称为持续集成/持续交付，CI/CD），自动化工作从运行时活动转变成了构建时活动。
在容器范式背景下交付IT
当然，我们在IT中所关注的核心问题并没有消失，即我们需要一些机制来确保应用程序没有漏洞，运行已经过IT认证的最新软件版本，让它们可以随负载进行扩展，同时能够提供数据痕迹从而使记录和监测系统能够帮助我们发现问题，甚至在问题发生之前对其进行预测。
为了充分利用容器带来的敏捷性，以及为我们提供运营业务所需的安全、管理、合规和审计跟踪，我们必须重新设计软件交付工作流程。容器编排系统和容器交付管道是我们当前需要维护和运营的两个最重要的技术。
关于前者，在过去两年中，Kubernetes已成为多厂商开源标准。Kubernetes提供的功能曾经是每个IT部门都需要掌握的：工作负载调度、日志聚合、扩展、运行状况监控和无缝应用程序升级。IT部门不是通过保留旧的工作流程和工具来对抗这些内置功能，而是需要接受它们作为新“操作系统”的一部分，并围绕Kubernetes提供的内容构建其工作流程。
第二个关键组件是容器交付管道。这个系统可以为每个代码签入实现构建/测试周期自动化，并将成功的签入部署到容器编排系统中。运维工作流程中最关键的变化是将软件交付生命周期的核心部分（如漏洞修复）移出生产系统的运行时监控并将其转入构建管道。例如，运维团队不需要在正在运行的容器上修补易受攻击的软件包，取而代之的是需要使用容器检查工具标记易受攻击的软件包版本，触发容器镜像的重建，扫描镜像以查找CI/CD管道中易受攻击的软件包，以及仅部署通过这些扫描的镜像。
通过新的容器工作流程统一开发与运维
对于IT来说，他们可能会认为这是一个可怕的转变，但实际上这一转变与向开发运维的转变完全一致。通过让开发和运维在应用程序的构建阶段协同工作，可以在软件交付生命周期的早期发现问题，并且通过为开发和运维提供更密切的工作流程，可消除为解决这些问题所带来的大量浪费。
IT现在有两个额外的任务关键系统可为业务进行标准化和运维：容器编排系统和容器交付管道。但是，配置管理系统、日志聚合系统和监控系统等常见IT设备会发生什么？它们不会在容器世界中消失。相反，他们承担不同的角色。配置管理系统用于部署和管理核心分布式系统的生命周期，例如容器编排系统、容器交付管道以及未在容器中运行的数据管理系统等其他相关的东西。日志聚合系统通过提供来自容器编排系统和容器交付管道的日志，继续为审计、取证和预测分析提供关键功能。监控系统则将对来自容器编排系统的数据与其他外部数据源进行聚合。
利用开发运维和容器建立结构性竞争优势
那些能够将引入的企业标准容器编排系统和容器交付管道与开发运维转型相结合的企业将享受到这一新工作流程与生俱来的敏捷性优势，能够更快地进行测试和从客户那里总结经验，并最终比竞争对手更快地向客户提供适当功能。这些有远见的企业将建立起重要的结构性竞争优势，并将成为新的开发运维和容器领域中的主要受益者。
容器正迅速成为企业应用程序的打包和部署工具。然而，许多IT人员仍然只是将容器视为从物理服务器向虚拟机迁移进程中的一个逻辑环节而已，他们认为，相对于运行在物理服务器上的虚拟机数量而言，容器在计算密度上又增加了一个量级。
虽然这种观点认识到了容器意味着IT部门需要管理的事物在数量级上又将出现一次爆炸，但他们没有认识到容器生态系统带来的最重要的变化，即容器将导致软件交付工作流程发生根本性变革。
在传统的软件交付工作流程中，两个独立的团队负责堆栈的不同层：运维团队负责操作系统镜像，开发团队负责应用程序构件。在这一工作流程中，应用程序构件和相关性将通过操作系统打包方式，如RPM（红帽打包管理器）、MSI（Windows打包管理）等等……由开发转至运维。运维团队会将这些构件部署在符合公司策略且包含有监测和日志记录软件的操作系统镜像上。随后，这一复合镜像会在生產中运行。开发团队会通过将新软件包交给运维团队的方式来不断推动应用程序的发展，同时运维团队会通过使用脚本或配置管理软件的方式部署这些更新以及任何其他的更新（例如解决操作系统漏洞的补丁）。
基于容器的软件交付方式不同于传统方式
容器交付工作流程完全不同于传统的软件交付工作流程。开发团队和运维团队将合作创建一个由不同层组成的单一容器镜像。这些层从操作系统开始，然后添加相关性（每个都在自己的层中），最后是应用程序构件。更重要的是，容器镜像在软件交付过程中被视为不可变的镜像：对底层软件的任何改动都需要重建整个容器镜像。通过使用联合文件系统将基本操作系统镜像与应用程序及相关性组合在一起，容器技术和Docker镜像比虚拟机镜像结构等早期方法更具实用性。对每个层的修改只需要重建该层即可。这使得每个容器镜像的重建比重新创建一个完整的虚拟机镜像要便宜许多。此外，架构出色的容器只运行一个前台进程，这也与将应用程序分解为众多微服务的实践完全相符。因此，与传统的操作镜像相比，容器镜像更小且更容易重建，这也使得后者的部署和启动时间大幅降低。
不可变性和微服务架构的一个重要影响是，运维团队用于进行配置管理、监视和日志记录的软件代理通常无法在容器镜像中找到。相反，如果软件必须进行修改，那么容器化应用要重建整个镜像。日志记录和监视同样要外部化到容器编排系统。换言之，代理不会在运行时进行软件修改，因为它们是在构建时创建的。通过使用自动化的构建/测试/部署周期（通常称为持续集成/持续交付，CI/CD），自动化工作从运行时活动转变成了构建时活动。
在容器范式背景下交付IT
当然，我们在IT中所关注的核心问题并没有消失，即我们需要一些机制来确保应用程序没有漏洞，运行已经过IT认证的最新软件版本，让它们可以随负载进行扩展，同时能够提供数据痕迹从而使记录和监测系统能够帮助我们发现问题，甚至在问题发生之前对其进行预测。
为了充分利用容器带来的敏捷性，以及为我们提供运营业务所需的安全、管理、合规和审计跟踪，我们必须重新设计软件交付工作流程。容器编排系统和容器交付管道是我们当前需要维护和运营的两个最重要的技术。
关于前者，在过去两年中，Kubernetes已成为多厂商开源标准。Kubernetes提供的功能曾经是每个IT部门都需要掌握的：工作负载调度、日志聚合、扩展、运行状况监控和无缝应用程序升级。IT部门不是通过保留旧的工作流程和工具来对抗这些内置功能，而是需要接受它们作为新“操作系统”的一部分，并围绕Kubernetes提供的内容构建其工作流程。
第二个关键组件是容器交付管道。这个系统可以为每个代码签入实现构建/测试周期自动化，并将成功的签入部署到容器编排系统中。运维工作流程中最关键的变化是将软件交付生命周期的核心部分（如漏洞修复）移出生产系统的运行时监控并将其转入构建管道。例如，运维团队不需要在正在运行的容器上修补易受攻击的软件包，取而代之的是需要使用容器检查工具标记易受攻击的软件包版本，触发容器镜像的重建，扫描镜像以查找CI/CD管道中易受攻击的软件包，以及仅部署通过这些扫描的镜像。
通过新的容器工作流程统一开发与运维
对于IT来说，他们可能会认为这是一个可怕的转变，但实际上这一转变与向开发运维的转变完全一致。通过让开发和运维在应用程序的构建阶段协同工作，可以在软件交付生命周期的早期发现问题，并且通过为开发和运维提供更密切的工作流程，可消除为解决这些问题所带来的大量浪费。
IT现在有两个额外的任务关键系统可为业务进行标准化和运维：容器编排系统和容器交付管道。但是，配置管理系统、日志聚合系统和监控系统等常见IT设备会发生什么？它们不会在容器世界中消失。相反，他们承担不同的角色。配置管理系统用于部署和管理核心分布式系统的生命周期，例如容器编排系统、容器交付管道以及未在容器中运行的数据管理系统等其他相关的东西。日志聚合系统通过提供来自容器编排系统和容器交付管道的日志，继续为审计、取证和预测分析提供关键功能。监控系统则将对来自容器编排系统的数据与其他外部数据源进行聚合。
利用开发运维和容器建立结构性竞争优势
那些能够将引入的企业标准容器编排系统和容器交付管道与开发运维转型相结合的企业将享受到这一新工作流程与生俱来的敏捷性优势，能够更快地进行测试和从客户那里总结经验，并最终比竞争对手更快地向客户提供适当功能。这些有远见的企业将建立起重要的结构性竞争优势，并将成为新的开发运维和容器领域中的主要受益者。