【AI時代のLinuxエンジニア IaC編】第6回：Packerとcloud-initで作る「黄金のOSイメージ」と不変インフラ（Immutable Infrastructure）

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
「AI時代のLinuxエンジニア IaC（Infrastructure as Code）編」もいよいよ終盤戦、「第6回：Packerとcloud-initによる不変インフラ（Immutable Infrastructure）の構築」をお届けします。

第2回でTerraformによる「ハコ」作り、第3回でAnsibleによる「中身」の設定を学びました。しかし、ここで一つ冷静に考えてみてください。新しいサーバーを立ち上げるたびに、毎回 apt install を実行し、数十分かけて設定を流し込むのは効率的でしょうか？

1台ならまだしも、アクセス急増時に100台のAIサーバーを一斉にスケールアウト（増設）させる必要がある場合、100台すべてで「ゼロから構築」が始まると、サービスの復旧が間に合いません。そこで登場するのが、あらかじめ完璧に設定を済ませた「黄金のOSイメージ（Golden Image）」を作成し、それを量産するという考え方です。

本記事では、最新の Ubuntu 26.04 LTS をベースに、HashiCorp社のPackerを用いたOSイメージの自動ビルド手法、そしてサーバー起動時の最終微調整を行う cloud-init の活用術を、8000文字超の圧倒的ボリュームで完全解説します。

---

1. 運用パラダイムの転換：可変インフラから不変インフラへ

インフラの管理手法には、大きく分けて2つの流派があります。私たちがこれまで行ってきたのは「可変インフラ（Mutable Infrastructure）」、そして今回目指すのが「不変インフラ（Immutable Infrastructure）」です。

1-1. 可変インフラ（Mutable）の限界

サーバーを一度立てたら、そのOSの中でずっと apt upgrade や設定変更を繰り返す方法です。
問題点：
・長期間運用すると、各サーバー間で微妙な設定のズレ（構成ドリフト）が生じる。
・数年前の設定ミスがずっと残り続け、原因不明のバグを生む。
・新しくサーバーを増やす時、設定の適用に時間がかかる。

1-2. 不変インフラ（Immutable）の理想

サーバーに変更を加えたい時、既存のサーバーを修正するのではなく、「新しい設定を含んだOSイメージを作り直し、古いサーバーと丸ごと入れ替える」方法です。
メリット：
・すべてのサーバーが「同一のバイナリ（イメージ）」から起動するため、ズレが絶対に起きない。
・テスト済みのイメージをデプロイするだけなので、起動が極めて速い。
・不具合が起きても「イメージを一つ前に戻すだけ」で一瞬で復旧できる。

比較項目	可変インフラ (Ansible中心)	不変インフラ (Packer+Terraform)
アプローチ	既存環境を「修正」する	新しい環境を「再作成」する
構築スピード	遅い（毎回コマンドを実行）	爆速（イメージを起動するだけ）
一貫性	保証が難しい（ドリフト発生）	完璧（イメージが同じなら中身も同じ）
障害復旧	原因調査と修正が必要	古いイメージで再起動（ロールバック）

---

2. Packerの基本概念：OSイメージの「金型」をコードで作る

Packerは、単一のソース構成から、AWSのAMI、Google Cloudのイメージ、Dockerイメージ、VMwareの仮想マシンなど、複数のプラットフォーム向けのイメージを自動作成するオープンソースツールです。

2-1. Packerの構成要素

1. Sources（ソース）: どのベースOS（Ubuntu 26.04の公式イメージなど）を使って、どのクラウド（AWSなど）に一時的なマシンを建てるかを定義します。
2. Provisioners（プロビジョナー）: 起動した一時的なマシンの中で何を実行するかを定義します。ここに**Ansible**を組み込むのがプロの鉄則です。
3. Post-Processors（ポストプロセッサ）: イメージ作成後の処理（タグ付けや配布設定）を定義します。

---

3. 黄金イメージの3階層：ベース・ミドル・アプリ

何でもかんでも一つのイメージに詰め込むのは賢くありません。AI時代のインフラでは、以下の3つの階層を意識してイメージを設計します。

