最終更新:
genpack は、Gentoo Linux をベースとして用途特化型の 不変 (immutable) システムイメージ を宣言的に生成・配布・起動するための一連のツール群です。従来の「OS をインストールしてからカスタマイズする」アプローチとは異なり、設計図 (JSON5) から OS イメージ全体をビルドするというイメージファクトリの考え方に基づいています。
Docker がアプリケーションコンテナの世界で実現したことを、OS 全体のレベルで、しかもベアメタル・仮想マシン・組み込み機器を横断して実現することを目指しています。
| コンポーネント | 言語 | 役割 | リポジトリ |
|---|---|---|---|
| genpack | Python + C++ | JSON5 設定から SquashFS イメージを生成 | wbrxcorp/genpack |
| genpack-overlay | Gentoo ebuild/profile | パッケージ定義・プロファイル階層・初期化スクリプト群 | wbrxcorp/genpack-overlay |
| genpack-init | C++ + Python (pybind11) | 毎回起動時に system.ini に基づきシステムを構成 | wbrxcorp/genpack-init |
| genpack-install | C++ | イメージをディスク/ISO/ZIP にデプロイ、セルフアップデート | wbrxcorp/genpack-install |
| vm | C++ | genpack イメージを QEMU/KVM 上で実行・管理 | shimarin/vm |
| genpack-artifacts | JSON5 + シェルスクリプト | 具体的なイメージ定義の集合 | genpack-artifacts (GitHub Organization) |
genpack はツールチェーンの中核をなすビルドエンジンです。genpack.json5 という宣言的な設定ファイルを入力として受け取り、Gentoo Linux の stage3 + Portage を使って最適化された SquashFS イメージを生成します。
genpack は lower/upper の 2 層構造 でビルドを行います。
systemd-nspawn コンテナ内でコンパイル・インストールする完全なビルド環境この設計により、コンパイラやヘッダファイルなどビルド時にしか使わないファイルは Lower 層に残り、最終イメージには含まれません。最小限のランタイムイメージが自然に得られます。
{
name: "nextcloud",
profile: "paravirt",
packages: [
"www-apps/nextcloud",
"dev-db/mysql",
"dev-lang/php",
"net-misc/redis"
],
services: ["apache2", "mysqld", "redis"],
users: [{ name: "nextcloud", uid: 1000 }],
use: {
"dev-lang/php": "+mysql +curl +gd +xml +zip"
},
compression: "xz"
}パッケージリスト、有効にするサービス、ユーザー定義、USE フラグ、カーネル設定まで、全てがこの 1 ファイルに集約されます。これにより手作業によるシステム構築を排除し、完全に再現可能なビルドを実現しています。
| コマンド | 機能 |
|---|---|
genpack build | フルビルド (lower → upper → pack) |
genpack lower | Lower 層のビルド/リビルド |
genpack upper | Upper 層のビルド/リビルド |
genpack pack | SquashFS イメージの生成 |
genpack bash [command...] | Lower 層内の対話シェル / コマンド実行 |
genpack archive | 設定の tar.gz アーカイブを作成 |
x86_64, aarch64 (ARM64), i686, riscv64 に対応しています。アーキテクチャ固有の設定は genpack.json5 の arch セクションで管理できます。
GitHub: wbrxcorp/genpack-overlay
genpack-overlay は Gentoo のパッケージ管理システム (Portage) を拡張するオーバーレイです。genpack でビルドするイメージの「部品」となるメタパッケージ群と、デプロイ先の違いを吸収するプロファイル階層を提供します。
イメージ定義側は profile: "paravirt" や profile: "gnome/baremetal" を指定するだけで、適切なベース環境が自動的に選択されます。
各パッケージは /usr/lib/genpack/package-scripts/ 以下に初期化スクリプトを配置できます。MySQL のデータディレクトリ初期化、Docker のストレージ設定、SSH ホスト鍵の生成など、パッケージ固有の構成処理がここに定義されています。
genpack-init は C++ と Python (pybind11) のハイブリッドで構成された初期化システムです。PID 1 として起動し、毎回の起動時に ブートパーティション上の system.ini を読み取って Python スクリプト群を実行し、システムを構成します。
/run/initramfs/boot/system.ini (FAT パーティション上) を読み込み/usr/lib/genpack-init/*.py の各モジュールの configure(ini) 関数を実行/sbin/init = systemd) に exec で移行genpack-init は pybind11 を通じて以下のような低レベル操作を Python スクリプトに公開します:
genpack-init の最も重要な設計上の特徴は、FAT パーティション上の system.ini だけでシステム全体の動作をカスタマイズできる点にあります。
genpack イメージの initramfs は、起動時にブートストレージ上のデータパーティション（QEMU の場合はデータ用仮想ディスク）の有無を検出し、overlayfs ルートファイルシステムの upper layer を動的に決定します:
この仕組みにより、同一イメージでありながらデプロイ構成によって動作特性を使い分けることができます。データパーティションを設けない構成ではキオスク端末やデモ環境のような「毎回リセットされる」運用が、データパーティションを設ける構成ではサーバーのような永続的な運用がそれぞれ可能です。いずれの場合も、genpack-init は毎回起動時に system.ini を読んでシステムを構成するため、system.ini の変更は常に次回起動時に反映されます。
GitHub: wbrxcorp/genpack-install
genpack-install は生成されたシステムイメージを物理ストレージに書き込み、ブート可能な状態にするツールです。
| モード | 用途 |
|---|---|
--disk=<device> | 物理ディスクへのインストール (パーティショニング + ブートローダー設置) |
| セルフアップデート | 稼働中のシステムのイメージをアトミックに入れ替え |
--cdrom=<file> | ブータブル ISO 9660 イメージの作成 |
--zip=<file> | ZIP アーカイブの作成 |
BIOS / UEFI (x86_64, i386, ARM64, RISC-V) / Raspberry Pi の各ブート方式に対応した GRUB ブートローダーを生成・配置します。El Torito によるCD/ISOブートもサポートしています。
稼働中のシステムのイメージ更新は、以下のアトミックなリネーム操作で実現されます:
vm は genpack で生成したシステムイメージを QEMU/KVM 上で仮想マシンとして実行・管理するためのコマンドラインツールです。
| コマンド | 機能 |
|---|---|
vm run <image> | システムイメージから VM を起動 |
vm service | vm.ini に基づいて VM をサービスとして実行 |
vm console <name> | VM のシリアルコンソールに接続 |
vm stop <name> | QMP プロトコルによるグレースフルシャットダウン |
vm list | 実行中の VM を一覧表示 |
vm ssh user@vm | vsock 経由で VM に SSH 接続 |
vm usb | USB デバイスの列挙 (XPath クエリ対応) |
GitHub Organization: genpack-artifacts
genpack-artifacts は、genpack ツールチェーンを使って構築する具体的なシステムイメージの定義集です。各アーティファクトは個別のリポジトリとして管理されています。
各アーティファクトは統一されたディレクトリ構造を持ちます:
| カテゴリ | アーティファクト | 用途 |
|---|---|---|
| デスクトップ | gnome, streamer | GNOME デスクトップ、OBS 配信ワークステーション |
| ML/AI | torch | PyTorch + ROCm/CUDA 機械学習環境 |
| クラウド | nextcloud, owncloud | セルフホストクラウドストレージ |
| プロジェクト管理 | redmine | Redmine プロジェクト管理 |
| ネットワーク | vpnhub, walbrix | VPN ゲートウェイ、ネットワークアプライアンス |
| セキュリティ | suricata, borg | IDS、バックアップサーバー |
| 組み込み | camera | モーション検知カメラシステム |
| ユーティリティ | rescue, stub | システムリカバリ、最小ビルド環境 |
最小構成 (rescue: 十数パッケージ) からフルデスクトップ (gnome: 数百パッケージ) まで、全て同じ genpack.json5 + files/ のパターンで定義されています。
全てのイメージは genpack.json5 で宣言的に定義されます。パッケージ、USE フラグ、ユーザー、サービス、カーネル設定まで 1 ファイルに集約されており、手作業を排除した再現可能なビルドを実現しています。
最終成果物は読み取り専用の SquashFS です。システムの更新は既存環境の変更ではなく新しいイメージのビルドとアトミックな入れ替えで行われます。実行時のルートファイルシステムは overlayfs で構成され、データパーティションの有無により upper layer が永続ストレージか tmpfs かが自動的に決まります。データパーティションがない場合は毎回クリーンな状態から起動するため構成ドリフトが原理的に発生せず、データパーティションがある場合はサーバー用途に適した永続的な運用が可能です。
OS イメージ (SquashFS) は不変、ユーザー設定 (system.ini) は FAT パーティション上のテキストファイル。この 2 つが完全に分離されているため、OS の更新で設定が失われることがなく、設定変更に Linux の専門知識も不要です。
genpack-init は初回だけでなく毎回の起動時に system.ini を読んでシステムを構成します。これにより、system.ini への変更は常に次回起動時に反映されます。さらに、データパーティションを設けないトランジェントモードでは overlayfs の upper layer が tmpfs となるため、実行中の変更は再起動で自動的に消失し、毎回クリーンな状態 + system.ini の設定で起動します。
Lower 層 (ビルド環境) と Upper 層 (ランタイム) を分離し、実行時に不要なコンパイラやヘッダを自然に除外します。
ベースに Gentoo を採用することで:
x86_64 / aarch64 / i686 / riscv64 のアーキテクチャと、BIOS / UEFI / Raspberry Pi のブート方式をツールチェーン全体で横断的にサポートしています。
NixOS、Yocto、Buildroot、mkosi、OSTree など同様の目的を持つツールは数多く存在しますが、genpack は 「高度に最適化された Linux イメージを、非技術者でも運用できるアプライアンスとして配布する」 という独自の立ち位置を持っています。
その核となるのは、FAT32 上の INI ファイルという意図的に原始的な構成インターフェース、毎回起動時の構成適用とハードウェア検出による動作モードの自動決定、可変システムの代表である Gentoo の不変イメージへの転用、そして pybind11 によるプラグイン型 init といったアイディアの組み合わせです。
既存ツールとの詳しい比較については genpackが提供する価値の独自性についての対話 を参照してください。
このドキュメントは以下のリポジトリのスナップショットに基づいて作成されました: