为什么要建立不可变的基础架构

今天，构建基础架构时的一些主要挑战是可预测性，可伸缩性和自动恢复。 可预测的系统将把您测试过的完全相同的工件提升到生产系统中，因此间歇性故障不会造成任何麻烦。 可扩展的系统使处理流量的增加变得微不足道，尤其是自动进行。 而自动恢复将确保您的团队可以专注于开发更好的产品并在夜间保持睡眠状态，而无需持续维护基础架构。

在Codeship，我们发现由不可变组件组成的基础架构极大地帮助了我们实现这些目标。

Chef的朱利安·邓恩（Julian Dunn）最近发布了一篇博客文章，介绍了他们对不变基础架构的立场。

查德·福勒（Chad Fowler）在推文中总结得很好：

@flomotlik IMO很弱。 它融合了“容器化”和“不可变的基础设施”，然后竖起“不可变”的严格定义

—查德·福勒（@chadfowler） 2014年6月30日

我不想介绍本文的每一部分，而是要概述我们以及其他人在使我们的基础架构部分不可变方面所拥有的经验。

什么是不可变基础架构

不可变的基础结构由不可变的组件组成，这些组件将为每个部署替换，而不是就地更新。 这些组件从一个通用映像开始，该映像在每次部署中都会构建一次，并且可以进行测试和验证。 通用映像可以通过自动化来构建，但不是必须如此。 不变性独立于构建图像的任何工具或工作流程。

其最佳用例是在云或虚拟环境中。 尽管在非虚拟化环境中有可能，但是收益并没有超过努力。

状态隔离

正如Chef博客文章所述，对不可变基础架构的主要批评是，系统中始终存在状态，因此，整个系统并非不可变。 这错过了不变组件的意义。 谈到不可变基础架构中的状态时，其主要优势在于它是孤岛。 清楚地绘出了存储状态的层与短暂层之间的边界，并且在这些层之间可能不会发生泄漏。 当您无法期望状态在下一分钟启动并运行时，根本无法将状态混合到不同的组件中。

原子部署和验证

更新现有服务器很容易产生意想不到的后果。 这就是存在Chef，Puppet，CFEngine或其他此类工具的原因-要确保整个基础架构的一致性。 需要一个中央系统来管理每个服务器的预期状态并采取措施以确保合规性。 部署不是原子动作，而是可能出错并导致未知状态的过渡。 由于很难知道您所处的确切状态，因此调试起来非常困难且复杂。 Chef，Puppet或CFEngine是非常复杂的系统，因为它们必须处理一个过于复杂的问题。

解决该问题的另一种方法是在每次部署时都构建包含应用程序和环境的全新映像和服务器。 在这种情况下，部署不取决于服务器之前的状态，因此结果更可预测和可重复。 可以通过验证新映像并确保不影响生产系统来捕获可能导致部署失败的任何第三方问题。 例如，通过更改负载平衡器，该镜像可用于启动任意数量的服务器，并从旧计算机自动切换到新计算机。

当然，每次部署都需要重建映像。 完全重建系统要比单纯更新和重新启动应用程序花费更多的时间。 通过对部署进行分层，您可以优化此部署，例如，拥有一个存储库来构建基础映像，并使用该基础映像将其放入部署映像中的应用程序中，但这仍然是一个较慢的过程。

另一个问题是您在部署期间将依赖项引入了第三方。 如果您在系统中安装软件包，并且apt储存库速度太慢或速度较慢，则可能导致部署失败。 虽然这在不可改变的基础架构中可能也是一个问题，但是当您将新代码推送到已配置的系统中时，通常与第三方系统的交互较少。

通过从预先配置的基础映像进行部署并定期更新该基础映像，可以缓解该问题，但是问题仍然存在，并且可能会不时导致部署失败。

当前，在项目开始时构建自动化仍然需要花费更多时间，因为构建不变基础架构的工具仍然是新的或需要开发的。 一开始肯定是更多的投资，但会立即得到回报。

您仍然可以使用Chef，Puppet，CFEngine或Ansible来构建图像，但是由于它们不是为不可变的基础结构工作流而构建的，因此它们往往比所需的更为复杂。

通过保留历史记录快速恢复

由于所有部署都是通过构建新映像来完成的，因此会自动保留历史记录，以便在必要时进行回滚。 可以使用与部署下一个版本相同的过程和自动化来回滚，以确保回滚的过程能够正常进行。 通过自动创建映像，您甚至可以重新创建历史映像，并从基础架构历史中的较早分支分支。

数据模式更改是一个潜在的问题，但这是回滚的普遍问题。 向后兼容性和零停机时间部署是确保无论更改如何都可以正常运行的方法。

简单实验

当您控制整个环境和应用程序时，使用新版本的语言，操作系统或依赖项进行的任何实验都很容易。 有了严格的测试和验证，并在必要时进行了回滚，消除了升级任何依赖项的所有担心。 实验成为构建基础架构不可或缺的重要部分。

使您可以在中央位置收集日志和指标

有了不变的组件，就很容易杀死行为异常的服务器。 虽然错误通常只是环境的产物，例如第三方系统的行为异常，可以忽略，但有些错误还会继续出现。 没有访问服务器的权限，会激发团队正确的动机来从外部收集和存储日志和系统指标。 这样，可以在服务器长时间不运行时进行调试。

如果缺少日志和指标来正确调试问题，则可以轻松地向基础架构添加更多数据收集并替换所有现有服务器。 然后，一旦错误再次出现，您可以从外部系统上存储的数据中完全对其进行调试。

结论

作为基础架构一部分的不可变组件是一种减少基础架构不一致并增强对部署过程的信任的方法。 原子部署与图像验证和轻松回滚相结合，使基础架构的管理变得更加容易。

它迫使团队隔离数据，并预期在基于云基础架构或一般系统构建时固有的故障。 这样可以提高适应能力，并在整个过程中训练您应对任何问题，尤其是以自动化的方式。 此外，它有助于构建易于部署和扩展的简单且独立的组件。

这不是一个理论上的想法。 在Codeship ，我们以这种方式构建基础架构已有很长时间了。 Heroku和其他PaaS提供商都是作为不可变组件构建的，许多公司（无论大小）都将不可变性作为其基础架构的核心概念。

诸如Packer之类的工具使构建不变组件变得非常容易。 与现有的云基础架构一起，它们是一个强大的概念，可帮助您构建更好，更安全的基础架构。 如果您有任何问题或需要分享的有趣见解，请在评论中让我知道。

翻译自: https://www.javacodegeeks.com/2014/07/why-you-should-build-an-immutable-infrastructure.html