Terraform と Bicep の比較

統合機能

スケールを実現するために、DevOps チームは常に信頼された反復可能なプロセスを使用してコードをすばやくデプロイする方法を探しています。 クラウドとインフラストラクチャに関しては、コードとしてのインフラストラクチャ (IaC) でこのプロセスの実現が加速しています。 IaC ツールには、特定の環境向けのさまざまな汎用ツールがあります。 Terraform は前者の一例です。一方、Bicep は Azure 関連のタスクを処理するように設計されています。

この記事では、Bicep と Terraform の 9 つのインフラストラクチャおよび統合機能を比較します。 これらの違いを理解すると、インフラストラクチャとプロセスをサポートするのに最適なツールを決めるのに役立ちます。

状態とバックエンド

Terraform と Bicep はどちらも Desired State Configuration (DSC) であり、IT および開発インフラストラクチャをコードとして管理しやすくします。 Terraform には、マネージド インフラストラクチャと構成に関する状態が格納されます。 Terraform はこの情報を使用して、実際のリソースを構成にマッピングし、メタデータを追跡し、大規模なインフラストラクチャのパフォーマンスを向上させます。 状態は、terraform.tfstateという名称のローカル ファイルに格納されますが、遠隔で格納する こともできます。 状態ファイルをバックアップし、セキュリティで保護することが重要です。 Terraform と同様に、Bicep は目標を設定する宣言型言語です。 ただし、Bicep は状態を格納しません。 代わりに Bicep は増分デプロイに依存します。

インフラストラクチャのターゲット

Bicep と Terraform を比較してクラウド インフラストラクチャを管理する場合は、対象となるクラウド環境を考慮することが重要です。

• Azure のみ
• マルチクラウドまたはハイブリッド クラウド

Bicep は Azure 専用であり、他のクラウド サービスと連携するように設計されていません。

次のいずれかの環境へのデプロイを自動化することが目的の場合は、Terraform の方が適している可能性があります。

• 仮想化環境
• Azure やその他のクラウドなどのマルチクラウド シナリオ
• オンプレミス ワークロード

Terraform は、他のクラウド プロバイダーまたは プロバイダー というプラグインを使用した API に対応しています。 Azure インフラストラクチャの管理を有効にする Terraform Azure プロバイダー は複数あります。 Terraform 構成をコーディングする場合は、使用する必須プロバイダーを指定します。 Terraform init を実行すると、指定したプロバイダーがインストールされ、コードから使用できるようになります。

CLI ツール

コマンド ライン インターフェイス (CLI) ツールは、オートメーション テクノロジの実装と管理によるオーケストレーションにおいて重要な役割を果たします。 Bicep と Terraform の両方に CLI ツールが用意されています。

Bicep は Azure CLI と統合されているため、開発者は次のような azコマンドを使用できます。

• az bicep: az bicep コマンドを使用すると、Bicep のインストール、Bicep ファイルのビルドと発行などのタスクを実行できます。
• az deployment: Bicep と Azure CLI を使用してリソースをデプロイする方法 に関する記事では、Bicep ファイルで Azure CLI を使用してリソースを Azure にデプロイする方法について説明しています。

Terraform CLI を使用すると、Terraform コードの検証と書式設定、実行プランの作成と適用などのタスクを実行できます。

• 「クイック スタート: Terraform を使用して Azure リソース グループを作成する」 の記事では、いくつかの Terraform コマンドを使用して Azure リソース グループを作成する方法について説明しています。

Bicep には、Bicep と Azure Pipelines を簡単に統合できる機能も用意されています。 Terraform にも同様の機能がありますが、Visual Studio 向け Azure Pipelines Terraform タスク拡張機能 をダウンロードし、インストールする必要があります。 インストールすると、Azure Pipelines から Terraform CLI コマンドを実行できます。 さらに、Terraform と Bicep の両方で、ソフトウェアビルド、テスト、およびデプロイを自動化するための GitHub Actions がサポートされています。

処理

Bicep と Terraform には、デプロイの効率と最適化に関する重要な相違点がいくつかあります。 Bicep では、コア Azure インフラストラクチャ サービス側で処理が行われます。 この機能には、ポリシーを確認するためのプリフライト処理や、リージョン内に複数のインスタンスをデプロイするための可用性などの利点があります。 Terraform では、Terraform クライアント内で処理が行われます。 したがって、事前処理では、状態と HCL (HashiCorp 言語) を使用して必要な変更を決定するため、Azure への呼び出しは必要ありません。

認証

