ターミナルアプリに「サーバールーム」を作った話 — KKTermの新しいIT Opsモジュール

この記事は、自作OSS「KKTerm」の開発記録兼紹介です。

SSH、SFTP、RDP、VNC、Web UI。インフラ運用では、対象が増えるほど「接続する」だけでは足りなくなります。

• この機器はどの拠点・サーバールーム・ラックにあるのか
• 同じ確認コマンドを複数ホストで実行したい
• 実行結果をホストごとに追いたい
• 障害の兆候を検知したら通知やタスクを動かしたい

こうした作業を、普段使っているターミナルの外へ切り離さずに扱えないか。そこでKKTermに、新しい IT Opsモジュールを追加しました。

KKTermとは

KKTerm は、Tauri v2、Rust、React/TypeScriptで開発している、クロスプラットフォームのローカルファーストなデスクトップ管理ツールです。

ローカルターミナル、SSH/SFTP、FTP/FTPS、Telnet、シリアル、RDP/VNC、Webページ、ローカルファイルなどを、1つのウィンドウとワークスペースで扱えます。データは基本的に手元へ保存し、テレメトリはありません。

今回紹介するのは、v0.1.124で開発中のIT Ops機能です。

まず「場所」を見えるようにする

IT Opsでは、機器を次の階層で整理します。

Site
└─ Server Room
   └─ Rack
      └─ Rack Device / Host

単なる一覧ではなく、同じデータを用途に応じた3つの表示へ切り替えられるようにしました。

1. フロアプラン

ラック、電源、空調、センサーなどをフロア上へ配置できます。編集モードでレイアウトを組み、通常時は設備の位置や状態を俯瞰するための画面として使います。

ラック名だけでなく、消費電力や搭載数など、現場で確認したい情報を空間と一緒に読めることを重視しました。

2. 2.5Dビュー

同じサーバールームを2.5Dでも表示できます。

「正確なCAD」ではなく、ラック列、通路、空調やUPSの位置関係を素早く把握するための運用ビューです。画面上部から正面図、フロアプラン、2.5Dを切り替えられます。

そして台湾発のアプリらしく、ラック上には 乖乖（Kuai Kuai） も置けます。台湾のサーバールームで、機械が「乖乖＝おとなしく」動くよう願って緑色のお菓子を置く文化へのオマージュです。KKTermという名前もここから来ています。

3. ラック正面図

ラックを開くと、U位置に合わせた機器の正面図を表示します。

サーバー、スイッチ、ルーター、ファイアウォール、パッチパネル、PDU、UPSなどを配置でき、接続情報を持つ機器は、管理対象のConnectionやHostと結び付けられます。前面・背面の両方を扱え、ラック単位の編集やエクスポートにも対応しています。

見た目を作り込んだ理由は、飾りではありません。機器名だけの表よりも、「何Uを使っているか」「空きがどこにあるか」「隣に何があるか」を一目で判断しやすいからです。

トポロジーだけでは終わらない

IT Opsモジュールは、ラック管理だけでなく、実際の運用フローまで同じモデルでつなげます。

Hosts

既存のSSH ConnectionをHostへ関連付け、到達性や現在のBatch Run状態、直近の実行結果を一覧で確認できます。

Task Library

何を実行するかを、再利用可能なTaskとして管理します。スクリプトだけでなく、順番に処理するPlaybookも作成できます。

Taskは対象ホストを内包しません。同じTaskを複数のSiteで再利用できるように、実行内容と対象を分離しています。

Batch Runs

選択したHostに対してTaskを並列実行し、ホストごとの進行状況、標準出力、終了コードを追跡します。完了後は統合されたRun Reportをローカルへ保存します。

Automations

Automationは「トリガー + 条件 + アクション」の永続的なルールです。通知、Webhook、メール、Taskの起動などを組み合わせられ、アプリの再起動後も再度有効化されます。

概念としては、次のように整理しています。

Task + Targets
  └─ 今すぐ実行 → Batch Run

Trigger + Condition + Task + Targets
  └─ 条件成立時に実行 → Automation

ローカルファーストを崩さない

KKTermは、クラウドサービスではなくデスクトップアプリです。

• 構成データとRun HistoryはローカルのSQLiteへ保存
• パスワードなどの秘密情報はOSのキーチェーンへ保存
• 実行中のSessionや進捗はメモリ上だけで管理
• テレメトリなし
• AIによる操作は承認を前提にする

「設備情報を入力するために、まず外部サービスへ送信する」という前提にはしていません。個人のホームラボから、閉じたネットワーク内の運用まで、自分の管理下で使えることを優先しています。

作ってみて分かったこと

ラックUIで難しかったのは、きれいな絵を描くことより、データモデルと操作を矛盾させないことでした。

• Server Roomに属さないRackを作らない
• 前面と背面のU位置を別々に扱う
• 機器サイズと配置範囲を検証する
• Connection、Host、受動的なラック部品を混同しない
• 編集中の配置状態と、保存される構成を分ける

見た目が空間的になるほど、ドラッグ&ドロップや表示倍率だけでなく、削除、移動、再起動後の復元、エクスポートまで一貫して動かす必要があります。この部分はまだ改善を続けています。

現在地

KKTermはまだ若いOSSです。IT Opsも、大規模監視基盤やDCIM製品を置き換えるものではありません。

目指しているのは、普段のターミナル、リモート接続、ファイル転送、設備の見取り図、複数ホストへの定型作業を、1つのローカルアプリで自然につなぐことです。

今後は、Batch Run結果の集約・差分表示、より実用的な組み込みTask、Automationのイベント履歴などを強化したいと考えています。

試してみたい方へ

• GitHub: ryantsai/KKTerm
• 最新リリース: Download KKTerm
• ライセンス: MIT

ラック表示、運用フロー、対応してほしい機器やTaskなど、フィードバックやIssueを歓迎します。気に入っていただけたら、GitHubでStarを付けてもらえると開発の励みになります。