这篇博文是我们关于Databricks平台、基础设施管理、集成、工具、监控和供应的一系列内部工程博客的一部分。今年夏天，在Databricks，我设计并实现了一项服务，用于协调和部署云提供商的基础设施资源，大大提高了我们自我管理的云平台上的操作速度。这项服务被称为"Terraform Deploy Pipeline"，我与云和可观测性团队合作，使之成为可能。在这个博客中，我解释了我们如何增强使用Terraform的现有工作流，并解决了痛点，从而大大减少了操作负担和出错的风险。我将总结它对工程速度的影响，以及我在Databricks的实习经历。介绍在Databricks，工程师每天与各种云提供商（如AWS、Azure）管理的资源进行交互。为了简化资源调配，我们利用了Terraform，一个与云无关的开源资源供应工具。结合Databricks基于jsonnet的模板系统，工程师可以声明性地指定所需的资源，并跨多个区域和云提供商提供这些资源。在实现操作效率方面，缺少的一个部分是模板的部署编排，以提供各自的资源。Terraform：基础设施即代码对于不熟悉Terraform的读者，我们简要介绍一下如何使用Terraform管理云资源。为了使用Terraform提供云基础设施，用户在模板文件中定义自己的资源，通常使用JSON或Hashicorp配置语言（HCL）（Terraform创建者构建的配置语言）。提供Azure keyvault的示例JSON模板如下所示：{"资源"：{"azurerm_key_保险库"：{"databricks_example_key_保险库"：{"location"："韦斯特"，"租户_id"："您的租户_id""name"："db example千伏"，"resource_group_name"："dbwestus"，... 一些密钥库参数。。。}}}}当Terraform应用模板时，将生成一个输出tfstate文件。tfstate文件描述由相应terraform模板提供的云资源的当前状态。这些文件对于Terraform在已经部署的资源上执行后续的资源更新至关重要，因为Terraform从tfstate文件中计算现有基线状态的所需状态的差异，并相应地执行更新以获得所需的云资源最终状态。要更改或销毁现有资源，用户只需更改模板并使用Terraform重新应用它。如果存在相应的tfstate文件，Terraform将正确修改资源并生成新的tfstate文件来替换旧的tfstate文件。如果缺少tfstate文件，Terraform将把模板中指定的所有资源视为新的。状态管理是一个很难管理的部分，但是Terraform必须有效地将资源迁移到所需的状态。当Terraform使用与当前云资源状态不匹配的tfstate文件时，可能会发生意外的应用程序行为。现有痛点Terraform是一个非常强大的工具，它极大地提高了利用云资源时数据块的效率。然而，跨生产环境管理数千个模板和云资源给数据库工程带来了许多新的挑战。一些最关键的问题包括：部署生产资源的操作瓶颈——在Databricks，有限数量的人有权将资源部署到我们的生产环境中。为了让工程师部署他们的资源，他们需要向基础设施团队提出请求，以批准请求并部署生产更改。对于看似轻量级的更改，例如更新生产数据库参数，这甚至是正确的。从最初的工程请求开始，甚至需要几天的时间来完成请求。缺乏强制的tfstate一致性–Databricks将tfstate文件存储在Git中，这提供了诸如版本控制（尤其是更改跟踪）之类的细节。但是，由于Git允许用户通过设计在不同的时间点查看代码，因此两个用户可以使用tfstate文件的冲突视图。随着系统的扩展，不可能阻止不同分支上的用户部署相同的资源、覆盖现有资源或进入不一致的状态。缺乏对部署具有敏感信息的资源的支持–Databricks上Terraform的一个非常常见的用例是部署每个服务的数据库。在部署时，需要指定一组初始凭据。如果只是简单地添加到模板中，那么在Git中，无论是在模板还是具体化的tfstate文件中，凭证都是可见的，这显然违反了安全性。作为一种解决方法，模板包含凭据的占位符，tfstate文件通过事后编校凭据进行清理。占位符尤其有问题，因为工程师需要记住在提交之前手动删除真正的凭证。Terraform部署管道：资源供应变得简单和安全为了解决上一节中提到的问题，我们设计了Terraform Deploy管道，这是一种自助式资源供应工具。该管道由Jenkins提供支持，并提供了一个简单的用户界面来部署Terraform模板：图1:Terraform部署管道UI。为了在云上提供资源，工程师需要构建一个Terraform模板，将路径作为作业的参数输入，然后部署作业。管道将解析模板，利用各自的云提供商凭据，并使用Terraform应用模板。为了确保部署是有意的，管道将短暂暂停以显示建议的资源更改并提示用户进行确认。确认后，资源无缝部署！图2：部署Terraform模板（在本例中是azurekeyvault）时显示的示例diff。如果有任何资源以生产环境为目标，则管道在继续之前必须得到我们基础设施团队的批准。尽管出于安全目的仍然需要干预，但是工作流要简单得多，因为基础设施团队只需要批准请求并允许管道处理自动交付。或者，该管道支持两人授权的生产资源变更，这些变更已经通过了代码审查流程（包括获得基础设施团队的批准），并被合并到我们的主分支中。在这种情况下，管道生成一个链接，供请求工程师发送给另一个工程师批准。审批者审查并接受请求后，管道继续并应用Terraform模板。这些工作流将更新生产资源所需的工作量降至最低，同时防止未经授权部署到生产中。在管道完成应用Terraform模板后，生成的tfstate文件将上载到分布式tfstate服务（由Azure blob store支持），而不是提交到版本控制。这种设计确保了tfstate文件的一致性，并消除了用户从表示历史上不同点的状态的tfstates应用Terraform模板的风险。部署机密为了允许部署具有敏感凭证的云资源，我们将管道与Hashicorp Vault支持的中央凭证管理系统集成。在Terraform资源模板中，用户可以指定对引导资源所需凭据的引用。在运行时，管道将从Vault获取引用的凭据，并通过运行时参数无缝地将其注入Terraform。凭据在服务之间传递，无需任何手动用户干预。通过利用凭证注入和事后tfstate编校，用户可以安全地提供云资源，而不必担心凭据泄漏。结论Terraform Deploy管道旨在提高Databricks上云资源供应的效率和安全性。它于2018年8月在内部发布，从那时起，它已经成为微软Azure资源部署的标准管道。我们已经看到引导新的云资源所需的时间大幅减少，并且由于新解锁的工作流，采用率有所提高。通常，生产资源配置任务现在将在几分钟内完成。此外，由于凭据注入，这些工作流现在更加安全。我在Databricks的实习经历是惊人的。我曾在多家公司实习过，而Databricks的实习经历则有所不同——从实习的一开始，我从未觉得自己被当作实习生对待过，相反，我是团队和公司的一员。我有机会产生影响，并几乎立即创造价值。Databricks的工程师很谦虚和支持，尽管他们有更多的行业经验，但他们总是乐于接受反馈。最重要的是，我能够从其他公司无法获得的各种经验中成长和学习，无论是技术上的还是非技术上的：与联合创始人1对1聊天，参加Spark和AI峰会，Spark最大的会议，聆听CEO重新提交董事会报告，参加午餐会和全公司的副总裁一起，跟踪Databricks的面试过程。最后，我还要感谢公司里的每一个人，特别是我的同事们，他们是我暑期实习的一部分。当我设计和构建可伸缩的云基础设施时，它深深地影响了我的思维方式。阅读更多了解我们的工程实习生的工作内容：引入集群范围的Init脚本介绍mlflow应用程序：mlflow示例应用程序的存储库数据库