Fedora ServerのCockpit Webコンソール:ブラウザでStorage LVMとPodmanコンテナを管理する

Fedora tutorial - IT technology blog
Fedora tutorial - IT technology blog

Fedora Server管理6ヶ月で直面した課題

Fedoraをメイン開発マシンとして2年間使ってきており、パッケージのアップデート速度には満足しています。Fedoraサーバー3台のホームラボに拡張したとき、手動管理の限界が見えてきました:複数のボリュームグループにまたがるStorage LVM、さまざまなサービスを動かす数十個のPodmanコンテナ、そしてこれらすべてを複数のターミナルからSSH経由で管理しなければならない状況です。

CLIが悪いわけではなく、今でもメインはCLIを使っています。ただ、マシンAでコンテナをデバッグしながら、マシンBのディスク使用量を確認したいとき——新しいターミナルを開き、SSHで接続し、df -hとpodman psを入力する——このルーティンが毎日十数回繰り返されます。1回あたり2〜3分ですが、積み重なると無視できません。さらに困るのが、他の人にサーバーの状態を説明するとき。URLを一つ渡す方が、SSH手順を一から説明するよりはるかに楽です。

CLIが時間を節約するどころか手間を増やし始めたとき

ワークフローを振り返ってみると、CLIが余計な手間を生んでいた4つの具体的なポイントが見えてきました:

  • 複数のメトリクスの同時監視:CPU、RAM、ディスクI/O、ネットワーク——複数のターミナルでtop、iostat、netstatを並列実行しなければならず、一画面での全体把握ができない
  • LVM管理:ディスクが一杯になったときにLogical Volumeをリサイズするには、lvcreate/lvextend/resize2fsの正確な構文とデバイス名を覚えていなければならず、1文字ミスるとトラブルになる
  • コンテナのライフサイクル:複数のコンテナを同時にstart/stop/inspect、リアルタイムログの確認——それぞれ個別のコマンドが必要
  • 他デバイスからのリモートアクセス:SSHクライアントが入っていないスマートフォンや別のパソコンからでも、ブラウザは常に使える

Cockpit導入前に試した代替ソリューション

Netdata——優れたモニタリングだが読み取り専用

Netdataは詳細なリアルタイムメトリクスを持つ美しいダッシュボードを提供しています。ただし、読み取り専用です——サービスの再起動も、storageやコンテナの管理もできません。結局ターミナルを並行して開く必要があり、最初の問題は解決しません。

Webmin——機能は豊富だがFedoraスタックとネイティブ統合できない

WebminはIT学習を始めた頃からあるツールで、ほぼ何でもサポートしています。ただしインターフェースが古く、設定が複雑で、何より重要な点として、WebminはFedoraが使うsystemdやPodmanとネイティブに統合できません。追加のラッパー層が必要になり、WebminとCLIの間で動作が一致しないことが起きやすいです。

Portainer——コンテナ管理には優れているが、storage問題は解決しない

PortainerはDocker/Podmanコンテナの管理に非常に優れています。ただしコンテナ部分しか扱えず、storageとシステム監視は別のツールが必要です。

Cockpit:Fedoraスタックとネイティブ統合、トレードオフなし

Cockpitが他の3つと異なる核心的な点は:Red Hatによって開発され、Fedoraが使うスタック——systemd、NetworkManager、Podman、LVM——とネイティブに統合されていることです。追加のラッパー層も、バックグラウンドで動くエージェントも必要ありません。そして何でもやろうとしない:自分が必要なことを的確にこなします。

Cockpitと必要なモジュールのインストール

Fedora Serverでは、Cockpitは通常プリインストールされています。入っていない場合は、すぐにインストールできます:

# Cockpitコアをインストール
sudo dnf install cockpit -y

# ストレージ管理モジュール(LVM、RAID、Btrfs、iSCSI)
sudo dnf install cockpit-storaged -y

# Podmanコンテナ管理モジュール
sudo dnf install cockpit-podman -y

# 有効化してすぐに起動
sudo systemctl enable --now cockpit.socket

重要な注意点:Cockpitはsocket activationを使用します——接続があったときだけ実際に動作し、使っていないときは完全にアイドル状態になります。私のサーバーでは、CockpitはアイドルRAMをほぼ消費しない一方、NetdataやWebminは常時50〜100MBを使い続けます。リソースが限られたサーバーにとってこれは重要な点です。

ファイアウォールの設定と初回アクセス

# firewalldでポート9090を開放
sudo firewall-cmd --add-service=cockpit --permanent
sudo firewall-cmd --reload

# 確認
sudo firewall-cmd --list-services

https://[IP-server]:9090にアクセスします。デフォルトの自己署名証明書を使用しているため、ブラウザがSSL警告を表示しますが、これは正常です。例外を受け入れるか、後でLet’s Encryptで本物の証明書を導入してください。sudo権限を持つLinuxユーザーでログインします。

