【ITニュース解説】Terraform: UP& Running

ソフトウェア開発の世界では、プログラムコードの管理にgitというツールが広く使われている。git commitはアプリケーションの特定の時点の状態を記録するスナップショットのようなものであり、git logを見れば、いつ、何が、なぜ変更されたのかの履歴を追跡できる。新しい機能の実験もgit branchで安全に行うことができ、もし問題が発生してもgit revertで以前の安定した状態に戻すことが可能だ。

このコード管理の安心感を、あなたが利用するクラウド上のインフラ、例えばAWS、Azure、Google Cloudといったサービス上のサーバー、データベース、ネットワークに対しても適用できるとしたらどうだろうか。手作業でウェブコンソールを操作し、どのチェックボックスをクリックしたかを必死にメモしたり、特定のクラウドアカウントでしか動作しないといった問題を抱えたりする必要がなくなる。これがTerraformが提供する大きなメリットである。

Terraformは、HashiCorpという企業が開発した「Infrastructure as Code (IaC)」、つまり「コードとしてのインフラ」を実現するためのツールだ。これは、手作業でクラウドサービス提供者のコンソール画面を操作してサーバーやデータベースを作成する代わりに、それらのインフラの構成をコード（設定ファイル）として記述し、そのコードに基づいてインフラを自動的に構築・管理する仕組みを指す。コードで「こういうサーバーが欲しい」「このデータベースが必要だ」と宣言的に記述するだけで、Terraformがその記述に合わせて実際のインフラを調整してくれる。インフラのバージョン管理を実現するツールと言い換えることもできる。

なぜこのようなツールが必要なのか、手動でのインフラ構築における課題を考えてみよう。例えば、新しい開発環境を構築する際、あなたは数時間かけてAWSのコンソール画面でVPC（仮想ネットワーク）、サブネット、セキュリティグループ、EC2インスタンス（仮想サーバー）、ロードバランサーなどを丹念に設定したとする。その結果、無事に環境が動作した。しかし、数週間後、別の顧客のために全く同じ環境をもう一つ構築する必要が生じた時、あなたは以前の正確な手順を思い出せないかもしれない。「セキュリティグループのインバウンドルールはポート8080だったか、8000だったか」「どのAMI ID（サーバーのOSイメージ）を使ったか」といった詳細な設定が曖昧になり、インフラ構築の知識が個人の記憶や不確かなメモ、そして元に戻せない手動のクリック操作の中に閉じ込められてしまうのだ。これは再現性の欠如や、ヒューマンエラーのリスクを招く。

Terraformはこの問題を解決するため、インフラ構築に関する知識をコードとして明文化する。これにより、個人に依存していた知識がチームで共有できる資産となるのだ。

Terraformを使ったインフラ構築の基本的な流れは以下の三つのステップからなる。

まず、コードを記述する。あなたはインフラの構成を、.tfという拡張子を持つファイルに「HashiCorp Configuration Language (HCL)」という言語で記述する。このHCLは人間にとっても分かりやすく、同時に機械が処理しやすいように設計されている。

次に、**計画（Plan）**を実行する。terraform planコマンドを実行すると、Terraformはあなたが書いたコードと、現在クラウド上に存在する実際のインフラの状態とを比較し、その差分から「どのような変更が行われるか」という実行計画を生成する。この計画は、実際にインフラを変更する前に何が作成され、変更され、あるいは削除されるのかを詳細に教えてくれるため、最終的な変更を実行する前の安全確認として非常に重要である。

最後に、**適用（Apply）**を実行する。terraform applyコマンドを実行すると、Terraformは先ほど生成された計画に基づいて、クラウドプロバイダーのAPI（アプリケーション・プログラミング・インターフェース）を通じて実際のインフラを構築・変更する。

このようにして記述された.tfファイル群は、インフラの構成に関する「シングルソースオブトゥルース」、つまり唯一の信頼できる情報源となる。これらのコードは、次のような多様な利点をもたらす。

