本文讲的是不可变基础架构与容器，【编者的话】本文翻译自Tutum社区，在文章中，作者讲解了什么是immutable infrastructure、immutable infrastructure的优势，以及如何构建immutable infrastructure，并着重介绍了两种构建方式，突出了Tutum在构建应用程序容器过程中体现的优势。

很久以前，我在纽约参加了一场Docker见面会，在会上， Michael Bryze（Gilt的CTO）谈论了使用Docker过程中的不可变基础架构优势。有些人仍心存疑惑，但在Tutum，我们强力支持这个受益于容器崛起的model。

什么是“Immutable Infrastructure”?

当你向应用程序部署更新时，正常情况下，你会创建新的实例（存在于服务器或容器上），并删除旧的实例，而不是尝试去更新原有实例。一旦你的应用程序开始运行，就不要再动它。重复性、管理开销的减少、更易回滚等优势自然形成， 关于其优势，Chad Fowler、Michael DeHaan和Florian Motlik曾在在他们的文章中深入探讨过。

为了实现这些优势，你需要构建一个应用程序来满足下面这两个基本要求：

• 你的应用程序进程是无状态的。它们的状态要储存在一个服务中，这个要位于“immutable infrastructure”的范围之外（除了使用Volume的，并正在运行的容器，这个问题我们将会解决）
• 你要有一个模板或一组可以从头部署应用程序实例的指令。

第二个要求是关键，虽然有很多种实现方式，但容器就是为了满足这个要求而创建的。

使用配置管理软件

在这个model中，需要使用容器吗？从技术上讲，答案是否定的。但是，使用容器能带来的巨大的帮助。

在没有使用容器的情况下，通过部署新的虚拟机，你仍然可以获得不可变性。这个新的虚拟机中，可以使用新版本应用程序的VM模板（应用程序可以是自动化的），也可以通过使用像Chef或者Puppet这样的配置管理软件来进行配置。目标是从头开始部署新的应用程序实例，并且处理流量。

一旦完成这些，你就可以切换你的负载平衡器，从而开始发送请求，并终止旧的负载平衡器。采用这种model，在为本地应用程序升级而移除代码时，你的'recipes'复杂度就降低了。

但老实说，为每一个只能在特殊cloud provider上工作的应用程序版本创建VM模板，这不是理想的解决方案（即使可以自动化进行，这个过程仍然是麻烦的），并且对开发者来说，避免持续性地测试配置管理脚本是一种有经验的做法。

借助容器进行工作

为什么使用容器？因为，相较于对虚拟机进行快照处理，或者为配置服务器运行脚本，容器可以做到快速创建、测试以及部署。并且，一旦你的应用程序完成构建、测试以及标记。部署它将是一个非常高效的过程，因为你已经从等式中基本移除了底层操作系统的配置。

为最新的Vanilla OS，部署cloud provider的基础模板，通过以上步骤，你就可以将重任委托给你的cloud provider。如果打过补丁，并且为虚拟机（关于虚拟机，你不用在意具体细节，只要虚拟机运行Docker就可以）优化过，它甚至可以有更好的性能。

每次你想要推送新版本的应用程序时，容器也不再需要部署新的服务器。因为，所有的应用程序依赖项和逻辑已经内置在容器中，并且已经被它们的新版本替代了，你的服务器可以保持，并获得不可变基础架构model的优势，这可以显著地减少开发时间。

最重要的是，你仍可以受益于容器，例如，不会被任意cloud provider或者Linux发布版所限制（只要它们运行的是Docker），如果可以在本地工作，那么，它同样也可以在任意provider上工作。这不是我们梦寐以求的吗？

通过使用容器，如何使你的新版本部署工作自动化地进行呢？下面有两个主要的步骤：

• 构建你的新镜像。虽然有很多种构建应用程序镜像的方法（手动，或者使用配置管理软件等），但是，使用一个简单优化的Dockerfile是普遍的做法。在推送镜像前，你可以使用CI/CD平台进行测试。在生产部署时，要为镜像加上版本号标记，这有助于在必要时回滚应用程序。
• 部署你的新容器。你可以在新的，或者已经存在的服务器上部署（手动或自动）容器，并切换负载平衡器，向你新部署的容器发送流量。这可以是实例级别的（例如，在每台AWS EC2的实例上使用应用程序容器，以及动态负载均衡器），也可以是容器级别的（使用haproxy或者nginx服务器，转发流量到你的应用程序容器）。

在为应用程序使用多台主机和容器的情况下，如何使步骤2自动化地进行呢？那就使用Tutum。

借助Tutum进行工作

通过使用Tutum，部署新版本应用程序成了一个微不足道的任务。你只需要在服务定义上改变镜像标记，并点击重新部署就可以了。

在一个回滚到特定版本不是那么重要的非生产部署下，通过使用我们的
自动重新部署特性，或者与DockerHub相关的自动重新部署triggers，我们甚至可以使自动部署程序自动化地进行。

一旦自动部署程序开始工作，Tutum将会用新容器，一个接着一个地替代原有的旧容器。我们提供了一个tutum/haproxy镜像，这个镜像会根据它所处的容器进行自动配置。无论你是使用Docker links在本地部署，还是进入Tutum内部部署，当所连接的服务发生收缩或被重新部署等情况时，它都会自动化地重新调整它自己。

如果你想要并行地使用新容器与旧容器进行快速地回滚，你不需要一些和Asgard一样超级复杂的工具。

无论是部署一个使用新镜像标记的服务，还是从tutum/haproxy服务中增加一个链接。Tutum都将会检测到更改，并自动化地开始转发请求到新的服务和旧的服务。当你准备好切换时，你只需要终止旧的服务。默认情况下，tutum/haproxy会自动检测到死亡的应用程序容器，并再次发送请求到健康的容器。

要是开发者使用data volumes呢？我知道我刚才说过，这些应用程序需要是无状态的，但在Tutum中，volumes是跨部署的持久化存在，因此，如果你重新部署一个tutum/mysql容器（默认情况下，这种操作会为/var/lib/mysql创建一个data volume），Tutum将会重新使用这个Volume，并保留它的数据。

一旦你的容器开始运行，就不要去碰它！使用docker exec（或者Tutum的“terminal”特性）只能调试，并运行一次性管理任务，不要去改变你的应用程序代码！应用程序的改变应该在镜像和环境变量中完成，而不是正在运行的实例。

然后呢？

我们正在努力使从代码到部署的过程变得清晰明了，简单而有力。我们还有一些令人兴奋的新特性，这些特性会在接下来的几个礼拜内宣布。同时，我们听取社区的意见，并欢迎你的想法和观点。

原文链接：Immutable Infrastructure and Containers （翻译：洪国安 审校：魏小红）

============================================
译者介绍
洪国安，编程爱好者，目前是一名大三学生，希望通过帮社区翻译，提高自己的知识面。

原文发布时间为：2015-06-10

本文作者：Arthur

本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。

原文标题：不可变基础架构与容器