Fleetdを公開しました：Linuxサーバーとルーターを1つの管理画面に

サーバーやルーターが数台なら、管理は簡単に見えます。状態を確認するときはSSHで接続し、サービスが落ちたらログを読み、更新するときはコマンドを実行するだけです。

面倒なのは、それぞれの作業場所が分かれていることです。サーバーとルーターでは入口が違い、アラートが出ても、対象を探し、環境を確認してから調査を始めます。

こうした日常作業をまとめたいと思いました。1つのページでオンラインの機器とアラートを把握し、詳細を開き、必要ならコマンドやターミナルへ進む。そのために作ったのが Fleetdというセルフホスト型のLinuxサーバー・ルーター管理ツールです。

コードはMITライセンスで公開し、最初の公開版はv0.3.0。英語と中国語のドキュメントも公開しました。

今回は解決したい問題、現在の機能、主要な設計判断を紹介します。実装の詳細は後の記事で扱います。

問題を見つけてから対応するまでをつなぐ

監視でディスク不足が分かっても、増えているディレクトリを調べる必要があります。サービスの失敗なら、ログと設定を確認し、再起動するかを判断します。

少数の機器を自分で管理する場合、これらは連続した作業です。同じ機器を別のツールで何度も探さずに済むよう、その流れを管理画面に残したいと考えました。

機能	現在できること
監視	CPU、メモリー、負荷、ディスク、通信速度と7日間の履歴
稼働状態	失敗したsystemdユニット、Dockerコンテナー、WireGuardピアの情報
アラート	オフライン、継続的な資源超過、容量不足、関連サービス異常。メール通知も設定可能
リモートコマンド	ローカル権限に従う署名付きコマンドを1台または複数台で実行
Webターミナル	full権限の機器で対話セッションを開く
エージェント管理	新規機器の承認と署名付き更新パッケージの配布

Fleetdの機器一覧。資源使用量とオンライン状態を表示

プロジェクト文書にある一覧画面の一部です。数値は画面構成を示すもので、性能測定結果ではありません。

情報は機器の環境と併せて読む必要があります。systemdの状態はsystemdを使う環境が対象で、OpenWrtに同じサービス一覧を求めるものではありません。WireGuardのハンドシェイク時刻も、通信や設定を考慮して判断する手掛かりです。

まずは異常から調査へ進める入口を作ります。複雑な監視ルール、長期分析、全面的な構成管理には、それぞれを得意とするツールを使えます。

サーバー1台と各機器のエージェント

サーバーは管理画面、機器情報、監視データ、操作履歴を扱い、PostgreSQLに保存します。管理対象のLinux機器ではエージェントが状態を集め、要求を受け取り、実行可否を判断します。

Vue 3の管理画面はビルド後にGoのサーバーバイナリーへ組み込みます。エージェントもGo製で、Linux amd64とarm64の版を公開しています。導入前には機器のアーキテクチャを確認してください。OpenWrt搭載というだけでは公開バイナリーが動くとは限りません。

サーバー、データベース、各機器のエージェントと設定という境界が明確です。調査でも、接続できたか、データが上がったか、要求が届いたか、なぜ受理または拒否したかを順に追えます。

ルーターでは接続方向から考える

クラウドサーバーに公開アドレスがあっても、家庭のルーターはNATの内側かもしれません。管理のために新たな外向け入口を設けると、設定と保守が増えます。

Fleetdではエージェント側からサーバーへ接続します。設定されたサーバーに到達できれば、管理対象側に専用の着信管理ポートを開ける必要はありません。

異なるネットワーク上のLinux、OpenWrt、iStoreOS機器をまとめるのに向いています。ただしサーバーはエージェントから到達できる必要があり、本運用では文書に従ってHTTPSとWebSocket転送を設定します。

新規機器は接続直後から操作できるわけではなく、承認待ちになります。管理者はインストーラーと管理画面のフィンガープリントを比較し、承認または拒否します。今つながったのは、自分が追加しようとした機器なのか。 ホスト名や一覧への追加だけでは、その確認を代替できません。

次回は登録、フィンガープリント、再接続を詳しく扱います。

見える機器をすべて自由に操作できる必要はない

監視だけの機器もあれば、決まった保守操作だけを許す機器もあります。任意コマンドや完全なターミナルが必要なのは一部です。

Fleetdではエージェントのローカル設定で権限を決めます。