cockpit-storagedでStorage LVMを管理する

cockpit-storagedがCockpitをインストールした主な理由です。Storageタブには、物理ディスク、パーティション、ボリュームグループ、ロジカルボリューム、ファイルシステムがすべて、リアルタイムI/Oグラフとともに一画面で表示されます。

ログでディスクが一杯になり/varのロジカルボリュームを拡張する必要があったとき、以前は以下を正確に入力していました:

sudo lvextend -L +20G /dev/fedora/var
sudo resize2fs /dev/fedora/var

Cockpitでは:ボリュームをクリックし、リサイズのスライダーを動かし、Growを押す——10秒で完了、デバイスパスを間違える心配もありません。ファイルシステムも自動的にリサイズされます。

LVM以外にも、cockpit-storagedは以下をサポートしています:

  • パーティションの作成・削除とファイルシステムのフォーマット
  • マウント・アンマウントと/etc/fstabの自動更新
  • ハードディスクのSMART statusの監視——ドライブが壊れる前に警告
  • ソフトウェアRAID(mdadm)とiSCSIの設定

cockpit-podmanでPodmanコンテナを管理する

このモジュールを使う前に、Podmanがインストール済みであることを確認します:

podman --version

# インストールされていない場合
sudo dnf install podman -y

Podman containersタブには、rootless(ユーザー)コンテナとrootful(root)コンテナの両方が表示され、各コンテナのリアルタイムCPU/RAM使用量も確認できます。UIからできること:

  • コンテナのリアルタイムログ確認——podman logs -fの代替
  • コンテナのstart/stop/restart/delete
  • 環境変数、マウントポイント、ポートバインディングの確認
  • コンテナを新しいイメージにcommit

最も便利なのは、ブラウザから直接リアルタイムログを確認できることです。夜中にスマートフォンでデバッグする際、モバイルSSHクライアントを開く必要はありません——ブラウザを開いてCockpitのURLにアクセスするだけで、すぐにログが見えます。

システム監視とサービス管理

デフォルトのダッシュボードでは、CPU、RAM、ディスクI/O、ネットワークトラフィックがリアルタイムグラフで常時更新されます。Servicesタブにはすべてのsystemdユニットが状態とともに一覧表示され、ターミナルなしでstart/stop/restartとjournal logの確認ができます。

1つのインターフェースで複数のサーバーを管理

最も便利な機能:マシンAのCockpitからマシンBを追加し、ウィンドウ切り替えや新しいターミナルを開くことなく、1つのブラウザタブから両方を制御できます。リモートサーバーでは、Cockpitが動いていれば十分です:

# リモートサーバーの確認
sudo systemctl status cockpit.socket

Cockpit UIで:Hosts → Add new host → IPを入力してSSH認証。それ以降、2台のサーバー間の切り替えはサイドバーのホスト名をクリックするだけです。

本番環境でのアクセス制限

デフォルトでは、CockpitはすべてのLinuxユーザーのログインを許可します。本番環境では制限することを推奨します:

sudo tee /etc/cockpit/cockpit.conf << 'EOF'
[WebService]
AllowedUsers = youradminuser
Origins = https://your-domain.com https://[SERVER-IP]:9090
EOF

sudo systemctl restart cockpit

CockpitはSELinux Enforcingモードでも問題なく動作します——他のツールのようにSELinuxを無効化する必要はありません。これはFedoraのSELinux設定記事と組み合わせる際の大きなメリットです。

CockpitがFedoraスタックに最適な選択である理由

6ヶ月間実際に使い続けて、Cockpitを使い続ける理由:

  • 真のネイティブ統合:CockpitはCLIコマンドの出力をパースするのではなく、systemd D-Bus API、Podman REST API、LVMを直接呼び出します。UI操作の結果はCLIと完全に一致し、予期せぬ動作がありません
  • 柔軟なモジュール化:必要なモジュールだけインストールできます。ホームラボと本番サーバーでは必要なものが異なります
  • アイドル時のリソース消費ゼロ:Socket activation——使っていないときはバックグラウンドで何も動いていません
  • Red Hatによるメンテナンス:Fedoraのアップデートが速くても、Cockpitはついてきます——最新のカーネルとsystemdバージョンとの互換性を心配する必要はありません
  • SELinux対応:Enforcingモードで問題なく動作し、設定済みのセキュリティポリシーを破壊しません

オートメーション、スクリプティング、複雑な操作にはCLIを引き続き使っています——Cockpitはターミナルの代わりにはなりません。ただし、素早いシステム状態の確認、ディスクが一杯になったときのstorage管理、どのデバイスからでもコンテナのデバッグ——こういった用途では、Cockpitはブラウザのタブにpinしておく他のダッシュボードと並んで常時開いているツールになりました。

Share: