以下是LogicMonitor高级技术操作工程师Randall Thomson的客座博客。当他不是在幻想下一次滑雪冒险时，你会发现他正忙着打字，以保持LogicMonitor SaaS平台处于最佳状态。»构建高可用性平台LogicMonitor是一个面向企业组织的基于SaaS的监控平台，每天从55000多个用户收集超过200亿个指标。我们的服务需要全天候提供，毫无疑问。为了确保发生这种情况，LogicMonitor TechOps团队使用HashiCorp Packer、Terraform和Consult以可靠和可持续的方式动态构建灾难恢复基础设施（DR）。LogicMonitor SaaS平台是基于蜂窝的体系结构。运行LogicMonitor所需的所有资源（web和数据库服务器、DNS记录、消息队列、ElasticSearch群集等）都称为pod。每一种资源都要得到一致的配置，并且不能遗漏任何东西，这一点非常重要。为了实现这一级别的细节，我们在公共云中提供的任何资源都必须通过Terraform完成。在过去的18个月里，我们做出了巨大努力，不仅使用Terraform提供新的基础设施，而且还回填（导入和/或重新创建）现有资源。就这样，我们的博士计划诞生了。我们不再需要一种提供生产基础设施的方法，也不需要为灾难恢复计划提供不同的方法。对于Terraform，这两种情况基本相同。即使有了这个万无一失的计划，对于我们善意的、却容易出错的人类来说，灾难恢复过程中仍然存在一些空白。您可能有几百个web服务器并行运行，但是如果它们需要手动干预才能为客户提供服务，那么这些任务必须串行处理。更糟糕的是，一旦自动化停止，恢复时间目标（RTO）就会迅速增加。从并行自动检测动作到基于串行操作的手动任务的切换不仅使过程变慢，而且会立即增加压力负担。我们的团队讨论了先前DR练习的结果，并制定了两个目标：加快速度；取消手动步骤。实现这些HashiCorp产品（Packer、Terraform和consur）有助于实现这两个目标。所以，让我们继续向前看，看看我们是如何克服各种障碍的。»积木我们使用Packer来生成各种预先烘焙的服务器模板。使用这种方法而不是从一个通用映像开始提供了许多好处：可以标记模板（这有助于为模板的用途添加有意义的上下文），服务器在安装了所有应用程序的情况下启动（配置管理预应用，请检查！）图像的构建方式被记录下来并置于版本控制之下。我们还将Packer集成到我们的软件构建和部署服务中，以提供更好的可见性和一致性。==>amazon ebs:创建AMI标记amazon ebs:添加标记："name"："santaba-centos7.4"amazon ebs:添加标记："approved"："true"amazon ebs:添加标签："prebaked"："true"amazon ebs:添加标签："LM\u app"："桑塔巴"amazon ebs:添加标签："packer_build"："1522690645"amazon ebs:添加标记："buildresultsurl"：https://build.logicmonitor.com/PACK"==>amazon ebs:创建快照标记==>amazon ebs:正在终止源AWS实例。。。==>amazon ebs:正在清理任何多余的卷。。。==>amazon ebs:正在销毁卷（vol-0134567890abcdef）。。。==>amazon ebs:正在删除临时密钥对。。。构建"amazon ebs"完成。'''==>生成完成。成功构建的构件包括：-->亚马逊ebs:AMI创建于：欧盟西部1:ami-1234567876美国东部-1:ami-9101112131美国西部-1:ami-4151617181随着这一新工艺的实施，封隔器提供的最重要的改进之一就是节省时间。我们从通常需要45分钟以上的时间启动到只有5分钟的时间，单个组件才能提供服务。»精心策划的构建在过去，如果我们想复制现有服务器的构建方式，我们必须查找文档（交叉手指），然后评估是否进行了任何手动更改（甚至可能没有同事的.bash_历史来梳理），或者假设有什么魔法。这导致了应该完全相同的环境的不一致性。这种一次性的，基于人工的方法也是一个巨大的时间消耗谁不得不去反向工程一个吊舱，以建立一个新的。通常还需要各种不同的资源调配技术。当我们将所有的生产基础设施移到Terraform中时，我们意识到可以使用相同的代码进行灾难恢复。我们将有能力在没有太大压力的情况下，以可重复的方式测试我们的灾难恢复计划。地形可以摧毁基础设施，就像建造它一样容易。创建一个pod需要120多个不同的资源，这需要记住删除很多。通过开发我们自己的Terraform提供商，我们解决了在灾难恢复过程中需要手动干预的一些差距。我们创建了两个独立的提供者，每个提供者都实现了一个独特的任务。由于我们的团队使用LogicMonitor作为中断的真实来源，所以我们需要一种将Terraform创建的资源加载到LogicMonitor帐户中的方法。然后我们可以按需监控这些资源，并知道它们何时需要服务。如果领事的健康检查不合格（下一节将详细介绍），我们希望立即得到警告。下一个需要填补的空白是应用程序配置管理。我们开发了一个内部使用Terraform提供程序，从资源输出中自动填充配置信息。目前，每个吊舱需要130个单独的配置项，这给错误留下了很大的空间。使用Terraform提供程序不仅可以节省更多的时间，还可以减少复制和粘贴的需要，从而最大限度地减少错误（是否尝试加载一个URL时".com"中缺少"om"。»那东西又在哪儿跑？在领事馆注册服务给我们带来了一些好处。我们已经可以通过监视自动确定服务的运行状况，但是我们不能以有意义的方式将这些信息应用到我们的pod中的组件。在consur中使用HTTP和DNS接口意味着减少手动或静态配置，以便服务知道其他服务在哪里。到目前为止，我们在每个pod中注册了17个不同的服务。我们甚至注册了我们的Zookeeper集群，包括为领队添加标签，这样我们就有了一个一致的（和方便的）方法来知道服务是否和在哪里启动。例如，Zookeeper客户端可以使用动物园管理员服务领事作为通过领事DNS的FQDN。下面是一个conver health check的示例，用于确定给定的Zookeeper成员是否是集群中的当前领导者：{"name"："zookeeper"，"id"："动物园管理员领队"，"tags"：["leader"]，"端口"：2181，"支票"：[{"script"："timeout-s KILL 10s echo stat | nc 127.0.0.1 2181 | grep leader；if[$？-公式0]；然后退出0；否则退出2；fi"，"间隔"："30秒"}]}您可以对您认为的服务（例如客户帐户的实例）进行创新。我们的代理和负载平衡器使用consur模板自动编写路由配置文件。这减少了出错的机会，并提供了一个可扩展的模型，以便我们可以继续管理更复杂的系统。代理实际上是在配置自己，管理成百上千的后端，而不需要人工干预。当然，委托书本身也在领事馆登记。»当灾难来临时这一天到了。数据中心断电。现在是早上5点，你和你的孩子已经睡了半个晚上了。你想做多少思考？你还能思考多少？可能很少。提示地形平面图；地形应用。复制项目文件并重复（希望您的VPN能够正常工作，并且您在目标区域中有最新的服务器模板以及足够的实例限制…）。实现HashiCorp Packer、Terraform和consur之间的协调工作减少了手动配置的需要，并提供了一个弹性的DR过程。通过使用LogicMonitor提供程序，我们可以在迭代改进时快速验证测试结果。锻炼我们的灾难恢复肌肉已经把我们过去害怕的过程变成了几乎没有考虑的任务。如果您对这些产品感兴趣，请访问HASHIC表格。