Posted inDevOps

OpenTofu への移行：オープンソース Terraform フォークの実践ガイド

DevOps tutorial - IT technology blog
DevOps tutorial - IT technology blog

Infrastructure as Code の転換点

2023年8月、DevOpsの世界に大きな激震が走りました。HashiCorpがTerraformのライセンスをMozilla Public License（MPL）から制限の厳しいBusiness Source License（BSL）へ変更したのです。この変更により、多くのチームが将来的なコスト増加やベンダーロックインを懸念するようになりました。エコシステムをオープンに保つため、コミュニティはLinux Foundation傘下でOpenTofu を立ち上げました。これは完全なオープンソースのフォークであり、私たちが依存してきたツールがコミュニティの手に残り続けることを保証するものです。

OpenTofu はドロップイン置き換えとして機能します。HCL（HashiCorp Configuration Language）を使用しているため、すでに使い方はご存知のはずです。私の経験では、チームがライセンス問題だけでなく、特定ベンダーのロードマップに縛られないために移行するケースが増えています。Terraformのファイルが書けるなら、OpenTofu プロジェクトも数分で管理できるようになります。

インストール：OpenTofu を動かすまで

OpenTofu のセットアップは素早く完了します。AMD64とARM64アーキテクチャを含む主要プラットフォーム向けに安定したバイナリが提供されています。OpenTofu はリリース時にTerraform 1.5.xとの互換性を維持していたため、移行は非常にスムーズに感じられます。

macOS へのインストール

Macユーザーは簡単です。Homebrewを使うだけです：

brew install opentofu

Linux セットアップ（Ubuntu/Debian）

本番のLinuxサーバーには、公式リポジトリを使うことをお勧めします。これにより、最新のセキュリティパッチと機能アップデートを自動的に受け取ることができます。

# 初期要件のインストール
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gnupg

# OpenTofu GPGキーの安全な取得
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://get.opentofu.org/opentofu.gpg | sudo tee /etc/apt/keyrings/opentofu.gpg >/dev/null
sudo chmod a+r /etc/apt/keyrings/opentofu.gpg

# リポジトリの登録
echo "deb [signed-by=/etc/apt/keyrings/opentofu.gpg] https://packages.opentofu.org/opentofu/main/ubuntu/ any main" | sudo tee /etc/apt/sources.list.d/opentofu.list

# tofuバイナリのインストール
sudo apt-get update
sudo apt-get install -y tofu

tofu --version と入力してインストールを確認してください。1.6や1.7といった現在の安定版バージョンが表示されるはずです。

最初の設定ファイルを書く

OpenTofu は標準の .tf 拡張子を使用します。既存のコードを書き直す必要はありません。以下はクラウド料金を一切かけずにセットアップをテストするため、ローカルのテキストファイルを作成するシンプルな例です。

# main.tf
resource "local_file" "example" {
  content  = "Hello, OpenTofu!"
  filename = "${path.module}/hello.txt"
}

よくあるハードルのひとつがデータ形式の変換です。インフラの仕様をJSONで受け取っても、変数ファイルにはYAMLが必要なことがあります。その際、私はYAML ↔ JSON コンバーターを活用しています。ToolCraftのものはブラウザ上でローカル処理されるため、機密性の高いインフラのスキーマが外部サーバーに送信されない点が気に入っています。

クラウドプロバイダーへの接続

OpenTofu は独自のレジストリからプロバイダーを取得しますが、そこにはAWS、Azure、GCPなど使い慣れたプロバイダーがそろっています。おなじみのブロック構造で定義できます：

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.30"
    }
  }
} 

provider "aws" {
  region = "us-east-1"
}

上記のブロックで terraform ラベルをそのまま使っていることに気づいたかもしれません。OpenTofu は後方互換性のためにこれをサポートしているので、既存のスクリプトは壊れません。完全にネイティブな記述にしたい場合は、ブロックヘッダーを opentofu に切り替えることもできます。

基本ワークフロー：Init・Plan・Apply

標準ワークフローに変わりはありません。変更を本番環境に適用する前に安全を確認するための3ステップサイクルに依然として基づいています。

1. 初期化

ワークスペースを準備するために tofu init を実行します。このコマンドはプロバイダーをダウンロードし、バックエンドストレージをセットアップします。

tofu init

2. プランニングフェーズ

tofu plan コマンドは安全網の役割を果たします。作成・変更・削除されるすべてのリソースを一覧表示します。CI/CDパイプラインでは、プランとアプライのステップ間で意図しない変更が発生しないよう、常にこの出力をファイルに保存してください。

tofu plan -out=main.tfplan

3. 実行

プランを十分に確認したら、環境に適用します：

tofu apply "main.tfplan"

セキュリティとチェックサム

インフラ管理においてセキュリティは非常に重要です。一意のデータベース認証情報を作成する際は、パスワードジェネレーターを使ってエントロピーの高い文字列を生成しています。ToolCraftはクライアントサイドで動作するため、シークレットが自分のマシンの外に出ることはありません。また、ハッシュジェネレーターを使ってステートファイルのバックアップのSHA-256チェックサムを検証し、転送中にデータ破損が発生していないことを確認しています。

Terraform からの移行

すでにTerraform 1.5.xまたは1.6.xを使用している場合、移行は驚くほど地味な作業です——DevOpsにおいてはそれが理想的な状態です。OpenTofu は既存の terraform.tfstate ファイルをそのまま読み込むことができます。

  1. 安全のため、現在のステートファイルをバックアップしてください。
  2. マシンまたはビルドサーバーに tofu バイナリをインストールします。
  3. プロジェクトフォルダで tofu init を実行してプロバイダーを再初期化します。
  4. tofu plan を実行してステートがインフラと一致していることを確認します。

ツールは既存のリソースをそのまま引き継ぎます。実際のコードを変更しない限り、リソースを削除して再作成しようとはしません。

本番環境向けのプロのヒント

OpenTofu をプロフェッショナルな環境に導入する際は、以下のルールに従ってください：

  • リモートステート：ステートはS3バケットまたはAzure Blob Storageに保存してください。ローカルのステートファイルはチーム環境では障害の原因になりかねません。
  • ロックの有効化：DynamoDBのようなロック機構を使用してください。2人のエンジニアが同時に tofu apply を実行してステートが壊れるのを防ぎます。
  • バージョン固定：プロバイダーのバージョンは常に固定してください（例：~> 5.0）。予期しないアップデートによってデプロイが壊れる事態を防げます。

OpenTofu に移行することで、企業ライセンスよりもコミュニティのニーズを優先するプロジェクトを支援することになります。スタックの柔軟性を保つための信頼できる方法です。変数ファイルで構文エラーが発生した場合は、JSONフォーマッターにかけてみてください。デプロイを止めている余分なカンマを最速で見つけられる方法です。

Share:
Tags: