云计算架构学习整理（十一）：不可变基础设施不可变基础设施的理念；不可变基础设施相关的应用：微服务、蓝绿部署、容器集群；

前言

云计算架构作为一种基础设施服务几乎已经成为了现代Web开发的标配，它显著地降低了 DevOps（Development and Operations）的门槛，通过云服务商提供的管理平台，Web应用开发人员可以轻松地在云上搭建自己的系统。作为一名云时代的全栈开发工程师，了解云计算架构背后的机制可以让我们更好地利用这个强大的基础设施，在设计、开发、部署和维护应用程序时做出更明智的决策。同时云计算是互联网技术的延伸，通过学习云计算架构，可以更深入地掌握互联网基础知识，这对于个人的技术水平也是一个很大的提升。

为了对云计算有一个全面的了解，最近在读 《图解云计算架构——基础设施和API》 一书，这本书主要以OpenStack和AWS为例，通过API来重点讲解IaaS云服务的本质。下面是边读边整理的学习笔记，一方面可以随时回顾，另一方面希望通过输出来促进自己思考。

正文

前面的章节讲了如何在云中搭建基础设施环境，以及使用云API搭建各种系统组件的机制。本章将揭示由组件搭建出来的系统与传统系统之间的显著差异，即它是可以即用即抛、可以按照应用程序的生命周期进行管理的“不可变基础设施”。

1. 传统的基础设施搭建方法和存在的问题

在传统基础设施搭建环境的步骤跟在云中搭建环境很不一样，在云中搭建的步骤得到了简化，提升了搭建的效率，本节从应用程序和底层基础设施的生命周期的角度出发，指出传统的环境搭建方式存在的问题。

1.1 传统系统的生命周期

传统的环境搭建，即以本地部署的方式搭建环境时，硬件或软件的保修期是系统生命周期中的重要因素。传统的IT系统往往受限于硬件或软件的生命周期，不得不每隔几年就变动一次。假如要搭建一套10年使用期限的业务系统，我们从看看它的对应的硬件和软件的生命周期：

硬件：硬件的保修期通常是按5年左右的折旧期限来估算。而且随着硬件的更新换代，耗电率也会逐年降低，计算能力会不断提升，一直使用旧的硬件也未必能节约成本。
软件：操作系统、数据库和应用程序服务器往往每隔几年就会进行大版本升级，而且超过软件保修期后官方不再提供补丁更新，可能导致安全问题。此外还要考虑技术架构的升级，新的技术架构不断涌现，老旧的技术架构可能慢慢变得无人维护。

所以，在传统的基础设施搭建过程中，系统的生命周期受制于硬件或软件的生命周期，而无法按照业务系统本身的生命周期来进行系统投资。

另外，系统配置的文档管理也是一个问题。基础设施环境搭建之后，还会面临不断的更新和修补，很可能导致实际环境跟配置文档不一致，增加了维护的麻烦。

2. 什么是不可变基础设施

在云中搭建基础设施时，我们可以通过API来轻松搭建、添加或删除虚拟服务器。这样一来，系统的生命周期和维护成本就变得大不一样了。

不可变基础设施的理念

不可变基础设施（Immutable Infrastructure）是一种基础设施构建和管理的理念，它跟函数式编程中的不可变编程有共通之处。在这种理念下，基础设施（如服务器、虚拟机、容器等）一旦部署，就不再进行修改。如果需要对基础设施进行更新、修复或升级，会通过创建新的基础设施实例来替换旧的实例，而不是直接在现有实例上进行更改。

不可变基础设施的生命周期

对于企业来说，最理想的情况是不再受制于硬件和软件的生命周期，只按照业务系统的生命周期来规划基础设施的投入和使用，即贴合业务需求的生命周期，即需即用，不用即抛，没有多余的浪费。

不可变基础设施的生命周期正好可以满足这样的生命周期需求。

首先，资源是要用时才购买的，而且可以按使用量付费，不用就不再付费。这样一来就无须考虑初期投资或折旧问题了。
此外，硬件升级也变得简单，以AWS为例，只需停止旧的Amazon EC2示例，然后指定新的实例类型再重启实例，就可以在最新的硬件上运行实例了。硬件的生命周期不再影响系统的生命周期。
软件方面，软件升级和安全漏洞修补都可以与代码发布同步进行，而架构迁移可以通过环境的迁移来实现。

3. 不可变基础设施与基础设施即代码

