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しておく他のダッシュボードと並んで常時開いているツールになりました。

