この記事の位置づけ
Ubuntu 22.04 に Cockpit を導入し、Linux サーバーを WebUI から確認できるようにする記事です。Cockpit は常用の管理基盤というより、状態確認、補助操作、検証環境の見える化に向いた Web 管理インターフェースとして扱います。
Cockpit をどう位置づけるか
Linux サーバー管理は CLI を中心に考えるのが基本です。ただし、すべてを CLI だけで確認する必要はありません。Cockpit は、サービス状態、ログ、リソース使用状況、ストレージ、ユーザー、ターミナルなどをブラウザから確認できるため、補助的な管理画面としては便利です。
一方で、Ubuntu Server では Netplan、systemd-networkd、NetworkManager、個別ミドルウェアの設定が混在しやすく、Cockpit だけで全体を正しく管理できるわけではありません。Cockpit で見える範囲と、設定ファイルや Ansible などで管理すべき範囲を分けて考える必要があります。
| 用途 | Cockpit で扱いやすいか | 考え方 |
| CPU / メモリ / ディスクなどの状態確認 | 扱いやすい | ダッシュボードとして使いやすい |
| サービスの起動状態確認 | 扱いやすい | systemd の状態確認には便利 |
| ログ確認 | 扱いやすい | journalctl の補助として使える |
| ネットワーク設定 | 環境による | Ubuntu Server の Netplan 管理とは相性に注意する |
| 証明書や認証の設計 | 限定的 | 配置や権限は CLI / 構成管理で扱う |
| 本番サーバーの一元管理 | 慎重に判断 | 公開範囲、認証、監査を先に決める |
前提
この記事では、Ubuntu 22.04 の基本設定、ネットワーク設定、内部 CA / 自己署名証明書の準備が済んでいる前提で進めます。Cockpit は HTTPS でアクセスするため、検証環境であっても証明書の扱いを明確にしておく方が運用しやすくなります。
- Ubuntu 22.04 Netplan ネットワーク設定 – DHCP / 固定 IP / DNS の基本
- Ubuntu 22.04 easy-rsa – 内部 CA と SAN 付き自己署名証明書を作成する
- Ubuntu 22.04 update-ca-certificates – 内部 CA と自己署名証明書を信頼する
インストール
Cockpit をインストールします。
sudo apt update
sudo apt -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold install cockpit証明書の配置
デフォルトの自己署名証明書をそのまま使うのではなく、内部 CA で発行した証明書に置き換えます。ここでは /etc/my-ssl/certs/si1230.com.cert と /etc/my-ssl/certs/si1230.com.key が用意されている前提です。
sudo rm /etc/cockpit/ws-certs.d/{0-self-signed.cert,0-self-signed.key}
sudo cp /etc/my-ssl/certs/si1230.com.cert /etc/cockpit/ws-certs.d/
sudo cp /etc/my-ssl/certs/si1230.com.key /etc/cockpit/ws-certs.d/
sudo chgrp cockpit-ws /etc/cockpit/ws-certs.d/si1230.com.key
sudo chmod 640 /etc/cockpit/ws-certs.d/si1230.com.keyサービスを再起動して確認する
証明書を配置したら、Cockpit の socket を再起動して状態を確認します。
sudo systemctl restart cockpit.socket
systemctl status cockpit.socketアクセス方法
ブラウザから次の形式でアクセスします。
https://<fqdn>:9090閉域環境や管理ネットワーク内で使う場合でも、Cockpit の公開範囲は絞るべきです。必要であればファイアウォール、リバースプロキシ、VPN、管理端末の制限と組み合わせて考えます。
使う時の注意点
- Cockpit で変更した設定が、既存の構成管理や手動管理方針と衝突しないようにする。
- ネットワーク設定は Netplan / NetworkManager / systemd-networkd の関係を確認してから扱う。
- 本番サーバーでは、Cockpit の公開先、認証、ログ、証明書更新を運用設計に含める。
- CLI で確認できる内容を WebUI で補助的に見る、という位置づけにすると扱いやすい。
Cockpit を使う時の距離感
Cockpit はサーバー状態を Web UI で確認できる便利なツールですが、CLI や構成管理の代わりにするものではありません。ログ、サービス、ストレージ、ネットワークの確認を補助する入口として使うと扱いやすくなります。
公開範囲は必ず絞り、必要であれば VPN や管理ネットワークからだけアクセスできるようにします。
次に読む記事
参考書籍
Advanced Ubuntu Administration and Management Best Practices
Ubuntu Server の運用項目を体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。



NetworkManager がインストールされてしまいます。
私は、 cockpit-networking (ネットワーク管理機能) と cockpit-machines (仮想マシン管理機能) を除いたインストールを実行しています。
sudo apt install -y cockpit-ws cockpit-system cockpit-packagekit cockpit-storaged cockpit-pcp
ご指摘の通り、apt install cockpit では依存関係として NetworkManager もインストールされますね。
ただ、Netplan をデフォルト (renderer: networkd) で使う場合は、Cockpit から管理できないだけで、特に動作に影響はないため、私はあまり問題視していませんでした。
とはいえ、使わないものをインストールしない という観点では、パッケージを絞る方法は確かに有益ですね。
記事の更新も検討してみます。コメントありがとうございました!