Reuse Existing Workflows Through Terraform - The Databricks Blogの翻訳です。
本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
Terrformシリーズのパート2
Terraformを通じたワークフローのデプロイに関するブログシリーズのパート2です。ここでは、継承ワークフローをどのようにTerraform IaCに変換するのにフォーカスします。
以前の記事Terraformを通じたDatabricksワークフローでは、マルチタスクジョブ/ワークフローのインフラストラクチャアズコード(IaC)をスクラッチから作成するために、どのようにTerraform Databricksプロバイダーを使うのかを学びました。ワークフローUIは簡単かつモジュール化されており、依存関係のビジュアル表現を提供します。このため、多くのエンジニアやデータサイエンティストにとってワークフローを構築する際に好まれる手段かもしれません。しかし、特定の組織においてはコードを用いて自身のインフラストラクチャを管理することを好み、専用のインフラエンジニアのチームを有している場合があります。このケースにおいても、依然としてUIで作成シアワークフローを継承し、コードとしてメンテナンスすることが可能です。このプラクティスがどのように見えるのかを以下に示しています。
図1. Terraformを通じたワークフロー管理
この記事では、既存ワークフローをTerraform IaCに変換することができるツールを議論します。また、このようなIaCをデプロイできる様々な方法を見ていきます。
Terraformのリソースエクスポーター(実験段階)
Terraform Databricksプロバイダーパッケージの一部として、DatabricksではExperimental Resource Exporterとして知られるツールを提供しています。提供されるすべてのクラウドに対して、オールインワンのDatabricksリソースIaCジェネレーターに変換する作業は継続中ですが、現状においてもこのツールには、マルチタスクジョブにおけるTerraform HashiCorp Language (HCL)コードを生成する能力を備えています。以下に使用するステップを示します:
- Terraform Databricks Providerをセットアップします。
- ソースのDatabricksワークスペースで接続の認証をセットアップします。
- Exporterユーティリティを実行し、Terraform IaCを生成します。
- Terraform IaCをリファクタリングし、別のワークスペースに際デプロイします。
Terraform Databricksプロバイダーのセットアップ
Exporterユーティリティは、Terraform Databricks providerのバイナリーで提供されています。プロバイダーをセットアップすると、ローカルディレクトリにこれらをバイナリーをダウンロードします。このため、フォルダを作成し、内部に<my_provider>.tf
ファイルを作成します。ファイルに以下のコードを追加します(リリースリポジトリから最新プロバイダーバージョンを選択してください)。terraform init
コマンドを実行します(このためにTerraformをインストールする必要があります)。
terraform {
required_providers {
databricks = {
source = "databricks/databricks"
version = "1.6.1" # provider version
}
}
}
Terraformは、バイナリーをダウンロードし作業用ディレクトリ内の.terraform
フォルダーに保存します。Apple M1 Pro Mac (macOS Monterey V 12.5.1)では、ダウンロードは以下のようになります。
我々が興味があるアーティファクトは<my_provider >.tf
ファイルで指定されるプロバイバーバージョン1.6.1
を保持しているterraform-provider-databricks_v1.6.1です。
認証のセットアップ
この記事を公開した際、ExporterユーティリティはDatabricksに対する2つの認証モードのみをサポートしています:
- Databrikcs CLI向けに設定された資格情報ファイル
~/.databrickscfg
に格納されるDEFAULT
プロファイル。これはdatabricks configure --token
コマンドで作成されます。詳細はこちらのページを参照ください。 - コマンド
export DATABRICKS_HOST=https://my-databricks-workspace.cloud.databricks.com
とexport DATABRICKS_TOKEN=my_databricks_api_token
で設定される環境変数DATABRICKS_HOST
とDATABRICKS_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 registryでアクセスすることができます。
Terraform IaCのリファクタリングと再デプロイ
エクスポーターユーティリティによって生成されるIaCファイルは、以前の記事Terraformを通じたDatabricksワークフローで作成されたものと非常に似たものとなります。これらのファイルをgitプロバイダーを通じてバージョン管理することも可能です。インフラエンジニアは、このコードをベースとして用い、モジュール化することができます。ハードコードされたオブジェクトは変数(.tfvars, vars.tf, var., TF_VAR_環境変数)に変換され、terraform apply
で引数として指定される場合があります。例えば、同じジョブを2つのワークスペースにデプロイしたいが、背後のタスクのために異なるクラスター設定を指定したいとします。ジョブやタスクが失敗した際、別の人に通知をしたいと考えたとします。このシナリオを実装できるようにするために、ワークスペース、環境、ビジネスドメインごとに異なるリソース設定を持つ複数の変数ファイルを保持することができます。
注意すべき別のポイントは、上述のステップを通じてワークフロー向けに生成されたIaCは、バキュームで実行することができないということです。以前の記事で述べたように、すべてのワークフローはアイデンティティ、クラスターポリシー、インスタンスプール、git資格情報など多数の依存関係を持っています。これらのリソースに対するIaCも、すべてのジグソーパズルのピースが一貫性のある方法で適切に当てはまるように同じ方法で生成される必要があります。
練習として、変数によるメール通知シナリオをを実装してみましょう。ワークフローがスタート、成功、失敗した際、環境のタイプ(dev, test, prod)に応じて決定される別のメールアドレスに通知を送りたいと考えています。作業用IaCディレクトリに2つの変数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"
ワークフローのメール通知セクションは以下のようになります。
図2. 変数を通じて動的に設定されたメール通知
以下の図では、デプロイメントにおいて異なる設定が実行時にどのように組み合わせ、様々なバリエーションのワークフローを作成するのかを要約しています。
図3. Terraform IaCのモジュール化
Illimity BankがDatabricksリソースのTerraform IaCを生成するために、どのようにExporterユーティリティを活用し、彼らの二番目の環境に再デプロイしたのかを学ぶために、Ilimity Bank Disaster Recoveryを参照することができます。
まとめ
データエンジニア、データサイエンティスト、インフラエンジニアのコラボレーションによって、企業はTerraformインフラストラクチャアズコードを通じて、同時に複数のワークスペースにデプロイできるモジュール化され、スケーラブルなワークフローを構築することができます。すべてのDatabrikcsワークフローのIaCをスクラッチから記述するのはうんざりとするタスクです。Exporterユーティリティは、ベースラインのTerraformコードを生成し、必要に応じて拡張する際に便利なものとなります。
使い始める
Learn Terraform
Databricks Terraformプロバイダー
Terraformを通じたDatabricksワークフロー