容器正在吞噬世界

为了充分利用容器带来的敏捷性，软件开发团队必须调整其软件交付流程。

容器正迅速成为企业应用打包和部署的基本单位。然而IT部门的很多人仍然认为容器只是接下来的发展方向，相对于VM而言，容器只是会使计算密度又增加一个数量级。

虽然这种认知能意识到容器代表了IT需要管理的事物的另一次爆炸，但是它忽略了容器生态带来的最重要的改变——即容器使软件交付流程发生彻底的改变。

在传统的软件交付流程中，运维团队和开发团队分别负责技术栈的不同层：运维团队负责操作系统镜像，开发团队负责应用的开发。在这种流程中，开发团队使用操作系统打包工具（RPM，MSI等等工具）向运维团队交付应用和应用相关的依赖。然后运维团队把应用添加到符合公司规范的VM镜像中，并且这些VM镜像都附带了监控和日志软件，最后组合VM镜像并在生产环境中运行。开发团队通过把新包交给运维团队来迭代应用程序，运维团队使用脚本或者配置管理软件来部署新版本的应用和其他的一些更新（例如修复操作系统漏洞的补丁）。

基于容器的软件交付流程是不同的

容器交付流程和之前基于虚拟机的交付流程是完全不同的。在基于容器的交付流程中，开发团队和运维团队合作创建一个由不同层组成的单一容器镜像。这些层中最底层是操作系统层，然后是依赖层，最后是应用程序层。最重要的是，容器镜像在软件交付过程中被视为不可变的：容器中涉及的任何软件变动都需要重新构建整个容器镜像。容器技术和 Docker 镜像通过使用联合文件系统来构建一个包含应用及其依赖的基础容器镜像，这比VM镜像等早期方法更具可操作性；对容器镜像每层的更改只需要重新构建该层。这使得每个容器镜像重新构建比重新创建一个完整的VM镜像代价小得多。此外，拥有良好架构的容器只会运行一个前台进程，这与将应用程序分解为多个应用的实践相吻合（这通常称为微服务）。另外，重新构建一个容器镜像比重新构建一个VM镜像更小也更加容易，部署和启动所需要的时间也就更短。

容器镜像的不可变性和应用的微服务架构使得运维团队用于处理配置管理，监控和日志记录的软件通常不会包含在容器中。也就是，如果软件进行变更，应用需要重新构建整个镜像，但容器编排系统不会把监控和日志编排进容器镜像中。换句话来说，处理配置管理，监控和日志记录的软件并不是在运行时处理软件的变更-他们是在构建时处理的。通过使用自动构建、自动测试、自动部署（通常称为持续集成、持续交付），自动化过程从运行时活动转变成构建时活动。

在容器范例背景下进行交付

当然，我们在IT中所关心的核心问题并没有消失：我们需要确保我们的应用是没有漏洞的，运行的是已经经过IT部门确认的最新应用，可以随着负载伸缩，同时也能提供数据让日志和监控系统来协助我们确认应用是否有问题，甚至能在问题发生前预测问题。

为了充分利用容器来带的敏捷性，同时为确保应用的安全，治理，合规性以及审计追踪，我们必须重新设计我们的软件交付流程。 现在，我们必须维护和操作的最重要两项技术是容器编排系统和容器交付管道。

对于容器编排系统，在过去的两年中，Kubenetes已经成为开源标准。Kubenetes提供的特性曾经在每个IT部门都被得到应用：负载调度，日志聚合，扩缩容，健康检查和应用无缝升级。IT部门并不需要保留旧的流程和工具，而应该把Kubenetes这些特性当做新运维系统的一部分，基于Kubenetes提供的功能来创建他们的流程。

第二个关键组件是容器交付管道：这是一个对所有代码进行检查时，自动进行构建和测试，并且把检查通过的代码部署到容器编排系统上。运维流程中最关键的转变是把软件交付过程中核心点（例如漏洞修复）从生产系统的运行时监控转移到构建管道。例如，运维团队不需要对正在运行的容器打补丁，而是应该是用容器检查 工具 标记有漏洞的包的版本，触发一个容器镜像的重新构建，把检索容器镜像是否有漏洞作为CI/CD的一个步骤，并且只部署通过检查的镜像。

通过新的基于容器的交付流程来统一开发团队和运维团队

这个转变对IT部门来说可能会感到非常可怕，但是实际上它与DevOps需要进行的转变完全保持一致：应用程序的构建阶段由开发团队和运维团队共同负责，这样能尽早的发现问题，通过为开发团队和运维团队提供更严格的工作流程来消除DevOps过程中造成的大量浪费。

IT部门现在有额外的两个系统来标准化和运维业务系统：容器编排系统和容器交付管道。但是对例如配置管理系统，日志聚合系统和监控系统等IT公共组件会发生什么呢？他们并不会消失在容器世界里。相反，他们会在容器中扮演不同的角色。配置管理系统被用于部署和管理容器编排系统、容器交付管道和其他的例如数据管理系统等没有运行在容器中的核心分布式系统的生命周期。日志聚合系统继续从容器编排系统和容器交付管道系统的日志中为审计、预测性的分析提供关键性的功能。同时监控系统也会聚合容器编排系统和其他外部数据源的数据。

通过DevOps和容器建立结构化竞争优势

通过引入企业标准的容器编排系统和容器交付管道来拥抱DevOps的企业将会具有敏捷性优势，能更快的试验和理解客户的需求，最终能正确并且比竞争对手更快的交付软件。这些有远见的企业将会具有结构性竞争优势并将称为DevOps和容器的主要受益者。