什么是不可变的基础设施?

介绍

在传统的可变服务器基础架构中,服务器会不断更新和修改。使用此类基础架构的工程师和管理员可以通过SSH连接到他们的服务器,手动升级或降级软件包,逐个服务器地调整配置文件,以及将新代码直接部署到现有服务器上。换句话说,这些服务器是可变的; 它们可以在创建后进行更改。由可变服务器组成的基础设施本身可称为可变,传统或(贬低)手工艺。

一个不变的基础设施是另一个基础设施范例,他们部署了服务器之后决不会被修改。如果需要以任何方式更新,修复或修改某些内容,则会根据具有相应更改的公共映像构建新服务器以替换旧服务器。经过验证后,它们就会投入使用,而旧的则会退役。

不可变基础架构的好处包括基础架构中更高的一致性和可靠性,以及更简单,更可预测的部署过程。它可以缓解或完全防止可变基础架构中常见的问题,例如配置漂移和雪花服务器。但是,有效地使用它通常包括全面的部署自动化,云计算环境中的快速服务器配置,以及处理状态或短暂数据(如日志)的解决方案。

本文的其余部分将:

  • 解释可变和不可变基础架构之间的概念和实际差异
  • 描述使用不可变基础架构的优势并将复杂性置于语境中
  • 概述不可变基础架构的实现细节和必要组件

可变和不可变基础设施之间的差异

可变基础和不可变基础设施之间最根本的区别在于它们的核心政策:前者的组件旨在在部署后进行更改; 后者的组成部分旨在保持不变并最终被替换。本教程将这些组件作为服务器,但是还有其他方法可以实现不可变的基础结构,例如容器,它们应用相同的高级概念。

为了更深入,基于服务器的可变基础架构和不可变基础架构之间存在实际和概念上的差异。

从概念上讲,这两种基础设施在如何处理服务器(例如创建,维护,更新,销毁)方面的差异很大。这通常用“宠物与牛”类比来说明。

实际上,可变基础架构是一种更老的基础架构范例,它早于核心技术,如虚拟化和云计算,使不可变的基础架构成为可能和实用的。了解这段历史有助于将两者之间的概念差异以及在现代基础设施中使用其中一个或另一个的含义进行背景化。

接下来的两节将更详细地讨论这些差异。

实际差异:拥抱云

在虚拟化和云计算成为可能并且广泛可用之前,服务器基础架构以物理服务器为中心。这些物理服务器创建起来既昂贵又耗时; 初始设置可能需要数天或数周,因为订购新硬件,配置机器,然后将其安装在colo或类似位置需要多长时间。

可变基础设施起源于此。由于更换服务器的成本非常高,因此尽可能在尽可能短的停机时间内尽可能长时间地使用您运行的服务器是最实际的。这意味着对于常规部署和更新有很多适当的更改,但对于出现问题时的临时修复,调整和补丁也是如此。频繁手动更改的结果是服务器变得难以复制,使每个服务器成为整个基础架构中独特且易碎的组件。

虚拟化和按需/云计算的到来表示服务器体系结构的一个转折点。虚拟服务器虽然规模较小,但成本较低,可以在几分钟而不是几天或几周内创建和销毁。这使得新部署工作流和服务器管理技术首次成为可能,例如使用配置管理或云API快速的,程序化的并且自动的配置新服务器。创建新虚拟服务器的速度和低成本使得不变性原则变得切实可行。

传统的可变基础设施最初是在使用物理服务器决定其管理可行性时开发的,并且随着技术的不断改进而不断发展。在部署之后修改服务器的范例在现代基础设施中仍然很常见。相比之下,不可变基础架构从一开始就设计为依赖基于虚拟化的技术来快速配置架构组件,如云计算的虚拟服务器。

概念差异:Pets与Cattle,Snowflakes与Phoenixes

云计算先进的基本概念变化是服务器可以被认为是一次性的。考虑丢弃和更换物理服务器是非常不切实际的,但使用虚拟服务器,这样做不仅可行而且简单有效。

传统可变基础架构中的服务器是不可替代的,独特的系统必须始终保持运行。通过这种方式,它们就像pets一样:独一无二,无法模仿,并且倾向于手工制作。失去一个可能是毁灭性的。另一方面,不可变基础架构中的服务器是一次性的,易于复制或使用自动化工具进行扩展。通过这种方式,他们就像cattle一样:牛群中的众多群体中没有一个人是独一无二或不可或缺的。

引用Randy Bias,他首先将宠物与牛类比应用于云计算:

在旧的做事方式中,我们将服务器视为宠物,例如Bob是一个邮件服务器。如果Bob损坏了,那就全都要靠手动的了。那么首席执行官也就无法收到他的电子邮件了,这无异于是世界末日。但如果以新的方式,服务器会被编号,就像牛群中的牛一样。例如,www001到www100。当一台服务器发生故障时,它会被取回,射击并在线路上更换。

