通过使用Terraform来重复利用现有的Databricks工作流

2 年 ago

清, 扬

2 minutes

通过Terraform重用现有的工作流程- The Databricks Blog的翻译。

這本書是摘譯版，不能保證內容的準確性。請參考原文以獲得確切的內容。

Terrform系列之第2部分

本文是关于通过Terraform部署工作流程的博客系列的第二部分。在这里，我们将重点讨论如何将继承工作流程转换为Terraform IaC。

在这篇文章中，我们将讨论一种可以将现有工作流程转换为Terraform IaC的工具。同时，我们还将探讨可以部署此类IaC的各种方法。

Terraform的资源导出器（实验阶段）

作为Terraform Databricks提供程序包的一部分，Databricks提供了一个被称为Experimental Resource Exporter的工具。目前这个工具已经具备了生成Terraform HashiCorp Language（HCL）代码以实现多任务作业的能力。我们将以下步骤用于生成一个全功能的Databricks资源IaC生成器：

对Terraform基础设施即代码进行重构，并部署到另一个工作区。

设置Terraform Databricks提供程序

Exporter工具是以Terraform Databricks提供程序的二进制形式提供的。设置提供程序后，将在本地目录中下载这些二进制文件。因此，创建一个文件夹并在其中创建.tf文件。将以下代码添加到文件中（请选择来自发布存储库的最新提供程序版本）。执行terraform init命令（为此需要安装Terraform）。

terraform {
  required_providers {
    databricks = {
      source = "databricks/databricks"
      version = "1.6.1" # provider version
    }
  }
}

我们感兴趣的工具是 terraform-provider-databricks_v1.6.1，它在.tf文件中指定了提供者版本1.6.1。

设置认证

当发布这篇文章时，Exporter工具只支持两种认证模式：对于Databricks。

环境变量DATABRICKS_HOST和DATABRICKS_TOKEN由以下命令设置：export DATABRICKS_HOST=https://my-databricks-workspace.cloud.databricks.com和export DATABRICKS_TOKEN=my_databricks_api_token。有关生成Databricks API令牌的方法，请参阅此文档。

执行出口程序

可以使用这个命令来获取过去120天内活跃的名为my-favorite-job的任务的Terraform HCL代码。

.terraform/providers/registry.terraform.io/databricks/databricks/1.6.1/darwin_arm64/terraform-provider-databricks_v1.6.1 exporter -skip-interactive -match=my-favorite-job -listing=jobs -last-active-days=120 -debug -skip-interactive

要获取所有作业，请执行以下命令。

.terraform/providers/registry.terraform.io/databricks/databricks/1.6.1/darwin_arm64/terraform-provider-databricks_v1.6.1 exporter -skip-interactive -services=jobs -debug

这个实用程序还有一个交互模式，可以执行它。你可以通过指定用于生成Terraform文件的目录作为参数来指定。截止到1.6.1版本，要使用此实用程序进行检测，您必须至少执行一次作业。有关此导出工具的详细使用说明，请访问Terraform注册表获取。

对Terraform的IaC进行重构和重新部署。

由导出器实用工具生成的IaC文件与之前通过Terraform创建的Databricks工作流非常相似。可以通过git提供程序对这些文件进行版本管理。基础架构工程师可以借助这些代码进行模块化。硬编码的对象可以转换为变量（.tfvars、vars.tf、var.、TF_VAR_环境变量），并且可能在terraform apply中作为参数指定。例如，我们可能想要将相同的作业部署到两个工作区，但要指定不同的集群配置以支持后续任务。还假设我们想在作业或任务失败时通知其他人。为了实现这种情景，我们可以保持多个变量文件，每个文件针对不同的工作区、环境和业务域具有不同的资源配置。

需要注意的另一个要点是，通过上述步骤为工作流生成的IaC是无法通过自动化程序执行的。正如之前的文章所述，所有的工作流都拥有许多依赖关系，例如身份、集群策略、实例池、git资格信息等等。对于这些资源的IaC生成也需要以一致的方式正确地适配所有拼图的组成部分。

作为练习，让我们来实现一个基于变量的电子邮件通知场景。我们希望在工作流开始、成功或失败时，根据环境类型（开发、测试、生产）决定将通知发送到不同的电子邮件地址。我们可以从在工作用的IaC（基础架构即代码）目录中声明两个变量environment和email_notification_groups的Terraform文件（my-variables.tf）开始。

variable "environment" {
   default = "dev"
}

variable "email_notification_groups" {
   default = {
       "dev" = {
                               "on_start" = ["group1@xyz.com"]
                               "on_success" = ["group2@xyz.com"]
                               "on_failure" = ["group3@xyz.com"]
                           }
       "test" = {
                               "on_start" = ["group2@xyz.com"]
                               "on_success" = ["group2@xyz.com"]
                               "on_failure" = ["group2@xyz.com"]
                           }
       "prod" = {
                               "on_start" = ["group4@xyz.com"]
                               "on_success" = ["group4@xyz.com"]
                               "on_failure" = ["group4@xyz.com"]
                           }
   }

   description = "Environment decides who gets notified"  
}

将Terraform IaC中的多任务作业从邮件通知模块中删除所有硬编码部分，并将其更改为动态内容（var.email_notification_groups和var.environment将被用于访问已声明变量的值）。

email_notifications {
   on_failure = var.email_notification_groups[var.environment]["on_failure"]
   on_start = var.email_notification_groups[var.environment]["on_start"]
   on_success = var.email_notification_groups[var.environment]["on_success"]

然后，最后通过命令行动态注入环境。

terraform apply -var="environment=test"

您可以参考Illimity Bank的灾难恢复计划，了解他们是如何利用Exporter工具来生成Databricks资源的Terraform IaC，并在他们的第二个环境中重新部署的。

总结

通过数据工程师、数据科学家和基础设施工程师的协作，企业可以通过Terraform基础设施即代码来构建模块化和可扩展的工作流，从而在同时部署到多个工作空间。从头开始编写所有Databrikcs工作流的基本设施即代码是一项繁琐的任务。Exporter工具可以生成基线的Terraform代码，并在需要时进行扩展，非常方便。

开始使用

学习Terraform
Databricks的Terraform提供程序
通过Terraform进行Databricks工作流