イメージ層	内容	作成頻度
OSベース層	Ubuntu 26.04 本体のセキュリティパッチ適用済みのもの。	月1回程度（セキュリティ更新に合わせる）
ミドルウェア層	NVIDIA GPUドライバ、Docker、Nginx、常用監視ツールなど。	数ヶ月に1回（主要ソフトの更新時）
アプリケーション層	特定のAIモデルや、独自のPHPアプリケーションコード。	デプロイごと。 最近はここはDockerコンテナに任せることが多いです。

Packerを使えば、ミドルウェアまでインストール済みの「共通イメージ」を社内で配布し、各チームがそれを使って瞬時に開発を始めることができます。

---

4. 【実践】Ubuntu 26.04 のカスタムAMIをPacker (HCL2) でビルドする

それでは、実際にPackerを使って、AWS上に「セキュリティ設定とDockerが導入済みのUbuntu 26.04黄金イメージ」をビルドするコードを書いてみましょう。PackerもTerraformと同じく **HCL2構文** を使用します。

4-1. ubuntu-gold.pkr.hcl の記述例

packer {
  required_plugins {
    amazon = {
      version = ">= 1.3.0"
      source  = "github.com/hashicorp/amazon"
    }
  }
}

# 1. どのベースOSを使うか定義
source "amazon-ebs" "ubuntu" {
  ami_name      = "linuxkoubou-gold-ubuntu-2604-{{timestamp}}"
  instance_type = "t3.medium"
  region        = "ap-northeast-1"
  source_ami_filter {
    filters = {
      name                = "ubuntu/images/hvm-ssd/ubuntu-noble-26.04-amd64-server-*"
      root-device-type    = "ebs"
      virtualization-type = "hvm"
    }
    most_recent = true
    owners      = ["099720109477"] # Canonical
  }
  ssh_username = "ubuntu"
}

# 2. イメージの中で何をするか定義（Ansible呼び出し）
build {
  sources = ["source.amazon-ebs.ubuntu"]

  # Ansibleを流し込んで構築を自動化！
  provisioner "ansible" {
    playbook_file = "./ansible/setup-gold-image.yml"
    user          = "ubuntu"
    use_proxy     = false
  }

  # 最後に cloud-init のログや一時ファイルを削除してクリーンにする
  provisioner "shell" {
    inline = [
      "sudo apt-get clean",
      "sudo rm -rf /var/lib/apt/lists/*",
      "sudo rm -f /etc/ssh/ssh_host_*", # SSHホスト鍵は起動時に再生成させるため削除
      "sudo truncate -s 0 /etc/machine-id"
    ]
  }
}

このファイルを packer build ubuntu-gold.pkr.hcl で実行するだけで、世界に一つだけの「自社専用・最強セキュリティOSイメージ」がクラウド上に誕生します。

---

5. cloud-init の役割：焼きたてイメージに「魂」を吹き込む初期化技術

Packerで作った「黄金イメージ」は完璧ですが、唯一の欠点があります。それは**「すべてのコピーが同じ中身になってしまう」**ことです。全サーバーが同じ「ホスト名」だったり、同じ「パスワード」だったりすると管理上困りますよね。

そこで、イメージから起動する「その瞬間」に、サーバー個別の個性（ホスト名、IP、SSH鍵、独自変数の流し込み）を与える技術が cloud-init です。

5-1. cloud-initの実行タイミング

cloud-initは、OS起動プロセスの初期段階で動きます。
1. **Packer (Build時):** 共通の設定、ソフトのインストールを済ませる。
2. **cloud-init (Launch時):** サーバーごとの個別設定（ホスト名変更など）を行う。

---

6. ユーザーデータの極意：インスタンス毎に異なる個性を与える

TerraformからEC2などのインスタンスを立ち上げる際、user_data パラメータとして cloud-init 形式のYAML（cloud-config）を渡します。

6-2. プロの user-data 記述例（Terraformとの連携）

#cloud-config
# プロレベルの初期化設定

# 1. ホスト名を動的に設定
hostname: ai-node-${count_index}
manage_etc_hosts: true

# 2. ユーザー作成とSSH公開鍵の配置
users:
  - name: sadmin
    groups: sudo
    shell: /bin/bash
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    ssh_authorized_keys:
      - ${public_key_data}

