Lightwhale 3: Linuxサーバーを再び楽しくする
(lightwhale.asklandd.dk)- Dockerコンテナ専用に設計された Linux サーバー OS で、ISO を起動するだけでそのまま Docker Engine 環境に入れる
- コアシステムを 不変・ステートレス構造にし、
/etc、/var、/homeと Docker データだけを別の書き込み領域に分離することで、インストールや初期設定の負担を大きく減らしてくれる - デフォルトのデータファイルシステムは tmpfs ベースの揮発性ストレージで、永続化を有効にすると別のストレージデバイスを自動検出してパーティション分割・フォーマット・マウントを行い、必要に応じて Btrfs RAID1 としても構成される
squashfsベースの読み取り専用ルートと最小構成要素を使い、マルウェアや意図しない変更への露出面を減らし、リソース使用量と消費電力も抑えるように作られている- x86-64 専用でベアメタルと仮想マシンで動作し、サーバー管理そのものよりコンテナ実行とセルフホスティング運用にすぐ集中できる
概要
- Dockerコンテナ専用に設計された Linux サーバー OS であり、ISO でライブ起動するとそのまま Docker Engine 環境に入る
- インストールと初期設定の負担を減らすため、コアシステムは不変構造とし、データとユーザーカスタマイズは別の保存領域に分離する
- ホームラボ、ベアメタル、仮想化環境、エッジノード、クラスターまでを想定しているが、対応アーキテクチャは x86-64 に限定される
- 最小構成と使いやすさを優先し、サーバー管理よりもコンテナの実行と運用そのものに集中できるようにする
主な特徴
- プラグアンドプレイ方式なので、ISO をダウンロードして起動するだけで必要なツールを含む Docker Engine がすぐに利用できる
- 構成要素を最小化し、学習負担を下げてシステムの動作を素早く把握できるようにする
- 不変・ステートレスなコアを使うことで、マルウェアや意図しない変更への露出面を減らし、毎回同じ状態で起動する
- 選択的な永続化を提供し、デフォルトのデータファイルシステムは RAM 上の揮発性
tmpfsで、永続化を有効にすると別のストレージデバイスを自動検出してパーティション分割・フォーマット・マウントする - 不要なプロセスを減らして リソース使用量と消費電力を抑え、古い機器や低スペック機器をより長く活用できるようにする
- セルフホスティングを簡単に運用できるようにし、Big Tech への依存から離れてデータとプライバシーを自分で管理できるようにする
始め方
- 最新 ISO をダウンロード するか、ダウンロードセクション からイメージを入手して USB に書き込み、起動すればよい
- 一部のシステムでは起動前に BIOS で セキュアブートの無効化が必要になる場合がある
- デフォルトのログインはユーザー名
op、パスワードopsecretで、インターネットに公開する前に少なくとも パスワード変更が必要 - Wi‑Fi は
setup-wifiで任意に設定できる - コンテナ実行は通常の Docker 利用と同じで、例として
docker run -it --rm busybox psを使う - 永続化を有効にする際は、パーティションではなくブロックデバイスに magic header を書き込む必要があり、この過程で既存データは消去される
起動と実行構造
- ISO は ベアメタルと仮想マシンで起動可能で、UEFI と従来 BIOS の両方をサポートする
- 起動プロセスは sysv 風 init システムを使用し、単純で透過的なブートフローを保つ
- ブートローダーが Linux カーネルとルートファイルシステムをメモリに載せた後、カーネルがハードウェアを初期化して
/initに制御を渡す initは/etc/inittabを読み、/tmp、/run用のtmpfsをマウントした後、/etc/init.dのスクリプトを実行する- 初期段階で data filesystem をマウントし、Docker データと
/etc、/var、/homeの overlay 上位レイヤーを提供する - すべてのファイルシステムと overlay の準備が整った後に残りのサービスが開始され、その時点からコンテナを提供できる
不変性設計
- ルートファイルシステムは圧縮された
squashfs静的イメージとして提供され、それ自体は変更不能な構造になっている - この構造により、必須ソフトウェアと設定があらかじめ含まれ、インストール工程なしで起動可能な 自己完結型イメージになる
- パッケージマネージャー、依存関係管理、既存システムのアップデート競合を避け、すでに動くものを再インストールする作業を 再起動ひとつに置き換える
- ルートファイルシステムのファイルは誤って削除されたりウイルスによって改変されたりせず、従来のシステムのようにカーネルや基盤バイナリ全体が変更可能な状態で露出しない
- 読み取り専用ルート構造のため、長期運用中に残留ファイルが蓄積してバックアップ、性能、整理状態を損なう 不要物の蓄積を防ぐ
- ローカル VM や別のコンピューターで自由に試し、再起動で変更を元に戻せる
- 起動メディアには重要情報がなく、不変性によってその状態が保たれるため、デバイスが破損または紛失しても新しいコピーで復旧できる
永続化構造
- コンテナのインストール・実行、設定変更、データ書き込みには 書き込み可能なファイルシステムが必要で、再起動後も維持するには永続化が必要になる
- 初期起動段階で自動動作する下位システムが
/mnt/lightwhale-dataに data filesystem をマウントする - Lightwhale が書き込むデータは
/mnt/lightwhale-data/lightwhale-state配下に集まり、このディレクトリがoverlayfsの書き込み可能な上位レイヤーになる - デフォルトは揮発性
tmpfsで、永続化を有効にすると data filesystem は 別のストレージデバイス上に置かれるようになる - ルート全体を覆わず
/etc、/var、/homeだけを選択的に overlay 処理し、不変性の目的を保つ/etcはネットワーク、パスワード、sshdなどのシステム設定カスタマイズに使われる/varはログやその他のアプリケーションデータに使われる/homeは SSH authorized keys、Git リポジトリのクローン、Docker・Swarm スタック管理などのユーザーカスタマイズに使われる
- Docker の data root は
/mnt/lightwhale-data/lightwhale-state/dockerに直接置かれ、イメージ・コンテナ・ボリューム・ネットワーク状態を保存する
永続化の有効化と自動処理の段階
- 永続化は
echo "lightwhale-please-format-me" | sudo dd conv=notrunc of=/dev/sdxのように magic header をストレージデバイスへ書き込んで明示的に有効化しなければならない - 複数のストレージデバイスに magic header を書き込むことができ、その場合は Btrfs RAID1 ボリュームとして組み合わされる
- 次回起動時にシステムが magic disk を検出してフォーマットし、data filesystem として使用する
- persistence subsystem は
/etc/init.d/S11persistenceから開始される -
データファイルシステムの検出
- すべてのディスクを検査し、ファイルシステムラベルが
lightwhale-dataのパーティションを探す - 見つかればそれを data filesystem として使用し、以後のマウント段階をスキップする
- すべてのディスクを検査し、ファイルシステムラベルが
-
magic disk の検出とパーティション作成
- ディスク先頭位置のバイト列
lightwhale-please-format-meを探して magic disk を判定する - 各 magic disk には
lightwhale-swapラベルの swap パーティションと、残り全領域を使うlightwhale-dataラベルの Linux パーティションを作成する
- ディスク先頭位置のバイト列
-
ファイルシステムの作成
- magic swap パーティションはフォーマット後に
lightwhale-swapラベルを付ける - magic data パーティションが 1 つなら
btrfs --data single --metadata dupでフォーマットする - 複数なら RAID1 として束ね、
btrfs --data raid1 --metadata raid1cnでフォーマットする @lightwhale-data、@lightwhale-state、@lightwhale-state-snapshotsのサブボリュームを作成する
- magic swap パーティションはフォーマット後に
-
マウントと overlay 構成
- data filesystem があれば
@lightwhale-dataを/mnt/lightwhale-dataにマウントし、なければ代わりにtmpfsをマウントする - 不変の下位レイヤーは
/etcを/run/lightwhale/overlay/lower/etcに bind mount し、ルートファイルシステムのディレクトリツリーをミラーして準備する - 書き込み可能な上位レイヤーは
/mnt/lightwhale-data/lightwhale-state/overlay/upper/etcのようなパスに準備する - その後
overlayfsで 2 つのレイヤーを結合して/etcにマウントし、同じ方法を/var、/homeにも繰り返す
- data filesystem があれば
制約と FAQ の要点
- 対応ハードウェアは x86-64 専用で、BIOS と EFI の両方をサポートする
- Raspberry Pi は現在サポートされておらず、backlog に載っている
- Apple M-series はベアメタルではサポートしないが、仮想化での実行は可能
- VMWare/ESX/Proxmox/cloud などの仮想環境で実行可能で、QEMU/KVM と VMware ESXi 用のゲストエージェントを含む
- ソフトウェアは Dockerコンテナのみインストール可能で、ルートファイルシステムへ直接インストールする方式は使えない
- コアシステムは不変だが、設定・カスタマイズ・コンテナデータはデフォルトではメモリに書き込まれ、永続化を有効にしたときだけ再起動後も保持される
- デフォルトのホスト名にはネットワーク競合防止のため machine ID が含まれ、
setup-hostnameで変更すると現在のシェルを除いて即時反映される - 保証はなく、利用結果に対する責任はユーザーにある
- ルートファイルシステムに
wget、nanoのような好みのツールを追加する方向は志向しておらず、目的特化の最小サーバー OSという制約を維持する - プライバシーポリシーの TL;DR としては個人データを収集せず、テレメトリーに同意した場合のみ 匿名データ を収集し、その内容も確認できる
- 年齢関連規制の順守は OS 自体ではなく、その上で提供する ユーザーサービスの責任とする
1件のコメント
Hacker Newsのコメント
何かを実際にリリースしたのは祝うべきことだけど、なぜあえてこれを使うべきなのかはまだよく見えてこない
Flatcar Container Linux、Fedora CoreOS、Talos Linux、IncusOSのように似た目標を持つ代替案はすでにあり、コミュニティや商業的支援もより強固に見える
何が違うのかをもっと明確に説明してくれないと納得しにくい
Proxmoxから移行してVMを全部管理していて、コーディングアシスタントを積極的に使ってIncusOSのCLI設定の自動化、Docker-ComposeイメージのIncusへの変換、
--dangerously-skip-permissionsを使っても気軽に新しいコンテナを立ち上げられるbashスクリプトの作成といったことを処理している一番良い点は宣言的ファイルで管理できるので、ネットワーク構成やリソース設定が常に見通しやすいこと
似た用途ならIncusOSは一度見てみる価値がある
ソフトウェアがある限り保守を飛ばすことはできない
バグがないものはないし、アップグレードやパッチ、管理がまったく不要だと言うなら、結局は侵害されたシステムへの近道になりがちだ
従来のベースシステムで気にする必要のある保守のかなりの部分を減らせる、という話に近く、その理由は 1) インストールされているものがほとんどなく 2) ベースのアップグレードが簡単で、再起動してコンテナを再度立ち上げるだけで済むから
もちろんその上で動かすソフトウェアはアップグレードが必要だが、Dockerベースならそのレイヤーはたいてい別の側で管理されるので、新しいコンテナを取得して再起動すればよく、OSはデータが同じ場所にマウントされることを保証する役割に近い
すべてのソフトウェアをDockerで動かすのが問題ないなら、DebianやRedhatより一段進んだ選択肢に見えるし、CoreOSより手続き的な複雑さも少ない
実際にどれだけ使いやすいかは、とくにストレージ管理の面で少し疑問はあるが、少なくとも何を売りにしたいのかは非常に明確だ
セルフホスティングはできるが、勤務時間外の余暇にも事実上SLAを背負うことになる
だからユーザー数が1人を超えるものはずっと前に全部やめた
それでもTalosのようなプロジェクトが存在するのには理由がある
ターミナルもなく、SSHもなく、パッケージマネージャーもなく、読み取り専用ファイルシステムでsystemdも外し、実行ファイルの数も最小限にすれば、攻撃面は確実に減る
ここで出ているプロジェクト自体の話ではないが、より安全で保守も少なくて済むシステムは実際に存在する
どうせ100%安全にはなれないのだから、3分前に修正されたnpmパッケージでもYOLOで受け入れよう、という方向に行くのは答えではない
興味深くはあるけど、パッチ、アップグレード、そして独自ISOのビルドはどうするのか気になる
ソースリポジトリを見ても、その部分はほとんど見えてこない
最後のコミットが2年前で、3.0バージョンのソースはないようだ
これはOSではなくLinuxディストロでは？
この分野では自分はほぼ初心者だと感じるけど、セルフホスティングは10年以上やっていて、2019年ごろからはUnraidに移行した
Webポータル中心なので扱いやすく、保守も楽だった
このホームサーバーOSはどうやって操作するのか気になる
サイトに画像がないのを見ると、全部ターミナルベースで扱う必要があるのかと思ってしまう
さっきUbuntu ServerにDockerをワンライナーで入れてそのまま使い始めたところだけど、ここで何が正確に違うのか、どんな価値提案なのかがよくわからない
言っている保守が具体的に何を指すのかも気になるし、性能の低いハードウェアで動かすためにもっとスリムにしたサーバーなのかも気になる
ホームサーバーのセットアップを始めたばかりなので、どんな利点があるのか純粋に知りたい
immutable方式の利点は更新にあると言われるが、新しいイメージ版に行って問題があれば前の版でそのまま起動して戻せる
でも機能面では自分もUbuntu Serverで十分だと感じる
年に数回
apt updateとアップグレードをするだけで、ローカル専用かTailscale経由でしかアクセスしないこういうimmutable OSはホームサーバーよりノートPCやデスクトップのほうが魅力的に感じる
ホームディレクトリだけ書き込み可能なので、OSがより安定して壊れにくくなることを期待できる
Lightwhaleで動かすコンテナデータは、定期的にどういう方法でバックアップするのが推奨なのか気になる
よくわからない
Dockerを動かすだけなのに、なぜimmutableが必要なのかわからないし、数分でDockerを入れられるDebianやUbuntuの代わりに、なぜ特殊なDebian派生が必要なのかもわからない
保守も、もともと配布元のリポジトリや公式Dockerリポジトリをパッケージマネージャーで管理すれば済む話ではないのかと思う
こういうimmutableブームは少し消えてほしいし、flatpakやsnapも同じだと思う
Linuxはすでに、こうしたソリューションが解決しようとしていることを元からやってきた
ユーザーはrootなしではベースシステムを触れないし、アプリケーションは依存関係を
/usr/libに入れればいい問題が起きても助けを得やすいのが大きな保険でもある
もっと小さくはできるだろうけど、すでに低性能なBananaPiや低価格のRISC-Vのような変わったハードウェアでも十分動くので、他を求める理由があまりない
こういうものはSwarm modeクラスタにかなり合いそう
ホームサーバーだけに焦点を当てているのかはわからないけど、引き続き見ていくつもり
プロジェクトもとても良さそうだ
でもLightwhaleはすでに本番環境で動いていて、Swarmクラスタ用途にも非常によく合う
すごくすっきりして見える
初心者の立場では、設定を壊さないようにしてくれるこういうアプローチこそ必要なので、ぜひ使ってみたい