另一种类似的方式来说明服务器处理方式之间差异的含义是雪花服务器和凤凰服务器的概念。

snowflakes服务器类似于宠物。它们是手工管理的服务器,经常更新和调整到位,从而形成独特的环境。Phoenix服务器与牛类似。它们是始终从头开始构建的服务器,并且易于通过自动化过程重新创建(或“从灰烬中升起”)。

不可变的基础设施几乎完全由牛或凤凰服务器制成,而可变基础设施允许一些(或许多)pets或snowflakes服务器。下一节将讨论两者的含义。

不可变基础设施的优势

要了解不可变基础架构的优势,有必要将可变基础架构的缺点置于语境中。

可变基础架构中的服务器可能会受到配置偏差的影响,这种情况在未记录的情况下,即兴更改会导致服务器的配置变得越来越不同,并且与审核,批准和最初部署的配置之间的配置越来越不同。这些越来越像雪花的服务器难以重现和替换,使得缩放和恢复问题变得困难。即使复制问题来调试它们也会变得具有挑战性,因为创建与生产环境匹配的临时环境很困难。

在许多手动修改之后,服务器的不同配置的重要性或必要性变得不清楚,因此更新或更改任何配置可能会产生意想不到的副作用。即使在最好的情况下,也不能保证对现有系统进行更改,这意味着依赖于这样做的部署可能会导致失败或将服务器置于未知状态。

考虑到这一点,使用不可变基础架构的主要好处是部署简单性,可靠性和一致性,所有这些最终可以最大限度地减少或消除许多常见的痛点和故障点。

已知良好的服务器状态和较少的部署失败

不可变基础架构中的所有部署都是通过基于经过验证和版本控制的映像配置新服务器来执行的。因此,这些部署不依赖于服务器的先前状态,因此不会失败 - 或者只是部分完成 - 因为它。

配置新服务器时,可以在投入使用之前对其进行测试,将实际部署过程减少到单个更新,以使新服务器可用,例如更新负载均衡器。换句话说,部署变为原子:要么成功完成,要么没有任何变化。

这使得部署更加可靠,并且还确保始终知道基础结构中每个服务器的状态。此外,此过程可以轻松实现蓝绿色部署或滚动版本,这意味着无需停机。

没有配置drift或snowflake服务器

通过使用文档检查更新的映像到版本控制并使用自动,统一的部署过程来部署具有该映像的替换服务器来实现不可变基础结构中的所有配置更改。Shell访问服务器有时完全受限制。

通过消除雪花服务器和配置漂移的风险,这可以防止复杂或难以重现的设置。这还可以防止有人需要修改一个知之甚少的生产服务器,这种生产服务器存在高错误风险并导致停机或意外行为。

一致的登台环境和轻松的水平扩展

由于所有服务器都使用相同的创建过程,因此没有部署边缘情况。通过简化复制生产环境,可以防止混乱或不一致的登台环境,并通过无缝地允许您向基础架构添加更多相同的服务器来简化水平扩展

简单的回滚和恢复过程

使用版本控制来保留图像历史记录也有助于处理生产问题。用于部署新映像的相同过程也可用于回滚到旧版本,在处理停机时添加额外的弹性并缩短恢复时间。

不可变基础设施实施细节

不可变的基础架构在其实现细节方面有一些要求和细微差别,特别是与传统的可变基础架构相比。

通过简单地遵循不变性的关键原则,技术上可以实现独立于任何自动化,工具或软件设计原则的不可变基础设施。但是,强烈建议使用以下组件(大致按优先顺序)以实现大规模实用性:

  • 云计算环境中的服务器,或其他虚拟化环境(如容器,但会改变下面的一些其他要求)。这里的关键是通过自定义映像快速配置隔离实例,以及通过API或类似工具创建和销毁的自动化管理。
  • 整个部署管道的完全自动化,理想情况下包括创建后的图像验证。设置此自动化会显着增加实施此基础架构的前期成本,但这是一次性成本,可以快速摊销。
  • 一个面向服务的架构,基础架构分离成通过网络通信模块,逻辑上独立的单位。这使您可以充分利用云计算的产品,这些产品同样面向服务(例如IaaS,PaaS)。
  • 一个无状态的,挥发性应用层,其中包括您不可改变的服务器。这里的任何东西都可以在任何时候(易变)快速销毁和重建,而不会丢失任何数据(无状态)。
  • 一个持久数据层,其包括:
    • 集中式日志记录,包含有关服务器部署的其他详细信息,例如通过版本或Git提交SHA进行映像识别。由于服务器在此基础结构中是一次性的(并且经常处理),因此即使在限制shell访问或服务器被销毁之后,外部存储日志和指标也允许调试。
    • 数据库和任何其他有状态或短暂数据的外部数据存储,如DBaaS /云数据库对象或块存储(云提供或自我管理)。当服务器易变时,您不能依赖本地存储,因此您需要将该数据存储在其他位置。
  • 工程和运营团队致力于协作并致力于该方法。对于最终产品的所有简单性,在不可变的基础架构中有许多移动部件,没有人会知道所有这些部件。此外,在此基础架构中工作的某些方面可能是新的或在人们的舒适区之外,例如调试或在没有shell访问的情况下执行一次性任务。