我们要怎么确保基础设施环境的可维护性呢？我们可以将基础设施环境的配置信息定义成代码，然后通过自动化构建的机制使配置生效，这就是基础设施即代码。

自动化构建：可以将Chef、Puppet、Ansible以及用于对环境进行单测的Serverspec等工具结合起来实现自动化搭建的机制，这些工具会调用云API来搭建环境。公有云供应商也提供了类似的自动化搭建服务，比如OpenStack中的Heat、AWS中的CloudFormation。
PaaS层的配置化构建：AWS等公有云服务商还在致力于发展serverless的PaaS服务，让基础设施环境配置变得透明。比如AWS提供了Elastic Beanstalk服务，它向用户提供了PaaS层的配置化搭建，使得用户无需关注IaaS层。
代码管理代替传统文档：使用自动化搭建工具之后，我们可以将传统的基础设施环境设计文档转化成基础设施环境配置信息的代码，通过代码管理来提升可维护性。当需要更新配置时，我们先更新代码，再执行自动化构建，然后用新环境代替旧环境。这样就可以保持设计信息与实际环境的一致性了。

4. 蓝绿部署

不可变基础设施的理念就是当基础设施环境发生变化时，先丢弃当前环境再搭建新环境，那么切换的过程就存在停机的间隙，对于互联网上的大型系统来说，停机时间会影响业务，给用户带来不便。下面就介绍一种尽可能减少系统停机时间的切换环境的方法。

一般来说，更新当前正在运行的应用程序有两种常用的方法。

原地更新：将新的应用程序模块发布到正在运行的环境中。原地更新的缺点是服务器暂时无法接收请求，而且无法提前确认新的应用程序的实际行为，只能发布后才能发现问题。如果有多台服务器，虽然通过逐一发布的方式可以避免所有服务器同时停止服务，但是这样可能会导致同时存在新旧两个版本的内容，造成业务上的不一致。
蓝绿部署：蓝绿部署（blue-green deployment）交替使用两个线上环境。在更新应用程序或运行平台时，针对每个环境都部署一套新版本的应用程序，在验收测试等所有步骤都完成后，再跟当前环境交换URL，实现环境交替。切换到新环境后，可以在一段时间内保留旧环境，这样就能够在新环境出现问题时轻松切回旧环境。

蓝绿部署最早是2010年提出的，比不可变基础设施出现得还早。蓝绿部署的环境替换方式成为了采用不可变基础设施进行平台管理的基础。

5. 不可变基础设施和应用程序架构

并不是所有IT系统平台都适合直接套用不可变基础设施的概念。实现不可变基础设施的关键在于变更前后的基础设施环境要采用没有共享组件的“零共享”（ shared nothing）结构。

我们从典型的Web三层架构来剖析Web应用程序。从接近客户端的层级开始，这三层依次是“表现层”（presentation layer）、“应用层”（application layer）和“数据层”（data layer）。

5.1 适合采用不可变基础设施：表现层和应用层

表现层和应用层通常部署在Web服务器和应用程序服务器上。这两层往往会随着所提供的业务需求的变更而频繁变更，而且会受到来自外部网络的恶意访问的威胁，一旦发生安全漏洞就必须立即修复。因此这两层对不可变基础设施的需求比较强烈。

为了实现蓝绿部署，就要满足“零共享”的要求，将表现层和应用层的会话信息放到外部存储中。一般来说，表现层和应用层都有处理请求的功能，请求往往是带有会话信息的，会话信息中存储的是来自同一个用户的多个请求中的数据，比如保持用户的登录状态。如果我们将会话信息存储在应用服务器上，那么一旦蓝绿部署切换了服务器，会话信息就丢失了。对此，人们也想了其他办法，比如旧环境停止接收新请求，直到所有会话结束后再迁移到新环境，但是这样一来就无法在切换环境时保持系统在线，失去了蓝绿部署的优势。所以，会话信息不能存储在应用程序本地内存中，而要存储到类似于AWS DynamoDB这样的键值对存储型的外部存储空间中。

5.2 不适合采用不可变基础设施：数据层

数据层一般由关系型数据库构成，数据库中存储着交易数据和主要数据（master data），可供多个应用程序使用。假如要实现“零共享”结构，就要禁止变更前后的基础设施共享数据层，这是不太现实的；而且大型关系型数据库的数据迁移非常耗时。所以被多个应用程序共享的、持久化存储数据的数据层很难采用不可变基础设施来配置。而数据层一般也不会面临频繁的维护部署，它不要求采用不可变基础设施。