# 3. 起動時に実行する最後のコマンド
runcmd:
  - [ systemctl, restart, nginx ]
  - echo "Instance initialized at $(date)" >> /var/log/init_finish.log

---

7. セキュリティ上の利点：パッチ済みのクリーンな環境を一斉展開

不変インフラ（Immutable Infrastructure）の最大の恩恵は、実はセキュリティにあります。

7-1. 「パッチを当てる」から「入れ替える」へ

例えば、Ubuntu 26.04のカーネルに深刻な脆弱性が見つかったとします。可変インフラの場合、1台ずつ apt upgrade をして再起動して回らなければならず、途中で失敗するサーバーが出るリスクがあります。

不変インフラなら：
1. Packerの設定コードのベースAMIバージョンを1つ上げる。
2. 新しい「パッチ適用済み黄金イメージ」をビルドする。
3. Terraformの ami_id を新しいものに書き換える。
4. **terraform apply を実行し、古いサーバーを捨てて、新しいサーバーと入れ替える（Rolling Update）。**

これにより、常に「最新の、テスト済みの、クリーンな」環境だけが本番で動いている状態を維持できるのです。これは監査（オーディット）の観点からも非常に評価が高い運用手法です。

---

8. AIを部下にする：複雑なPackerテンプレートをLLMに自動生成させる

PackerのHCL2構文や、filterの書き方は非常に複雑で、ドキュメントを読み込むのに時間がかかります。2026年のインフラエンジニアは、AIに「金型の設計図」を書かせます。

8-1. Packer生成の神プロンプト

「あなたはシニアDevOpsエンジニアです。
HashiCorp Packer (HCL2) を用いて、AWS上で『Ubuntu 26.04 LTS』の黄金イメージをビルドするテンプレートを生成してください。

【要件定義】
1. 最新のUbuntu 26.04 AMIをソースとして検索する記述にすること。
2. ビルド中に Ansible プロビジョナーを呼び出し、`./ansible/webserver.yml` を実行すること。
3. 生成されるAMIの名前には、ビルド時のタイムスタンプを含めること。
4. ビルドの最終工程で、`/etc/ssh/ssh_host_*` キーの削除や `machine-id` の初期化を行うシェルスクリプトを実行すること（クローン時のトラブル防止のため）。
5. 成果物のAMIを、特定のAWSアカウントIDに対してのみ共有（Launch Permission）する設定例をコメントで含めてください。

【コーディング規約】
・Packerの最新ベストプラクティスに基づき、`variable` ブロックを活用してリージョンやインスタンスタイプを変数化すること。
・各コードブロックの役割を日本語で簡潔に解説してください。」

AIは、面倒な検索フィルターや後処理（Cleanup）の手順まで含めた、そのまま動くPackerコードを返してくれます。あなたはそれをチェックし、ビルドを開始するだけ。構築にかかる時間は、もはやあなたの「思考のスピード」だけになります。

---

総まとめ：イメージの力で「構築時間」をゼロにする

第6回の講座、本当にお疲れ様でした！インフラ自動化の次のステージ、「不変（Immutable）」の領域へと足を踏み入れました。

1. 不変インフラの思想： 既存のサーバーを直す手間を捨て、新しいイメージと入れ替えることで構成ドリフトを根絶する。
2. Packerの威力： Ansibleでの構築をあらかじめ済ませた「黄金イメージ」をコードで自動生成する。
3. cloud-initの魂： 共通イメージに対して、起動の瞬間にサーバー固有の個性を与える。
4. 運用の安定： 「イメージが同じなら動作も同じ」という確信が、大規模運用の恐怖を自信に変える。

これまで学んだ Terraform, Ansible, CI/CD, そして今回の Packer。これらが組み合わさることで、あなたのインフラ構築能力は、数千台規模のシステムすら一人で管理できるレベルにまで達しています。

しかし、最後にもう一つ重要なミッションが残っています。「Terraformでハコを作り、Ansibleで中身を作る」。この2つをバラバラに実行するのではなく、一つのシームレスな流れとして統合する方法です。

次回、第7回「TerraformとAnsibleの統合：ダイナミックインベントリの連携」では、Terraformで作ったサーバーの情報を、Ansibleが自動的に検知して設定を開始する、IaCツールの高度な連携術を解説します。お楽しみに！