Bicep と Terraform では Azure 認証機能が異なります。 Bicep では、Bicep ファイルと ARM テンプレートの送信が要求されている最中に承認トークンが提供されます。 ARM により、指定したテンプレート内でデプロイとデプロイ リソースの両方を作成するアクセス許可が付与されます。 Terraform は、プロバイダーの資格情報 (Azure CLI、サービス プリンシパル、Azure リソースのマネージド ID など) に基づいて各 API を認証します。 さらに、1 つの構成で複数のプロバイダー資格情報を利用できます。

Azure の統合

また、Azure Policy などの Azure 機能の使用と、それぞれが他のツールや言語とどのようにやり取りするかを検討する必要があります。 Bicep のプレフライト検証では、デプロイ前に失敗するようにリソースがポリシーに準拠していないかどうかを判断します。 したがって、開発者は提供された ARM テンプレートを使用し、ポリシーを使ってリソースを修復できます。 ARM テンプレートを使用して、自動修復のために別のリソースへのポリシー割り当てを作成できます。 ただし、Terraform では、ポリシーで禁止されているリソースがデプロイされると失敗します。

ポータルの統合

Bicep が Terraform よりも優れている点の一つは、ポータル アクションを自動化できることです。 Bicep では、Azure portal を使用してテンプレートをエクスポートできます。 テンプレートをエクスポートすると、リソースをデプロイする構文とプロパティを理解するのに役立ちます。 エクスポートされたテンプレートから始めて、ニーズに合わせて変更することで、今後のデプロイを自動化できます。 Terraform テンプレートがサポートされるまでは、エクスポートしたテンプレートを手動で翻訳する必要があります。

Terraform には Bicep と同じポータル統合機能はありませんが、Azure Export for Terraform を使用して Terraform 管理の下で既存の Azure インフラストラクチャを使用できます。 (Azure Export for Terraform は、Azure/aztfexport GitHub リポジトリ上で Microsoft が所有、管理するオープンソース ツールです。)

帯域外の変更

帯域外構成の変更は、ツールのコンテキスト外でデバイス構成に加えられた変更です。 たとえば、Bicep または Terraform を使用して Virtual Machine Scale Set をデプロイするとします。 ポータルを使用して Virtual Machine Scale Set を変更すると、変更は 「帯域外」になり、IaC ツールには不明となります。

Bicep を使用している場合は、帯域外の変更を Bicep と ARM テンプレート コードと調整して、次のデプロイで変更を上書きしないようにする必要があります。 これらの変更によってデプロイがブロックされることはありません。

Terraform を使用している場合は、帯域外の変更を Terraform 状態にインポートし、HCL を更新する必要があります。

したがって、帯域外変更が頻繁に発生する環境の場合は、Bicep の方が使いやすいでしょう。 Terraform を使用する場合は、帯域外の変更を最小限に抑える必要があります。

クラウド フレームワーク

クラウド導入フレームワーク (CAF) は、クラウド体験を通じてクラウド導入作業を加速するように設計されたドキュメント、ベスト プラクティス、ツールのコレクションです。 Azure には、ランディング ゾーンをデプロイするためのネイティブ サービスが用意されています。 Bicep は、ARM テンプレートとランディング ゾーンの実装に基づくポータル エクスペリエンスを使って、このプロセスを簡略化します。 Terraform では、Enterprise スケールのランディング ゾーン モジュールを利用して、Azure をデプロイ、管理、運用化します。

まとめ

Bicep と Terraform には、ユーザーが使いやすいインフラストラクチャと統合機能が多数用意されています。 これらの機能を使用すると、自動化テクノロジの実装と管理が容易になります。 環境に最適な環境を決定するときは、複数のクラウドにデプロイするかどうか、またはインフラストラクチャがマルチクラウド環境またはハイブリッド クラウド環境で構成されるかどうかを検討することが重要です。 さらに、この記事で説明されている 9 つの機能を考慮して、組織に最適な選択をしてください。

操作性機能

現在、組織は高い柔軟性と機敏性を必要とするダイナミックな課題に直面しています。 パブリック クラウド環境は、自動化 (特にコードとしてのインフラストラクチャ (IaC) を介して) これらのニーズを満たします。 主要な 2 つの IaC オプションとして、Hashicorp Terraform と Bicep があります。 Terraform は、DevOps プロフェッショナルが宣言型コードを使用して、オンプレミスおよびクラウド サービスを管理するのに役立つオープン ソース ツールです。 Microsoft Bicep では宣言型の構文を使用して、Azure リソースのデプロイを簡略化します。

この記事では、Terraform と Bicep の主要なユーザー エクスペリエンス機能をいくつか比較し、その類似点と相違点を説明します。

言語の構文

Bicep と Terraform は、使いやすく、開発者の時間を節約できるドメイン固有言語 (DSL) です。 どちらのツールにも、類似のキーワードと概念が組み込まれています。 これらの概念の一部はパラメーター化され、マルチファイル プロジェクトと外部モジュールをサポートします。 ただし、Terraform の方が、特定タスク向けの組み込み機能のライブラリが充実しています。 好みと経験によって、どちらを選ぶかを決めます。 次に、それぞれの言語構文で提供される概要と、使いやすい機能をいくつか示します。

Bicep は宣言型のプログラミング言語です。 そのため、コードで要素を定義する順序は、デプロイの処理方法には影響しません。 Bicep の既定のターゲット スコープは resourceGroup です。 ユーザーは変数を使用して複雑な言語式をカプセル化し、Bicep ファイルをもっと読みやすくすることができます。 モジュールの概念により、プロジェクトまたはチーム間で Bicep コードを再利用できます。

Terraform も HashiCorp Configuration Language (HCL) を利用する宣言型の言語です。 HCL は、リソースの宣言を主な目的としています。 その他の言語機能は、リソースの定義をより便利に行うために役立ちます。 Bicep と同様に、Terraform 構成ファイル内のコードの順序は重要ではありません。

言語ヘルパー

Bicep と Terraform には、どちらもコーディング タスクを簡略化するための 言語ヘルパー があります。 どちらも使いやすいので、好みと要件によって選択します。

Bicep では、コードをより動的かつ柔軟にするための言語式がサポートされます。 Bicep ファイルでは、さまざまな種類の関数が使えます。 これらの関数タイプには、論理関数、数値関数およびオブジェクト関数が含まれます。 ループでは、リソース、モジュール、プロパティ、変数または出力の複数のコピーを定義できます。 ループは、Bicep ファイル内の構文の繰り返しを回避するのに役立ちます。

Terraform には、値の変換と結合を行うために言語式内から呼び出される組み込み関数も用意されています。 Bicep と同様に、Terraform 言語式には、リソースによってエクスポートされたデータへの参照や条件付き評価など、複雑な言語式を入れることができます。 ループはコレクションの処理が可能で、コードを繰り返す必要なく複数のリソース インスタンスを生成できます。

モジュール

Bicep と Terraform は、どちらもモジュールの概念をサポートしています。 モジュールを使用すると、コードから再利用可能なコンポーネントを作成できます。 モジュールは、インフラストラクチャのスケーリングおよびクリーンな構成を維持するために重要な役割を果たします。 モジュールはリソース グループをカプセル化するため、同様のインフラストラクチャ コンポーネントのために開発する必要があるコードの量を減らします。 モジュールは、Bicep と Terraform で同じように機能しますが、実装では異なります。

Bicep では、モジュールは別の Bicep ファイルからデプロイされた単なる Bicep ファイルです。 Bicep モジュールは、Bicep ファイルの読みやすさを向上させるために役立ちます。 これらのモジュールもスケーラブルです。 ユーザーはチーム間でモジュールを共有して、コードの重複を回避し、エラーを減らすことができます。 Bicep モジュール定義の詳細については、Bicep モジュール を参照してください。

Terraform では、モジュール はチーム間でリソース構成をパッケージ化および再利用するための主要な手段となります。 Terraform モジュールは、1 つの論理ユニットとしてパッケージ化された複数リソースのコンテナーです。 モジュールは、ディレクトリに一緒に格納された .tfおよび、または .tf.json ファイルのコレクションで構成されます。 Terraform は、ローカル ファイルシステムのモジュールに加えて、さまざまなソースからモジュールを読み込むこともできます。 これらのソースには、レジストリ、ローカル パス、モジュール、GitHubが含まれます。

プロビジョニングのライフサイクル

Terraform でも Bicep でも、開発者はデプロイ前に構成を検証し、変更を適用することができます。 Terraform を使用すると、特定の構成によって管理されるすべてのリモート オブジェクトを破棄する際の柔軟性が向上します。 この機能は、作業が完了した時点で一時的なオブジェクトをクリーンアップするのに役立ちます。 最適なオプションを選択するときは、一般的なインフラストラクチャ デプロイのライフサイクル要件を考慮することが重要です。

Bicep には、Bicep ファイルをデプロイする前に変更をプレビューできる What-If 操作が用意されています。 Azure Resource Managerでは what-if 操作を提供し、既存のリソースに変更を加えません。 その後、Bicep ファイルで Azure PowerShell または Azure CLI を使用して、リソースを Azure にデプロイできます。 Azure PowerShell と Azure CLI では、リモート Bicep ファイルのデプロイメントはサポートされていません。 一方、Bicep CLI を使用して、Bicep ファイルを JSON テンプレートにビルドし、その JSON ファイルを遠隔な保存先に読み込むことができます。