因此，在配置IT系统时，我们将可以采用零共享结构的表现层和应用层作为不可变基础设施，而将数据层作为稳定的基础设施平台。

6. 微服务和不可变基础设施

应用程序需要具备哪些特征才能有效利用不可变基础设施呢？

应用程序的规模往往随着业务的扩大而膨胀。假如在一个不可变基础设施实现的运行平台上，我们需要更新应用程序的模块，同时还要为基础设施平台安装安全补丁。更新后就需要检查应用程序的所有模块是否在基础平台设施平台上正常运行。如果应用程序包含很多功能，那么每次更新基础设施平台都要检查所有功能，这是不现实的，也说明系统的可维护性低。

那么，应用程序规模应该控制在多大才算可维护性较高的应用程序呢？我们就带着这个问题来看看近年来备受瞩目的微服务（microservices）。

所谓微服务，就是通过能够独立部署的服务设计出的应用程序。微服务没有准确的定义，但是我们可以从一系列特征出发，整理微服务和非微服务之间的差异：

	微服务	非微服务
组件化	定义为服务；使用公开的接口	定义为代码库；调用内存中的函数
服务接口	REST/HTTP	Web服务等
数据管理	单独管理各服务的数据库	统一管理服务间共用的数据库
更改应用程序	升级服务	发布代码时全部更改
灾难恢复方案	假定失败机制（Design for failure）	彻底冗余
搭建基础设施环境	自动搭建、自动部署、自动测试；用独立的进程运行服务	整体进行搭建、测试和部署；用一个进程运行多个服务
服务治理	分别治理；可以为各服务选用不同的技术	集中治理；整个应用程序使用统一的技术
团队	由跨功能团队负责搭建、管理每个服务	按功能划分团队，整个应用程序由一个团队管理
团队存续时间	服务、商品的生命周期	直到项目结束

可以看到，以服务为单位的微服务架构和不可变基础设施具有较好的兼容性。管理微服务的团队在更换基础设施平台时可以充分评估对应用程序造成的影响。

7. 容器虚拟化技术和不可变基础设施

这一节讲解以Docker为代表的、与不可变基础设施和微服务关系密切的容器虚拟化技术。

7.1 容器

容器是一种轻量级、独立的软件单元，它将应用程序及其所有依赖（包括代码、运行时环境、系统工具、系统库等）打包在一起，使应用能够在不同的计算环境中以一致的方式运行。容器就像是一个便携式的 “软件盒子”，里面包含了运行应用所需的全部要素，并且提供了沙箱机制，与外部环境隔离。

容器共享宿主机的操作系统内核，在操作系统之上通过容器引擎（如 Docker 引擎）创建多个相互隔离的容器。每个容器包含应用程序、运行时环境以及相关的依赖库，但不需要安装完整的操作系统。例如，在一个 Linux 宿主机上，通过 Docker 可以创建多个容器，这些容器都依赖于宿主机的 Linux 内核来执行系统调用等底层操作，容器之间通过内核的 namespace 和 cgroup 等机制实现进程隔离和资源隔离。

7.2 容器化与不可变基础设施

我们看看容器虚拟化技术和IaaS层中的虚拟化技术有什么不同：

使用虚拟机管理程序的虚拟化技术：将子操作系统安装到每台虚拟服务器上，以此来构成一台台独立的服务器。
容器虚拟化技术：在一个操作系统上构成多个相当于虚拟服务器的“容器”。

通过容器虚拟化技术实现不可变基础设施时，用户可以不用关注操作系统层以及更底层的IaaS环境。用户只需要关注会对应用程序造成直接影响的运行环境，从而简化管理；而且可以在不同操作系统之间轻松迁移，可移植性得到了大大的提升。就好比在Java中，只需要将重点放在上层的Java运行时环境一样。

容器虚拟化技术与微服务技术之间具有良好的兼容性。微服务管理团队不需要关注应用程序运行环境底层的配置，只提供URL开放服务端点，容器管理机制就可以提供服务注册、服务发布和服务发现的功能。

此外，通过编排工具构建搭建服务器栈时，容器虚拟化技术不需要启动和配置操作系统，所以我们能够以非常短的时间启动应用程序的运行环境。如果提前将应用程序运行环境的镜像打包，那么接下来就只需要将依赖的代码库模块升级到最新版本并部署应用程序，进一步缩短了应用程序的启动时间。

