Terraform と Bicep の比較

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

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

状態とバックエンド

Terraform と Bicep はどちらも望ましい状態構成 (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 Tasks 拡張機能をダウンロードしてインストールする必要があります。 インストールが完了したら、Azure Pipelines から Terraform CLI コマンドを実行できます。 さらに、Terraform と Bicep の両方で GitHub Actions が サポートされ、ソフトウェアのビルド、テスト、デプロイが自動化されます。

加工

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

認証

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

Azure の統合

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

ポータルの統合

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

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

帯域外の変更

帯域外構成の変更は、ツールのコンテキスト外でデバイス構成に加えられた変更です。 たとえば、Bicep または Terraform を使用して仮想マシン スケール セットをデプロイするとします。 ポータルを使用してその仮想マシン スケール セットを変更した場合、変更は "帯域外" になり、IaC ツールでは不明になります。

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

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

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

クラウド フレームワーク

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

概要

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

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

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

言語構文

Bicep と Terraform は、使いやすく開発者の時間を節約できるドメイン固有言語 (DSL) です。 どちらのツールにも同様のキーワードと概念が組み込まれています。 これらの概念の一部は、パラメーター化、マルチファイル プロジェクトのサポート、外部モジュールのサポートです。 ただし、Terraform には、特定のタスク用の組み込み機能の豊富なライブラリが用意されています。 2 つを決定することは、好みと経験の問題です。 次に、簡単な概要と、各言語構文で提供されるわかりやすい機能の一部を示します。

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

Terraform は、HashiCorp 構成言語 (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 Language Server を構成して使用するための GitHub リポジトリ (https://github.com/hashicorp/terraform-ls/blob/main/docs/USAGE.md) に [詳細なインストール手順] も用意されています。

Azure の対象範囲

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

コミュニティとサポート

コミュニティは、課題の学習と克服を支援する上で重要な役割を果たします。 Terraform と Bicep の両方のコミュニティは、高レベルのエンゲージメントとサポートを提供します。

Bicep サポートの場合、ヘルプが表示される場所は、問題の性質によって異なります。

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

Terraform のサポートの場合、ヘルプが表示される場所は、問題の性質によって異なります。

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

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

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

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

  

概要

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