Terraform の場合、terraform plan コマンドは Bicep what-if操作に似ています。 この terraform plan コマンドを使用して、プレビューする 実行プラン を作成してから適用します。 その後、 terraform apply コマンドを介して実行プランを適用します。 Terraform で行うことのほとんどは、terraform planおよびterraform applyコマンドの両方を使用する必要があります。

はじめに

Bicep と Terraform のどちらにも、作業開始に役立つリソースが用意されています。 Bicep 用 Learn モジュールは、Azure リソースの構成方法を定義するのに役立ちます。 また、実践的なエクスペリエンスを提供するために、いくつかの Azure リソースのデプロイに関する説明もあります。

同様に、HashiCorp Learn には、ユーザーが Terraform をインストールして使い方を学べるように、さまざまな Terraform トレーニング リソース が用意されています。 これらのリソースには、Terraform を使って Azure にインフラストラクチャをプロビジョニングする方法の説明が含まれます。

コードの作成

コード作成エクスペリエンスは、選択したエディターで使用できるアドインの数によって決まります。 幸いにも、Bicep と Terraform の両方で、コード作成を効率化するためのリソースが提供されています。

Bicep の場合、最も効果的なアドインの 1 つとして Bicep Visual Studio Code 拡張機能 があります。 この拡張機能には、コードの検証、Intellisense、ドット プロパティ アクセス、プロパティのオートコンプリートなどが含まれます。

Terraform の場合、Terraform 言語サーバー を使用する Terraform Visual Studio Code 拡張機能には、Bicep Visual Studio Code 拡張機能と同様の機能の多くが用意されています。 たとえば、この拡張機能では、構文の強調表示、IntelliSense、コード ナビゲーション、モジュール エクスプローラーもサポートされています。 HashiCorp では、Terraform 言語サーバーを構成して使うために、GitHub リポジトリ (https://github.com/hashicorp/terraform-ls/blob/main/docs/USAGE.md) に [詳細なインストール手順] も用意されています。

Azure カバレッジ

Azure リソースの構成では、Bicep には Terraform よりも優れている点があります。 Bicep は Azure サービスと深く統合されています。 さらに、新しい Azure 機能がすぐにサポートされます。 Terraform では、ユーザーが Azure を管理できる 2 つのプロバイダー (AzureRM と AzAPI) を提供しています。 AzureRM プロバイダーは、安定した Azure サービスのために十分に調整されたエクスペリエンスを提供します。 この調整されたエクスペリエンスにアクセスすると、少し遅延する場合があります。 AzAPI プロバイダーは、Azure Resource Manager REST API の上にある薄いレイヤーであり、Bicep のように、新しい Azure 機能の即時サポートを可能にします。 決定する前に、組織のインフラストラクチャ要件と、それらが完全にサポートされているかどうかを検討することが重要です。

コミュニティとサポート

コミュニティは、課題の学習と解決をサポートする上で重要な役割を果たします。 Terraform と Bicep のコミュニティは、どちらも高水準のエンゲージメントとサポートを提供します。

Bicep サポートの場合、問題の性質によってサポート先が異なります。

• ドキュメントのバグ: Microsoft Learn の Bicep ドキュメント に関する問題については、各記事にフィードバック セクションが用意されています。
• Bicep ソース コードとバグの提出: Microsoft Bicep GitHub リポジトリ にアクセスして、オープンソースの Bicep 製品とファイルのバグに提供してください。

Terraform サポートの場合、問題の性質によってサポート先が異なります。

• ドキュメントのバグ: Microsoft Learn の Terraform ドキュメント に関する問題については、各記事にフィードバック セクションが用意されています。

• プロバイダーのソース コードとバグの提出: Microsoft には、オープンソースの Terraform Azure プロバイダーに貢献し、バグを提出できる GitHub リポジトリが用意されています。 使用できるプロバイダーを一覧表示するには、Azure GitHub 組織を参照し、[リポジトリの検索...] フィールドに terraform-provider- を入力します。

• Terraform に関する主な質問: HashiCorp コミュニティ ポータルの Terraform セクション を参照してください。

• Terraform プロバイダー関連の質問: HashiCorp コミュニティ ポータルの Terraform プロバイダーセクション を参照してください。

  

まとめ

Bicep と Terraform は、Azure リソースの構成とデプロイを容易にする主要な 2 つの IaC オプションです。 どちらも、組織が効率と生産性を高めるのに役立つ使いやすい機能を提供します。 組織にとって最適な選択を判断する場合は、インフラストラクチャの要件と好みを慎重に検討してください。