8.Docker和容器集群管理框架

最后讲讲容器化技术中最具代表性的Docker及其相关技术。

8.1 容器技术的演变过程

先简单回顾下容器技术的发展过程：

早期容器技术：如 Linux - VServer 和 OpenVZ 等，主要利用 Linux 内核的功能（如 namespace 和 cgroup），实现了一定程度的进程隔离和资源控制。然而，它们在易用性、可移植性和生态系统方面存在不足。
Docker 的诞生和发展：Docker 于 2013 年推出，它在早期容器技术的基础上进行了创新和优化。
- Docker 引入了容器镜像（Container Image）的概念，通过分层文件系统（UnionFS）将应用及其所有依赖打包成一个易于分发和部署的镜像，并且镜像内容以分层的方式存储，便于镜像的构建、更新和传输。
- Docker 还提供了简单易用的命令行工具和 API，使得开发人员和运维人员可以方便地管理容器。同时，Docker Hub 等容器镜像仓库的出现，使得容器镜像的分发和共享变得更加容易。
容器编排的兴起与成熟：随着容器技术的广泛应用，单个容器的管理已经不能满足复杂应用的需求。容器编排工具应运而生，其中 Kubernetes 是最具代表性的。Kubernetes 提供了一个强大的平台，用于管理多个容器组成的应用，包括容器的部署、扩展、更新、网络管理和存储管理等功能。

8.2 构成Docker的技术

Docker由Docker公司开发，是一款典型的容器管理开源软件，使用了Linux系的容器虚拟化技术。它借助了几个标准的Linux内核技术实现容器虚拟化：

Namespaces：实现资源隔离。借助PID（进程运行空间）、MNT（文件系统挂载点）、IPC（System VIPC 和 POSIX 消息队列）、NET（网络设备、协议栈和端口等）和UTS（主机名和域名）这五种命名空间，将用户的空间彼此隔离。
cgroups：实现进程隔离。负责控制经过分组的进程资源，包括cpu、cpuset、memory和device等。
Storage：支持可插拔（pluggable）存储驱动器。
Networking：借助veth（通过创建成对的网络设备来进行容器和主机间的通信）、bridge（通过实现虚拟网桥来进行容器间的通信）和iptables（决定是否允许容器间进行通信）等来控制容器内进程的网络通信。
Security：借助Capability（管理进程的特权）、SELinux（将容器内进程的行为控制在容器内）、seccomp（限制进程能够调用的系统调用）等来控制容器内的进程的行为。

从以上列举的Docker所使用的Linux内核技术可以发现，Docker只是结合主机上的Linux内核技术隔离了Linux主机上的进程，并没有像虚拟机管理程序那样，在主机和进程之间形成软件层。由于容器没有子操作系统，只是作为主机操作系统上的进程启动，所以启动速度更快。

Docker还可以将包含相关进程的容器制作成镜像，迁移到其他操作系统上的Docker环境中运行，这种高度可移植性也是Docker的特性之一。使用Docker实现的容器虚拟化技术能够使我们完全忽略其基础设施环境中的硬件层。

Docker的生命周期

我们可以通过命令行接口来管理Docker的整个生命周期。

存储Docker镜像的Docker仓库可以存储在多台主机上，Kubernetes和Docker Swarm等框架利用这个特性，用多台主机构成集群，使容器能够在集群中自由运行。通过Docker集群来充分发挥Docker容器的高可移植性，就可以更有效地利用多节点的资源。

容器集群功能

Docker容器本身只是一个进程，为了实现资源分配和多容器之间的协同，还需要结合容器集群功能。

容器集群的基本功能

容器集群功能为容器提供了资源管理的能力：

硬件资源聚合：容器集群将多个物理服务器（或虚拟机）的硬件资源（如 CPU、内存、存储和网络带宽）整合在一起，通过集群管理，这些资源被汇总成一个资源池。
为容器按需分配资源：在这个资源池中，容器可以根据需求分配资源。比如一个数据处理容器可能需要大量的 CPU 资源来进行快速计算，而一个数据库容器可能更需要大量的内存来缓存数据。容器集群能够动态地为这些容器分配和调整资源，以满足它们的运行需求。

此外，通过容器集群功能可以实现多容器部署，提升系统的可用性和资源利用率。