権限	許可する操作
monitor	監視のみ。リモートコマンドは実行しない
allowlist	ローカルで定義した操作だけ
full	任意コマンドとWebターミナル

コマンドは管理者のブラウザーで署名し、エージェントが信頼する公開鍵で検証します。対象、有効期限、ローカル権限も確認します。サーバーは要求を転送しますが、署名のない通常の要求だけで実行させることはできません。

この設計はサーバーからの指示を無条件で信じる範囲を減らします。ただし、ブラウザーとそこで動くフロントエンドコードが信頼できることも前提です。

管理画面はサーバーから配信されるため、サーバーが侵害されれば、後から開くページが差し替えられる可能性があります。秘密鍵がエクスポート不可でも、悪意あるコードによる署名呼び出しの試みまで防ぐわけではありません。署名だけを理由に、サーバー侵害後も完全に安全とは言えません。

この信頼関係は別の記事で詳しく説明します。導入時は監視だけならmonitor、固定操作ならallowlistを優先し、ターミナルが必要な機器だけfullにするのが出発点です。

更新にも独自の信頼の仕組みを持たせる

機器ごとに新しいプログラムを手作業でコピーするのは手間です。一方、ダウンロードしたファイルを無条件で実行しても、正当な更新なのかという問題が残ります。

Fleetdは署名付きリリースパッケージを使います。公開者が自分の環境で署名し、エージェントは設定済みのリリース公開鍵で検証します。コマンド用の署名とリリース用の署名は目的が異なります。

GitHub Releasesの通常バイナリーは対応アーキテクチャへの手動導入用です。.releaseパッケージは、対応する公開鍵を信頼するエージェントだけが利用できます。

独自に運用する人は文書に従って自分の鍵と更新手順を整えます。作者のパッケージをアップロードすれば、どの環境でも受け入れられるわけではありません。版の判定、検証失敗、更新時の復旧は後で説明します。

Docker Composeでサーバーを試す

DockerとComposeプラグインを用意し、手元のコンピューターで実行します。

git clone https://github.com/weiyi0/fleetd
cd fleetd
git checkout v0.3.0
docker compose up -d
docker compose run --rm fleetd admin-add admin

指示に従って管理者パスワードを設定し、http://localhost:8480を開きます。画面は英語と中国語に対応します。

記事と条件をそろえるためv0.3.0に固定しています。Composeはソースからサーバーをビルドし、PostgreSQLも起動します。初回は依存関係の取得とコンパイルがあるため、所要時間は環境によります。

ここで起動するのは管理画面までで、管理対象はまだ登録されていません。 Dockerイメージが署名付きエージェントを自動生成することもありません。

最初はクイックスタートに沿ってエージェントをビルドし、手動起動して登録を試せます。長期運用では自分のリリース鍵を設定し、署名付きパッケージをアップロードして管理画面の導入手順を使います。

Composeのサンプルには例示用のDB認証情報があり、8480番ポートもループバック限定ではありません。ローカル試用中は接続元を制限し、ネットワークで使う前に導入文書に沿って認証情報とHTTPSを設定し、DBと鍵をバックアップします。

復旧しやすいテスト機から始め、指紋、状態表示、許可された操作を確認してから台数を増やすと、環境差を見つけやすくなります。

最初の公開版がv0.3.0の理由

既存環境のエージェントはすでに0.2.0でした。更新先は現在より新しい版である必要があるため、公開版もその順序を引き継ぎました。

版番号は開発の順序を示します。成熟度は利用と検証を積み重ねて得るものです。現在のFleetdは、少数のLinuxサーバーやルーターを自分で管理し、データを手元に置き、基本的な導入と権限を理解したい人に向いています。

コード、バイナリー、文書を公開することで、導入前に動作を確認できます。機能表だけで既存のあらゆる運用ツールを置き換えるとは言えません。まずは状態、アラート、必要な保守をつなぎ、機器ごとの権限を明確にすることに集中します。

この後の連載

能動接続と承認、ブラウザー署名、ローカル権限、OpenWrt対応、アラート、更新を順に扱います。AIを使った開発過程も振り返る予定です。

どんな問題を解決し、どんな制約が増えたのか、具体的な判断を残したいと思います。実際の問題と検証記録も開発に合わせて追加します。

コードと文書をぜひ見てください。通常の質問はIssueへ、脆弱性はGitHubの非公開報告窓口へお願いします。日常保守の切り替えを減らし、この連載が似た開発の参考になればうれしいです。