CentOS Stream 9でImage Builder (osbuild-composer)を使いこなす：ISOとディスクイメージ作成の自動化 – ITFROMZERO

Table of Contents

実践的な課題：「繰り返されるインストール」という悩み

昨年、私のチームはある銀行向けに30台のサーバークラスターを構築するプロジェクトを担当しました。要件は非常に厳しく、すべてのサーバーでセキュリティ設定を統一し、監視ツールセットをプリインストールし、不要なサービスをすべて停止した上で、100%オフラインでインストールする必要がありました。

当初は、ひな形となるマシンを構成してからClonezillaで「クローン」するという従来の方法を選びました。しかし、結果は散々なものでした。ハードウェアの世代が少し違うだけでドライバーエラーが発生し、その後のパッチ管理も大きな負担となりました。もし、一台ずつサーバーにUSBを差し込んだり、夜通し数十台のVMに対してインストール後スクリプトを実行したりした経験があるなら、すぐにでも転職したくなるあの気持ちがわかるはずです。

なぜ古い手法は通用しなくなっているのか？

実際に運用してみると、仮想マシンのテンプレート作成やシェルスクリプトの使用といった手法には多くのリスクがあることがわかります。

一貫性の欠如：レポジトリの変更やネットワークの不安定さにより、スクリプトが途中でエラーになることが頻繁にあります。
メンテナンスの負担：ベースとなるインストールセットにパッケージを一つ追加するたびに、ほぼ最初からやり直すか、膨大なKickstartファイルを修正しなければなりません。
プラットフォームの断片化：VMware、AWS、物理マシン向けに3〜4種類の異なるフォーマットを手動で維持するのは、通常の3倍の手間がかかります。

現在の一般的なソリューションの振り返り

最適な解決策を見つける前に、私はあらゆるツールを試しました。

Kickstart: 非常に強力ですが、設定ファイルが極めて読みにくく、ハイフン一つ間違えるだけでプロセス全体が失敗します。
HashiCorp Packer: プロのDevOpsエンジニアには素晴らしいツールですが、手軽さを求める場合には技術的なハードルやパイプラインの構築がやや複雑です。
手動イメージ作成: 手動でインストールしてからQCOW2にエクスポートする方法。これは5台未満の規模には適していますが、拡張性は全くありません。

Image Builder (osbuild-composer)：システム管理者の救世主

6ヶ月の実戦を経て、私は Image Builder こそがCentOS Stream 9で最も使うべきツールであると確信しています。これはRHELから継承されたソリューションで、単一の「Blueprint（設計図）」を定義するだけで、システムがISO、KVM用のQCOW2、AWS用のAMI、Azure用のVHDなど、あらゆるフォーマットを自動的に出力してくれます。

ステップ1：コアコンポーネントのインストール

まずは osbuild-composer をインストールする必要があります。直感的な管理のために、複雑なコマンドを覚える手間を省けるCockpitのWebインターフェースを使用することをお勧めします。

# Image BuilderとCockpitプラグインのインストール
sudo dnf install -y osbuild-composer composer-cli cockpit-composer bash-completion

# サービスの即時有効化
sudo systemctl enable --now osbuild-composer.socket cockpit.socket

# コマンド補完を有効にするためにbash-completionをロード
source /etc/bash_completion.d/composer-cli

ステップ2：管理画面へのアクセス

サーバーにCockpitがインストールされている場合は、 https://<IP-Server>:9090 にアクセスしてください。左側のメニューに Image Builder という項目が表示されます。パッケージの選択からイメージのビルドまで、すべての操作をここで行うことができます。

ステップ3：Blueprint（システムの設計図）の作成

Blueprintは、パッケージリスト、ユーザー、設定を含む定義ファイルです。例えば、DockerとVimが組み込まれたWebサーバー用の標準ISOを作成するとしましょう。

Create Blueprint を選択し、名前を web-server-base とします。
Packages セクションで docker-ce、vim、git を検索して追加します。
Customizations セクションでユーザーを追加し、インストール後すぐにリモートログインできるようにSSHキーを貼り付けます。

コマンドライン（CLI）派の方は、以下のようなシンプルな内容で blueprint.toml ファイルを作成してください。

name = "web-server-base"
description = "Webサーバー用の標準インストールイメージ"
version = "0.0.1"

[[packages]]
name = "vim"
version = "*"

[customizations.services]
enabled = ["sshd"]

その後、次のコマンドでこの設定をシステムに反映させます。

composer-cli blueprints push blueprint.toml

ステップ4：ビルドとイメージの出力

この工程は完全に自動化されています。 Create Image をクリックし、希望の出力フォーマットを選択するだけです。

Installer ISO: USB経由で物理マシンにインストールするために使用します。人の手を介さずに最初から最後まで自動実行されます。
Guest Device (QCOW2): KVMやProxmox用です。インポートするだけで動作し、時間のかかるOSインストール工程をスキップできます。

ビルドプロセスには通常5〜10分かかります。システムは公式レポジトリからパッケージを自動的にダウンロードするため、速度はネットワーク環境に依存します。

トラブルを避けるための重要な注意点

以下に、デバッグ時間を大幅に短縮するための実践的な経験則をいくつか挙げます。

レポジトリの確認： Image Builderは、現在アクティブなレポジトリからのみパッケージを取得できます。Dockerをインストールしたい場合は、あらかじめCentOSにDockerレポジトリを追加しておく必要があります。
ディスク容量： ビルドプロセスは /var/lib/osbuild-composer で大量の容量を消費します。 /var パーティションに少なくとも20GBの空き容量があることを確認してください。
エラー時のログ確認： ステータスが「Fail」になった場合は、 composer-cli compose log <UUID> コマンドを使用してください。ログは非常に詳細で、通常はどの依存関係が不足しているかを示してくれます。

Image Builderを使用することで、展開プロセスが格段にプロフェッショナルかつ楽になります。各サーバーの設定に2時間費やす代わりに、わずか数分で100%正確なインストールイメージを手に入れることができます。CentOS Stream 9を運用しているなら、ぜひこのツールを試してワークフローをアップグレードしてください。