有许多不同的方法来实现这些组件。选择一个主要取决于个人偏好和熟悉程度,以及您希望自己构建多少基础架构而不是依赖付费服务。

CI / CD工具可以成为部署管道自动化的好地方; Compose是DBaaS解决方案的一个选项; rsyslog和ELK是集中式日志记录的流行选择; Netflix's Chaos Monkey在你的生产环境中随机杀死服务器,对你的最终设置来说是一次真正的试验。

结论

本文介绍了不可变基础架构,它与旧式可变基础架构之间的概念和实际差异,使用它的优势以及实现的详细信息。

知道是否或何时应该考虑迁移到不可变的基础设施可能很困难,并且没有明确定义的截止点或拐点。一种方法是实现本文中推荐的一些设计实践,例如配置管理,即使您仍然在很大程度上可变的环境中工作。这将在未来更容易过渡到不变性。

如果您的基础架构包含上述大多数组件,并且您发现自己遇到了扩展问题或者对部署过程的笨拙感到沮丧,那么现在可以开始评估不变性如何改善您的基础架构。

您可以从几家公司(包括CodeshipChefKoddiFugue)那里了解更多有关其不可变基础架构实施的文章。

更多Linux教程请前往腾讯云+社区学习更多知识。


参考文献:《 What Is Immutable Infrastructure?》

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏张善友的专栏

让应用程序与您形影相随-PortableApps.com

作为一名 IT 专业人员,您可能会经常需要从一台计算机移到另一台计算机。当您这样做时,您可能会希望能拥有一组随时可用的标准应用程序、工具和文档。满足这些需求的一...

22350
来自专栏智能计算时代

「云计算」什么是不可变的基础设施?

在传统的可变服务器基础架构中,服务器会不断更新和修改。使用此类基础架构的工程师和管理员可以通过SSH连接到他们的服务器,手动升级或降级软件包,逐个服务器地调整配...

16730
来自专栏北京马哥教育

Python爬虫爬取知乎小结

最近学习了一点网络爬虫,并实现了使用Python来爬取知乎的一些功能,这里做一个小的总结。网络爬虫是指通过一定的规则自动的从网上抓取一些信息的程序或脚本。我们知...

29540
来自专栏魏琼东

AgileEAS.NET平台开发实例-药店系统-快速的SAAS开发体验

一、AgileEAS.NET应用开发简介 在4月份,callhot写过一系列的有关于AgileEAS.NET平台的开发应用的系列AgileEAS.NET平台开发...

27160
来自专栏Flutter入门到实战

开发工具总结(9)之开源项目的README文档的最全最规范写法

版权声明:本文为博主原创文章,未经博主允许不得转载。https://www.jianshu.com/p/813b70d5b0de

12410
来自专栏Android机动车

Android模块化开发方案

随着业务的不断发展壮大,移动端所承担的功能也越来越重,特别是代码几易其主之后开始变得杂乱无章,牵一发而动全局的事情时常发生。为了应对团队壮大之后的开发模式,我们...

17020
来自专栏Seebug漏洞平台

Sebug 大牛支招之我是如何在Sebug中杀入前10的?

大家好我是koshell,ID:k0sh1, 在之前的文章中我分享了在web漏洞挖掘中的一些小技巧,这里要补充一下。 注入其实只是众多web入侵手段中的一种,脱...

39370
来自专栏杨平安的专栏

微信 PaxosStore:海量数据冷热分级架构

导语 本文整理自笔者在“腾讯大讲堂”的演讲。 作者介绍:杨平安,来自广州的微信事业群,在腾讯已经工作五年。 主要分享内容: 为何公司卓越研发金奖花落PaxosS...

2.3K90
来自专栏Java技术分享

谈谈MVC模式

1. 如何设计一个程序的结构,这是一门专门的学问,叫做"架构模式"(architectural pattern),属于编程的方法论。 MVC模式就是架构模式的一...

22070
来自专栏Golang语言社区

求取一份极致的简单:全链路跟踪中间件探索之路

公司内部的业务系统有近千个,基本上很少有比较孤立的;尤其外部系统,即便用户在页面上一个很普通的操作,后台也需要少则几个多则几十个服务协同完成。以前我们定位调用链...

15010

扫码关注云+社区

领取腾讯云代金券