OSデプロイの繰り返される単純作業からの解放
新しいLinuxワークステーションのプロビジョニングは、多くの場合、反復作業のマラソンのように感じられます。新しいマシンをセットアップするたびに、最初の2時間はapt installを実行し、SSHキーをインポートし、Docker環境を構成することに費やされます。AnsibleやBashスクリプトのようなツールも役立ちますが、それらを実行するにはまずベースとなるOSがインストールされている必要があります。20台や50台といった規模のマシンをデプロイする場合、この「インストールしてから構成する」という2ステップ of プロセスは大きなボトルネックになります。
汎用的なUbuntu ISOは一般向けに構築されています。そこには、特定のHWEカーネル要件や最新のセキュリティパッチ、あるいはログイン画面にたどり着くために必要なプロプライエタリなドライバーは含まれていません。インストール後の手間を省くには、必要な要件をインストールメディア自体に直接組み込む必要があります。
インストール後スクリプトがしばしば失敗する理由
以前の私は、GitHubにホストした500行のsetup.shスクリプトに頼っていました。ワークフローは単純で、Ubuntuをインストールし、ログインして、スクリプトをcurlで取得するというものでした。しかし、サポートされていないネットワークドライバーを搭載したハードウェアに遭遇した瞬間、この方法は通用しなくなりました。インターネット接続がなければ、システムを修正するためのスクリプト自体をダウンロードできなかったのです。また、リポジトリの変更によってインストール途中で依存関係が壊れ、中途半端に構成されたマシンが残されることもありました。
さまざまなクラウドプロバイダーで40以上のLinuxインスタンスを管理してきた結果、信頼性は最初の起動前から始まるのだと気づきました。カスタマイズレイヤーをインストール前の段階に移行することが、真に一貫した環境を確保する唯一の方法です。ここでCubic (Custom Ubuntu ISO Creator) が真価を発揮します。Cubicを使えば、ISOを展開し、仮想環境 (chroot) に入って変更を加え、それを再びブート可能なイメージとしてパッケージ化できます。
ビルド環境のセットアップ
CubicはGUIベースのワークフローを提供しますが、ISOのファイルシステムへのフルコマンドラインアクセスも可能です。開始するには、既存のUbuntuホストとCubicের PPAが必要です。以下のコマンドを実行してシステムを準備してください：
sudo add-apt-repository ppa:cubic-wizard/release
sudo apt update
sudo apt install cubicアプリケーションメニューからCubicを起動し、プロジェクトディレクトリを選択します。ホームフォルダを直接使用するのは避けてください。~/builds/custom-ubuntu/のような専用のパスをお勧めします。少なくとも20GBの空きSSDスペースがあることを確認してください。Cubicは抽出中にいくつかの大きな一時ファイルを生成するため、ディスクI/Oが遅いとプロセスが滞る可能性があります。
ChrootフェーズでのISOのカスタマイズ
ベースとなるISO（Ubuntu 24.04 LTSなど）を選択すると、Cubicは圧縮されたファイルシステムを抽出し、ターミナルを表示します。これが**Chroot環境**です。ここで実行されるコマンドは、ホストマシンではなくISOの内部構造を変更します。
1. パッチ適用とソフトウェアの注入
まず、イメージに完全にパッチを適用することから始めます。これにより、デプロイするすべてのマシンのセキュリティが最初から確保され、起動直後に500MBものアップデートを要求されることがなくなります。
apt update
apt upgrade -y次に、チームで使用するコアスタックをインストールします。標準的な開発用ビルドであれば、後で時間を節約するためにGit、Vim、Dockerをプリロードしておくとよいでしょう：
apt install -y git vim curl wget gpg
# 公式のDockerリポジトリを追加
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | tee /etc/apt/sources.list.d/docker.list > /dev/null
apt update && apt install -y docker-ce docker-ce-cli containerd.io2. グローバル設定のデプロイ
ソフトウェアのインストールは戦いの半分に過ぎません。残りの半分は設定です。Cubicインターフェースの「Copy」ボタンを使用して、ローカルファイルをISO内に移動します。すべての新規ユーザーに特定のbashエイリアスや企業の壁紙を適用したい場合は、それらのファイルを/etc/skel/に配置します。システムはアカウント作成時に、このディレクトリ内のすべての内容を新しいユーザーのホームフォルダに自動的にクローンします。
# 事前に構成された設定ファイルを /tmp/ からスケルトンディレクトリに移動
mkdir -p /etc/skel/.config/dev-tools/
cp /tmp/settings.conf /etc/skel/.config/dev-tools/高度なチューニング：不要なソフトの削除とカーネル
カスタマイズとは「引き算」でもあります。サーバーにメールクライアントやオフィススイートが必要ない場合は、それらを削除してISOサイズを縮小し、潜在的な攻撃対象領域を減らしましょう。LibreOfficeを削除するだけで、最終的なイメージから500MB削減できることもよくあります。
apt purge -y libreoffice* thunderbird*
apt autoremove -yCubicでは特定のブートカーネルを選択することもできます。これは、標準のLTSが提供するものよりも新しいカーネルを必要とする最新のハードウェアにデプロイする場合に不可欠です。ターミナルフェーズの後、grubやisolinuxファイル内のブートパラメータを変更して、タイムゾーンの選択やディスクパーティショニングを自動化することも可能です。
ゴールドイメージの生成と検証
調整が完了したら、「Next」をクリックして圧縮形式を選択します。テスト中の素早いビルドには**gzip**を好みますが、本番リリースではファイルサイズを最小限に抑える必要がある**xz**に切り替えます。最後に「Generate」を押して、カスタムの.isoを出力します。
テストされていないISOを本番環境のハードウェアにデプロイしてはいけません。私の個人的なルールは、「**テストされていないメディアは壊れたメディアである**」ということです。USBドライブに書き込む前に、必ず仮想マシン（Virt-ManagerやVirtualBoxなど）でイメージを起動してください。
検証チェックリスト：
- インストーラーは手動操作なしでデスクトップまで起動するか？
- Dockerのような重要なサービスはアクティブで、バージョンは正しいか？
/etc/skel/内のファイルはホームディレクトリに正しく表示されているか？- ネットワークインターフェースは即座に認識されるか？
VMがこれらのチェックをパスすれば、信頼できるゴールドイメージの完成です。学生用ラボのプロビジョニングであれ、標準化された開発者環境であれ、このカスタムISOによってすべてのマシンが正確に必要な状態でスタートできるようになります。