故障转移机制：在容器集群中，如果一个节点（物理服务器或虚拟机）出现故障，运行在该节点上的容器可以自动在其他健康节点上重新启动，从而保证服务的连续性。
多副本部署：通过部署多个容器副本，可以提高应用的可用性。例如，对于一个 Web 应用，在容器集群中可以部署多个相同的容器副本。当一个副本出现问题或者因为高负载响应缓慢时，其他副本可以继续处理用户请求，避免单点故障导致应用无法访问。
负载均衡：容器集群能够将外部请求均匀地分发到多个容器实例上，使整个集群的资源得到更合理的利用，从而提高整个应用的性能和响应速度。

容器编排功能

容器编排工具是用于自动化部署、管理、扩展和操作容器化应用程序的软件平台。它们协调多个容器的运行，确保容器之间的通信、资源分配、高可用性等诸多方面能够高效且稳定地进行，共同完成复杂的应用任务。

具有代表性的容器编排工具包括：

Kubernetes（K8S）：由谷歌公司于2014 年开源，广泛应用于各种规模的企业和云计算环境；
Docker Swarm：由Docker 公司推出的原生容器编排工具，作为 Docker 生态系统的一部分，为用户提供了相对简单直接的容器编排解决方案，易于上手，很适合中小规模的容器集群部署。
Apache Mesos：最初是由加州大学伯克利分校开发的集群管理器，后来成为 Apache 软件基金会的一个顶级项目。它的发展旨在解决大规模集群资源管理和分布式应用调度的问题，在大数据和混合工作负载的场景中应用广泛。

容器编排技术可以提供强大的多容器管理能力：

自动化容器部署：容器编排技术能够实现容器的自动化部署。以 Kubernetes 为例，通过定义部署文件（如 YAML 格式的 Deployment 配置文件），可以指定容器的数量、镜像版本、资源需求等信息。当应用更新或者新应用上线时，编排工具可以按照这个配置文件自动从镜像仓库拉取容器镜像，并将容器部署到集群中的合适节点上，大大减少了人工操作的复杂性和出错的概率。
智能调度策略：容器编排工具会根据节点的资源状态（如可用 CPU、内存、存储等）和容器的资源需求来调度容器。例如，有些调度策略会优先将容器部署到资源空闲较多的节点上，或者根据容器之间的亲和性和反亲和性来安排部署。如果两个容器需要频繁通信，编排工具可能会将它们调度到同一个节点或者相邻的节点上，以减少网络延迟；而对于一些需要避免单点故障的容器，会将它们分散部署到不同的节点上。
服务发现机制：在复杂的容器集群中，容器之间需要相互通信。容器编排技术提供了服务发现功能，使得容器可以方便地找到对方。例如，在 Kubernetes 中，通过创建 Service 对象，可以为一组具有相同功能的容器实例提供一个统一的服务名称。其他容器可以通过这个服务名称来访问这些容器，而不需要关心具体的容器 IP 地址和端口号。
管理容器的生命周期：容器编排技术可以有效管理从容器的创建、启动、运行中的监控，到容器的停止和删除的生命周期。还可以在容器删除后进行资源回收与清理，从而释放资源。

基于这些能力，容器编排技术在云中的在很多应用场景中发挥着重要作用：

蓝绿部署：
- 环境管理：容器编排工具可以方便地创建和管理蓝绿两个环境所需要的容器。并且在集群环境中，通过节点选择和亲和性/反亲和性配置，将蓝绿环境的容器分布在不同的节点上，实现蓝绿环境隔离。
- 蓝绿流量切换：在蓝绿部署的流量切换阶段，它可以与负载均衡器（如 Kubernetes 中的 Ingress）集成，通过滚动更新，实现流量的平滑切换。
- 监控和回滚：在蓝绿部署的整个过程中，容器编排工具可以对蓝绿环境中的容器进行持续监控。如果出现问题，可以使用旧容器镜像实现快速回滚。
多重云环境的管理：
- 跨云资源池化：容器编排功能可以将不同云服务提供商的计算资源（如 CPU、内存、存储）看作是一个统一的资源池。这样一来，就可以根据容器化应用的需求，灵活地从跨云资源池中分配资源，提高整体资源利用率。
- 跨云数据和服务交互：容器编排工具可以促进跨云环境的数据和服务交互。例如，在一个涉及多个云的供应链管理系统中，容器编排工具可以协调不同云环境中的数据存储容器（如 AWS 的 S3 和 Azure 的 Blob 存储）之间的数据传输，以及不同云环境中的微服务容器之间的通信。通过配置合适的网络策略和服务发现机制，使得跨云环境的各种数据和服务能够有效地协同工作，构建一个完整的、分布式的应用系统。
- 统一部署和管理：通过定义标准化的容器配置文件（如 Kubernetes 的 YAML 配置文件），可以在不同的云环境中以相同的方式部署容器化应用，实现统一部署流程。同时还可以对跨云环境的容器进行集中管理，包括容器的生命周期管理（如创建、启动、停止、删除）、版本更新和升级等操作。

