サーバー向けWebベースのグラフィカルインターフェース Cockpit
(cockpit-project.org)- Cockpit は、Linuxサーバーをブラウザーから管理するためのグラフィカルインターフェースで、初心者から専門管理者まで、個別システムの状態をすばやく確認し操作できるようにする
- コマンドラインと同じ システムAPIとコマンド を使用するため、Cockpit、CLI、Ansible、既存のサーバー管理ツールを併用しても管理フローが衝突しない
- ネットワーク、ファイアウォール、RAID・LUKSストレージ、仮想マシン、コンテナ、ログ、ハードウェア、更新、性能、ユーザーアカウント、systemdサービス、リモートターミナルを1つの画面で扱える
- デフォルトの認証はシステムの 通常のユーザーログインと権限 に従い、single-sign-on や他の認証方式にも対応し、必要なときだけ systemd socket activation によって起動される
- 主要なLinuxディストリビューションにインストールした後、Windows、MacOS、Androidを含むOSのブラウザーから、サーバーの 9090ポート に接続して利用できる
ブラウザーで扱う個別サーバー管理
- Cockpit は、サーバー向けに作られた統合Webベースのグラフィカルインターフェース
- 対象ユーザーは幅広い
- Windows管理者も含むLinux初心者
- Linuxに慣れているが、グラフィカルな方法でサーバーを簡単に管理したいユーザー
- 他のツールを主に使いながらも、個別システムの概要を確認したい専門管理者
- 既存の管理方法を置き換えるのではなく、同じシステムを複数の方法で管理できるよう設計されている
- Cockpit と コマンドラインユーティリティ を併用できる
- Ansible や他の既存ツールも引き続き活用できる
- Linux以外の機器から接続するときに便利な内蔵ターミナルを提供する
- Linuxコマンドを覚えていなくても、Webブラウザーでサーバーの状態を見てマウスで操作できる
- コンテナ起動
- ストレージ管理
- ネットワーク設定
- ログ点検
- Cockpit は、個別サーバー向けのグラフィカルな「デスクトップインターフェース」と見ることができる
認証、統合、拡張の仕組み
- Cockpit はシステムにすでに存在する API を使用し、新しい下位システムを作ったり独自のツール層を追加したりしない
- デフォルトでは システムの通常のユーザーログインと権限 を使用する
- ネットワーク全体のログインは single-sign-on や他の 認証 手法でサポートされる
- 使用していないときはバックグラウンドで常時実行されず、systemd socket activation により必要なときだけ起動される
- 各 Cockpit ホストで実行できる操作は次のとおり
- ネットワーク設定の確認と変更
- ファイアウォール設定
- RAID と LUKS パーティションを含むストレージ管理
- 仮想マシンの作成と管理
- コンテナのダウンロードと実行
- システムログの閲覧と検索
- システムハードウェアの確認
- ソフトウェアのアップグレード
- 性能の確認
- ユーザーアカウント管理
- systemd ベースのサービスの確認と操作
- ローカルWebブラウザーからリモートサーバーのターミナルを利用
- 複数のCockpitサーバー 間の切り替え
- アプリとアドオン のインストールによる機能拡張
- カスタムモジュール の作成
- トラブルシューティングにも活用できる
- ネットワーク問題の診断
- 誤動作する仮想マシンの発見と対応
- SELinux ログの確認と、一般的な違反事項のワンクリック修正
- CPU負荷、メモリ使用量、ネットワーク活動、ストレージ性能をシステムジャーナルと関連付けた詳細メトリクスの確認
- オプションおよびサードパーティ製アプリケーション をサポートする
- ユーザビリティ調査によって設計をテスト・調整し、すべてのコード変更はマージ前に必須テストを通過する
- 無料で利用でき、GNU LGPL で提供される
インストールと接続
- 主要なディストリビューションにインストールでき、起動後はどのOSの主要Webブラウザーからでも接続可能
- Windows、MacOS、Android を含む
- インストールと有効化 後、サーバーの 9090ポート に接続する
- 同じマシンのブラウザーでは
https://localhost:9090/で接続できる
- Cockpit は時間ベースのリリースサイクルを採用しており、新バージョンは 2週間ごと に公開される
2件のコメント
Cockpit - Linuxサーバー管理統合Webインターフェース
Hacker News の意見
グラフィカルな管理インターフェイスをけなし、コマンドラインだけを好むのは、木を見て森を見ずに近い態度です
クリックでサーバーを運用するのが良いやり方ではないとはいえ、正直に言えば
sshも運用方式としては同じです実際の本番サーバーの状態は最初から再現可能であるべきで、OS のインストール、ソフトウェアの追加、設定の適用後は触らないのが正しいです
sshであれ Cockpit であれ、直接入ると何かを壊してしまう可能性が高いですサーバーに直接入る必要があるのは探索的な作業をするときだけで、そのときは GUI とコマンドラインの優劣はそれほど明確ではありません
GUI は発見しやすさと可視性に優れているため、設定方法を探る実験段階で役に立ちます
なぜサーバーの状態が最初から再現可能でなければならないのか、「最初から」とは何なのか、なぜクリック運用がだめなのか、説明が必要です
OS のインストール、ソフトウェアの追加、設定の適用だけでサーバーの状態が完全に捉えられるとも言いにくいです
ソフトウェアのパッチレベル、アプリケーションデータ、ユーザーデータもサーバーの状態に含まれます
本番サーバーの状態はバックアップから復元すれば正確に再現でき、バックアップ／復元はクリック運用とも相性がよく、OS の再インストールや設定スクリプトより速く信頼性が高い場合があります
不揮発性データを保存するサーバーなら、新しいサーバーをデプロイした後にユーザーデータを復元するため、いずれにせよバックアップシステムが必要です
誰もがオーケストレーションプラットフォーム上で大規模な Web プラットフォームを運用しているわけではありません
ただしペット式のサーバーであっても、復旧や再構築の方法は知っておくべきで、そうでなければまともな災害復旧戦略がないということです
ホームラボで Raspberry Pi の設定に Ansible を使っていますが、OS インストール部分はブートメディアにイメージをビット単位でコピーし、一部の選択設定を行う方式なので、可能に見えます
ターミナル作業を好みますが、可視化には GUI のほうが優れているというのは議論の余地もないと思います
このプロジェクトの素晴らしい点は、systemd のソケットアクティベーションを使っているため、常時実行されるサーバープロセスが不要なことです
Cockpit を使っていないときはリソースの無駄がなく、ページへのアクセスは実質的にコマンドラインツールを実行して終了するのと同じです
設計が本当に美しいです
inetd以降、1986 年から似たような方式はありました細部の実装は違いましたが、大きなアイデアは同じで、一時は人気がありましたが特別な理由もなく流行が過ぎました
良いサーバープロセスは何もないときはアイドル状態で、実メモリ使用量もごく小さく、スワップアウトしやすいべきです
あるサーバーが用途上メモリを多く使うなら、オンデマンド起動で断続的なメモリ圧迫を起こすことも望まないでしょう
ただし、初期ブート時にサービス起動を待ってブロックされる問題を避けやすくなるため、起動性能には役立ちます
誰かが SSH で接続するまでは
sshdプロセスが起動しませんhttps://discourse.ubuntu.com/t/sshd-now-uses-socket-based-ac...
覗いてみるほど、優れていて便利な機能が次々に出てきます
小さな Raspberry Pi たちにインストールしておくとよいです
ターミナルの前にいないときに状態をざっと確認したり、Web ブラウザしかない状況で Web サーバー経由で実質ネイティブのように SSH 接続し、実際のコマンドプロンプトで
curl ...etc...を実行できたりして、とても便利ですsystemd のソケットアクティベーションは、エンドユーザーの Web クライアントがログ閲覧のような REST/GQL リクエストを送るときだけ使われる、という意味なのか気になります
「ポーセリン（porcelain）」には価値があります
既成のバックエンドがあるにもかかわらず、プロダクト開発を UI/UX まで押し進められずに畳まれたスタートアップを見てきました
ある会社では、完全カスタムのコンテナオーケストレーターでできたバックエンドを、週末のうちに AWS Lambda と ECS で置き換えられることを示しましたが、UI/UX とワークフローツールははるかに時間がかかる仕事でした
それでも「新しい Raft ベースのクラスター」を作ることに、お金と時間を浪費し続けていました
そのさなかに「バッチ処理の追加」という仕事を任され、すでに Go を使っていたので内部的に Nomad を組み込んで済ませました
技術のための技術だけでなく、機能をリリースするチームで働くのがよいです
https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
この分野のあらゆるツールには「ディスク容量不足」という巨大なバナーがあるべきです
サーバーをデバッグする人たちにとっても、意外とこれが常識ではない場合があります
2022年、コメント81件: https://news.ycombinator.com/item?id=31439811
2021年、コメント128件: https://news.ycombinator.com/item?id=26197510
2018年、コメント149件: https://news.ycombinator.com/item?id=16445612
これは使わないと思う
開いたポートが1つ、休みなく脆弱性をスキャンするボット向けの攻撃対象領域が1つ、常に最新状態に保たなければならないサービスがもう1つ増える
ただし、Linuxサーバーをより扱いやすくする助けにはなりそう
特にPHPベースの共有ホスティングから完全なVPSへ移行するものの、サーバー知識はあまりなく、cPanelやDirectAdminのようなものを求める人には有用
両者の違いはよく分からない
実際にRHCEだが、このスレッドはRed Hat側のクリックファームのように感じるほど、不自然なほど好意的な雰囲気が強い
Cockpitは悪くないが、実質的にはRed Hat版のWindows Server Managerに近く、Server Managerから直接影響を受けた可能性が高い
何年にもわたり、開発と改善の速度も苦痛なほど遅かった
SSHセッションに慣れている人は、新しいVMを作る時くらいを除けばCockpitを使わないし、Proxmoxと比較するのは筋違い
Proxmox UI機能の4分の1もなく、VM管理機能も比較的最近入ったうえ、ブラウザー経由の遅延と制約のため、今でもVirtual Machine Managerの方が優れている
Cockpitではできないことが多く、今後もできないことが多い
クリックしたい人、Bashの
for/whileループを使えない人、パイプのチェーンを理解していない人、vimが嫌いな人のためのツールに近い言ってみればRed Hat向けのwebminで、多少格好よくはあるが古すぎ、開発は遅く、過剰に持ち上げられていて、認定試験に必要なこと以外では使ったことがない
つまり、正しいとも言える
悪用が心配ならhn@ycombinator.comへメールすれば、データを見るとされている
https://news.ycombinator.com/newsguidelines.html
家族が旅行中にペットを見るため、より良いカメラモジュールを搭載したRaspberry Piカメラを複数台動かしている
RTSPカメラストリームは各機器のsystemdユニットとして実行され、パケットがストリーミングされているかを確認するヘルスチェックも別のsystemdユニットとして置いている
各カメラは管理しているZeroTierネットワーク上でプライベートIPを受け取る
Cockpitは必要な時だけ実行されるので、管理用に入れておかない理由がない
ときどきカメラの1台が空フレームだけを出し始めるのだが、休暇中にキーボードを探してSSHで入りストリームユニットを再起動するより、スマートフォンのCockpit Webインターフェースで処理する方がずっとよい
空フレームを検知するヘルスチェックを作ることもできるが、年に数回しか起きないことのためにそれを書くより、Cockpitで再起動する方がはるかに簡単だ
iPadを含むどんなプラットフォームからでもアクセスでき、パッケージのインストールと証明書の追加程度で済むほど設定もほとんど不要
VMを動かすDebianサーバーではProxmoxではなくCockpitを使っているが、その方がはるかに侵襲性が低く、そのマシン群がDockerコンテナなど他の用途も兼ねているため
2019年ごろからこの用途で使っている
統計画面も有用だが、それだけを理由にインストールはしないと思う
システム全体を乗っ取らずに、単一マシン上でWebブラウザーからlibvirt VMを作れる、よく保守された他の選択肢はほとんどない
NetworkManagerとしか使えないが、VM用のネットワーク構成が少しでも複雑になると、通常はNetworkManagerを無効にしなければならないため、Cockpitは事実上使えなくなる
GUIでVMを管理したい人にはvirt-managerの方がはるかに強力
[1] https://virt-manager.org/
品質は「そこそこ」程度
ごく小さな一部の用途には使えるが、ホームサーバーを運用するなら避ける
Cockpitのファイルサーバーインターフェースのプラグインは古くて良くない
いったい何に使うのかよく分からず、簡単なモニタリング程度は可能だろうが、管理ツールとしてはいまひとつ
なぜRed Hatがこのプロジェクトを推しているのか分からず、実用的な用途はあまりない
systemdサービスの一覧を表示することが、コマンドライン出力ですべて見るより役に立つわけではない
NASを自前ホスティングするなら、CockpitはOMVよりはるかに良いと思う
OMVにはCompose対応のDockerプラグインがあるので、Portainerのような別のDocker GUIは不要で、WindowsクライアントからのSMB共有もなぜかより安定している
初心者にやさしいGUIと姿勢があり、他のユーザーと共有しやすく、fail2banやWireGuardのような標準搭載機能もある
CockpitはEL/Fedoraディストリビューションではファーストクラス市民で、PodmanはサポートするがDockerは対象外で、Compose/Quadletのサポートもない
VM管理やターミナルのような強力な機能はあるが、Samba関連のバグがある
現在はOMVでローカルネットワークのファイル共有と、いくつかのDockerコンテナを動かしている
うまく動いているが、機能の90%は使っていない
気になる人向けに見ると、https://github.com/cockpit-project/cockpitによれば、Cockpitは複数の言語で書かれており、Cが最も多く、JavaScriptとPythonがそれに続く
src/cockpitはおそらく主なバックエンドロジックに見え、Pythonである新しいブリッジはPythonで書かれており、時期が来たらWebサーバーもよりモダンな方法で書き直したい
どんな依存関係があるのか、ロギングライブラリやCurlの脆弱性を気にすべきかといった点も重要
製品が単一の明確なスタックで書かれているのか、複数の技術が混在しているのかを見るのも興味深い