浏览我曾经构建的最佳基础架构，其中包括架构，灾难恢复，配置管理，业务流程和安全性方面的知识。
在初创公司工作有很多优点和缺点，但是与传统公司相比，主要优点之一是，初创公司通常会为您提供从头开始构建全新基础架构的机会。当您在一家成熟的公司中从事新项目时，通常必须考虑到遗留系统和为您做出的设计选择，而这通常是在您到达公司之前进行的。但是在初创企业中，通常会给您带来真正的空白：没有预先存在的基础架构，也没有可以考虑的现有设计选择。
如果您是系统架构师，那么全新的，从零开始的基础结构将是一个极具吸引力的前景。高级系统管理员和架构师级别之间的区别之一是，您已经在高级级别上运行了足够长的时间，以至于您亲自管理了多个不同的高级项目，并且了解了哪种方法有效，哪些方法无效。 t。当您处于此级别时，能够根据您从过去的努力中学到的所有经验从头开始构建全新的基础结构而无需支持任何旧式基础结构，这将是非常令人兴奋的。
在过去的十年中，我曾在几家不同的初创公司工作，他们被要求从头开始完全开发新的基础架构，但具有很高的安全性，正常运行时间和合规性要求，因此没有像以往通常面临的那样为提高速度而偷工减料在启动时。我不仅意识到设计新基础架构的乐趣，而且还能够多次做到这一点。每次，我都能带来过去所有可行的设计，抛弃那些无效的设计，并更新所有工具以利用新功能。这一系列的基础架构设计最终使我意识到，回顾它是我最喜欢的基础架构，我将以此为基础来判断未来的所有尝试。
在本文中，我将深入探讨我最喜欢的基础架构的一些细节。我描述了围绕设计的一些约束条件，并探讨了基础架构的各个部分如何组合在一起，为什么要做出自己的设计决策以及它们如何工作。我并不是说对我有用的对您有用，但希望您能从我的方法中得到启发，并使其适应您的需求。
约束条件
每当您描述一个您认为效果很好的解决方案时，在设计约束上加头就很重要。人们通常在寻找基础设施线索时，他们首先想到的是“大型科技公司”如何做到这一点。这种方法的问题在于，除非您也是一家大型科技公司（即使您也是），否则您的约束可能与约束完全不同。除非您非常喜欢他们，否则他们的预算，人力资源以及他们试图解决的问题可能无法为您服务。
同样，组织规模越大，则更有可能在内部解决问题而不是使用现成的解决方案。科技公司的成长处于某个阶段，当它拥有足够的开发人员时，当它有新的问题要解决时，它很可能会使用其开发人员的队伍为自己创建定制的专有工具，而不是使用现成的东西-即使使用现成的解决方案也可以使公司达到90％的水平。真可惜，因为如果所有这些大型高科技公司都将精力投入到改进现有工具和共享变更中，那么我们所有人都将花费更少的时间来重新发明轮子。如果您曾经采访过在大型高科技公司工作了很长时间的人，您会很快意识到他们在管理该特定基础架构方面确实训练有素，
创业约束也与大公司约束有很大不同，因此将适用于小型创业公司的解决方案应用于大型公司可能同样是一个错误。初创企业通常只有很小的团队，但也需要非常快地建立基础架构。误入生产的错误通常对初创公司的影响很小。他们最担心的是要在没有钱的情况下拿出某种功能性产品来吸引更多投资。这意味着，初创企业更有可能不仅赞成现成的解决方案，而且也倾向于偷工减料。
就是说，在您的限制下，对我有用的东西可能对您不起作用。因此，在我深入探讨细节之前，您应该了解我所受的限制。
约束1：种子轮融资启动
该基础结构是为正在金融领域开发Web应用程序的初创公司而构建的。在可用于构建基础架构的时间以及可用于构建基础架构的团队规模方面，我们都有局限性。在许多情况下，有单人团队。在构建理想基础架构的先前迭代中，我有一个至少由一个人（如果不是多个人）组成的团队来帮助我构建基础架构，但是在这里我是一个人。
时间限制加上我一个人做的事实，这意味着我更有可能选择使用我熟悉的技术在过去对我有用的稳定解决方案。我特别强调自动化，因此可以加倍努力。如果以正确的方式使用配置管理和业务流程，则可以建立一种动力。
约束2：非系统管理员紧急升级
我不仅要自己建立基础架构，而且要在管理紧急情况时全靠我自己。通常，我会尝试遵守将生产访问权限限制为系统管理员的规则，但是在这种情况下，这意味着如果我不可用，我们将不会有冗余。这种限制意味着，如果由于任何原因无法使用我，则需要将警报升级为主要具有开发人员背景并且仅具有一定Linux服务器经验的人员。因此，我必须确保响应最常见的紧急事件类型相对简单。
约束3：PCI合规性
我喜欢从零开始的基础架构开发与在严格的安全约束下阻止您偷工减料的初创公司一起进行的工作。安全领域中的许多人对PCI合规性都不太看好，因为如此多的公司将其视为检查和雇用以最小的麻烦检查该框而闻名的公司的框。但是，如果您将PCI-DSS视为诚实地管理的最低安全标准，而不是可以绕过的最高安全标准，则PCI-DSS中有许多良好的做法。我们非常依赖于PCI合规性，因此，满足并超过该政策会对设计产生一些最大的影响。
约束4：Custom Rails Web应用程序
开发团队在Rails方面具有很强的背景，因此大多数内部软件开发都是针对基于标准数据库支持的Rails应用程序堆栈的自定义中间件应用程序。存在许多用于包装和分发此类应用程序的不同方法，因此这也是设计的因素。
约束5：最小的供应商锁定
对于风险资本支持的初创公司来说，从云提供商那里获得信贷以帮助他们入门是很常见的。它不仅可以帮助初创企业在试图确定其基础设施时管理成本，而且还可以帮助初创企业设法使用特定于云的功能，这具有使初创企业更难转移至其他提供商的好处。一旦他们有更大的云账单，道路上。
我们的初创公司拥有不止一个云提供商的信用额，因此我们希望选择切换到另一家提供商，以防万一我们用完信用额度后资金短缺。这意味着我们必须为可移植性设计基础架构，并使用尽可能少的特定于云的功能。我们确实使用过的特定于云的功能需要进行抽象并易于识别，因此以后我们可以更轻松地将其移植到其他提供商。
建筑
PCI策略非常关注管理敏感持卡人数据的系统。这些系统被标记为“作用域”，这意味着它们必须符合PCI-DSS标准。此范围扩展到与这些敏感系统进行交互的系统，并且特别强调隔离-将范围内的系统与其余系统隔离和隔离，因此您可以对其网络访问进行严格控制，包括管理员可以访问它们以及如何访问它们。
我们的架构始于开发和生产环境之间的严格隔离。在传统的数据中心中，您可以通过使用单独的物理网络和服务器设备（或使用抽象来虚拟化分隔）来实现。对于云提供商，最简单，最安全和最可移植的方法之一是为每个环境使用完全独立的帐户。这样，就不会存在配置错误将生产暴露给开发的风险，并且它具有使易于计算每个环境每月要花费多少成本的附带好处。
对于实际的服务器体系结构，我们将服务器划分为各个角色，并为它们提供基于角色的通用名称。然后，我们利用Amazon Web Services中的虚拟私有云功能将这些角色中的每一个隔离到其自己的子网中，因此我们可以将每种服务器与其他服务器隔离开来，并严格控制它们之间的访问。
默认情况下，虚拟私有云服务器位于DMZ中并且具有公共IP地址，或者仅具有内部地址。我们选择在DMZ中放置尽可能少的服务器，因此环境中的大多数服务器只有一个专用IP地址。我们有意未设置将所有这些服务器的流量都路由到Internet的网关服务器-它们与Internet隔离是一个功能！
当然，某些内部服务器确实需要一些Internet访问。对于那些服务器，只需要与少量外部Web服务进行通信。我们在DMZ中设置了一系列HTTP代理，它们处理不同的用例并具有严格的白名单。这样，我们可以将来自主机外部的Internet访问限制为仅需要的站点，而不必担心收集特定服务的IP阻止列表（特别是如今，由于每个人都在使用云服务器，因此具有挑战性）。
容错能力
云服务通常是不可靠的，但是至关重要的是，我们的服务可以在任何一台特定服务器上进行扩展并在出现故障时幸免。我们从为每个服务使用最少三台服务器开始，因为为两个系统设计的容错系统往往会落入传统的主/故障转移体系结构中，而这种体系结构无法很好地扩展到两个之后。可以占三台服务器的设计可能也可以容纳四，六个或更多。
云系统依靠虚拟化来充分利用裸机，因此您使用的任何服务器都不是真正的物理机，而是某种在物理硬件上与其他虚拟机一起运行的虚拟机。这就带来了容错问题：如果所有冗余虚拟机最终都位于同一台物理计算机上并且该计算机发生故障，会发生什么情况？
为了解决此问题，一些云供应商将一个特定站点划分为多个独立的数据中心，每个数据中心都有自己的硬件，电源和网络，这些硬件，电源和网络彼此独立。在亚马逊的情况下，这些称为可用区，这是在可用区中分布冗余服务器的最佳实践。我们决定设置三个可用区，并在其中划分冗余服务器。
在我们的案例中，我们希望一致且自动地分布服务器，因此我们根据服务器主机名末尾的数字将服务器分为三部分。我们用来生成实例的软件将查看主机名中的数字，对其应用模三，然后使用该软件确定主机将进入哪个可用区。像web1，web4和web7之类的主机将位于一个组中。web2，web5和web8在另一个中；以及第三个区域中的web3，web6和web9。
当您有多台服务器时，如果一台服务器发生故障，您还需要某种方式将计算机故障转移到另一台服务器上。一些云提供商提供内部负载平衡，但是由于我们需要可移植性，因此我们不想依赖任何特定于云的功能。尽管我们可以在应用程序中添加自定义负载平衡逻辑，但是我们还是使用了一种更通用的方法，即使用轻量级且快速的HAProxy服务。
使用HAProxy的一种方法是设置一个运行HAProxy的负载平衡服务器，并让应用程序在各个端口上与其进行通信。这的行为很像某些云提供的负载平衡服务（或传统数据中心中的负载平衡设备）。当然，如果使用该方法，则会遇到另一个问题：当负载均衡器发生故障时会发生什么？为了实现真正的容错能力，您需要设置多个负载均衡器，然后使用自己的负载均衡逻辑配置主机，以便它们在出现故障时可以故障转移到冗余负载均衡器，或者以其他方式依靠传统负载均衡器。具有浮动IP的主/辅助负载平衡器故障转移，该IP将分配给活动的负载平衡器。
这种传统方法对我们不起作用，因为我们意识到，在某些情况下，可能会将整个可用区与网络的其余部分隔离开来。我们也不想添加其他故障转移逻辑来解决负载均衡器中断的问题。相反，我们意识到，由于HAProxy非常轻巧（特别是与服务器上的常规应用程序相比），因此我们可以将HAProxy实例嵌入到需要与另一服务进行冗余通信的每台服务器上。该HAProxy实例将知道本地服务器需要与之对话的任何下游服务，并在代表每个下游服务的localhost上显示端口。
这实际上是这样工作的：如果webappA需要与MiddlewareB进行对话，则它将仅连接到本地主机端口8001。HAProxy将负责对下游服务的运行状况检查，并且如果一个服务出现故障，它将自动连接到另一个服务。在这种情况下，webappA可能会发现其连接已断开，只需要重新连接即可。这意味着我们的应用程序唯一需要的容错逻辑是能够检测何时断开连接并重试。
我们还组织了HAProxy配置，以便每个主机都喜欢与自己的可用区中的主机进行通信。其他区域中的主机在HAProxy中被指定为“备份”主机，因此仅当主主机关闭时，它才会使用这些主机。这有助于优化网络流量，因为它停留在正常情况下开始的可用区域之内。这也使分析通过网络的流量变得更加容易，因为我们可以假设通过frontend2进入的流量将定向到中间件2，后者将访问数据库2。由于我们确保进入网络的流量是在前端服务器之间分配的，因此可以确保负载相对均匀地分配，但是在特定请求中，各个连接往往会停留在同一组服务器上。
最后，我们需要将灾难恢复纳入我们的计划。为此，我们在与生产完全分开的地理区域中创建了一个完整的灾难恢复环境，否则将模拟生产中的服务器和配置。根据恢复时间线，我们可以避免每隔几个小时同步数据库，并且由于这些环境彼此独立，因此我们可以测试灾难恢复过程而不会影响生产。
配置管理
在此基础架构中最重要的事情之一就是配置管理。因为我主要是自己构建和维护一切，并且时间紧迫，所以我首先关注的重点是使用Puppet进行配置管理的坚实基础。从Puppet成为今天的成熟而强大的产品开始的几年中，我一直在使用Puppet上有很多经验。但是今天，我可以利用Puppet社区为常见任务编写的所有高质量模块来抢先一步。当主要的Puppetlabs模块完成我已经需要的一切时，为什么要重新发明nginx配置？这种方法的关键之一是确保我们从基本的香草映像开始，上面没有任何自定义配置，然后对其进行设置，以使将香草服务器变成例如中间件应用程序服务器的所有配置更改都是通过Puppet完成的。
我选择Puppet的另一个关键原因正是由于许多人避免使用Puppet：Puppetmaster可以使用TLS证书对Puppet客户端进行签名。许多人在尝试设置Puppetmasters来签署客户端并选择无主设置时遇到了很大的障碍。在我的用例中，我会错过很多机会。我有一个严格的要求，即使用TLS保护云网络上的所有通信，并且通过让Puppetmaster对主机进行签名，我将获得一个受信任的本地证书颁发机构（Puppetmaster），并且我的每台主机上都必须具有有效的本地和签名证书网络免费！
许多人在启用Puppet客户端上的自动签名时会面对漏洞，但是必须手动签名新的Puppet客户端（尤其是在云实例中）可能很麻烦。我利用了Puppet中的一项功能，该功能可让您将自定义有效标头添加到Puppet客户端将生成的证书签名请求（CSR）中。我使用了一个特殊的x509标头，该标头旨在将预共享的密钥嵌入到CSR中。然后，我使用Puppet的功能来指定自定义自动签名脚本。然后，此脚本通过客户端CSR并决定是否对其进行签名。在我的脚本中，我们检查了CSR中的客户名称和预共享密钥。如果它们与Puppetmaster上该主机名/预共享密钥对的副本中的值匹配，则我们对其进行签名；否则，我们没有。
该方法之所以有效，是因为我们从Puppetmaster本身中产生了新主机。生成主机时，生成脚本将生成一个随机值，并将其作为预共享密钥存储在Puppet客户端的配置中。它还会将该值的副本存储在以客户端主机名命名的本地文件中，以供Puppetmaster自动签名脚本读取。由于每个预共享密钥都是唯一的，并且仅用于特定主机，因此一旦使用，我们便删除了该文件。
为了使在每台服务器上配置TLS变得简单，我添加了一个简单的内部Puppet模块，该模块可让我将本地Puppet客户端证书和本地证书颁发机构证书复制到特定服务所需的位置，无论它是nginx，HAProxy还是本地webapp或Postgres。然后，我可以为所有内部服务启用TLS，因为它们知道它们都具有可用于互相信任的有效证书。
我使用标准角色/配置文件模式来组织我的Puppet模块，并确保每当我有一个基于AWS特定功能的Puppet配置时，都将其拆分为一个AWS特定模块。这样，如果我需要迁移到另一个云平台，则可以轻松确定需要重写哪些模块。
所有Puppet更改都存储在Git中，其中master分支用作生产配置，其他分支则用于其他环境。在开发环境中，Puppetmaster会应用自动推送的所有更改，但是由于Git存储库是托管在开发环境之外的，因此我们有一个固定的规则，即任何人都不能直接从开发中更改生产。要执行此规则，对master分支的更改将同步到生产Puppetmasters，但不会自动应用-系统管理员需要登录生产并使用我们的编排工具显式推送更改。
编排
如果您不想确保以特定顺序应用更改，那么当您要确保一组特定服务器都具有相同的更改时，Puppet非常有用。不幸的是，您想要对系统进行的许多更改都遵循一定的顺序。特别是，在执行软件更新时，通常不希望它们在30分钟内以随机顺序到达服务器。如果更新存在问题，则需要停止更新过程并（在某些环境中）回滚到先前版本的功能。当人们尝试将Puppet用于本不该做的事情时，他们常常会感到沮丧和责备Puppet，而实际上他们应该使用Puppet进行配置管理和其他一些编排工具。
在我构建这种环境的时代，MCollective是与Puppet配对的最受欢迎的编排工具。与几十年前每个人都使用的更接近SSH for loop脚本的编排工具不同，MCollective具有强大的安全模型，在该模型中，系统管理员只能在预先启用的模块中使用有限的命令集。每个命令在整个环境中并行运行，因此将更改推送到一个主机或每个主机的速度非常快。
MCollective客户端没有对主机的SSH访问权限。相反，它会对发出的每个命令进行签名，并将其推送到作业队列。每台服务器都会检查该队列中是否有针对其的命令，并在执行签名之前验证签名。这样，破坏运行MCollective客户端的主机不会为您提供对其余环境的远程SSH根访问权限，而是仅使您能够访问已启用的受限命令集。
我们使用堡垒主机作为MCollective的命令中心，其目的是消除使sysadmin管理员必须登录到最低数量的最低要求。首先，我们要确保可以使用堡垒主机上的MCollective执行所有常见的sysadmin任务。MCollective已经包含一些模块，这些模块使您可以查询网络上与特定模式匹配的主机，并获取有关它们的事实，例如特定软件包的版本。
关于MCollective命令的妙处在于，它们使您可以为特定目的构建单个模块的库，然后可以将其链接到脚本中以用于通用工作流程。过去，我曾写过关于如何使用MCollective编写有效的编排脚本的文章，而这确实是一个大放异彩的环境。让我们采取最常见的sysadmin任务之一：更新软件。由于MCollective已经具有使用本机软件包管理器查询和更新软件包的模块，因此我们将所有内部工具也打包为Debian软件包，并将其放入内部软件包存储库中。要更新内部中间件软件包，系统管理员通常会手动执行以下一系列步骤：
获取运行该软件的服务器的列表。
从列表中的第一台服务器开始。
在监视该服务器时设置维护模式。
告诉所有负载平衡器将流量从服务器移开。
停止服务。
更新软件。
确认软件版本正确。
启动服务。
测试服务。
告诉所有负载平衡器将流量移回到服务器。
结束维护模式。
对其余主机重复上述步骤。
我要做的就是执行上述每个步骤，并确保有相应的MCollective命令。大多数步骤已经为它们提供了内置的MCollective插件，但是在某些情况下，例如对于负载均衡器，我为HAProxy编写了一个简单的MCollective插件，它将控制负载均衡器。记住，环境中的许多服务器都有自己的嵌入式HAProxy实例，但是由于MCollective是并行运行的，因此我可以告诉它们所有人都同时重定向流量。
一旦使用MCollective完成了这些步骤中的每个步骤，下一步就是将它们全部合并到一个通用脚本中以部署应用程序。我还在每个阶段都添加了适当的检查，因此，如果发生错误，脚本将停止并退出并出现描述性错误。在开发环境中，一旦更新通过所有测试，我们将自动推出更新，因此我还确保我们的持续集成服务器（我们使用Jenkins）使用相同的脚本为开发人员部署应用程序更新。这样，我可以确定脚本一直在进行测试，并且可以先在那里进行改进。
有一个脚本可以自动完成单个应用程序的所有这些步骤，这很棒，但是现实是，面向服务的现代体系结构拥有许多此类小应用程序。您很少一次部署一个。相反，您有一个生产版本，其中可能包含五个或更多应用程序，每个应用程序都有各自的版本。手动完成几次后，我意识到还有自动化的空间。
自动化生产版本的第一步是提供一个生产清单，我的脚本可以使用该清单来告诉它要做什么。生产清单列出了特定发行版将具有的所有不同软件，以及您将使用的版本。在组织良好的公司中，此类事情将在您的票务系统中进行跟踪，因此您可以适当地批准和查看何时生产的软件。如果以后遇到问题，这尤其方便，因为您可以更轻松地回答“发生了什么变化？”的问题。
我决定将正确的方法简化为简单的方法，并使用我们的实际生产清单票证作为脚本的输入。这意味着，如果您要自动发布产品，第一步是创建一个格式正确的票证，并带有适当的标题，其中包含要部署的每个软件以及要部署的版本的项目符号列表。希望他们被部署。然后，您将登录生产（从而证明您有权执行生产更改）并运行生产部署脚本，该脚本将输入应读取的特定故障单编号作为输入。它将执行以下步骤：
解析票证，并提示sysadmin及其将进行健全性检查的软件包列表，直到sysadmin说“是”后才继续进行。
使用故障单标题作为描述，在群聊中发布消息，提醒团队生产发布即将开始。
更新本地软件包存储库镜像，以使它们具有该软件的最新版本。
对于每个应用程序：1）通知群聊该应用程序正在更新，2）运行应用程序部署自动化脚本，以及3）通知群聊该应用程序已成功更新。
成功更新所有应用程序后，通知群聊。
通过电子邮件将所有更新的日志发送给sysadmin别名，并作为对故障单的注释。
像使用单个应用程序部署脚本一样，如果有任何错误，我们将立即中止该脚本，并将带有完整日志的警报发送到电子邮件，聊天和票证本身，以便我们可以调查出了什么问题。我们将首先在位于单独区域中的热灾难恢复环境中执行部署，如果成功的话，还将进行生产。一旦脚本在生产中成功运行，该脚本就足够智能以关闭故障单。最后，执行生产部署（无论是要更新一个应用程序还是要更新十个应用程序）都涉及以下步骤：
创建格式正确的票证。
登录到灾难恢复环境并运行生产部署脚本。
登录到生产环境并运行生产部署脚本。
自动化使过程变得如此简单，生产部署相对轻松，同时仍遵循我们所有的最佳实践。这意味着，即使我是团队中唯一的系统管理员，在我休假或没有其他工作时，拥有强大开发背景的老板也很容易接管生产部署。一致的日志记录和通知也使每个人都在同一页面上，并且我们对生产中的每个软件更改都拥有很好的审核记录。
我还使灾难恢复过程自动化。如果您已经测试了恢复，则只有真正备份了某些内容。我的目标是每季度测试一次灾难恢复过程，尽管实际上，我实际上每月进行一次测试，因为在灾难恢复环境中保存新数据非常有用，因此我们可以更好地捕获软件中任何数据驱动的错误在投入生产之前进行更新。与许多环境相比，这是一个更频繁的测试，但是我之所以能够做到这一点，是因为我编写了MCollective模块，该模块将从备份中还原灾难恢复数据库，然后将整个内容包装在一个主脚本中，从而将其全部转换为一个主脚本。一个将结果记录到票证中的命令，因此我可以跟踪每次还原环境的情况。
安全
我们对环境有非常严格的安全要求，该要求始于（但没有结束）PCI-DSS遵从性。这意味着服务之间的所有网络通信都使用TLS（以及提供的便捷的内部证书颁发机构Puppet）进行了加密，并且所有敏感数据都存储在静态加密的磁盘上。这也意味着每个服务器通常只执行一个角色。
大多数环境与Internet隔离，我们进一步在每个主机上定义了入口和出口防火墙规则，并在Amazon的安全组中实施了这些规则。我们从“默认情况下拒绝”方法开始，仅在绝对必要时才打开服务之间的端口。我们还采用了“最低特权原则”，因此只有少数员工可以访问生产，而我们的开发人员则无法访问堡垒主机。
每个环境都有自己的VPN，因此要访问除面向公众的服务之外的任何内容，您首先要连接到受两因素身份验证保护的VPN。从那里，您可以访问我们的日志聚合服务器以及其他监视和趋势显示板的Web界面。要登录到任何特定的服务器，您首先必须登录到ssh堡垒主机，该堡垒主机仅接受SSH密钥，还需要其自己的两因素身份验证。它是唯一被允许访问其他计算机上的SSH端口的主机，但是通常，我们尽可能使用编排脚本，因此，我们无需比堡垒主机更进一步来管理生产。
每个主机都有自己的使用ossec的基于主机的入侵检测系统（HIDS），它不仅可以警告服务器上的可疑活动，而且还可以通过日志进行分析以查找可疑活动。我们还使用OpenVAS在整个环境中执行常规的网络漏洞扫描。
为了管理机密，我们使用了Puppet的hiera-eyaml模块，该模块允许您以加密形式存储key：value对的层次结构。每个环境的Puppetmaster都有自己的GPG密钥，可用于解密这些机密，因此我们可以将开发或生产机密推送到同一Git存储库，但是由于这些文件是为不同的接收者加密的，因此开发Puppetmasters无法查看生产机密，和生产Puppetmasters无法查看开发秘密。hiera的优点在于，它允许您将纯文本和加密的配置文件结合在一起，并非常仔细地定义哪些秘密可用于哪种类型的主机。除非Puppetmaster允许，否则客户端将永远无法访问机密。
在生产和灾难恢复环境之间发送的数据使用灾难恢复环境中的密钥进行了GPG加密，并且还使用了环境之间的加密传输。灾难恢复测试脚本完成了解密备份和应用备份所需的所有繁重工作，因此管理员无需处理备份。所有这些密钥都存储在Puppet的hiera-eyaml模块中，因此我们不必担心主机崩溃时会丢失它们。
结论
尽管我在基础结构文章中介绍了很多基础知识，但我仍然只介绍了许多高级细节。例如，部署一个容错的，可伸缩的Postgres数据库本身可能只是一篇文章。我也没有过多地谈论我写的大量文档，就像我在Linux Journal上的文章一样，引导读者了解如何使用我们构建的所有这些工具。
正如我在本文开头提到的那样，这只是基础结构设计的一个示例，我发现在自己的约束条件下，它对我来说效果很好。您的约束可能有所不同，并可能导致不同的设计。这里的目标是为您提供一种成功的方法，因此可能会启发您使其适应自己的需求。
资源资源
LJ凯尔·兰金（Kyle Rankin）撰写的“ MCollective编排”，2016年12月
LJ的凯尔·兰金（Kyle Rankin），“ MCollective的编排，第二部分”，2017年1月
LJ的斯科特·拉基（Scott Lackey ）于2015年3月发表的 “将希拉与木偶一起使用”
Petros Koutoupis的“人偶重新定义了基础设施自动化”
评论专区