容器编排与容器集群

通过容器编排工具可以轻松地实现容器集群。我们以 Kubernetes 和 Docker 为例，在 Kubernetes 集群中，Docker 作为容器运行时，负责实际创建和运行容器，而 Kubernetes 则负责调度、管理和协调这些容器。我们来看下它们是怎么工作的：

首先，容器编排工具通过节点管理与容器调度实现集群基础架构。

节点管理：Kubernetes 集群由多个节点组成，包括控制节点（Master Node）和工作节点（Worker Node）。在工作节点上可以运行 Docker 容器。例如，在构建一个 Kubernetes 集群时，可以在多个物理服务器或者虚拟机上安装 Docker 作为容器运行时，这些节点就构成了容器集群的物理基础。控制节点负责管理和调度容器在工作节点上的运行，它会根据工作节点的资源状况（如 CPU、内存、存储等）和容器的需求来分配任务。
容器调度：Kubernetes 使用调度器（Scheduler）来决定将容器部署到哪个工作节点上。调度器会考虑多种因素，如节点的资源可用性、容器的资源请求、亲和性和反亲和性等。例如，一个对 CPU 要求较高的数据分析容器可能会被调度到 CPU 资源较为充裕的工作节点上；如果有两个容器需要频繁通信，Kubernetes 可以将它们调度到同一个工作节点或者网络延迟较低的相邻节点上，以提高性能。这种智能调度机制是构建高效 Docker 容器集群的关键，它能够充分利用集群中的资源，避免资源浪费和单点过载。

然后，借助容器编排工具的能力可以为容器集群提供资源分配、负载均衡等强大的管理能力。

资源动态分配：Kubernetes 能够根据容器的实际运行情况动态地分配资源，从而提升整个 Docker 容器集群的资源利用效率。
服务发现机制：Kubernetes 通过创建 Service 对象来实现服务发现。对于运行在容器集群中的 Docker 容器所提供的服务，Service 可以提供一个稳定的访问入口，使得容器之间的通信变得更加简单和稳定。
负载均衡：Service 还具备负载均衡功能。当有外部请求访问这个 Service 时，Kubernetes 会根据定义的负载均衡策略将请求分配到对应的 Docker 容器所在的 Pod 中，从而提高了整个集群的服务能力和可用性。
容器生命周期管理：通过定义 Deployment 或者 Pod 等资源对象，指定容器的镜像、配置等信息，Kubernetes 会在集群中的合适节点上拉取 Docker 容器镜像，并启动容器。在容器运行过程中，Kubernetes 会持续监控容器的状态。如果容器出现故障（如进程崩溃、资源耗尽等），Kubernetes 会自动尝试重启容器或者在其他节点上重新创建容器，维护容器集群的稳定性。
平滑升级：当需要更新 Docker 容器（如更新容器镜像版本）时，Kubernetes 可以采用滚动更新等策略来实现平滑升级。在更新过程中，还可以通过设置更新策略来控制更新的速度、副本数量等参数，进一步提高集群的稳定性和可靠性。

此外，很多云供应商都把容器编排的能力集成到云中。比如AWS提供了支持Amazon EC2实例集群的EC2 Container Service（ECS），OpenStack也发布了Magnum项目来集成容器集群功能。使用ECS或Magnum时，用户可以将容器所实现的功能作为任务来管理，在管理过程中无需操作Docker的CLI，通过控制任务与集群的API即可管理系统。

小结

本章着重讲解了搭建云中的基础设施环境时的生命周期，介绍了不可变基础设施的理念。通过在云中搭建基础设施，我们可以按照业务的生命周期来管理基础设施环境，还可以利用容器虚拟化技术在不可变基础设施中实现独立于硬件层的生命周期。