こんにちは。インフラの世界へようこそ。
現場で多くのプロジェクトを渡り歩いていると、必ずと言っていいほど直面する問題があります。それは「誰かが書いたVPC構築コードをコピー＆ペーストして、微妙に違う設定が散乱し、誰も全体像を把握できない」というコピペ地獄です。
これを解決するのが「Terraformモジュール」の共通基盤化です。今回は、GitHub PackagesをプライベートRegistryとして活用し、社内のインフラ資産を「一元管理された魔法の道具箱」に変える方法を伝授します。
—
1. なぜ「プライベートRegistry」が必要なのか？
TerraformのモジュールをただGitHubのリポジトリに置いておくだけでは、バージョン管理が曖昧になり、他のエンジニアが「どのコミットを使えば安全か」を判断できません。
Terraform Registry（プライベート版）を使うと、以下の恩恵が得られます：
- セマンティックバージョニング（SemVer）の強制: `v1.2.3` のように明示的に指定できる。
- 依存関係の可視化: どのプロジェクトがどのバージョンのモジュールを使っているか明確になる。
- アクセスコントロール: GitHubの権限をそのまま利用できる。
—
2. 準備するもの：GitHub Packagesの設定
Terraformは、GitHubをレジストリとして利用するための通信規格（`Terraform Registry Protocol`）をサポートしています。
手順①：GitHubの認証設定
ローカル環境やCI/CDからGitHub Packagesにアクセスするために、Personal Access Token (PAT) を発行します。
1. GitHubの `Settings` > `Developer settings` > `Personal access tokens` > `Tokens (classic)` へ。
2. `repo` と `write:packages`, `read:packages` スコープにチェックを入れて生成。
3. 環境変数にセットします：
export GITHUB_TOKEN=”ghp_xxxxxxxxxxxxxxxxxxxx”
export GITHUB_USER=”your-username”
—
3. モジュール作成：Hello Worldの作法
まずは、ディレクトリ構成を厳格に守りましょう。Terraform Registryとして認識させるには、ディレクトリ名に `terraform-
例：AWSのS3バケットモジュールを作る
terraform-aws-s3-bucket/
├── main.tf # 実装
├── variables.tf # 入力値
├── outputs.tf # 出力値
└── README.md # これが一番重要！ドキュメントとして表示される
main.tf の例
resource “aws_s3_bucket” “main” {
bucket = var.bucket_name
# 冪等性を高めるため、可能な限りデフォルト値を活用する
}
—
4. GitHub Packagesへの公開（ハンズオン）
ここが最重要ポイントです。Terraformは「Gitのタグ」を見てバージョンを判断します。
1. Gitタグを打つ（SemVer準拠）:
git tag v1.0.0
git push origin v1.0.0
2. GitHub Releaseを作成:
GitHubのUI上で、タグ `v1.0.0` に紐付いたReleaseを作成します。これだけで、Terraformは「新しいモジュールバージョンが公開された」と認識します。
—
5. 現場での呼び出し方：劇的に楽になる瞬間
準備が整えば、他のプロジェクトからは以下のように記述するだけです。コピー＆ペーストはもう不要です。
module “my_s3_bucket” {
# 指定フォーマット:
version = “1.0.0”
bucket_name = “production-assets-bucket”
}
このコードを書いた後、`terraform init` を叩いてください。Terraformが裏側でGitHub APIを叩き、セキュアにモジュールをダウンロードしてくれます。
—
伝説的エンジニアからのアドバイス：運用を成功させる鍵
1. README.mdを極めよ:
Terraform Registryは `README.md` を自動的にパースしてWebページ化します。入力変数（variables）の解説や、使用例（usage）はテンプレート化して、誰が見ても使えるようにしましょう。
2. 破壊的変更を恐れるな:
SemVer（メジャー.マイナー.パッチ）を厳格に守りましょう。メジャーバージョンを上げる（例：`v1.0.0` → `v2.0.0`）ときは、必ず移行ガイドを書くこと。これがチームの信頼を生みます。
3. CI/CDとの結合:
`terraform-docs` や `tflint` をGitHub Actionsに組み込み、「READMEが更新されていないモジュール」や「品質の低いコード」がレジストリに登録されないようガードレールを敷いてください。
—
「自分の書いたコードが、社内の標準として誰かの役に立つ」。これこそがインフラエンジニア冥利に尽きる瞬間です。最初は小さくてもいい。まずは一つのモジュールを「製品」としてリリースしてみることから始めてみてください。
あなたのインフラ構築が、今日からもっと自由で、もっとスマートになることを願っています。質問があればいつでもどうぞ。