Terraformとは

HashiCorp Terraformは、手続き型言語ではなく宣言型言語を使用します。ユーザーはインフラ・リソースの望ましい最終状態を記述し、Terraformは残りの部分を処理します。Terraformは実行計画を自動的に作成し、リソース間の依存関係を識別し、正しい順序でコンポーネントをプロビジョニングします。たとえば、仮想マシン（VM）が仮想プライベートクラウド（VPC）に依存している場合、TerraformはVMをプロビジョニングする前にVPCが作成されるようにします。

対照的に、手続き型言語では、開発者はインフラストラクチャーをプロビジョニングするための段階的な指示を記述する必要があります。

Terraform構成ファイルはバージョン管理、再利用、共有が可能です。Terraform は、コンピューティング・リソースやストレージなどの下位コンポーネントと、ドメイン・ネーム・システム（DNS）の項目やサービス型ソフトウェア（SaaS）の主要な機能などの上位コンポーネントを管理します。

2025年2月、IBMはHashiCorpとその製品（Terraformを含む）を買収しました。

Terraformは、アプリケーション・プログラミング・インターフェース（API）を通じて、クラウド・プラットフォームやその他のサービス上のリソースを作成および管理します。Terraformは、Amazon Web Services（AWS）、Microsoft Azure、Google Cloud、GitHub、IBM Cloud、Dockerなど、アクセス可能なAPIを備えたほぼすべてのプラットフォームやサービスで動作します。

Terraformの主要ワークフローは3つの段階で構成されています。

1. 作成
2. 計画
3. 適用

開発者は、人間が読める構成ファイルを作成し、希望するインフラのリソース構成を定義します。このファイルは宣言型であり、希望するインフラを記述しますが、それをどのようにプロビジョニングするかは記述しません。

たとえば、開発者がクラウド・ホスト型アプリケーションを展開するためのインフラストラクチャーをプロビジョニングしたい場合、関連するセキュリティー・グループとロードバランサーとともに、仮想プライベートクラウド内の仮想マシンが必要であると指定することがあります。

単一の構成ファイルで、複数のクラウド・プロバイダーのリソースを管理できます。

Terraformは、開発者が作成して指定した構成と、組織のインフラストラクチャーの現在の状態の両方を分析します。次に、現在の状態から望ましい最終状態に到達する方法を説明する実行計画を作成します。

計画自体は、開発者が記述した構成に実世界が合うようにTerraformが作成、更新、破棄するインフラストラクチャーのリストという形をとります。

開発者が仮想プライベートクラウド内の仮想マシンにアプリケーションを展開する先ほどの例を考えてみましょう。Terraformの計画には、次のようなアクションが含まれることがあります。

• アプリケーションをホストする新しい仮想マシンをプロビジョニング
  
  
• 新しい仮想マシンへのトラフィックを許可するように既存のセキュリティグー・グループを変更
  
  
• 仮想マシン間でトラフィックを分散させるためにロード・バランサーをプロビジョニング

開発者は、Terraformによる計画の実行前に、計画をレビューし、変更することができます。

計画が承認されると、Terraformはリソースの依存関係を守りながら、操作を正しい順序で実行します。つまり、リソースAがリソースBに依存する場合、TerraformはリソースBがリソースAの前に作成されるようにします。

たとえば、開発者がVPCのプロパティーを更新し、そのVPC内の仮想マシンの数を変更した場合、Terraformは仮想マシンをスケーリングする前に、更新後のプロパティーでVPCを再作成します。

Terraform の主な構成要素は次のとおりです。

• 構成ファイル
• モジュール
• 状態ファイル
• プロバイダー
• レジストリー
• Terraform CLI

組織はTerraformを使用して、ライフサイクル全体にわたってインフラストラクチャーのプロビジョニングと管理を行います。一般的なユースケースには、次のようなものがあります。

• マルチクラウド環境の管理
• アプリケーション・インフラストラクチャー管理
• セルフサービス・インフラストラクチャー
• ポリシーおよびコンプライアンスの管理
• チームの連携

各クラウド・プロバイダーが独自のインターフェース、ツール、ワークフローを持っているため、マルチクラウド 環境は複雑になる可能性があります。さらに、重要なリソースが複数のデータセンターに分散されているかもしれません。

組織はTerraformを使用して、大規模なマルチクラウド・インフラストラクチャーの管理と編成を簡素化できます。具体的には、Terraformを使用すると、組織は同じ構成言語を使用して、単一のワークフローで複数のサービス・プロバイダーにわたってリソースをプロビジョニングして管理できます。

Terraformは多層アプリケーションのインフラストラクチャーを展開し、管理できるため、組織は依存関係を尊重しながら、統合されたワークフローで各層のリソースを管理できます。

たとえば、多層アプリケーションは、Webサーバーのプール、データベース層、API層、キャッシュ・サーバー、ルーティング層で構成される場合があります。Terraformは、データベース層に依存するWebサーバーをプロビジョニングする前に、データベース層をプロビジョニングします。

大規模組織では通常、集中化されたIT運用チームが、反復的なインフラストラクチャーの要求を多数受けています。

組織は、Terraformを使用して、製品チームが自社のインフラストラクチャーを独立して管理できるようにするセルフサービス・インフラストラクチャー・モデルを構築できます。たとえば、事前構築済みのモジュールを使用することで、チームは標準化および承認済みのコンポーネントを直接展開できます。

また、Terraformをチケット・システムや継続的統合/継続的デリバリー（CI/CD）DevOpsパイプラインと統合して、新しいインフラストラクチャーのプロビジョニング要求を自動化することもできます。たとえば、ユーザーがインフラストラクチャーの要求をチケット発行システムに送信すると、Terraformはワークフローを開始し、それに応じてリソースを自動的に更新できます。

Terraformを使用すると、プロビジョニングや使用可能なリソースの種類についてセキュリティー・ポリシーとコンプライアンス・ポリシーを適用できます。

たとえば、Terraformモジュールを使用して、組織全体のリソースの展開と管理に関する標準を体系化できます。他のチームがこれらの承認されたモジュールを使用する場合は、組織の慣行に準拠してリソースを確実に展開できます。

Terraform構成ファイルはバージョン管理システム（VCS）に保管できるため、DevOpsチームはコードで共同作業し、定義をレビューし、インフラストラクチャーの変更を追跡し、必要に応じて以前のインフラストラクチャー・バージョンにロールバックすることができます。

KubernetesとTerraformはクラウド環境の一般的なコンポーネントであり、どちらもインフラストラクチャー関連のタスクの自動化を支援します。ただし、両者の主な違いを挙げると、Kubernetesはコンテナ化されたワークロードに重点を置いているのに対し、TerraformはKubernetesクラスター自体を含むあらゆる種類のインフラストラクチャー・コンポーネントを管理する点です。

Kubernetes は、コンテナ化されたアプリケーションの展開、管理、スケーリングをスケジュール設定し、自動化するためのオープンソースのコンテナ・オーケストレーション・プラットフォームです。Terraformは、インフラストラクチャーのプロビジョニングと管理を自動化するコード型インフラストラクチャー・ツールです。

これらは異なる機能を持つ個別のツールですが、クラウド環境では連携して機能することがよくあります。たとえば、Terraformはクラウド・プラットフォーム上のKubernetesクラスターのプロビジョニングを自動化し、Kubernetesはそのクラスター内のアプリケーションの展開を管理します。

TerraformとAnsibleはどちらも、インフラストラクチャーの主要な作業を自動化するためのコード型インフラストラクチャー・ツールです。ただし、両者は使用する言語が異なり、多くの場合、目的も異なります。Terraformはインフラ・リソースのプロビジョニングに使われ、Ansibleはリソース構成の管理に使われることがよくあります。

Terraformは宣言型言語のみを使用しますが、Ansibleは宣言型言語と手続き型言語の両方を組み合わせます。手続き型構成では、開発者はリソースを望ましい状態に構成するためのプロシージャーを指定します。プロシージャーの構成は手間がかかりますが、より制御しやすくなります。

YAMLで記述されたAnsibleプレイブックを使用すると、ソフトウェアのインストールやシステム設定の更新などの作業をきめ細かく制御できます。Ansibleには、パッケージ管理やオペレーティング・システムの更新など、一般的な構成管理タスク用のさまざまな事前構築済みモジュールもあります。また、 Ansible はリソースの変更をべき等に適用することができます。つまり、操作を初めて適用した後で、同じ操作をさらに適用してもリソースは変更されません。

これらの特性を組み合わせると、Ansibleが構成管理に一般的な選択肢となる理由がよくわかります。

Terraformはインフラストラクチャー・リソースをプロビジョニングできますが、リソース内のソフトウェアをAnsibleほど効果的に管理することはできません。たとえば、Terraformはインスタンス・タイプやディスク・サイズなどのプロパティを含む新しい仮想マシンを定義できますが、仮想マシン上のオペレーティング・システムを更新することはできません。

しかし、TerraformはAnsibleなどの構成管理ツールと連携して、インフラストラクチャー構成を簡素化および効率化することはできます。たとえば、組織ではTerraformを使用して仮想マシンをプロビジョニングし、Ansibleを使用してそれらのマシンでソフトウェアを構成する場合があります。