私のHomelabはメンテナンスしない
(cleberg.net)- 個人のHomelab運用負担を減らすため、単一サーバー構成と自動更新に集中し、日常的に手を入れる作業の大半をなくした状態
- 複数のサーバーを1台に統合したことで環境の複雑さが下がり、サーバー台数ベースのメンテナンスも 75%減少
- Raspberry Pi 4 は Home Assistant OS に任せ、ネットワークは UniFi の自動・予約更新に任せることで、手動管理ポイントを減らしている
- Docker サービスは週1回
docker compose pullとdocker compose up -dを実行する crontab で更新し、root の crontab は主にバックアップに使っている - 緊急時でなければ月間メンテナンスは約 15分 で、
apt updateや再起動を先送りしても直ちにサービスへ与える影響はほとんどない
単純化したインフラ構成
- Homelab サービスは複数機器から 単一サーバー に統合されている
- 以前は4台のサーバーを使っていたが、現在は1台の物理サーバーにサービスを集約
- クラスター、ハイパーバイザー、ハイブリッドクラウドではなく、地下室にある1台の物理機器で運用している
- この単純化により、サーバー基準のメンテナンス量は 75%減少 した
- Raspberry Pi 4 は別にあるが、Home Assistant OS が自前で更新を処理するため、管理負担は小さい
- 技術的にはサーバーに近いが、実際の使用感は自律的に維持される IoT デバイスに近い
- ネットワーク機器はミニラックの UniFi 構成で運用している
- UniFi Dream Machine Pro、スイッチ、複数の AP が含まれる
- 自動更新と予約更新をサポートしているため、ネットワーク機器も手動で頻繁に触る必要がない
自動化されたソフトウェア更新とバックアップ
- Docker サービスの更新は、サーバー上の単一の crontab エントリで毎週実行される
0 0 * * 0 docker-updatedocker-updateは~/docker/*/配下の各ディレクトリでsudo docker compose pullとsudo docker compose up -dを実行する
- root ユーザーの crontab は大半が バックアップ 用途
- 毎日システムレポートを生成する
- Immich と Piped の PostgreSQL ダンプを作成する
- Plex、Web サーバー、Nginx 設定、Docker ディレクトリ、SSH ファイルを ZFS プールへ
rsyncでバックアップする - Docker ディレクトリのバックアップでは、データベース・キャッシュ・一時ファイル・一部のログパスを除外する
- 残る手動作業は
apt update、apt upgrade、apt autoremoveの実行と、必要に応じた再起動程度- この作業には約 60秒 かかる
- 緊急時でなければ、メンテナンス時間は月あたり約 15分 程度
- 1か月間 SSH で接続して更新しなくても、実サービスには影響がない
- 6か月以上触らなくても壊れない可能性はあるが、わざわざ試すつもりはない
- 現在の構成は、忙しい日々の中でも プライバシー、セキュリティ、利便性 のバランスを提供している
1件のコメント
Lobste.rs の意見
自宅サーバーもほぼ同じように運用している
Debian で無人のセキュリティアップグレードを有効にし、すべてをバージョン固定した rootless コンテナで動かし、Podman Quadlet 経由で systemd に管理させている
Podman の auto-update がコンテナ更新を処理し、systemd タイマーがバックアップやイメージ整理のような定期作業を担う
カーネルのアップグレードがある時やイメージのバージョンを上げる時だけ再起動しに入り、この作業は Ansible が処理する
バージョン固定というのは自動で更新を取ってこないという意味だと理解したが、実際には更新しているようなので、別の対象を更新しているのかよくわからない
別途管理している機器はルーター 1 台だけで、OpenBSD なので新バージョンが出るおよそ 6 か月ごとにアップグレードしている
どちらも退屈なくらい安定している
似ているが、欲しい機能が入るまでは何も更新しない
セルフホストソフトウェア の良いところは、自分のスケジュールに合わせて更新できることだ
すべてが問題なく動いていて、Tailscale 経由でしかアクセスできず、インターネットに直接公開されていないなら、ハードウェア故障を除けばそのまま放っておいても安定している
アプリケーションに到達するデータは結局同じなのだから、同じ脆弱性が悪用されうるのではないかと思う
その状態ならかなり良い状況だと思う
自分もそこを目指しているが、まだ完全には到達していない
Debian のメジャーアップグレード は 2 年ごとにいまだ手作業が必要だ: "Issues to be aware of for trixie", "Obsolescence and deprecation", "Cleanup after the upgrade"
古い Ansible は最新の Debian システムを扱えないので、Debian サーバーを上げると Ansible のバージョンも上げる必要があり、結局 playbook も新しい Ansible に合わせて直さなければならない
今は using more Docker containers でこれを減らそうとしているが、Ansible を完全に置き換えるのは難しそうだ
freeDNS や dynv6.net のように自分でホストしたくないオンラインサービスもあり、これらも時々破壊的変更を出してくる
それでも全体としてはかなり良い方だ
正直に言えば、「メンテナンス不要」のホームラボ管理は、私たちが使うソフトウェア、パッケージ、Docker イメージを管理している世界中の オープンソース開発者 に委ねているようなものだ
自分の構成を「ホームラボ」と呼ぶのは少しためらうが、複数の Docker コンテナ を動かしている unRAID NAS だ
unRAID にお金を払っても満足している理由の 1 つは、Docker サポートがほどよく良く、プラグインでコンテナの自動更新ができ、その他のメンテナンスもかなり簡単だからだ
個人的には「ラボ」は実験する場所に近く、実験そのものをメンテナンスする必要はないという点が少し気になる
コンテナ の利用には長所と短所が混在している
プロジェクトによってはコンテナが第一級の配布手段で、その方法で適切にアップデートを受け取れる
しかし多くの人が管理の曖昧なコンテナを動かしているように見え、そこから多くの問題が生じるだろうと思う
要は、自分が使っているソフトウェアで更新を受ける 正式な経路 が何なのかを把握することにある
自分は主に RHEL クローンを自動更新で運用しており、再起動が必要なら Nagios が知らせてくれる
ほとんどのサービスが RHEL か EPEL に入っているので、メンテナンスはかなり少ない
自分のホームラボのメンテナンスには
pyinfraがちょうどよく手を抜けるレベルだった設定手順をコードとして書いておけるし、特に設定ファイルのようなものに便利で、
nixではこれをどう処理するかと悩まず、必要ならaptを呼べばいいとても賢いツールではないが、単一のシェルスクリプトよりはましで、今後もっと発展させてみたい
エージェント型コーディングを使う場合には、Claude に pyinfra ファイル を見せて構成のデバッグを手伝ってもらえるというおまけもある
サーバーでは NixOS を使っていて、思い出した時にたまに更新している
たいていは
nix flake update && nix run .#deployくらいで済むので、あまり気にしていない自分もかなり似た状況だが、認めたくはないものの、かなりの部分は結局構成が単純になったおかげだ
以前はローテーションログまで含めた完全な 可観測性スタック が好きだったが、最近の厄介ごとは 2 年以上ずっとその複雑さから来る些細な問題ばかりだった
ログやメトリクスのせいでディスクがいっぱいになるようなことだ
解決はとても簡単だが、もうそういうことに対処したくない
docker-compose の構成を最新に保つには Watchtower が気に入っている
https://hub.docker.com/r/nickfedor/watchtower
バージョンを追い続けつつ、破壊的変更をある程度見越せる設定オプションがかなり良い
ベース OS は Debian LTS で無人更新だけ有効にしておき、新しいカーネルが出たら再起動しに入る
本当にやることは多くなく、月 15 分未満という話には同意する