一つは、バージョン管理が可能になる点だ。アプリケーションのコードと同様に、Terraformのコードもgitにコミットして変更履歴を管理できる。これにより、いつ、誰が、なぜインフラに変更を加えたのかを追跡し、必要に応じて以前の状態に戻すことも容易になる。

二つ目は、共同作業とレビューの促進だ。GitHubのようなプラットフォームを使えば、他のチームメンバーがプルリクエストを通じてインフラの変更案を確認し、レビューできる。これにより、インフラ設計の品質向上やミスの早期発見につながる。

三つ目は、再利用性である。同じコードを使って、開発環境、ステージング環境、本番環境など、全く同じ構成の環境を何度でも、迅速に、確実に構築できる。

そして、知識共有にも役立つ。新しいチームメンバーがプロジェクトに加わった際、分厚いマニュアルを渡す代わりに、Terraformのコードを共有するだけで、インフラの構成を理解し、操作できるようになる。

具体的な例で、手動でのEC2インスタンス作成とTerraformを使った作成方法を比較してみよう。

手動でEC2インスタンスを作成する場合、AWSのEC2ダッシュボードにアクセスし、「インスタンスを起動」をクリック、AMI（Amazon Linux 2 AMIなど）を選択し、インスタンスタイプ（t2.microなど）を選び、「確認と起動」をクリックして「起動」を押す、といった複数のステップを踏む必要がある。

一方、Terraformを使う場合は、main.tfというファイルに以下のようなコードを記述する。

# AWSプロバイダーを設定
provider "aws" {
  region = "us-east-1"
}

# 作成したいリソースを宣言
resource "aws_instance" "my_web_server" {
  ami           = "ami-0c02fb55956c7d316" # Amazon Linux 2
  instance_type = "t2.micro"

  tags = {
    Name = "MyWebServer"
  }
}

このコードでは、AWSのどのリージョンに、どのAMIを使って、どのインスタンスタイプで、どのような名前のEC2インスタンスを作成するかを明確に定義している。このファイルを保存した後、コマンドラインでterraform init、terraform plan、terraform applyという三つのコマンドを実行するだけで、定義されたEC2インスタンスがクラウド上に自動的にプロビジョニングされる。

このコード自体がインフラの構成に関する正確な「ドキュメント」となる。もし二つ目のサーバーが必要なら、このブロックをコピーしてNameタグだけを変更し、再びapplyを実行するだけでよい。インフラに関する知識が個人の頭の中ではなく、共有されたコードベースに永続的に保存されるのだ。

Terraformを導入することで、プロジェクトは数々の重要な恩恵を得られる。

可視性と共同作業が向上する。インフラの設計全体がコードとして明確に表現されるため、チームの誰もがその設計を確認でき、コードレビューを通じて変更提案を行うことができる。

一貫性と信頼性が格段に高まる。手動による設定ミスが排除され、開発環境、テスト環境、本番環境といった異なる環境間でも、全く同じ構成を確実に保つことが可能になる。

速度と効率も向上する。手動では何日もかかっていた複雑なインフラのプロビジョニングが、Terraformを使えばわずか数分で完了するようになる。

さらに、Terraformはインフラのライフサイクル管理全体をカバーする。単にインフラを作成するだけでなく、その後の更新、スケールアップ・ダウン、そして何よりも重要な、安全な解体（terraform destroyコマンド）もコードに基づいて実行できる。これは、例えばテスト目的で一時的に環境を構築し、テスト完了後に確実に、そしてコストを抑えながら破棄したい場合に非常に有用だ。

Terraformを始めるのは比較的簡単だ。まず、あなたのコンピューターにTerraformをインストールする。次に、利用するクラウドプロバイダー（例えばAWS）の認証情報を設定する。そして、上記で紹介したような、シンプルなリソースを定義する.tfファイルを作成する。最後に、terraform init、plan、applyコマンドを実行するだけだ。

これらのステップを踏むことで、あなたは手動でのコンソール操作という古いやり方から脱却し、コード化され、バージョン管理され、信頼性の高いインフラ管理の世界へと足を踏み入れることになる。