不想天天敲 systemctl？用 Cockpit 把 Linux 运维搬进浏览器，再远程管理

不想天天敲 systemctl？用 Cockpit 把 Linux 运维搬进浏览器，再远程管理

前言

刚开始接触 Linux 服务器时，我最不适应的并不是某一条命令有多难，而是很多状态都藏在命令后面：CPU、内存、磁盘、systemd 服务、日志、用户、网络，想看一项就得想起一套对应指令。命令行当然很重要，但如果只是想快速确认“机器现在怎么样、哪个服务挂了、日志里发生了什么”，我更愿意先有一个能直接看全局的入口，再决定要不要继续进终端深挖。Cockpit 吸引我的地方就在这里——它把常见的 Linux 管理动作搬进浏览器，但又没有把命令行彻底藏掉。尤其是临时排查一台不常登录的服务器时，先有个总览页面，往往比从零回忆命令更省时间。

这次我在 CentOS 7 环境里安装 Cockpit，前面先准备 epel-release 和 KVM / libvirt，再通过 --disablerepo=pgdg-common 安装 Cockpit，启动后从 9090 进入 Web 控制台。实际查看了系统性能、日志、用户、服务和内置终端几个页面。局域网验证完成后，再安装 cpolar，把 Cockpit 的 9090 页面提供到公网，先测试随机地址，再切换到固定二级子域名 cockpitt。我不会把它写成“零命令行运维”，因为安装本身和复杂排障仍然离不开终端；更准确地说，它把大量日常查看和基础操作从命令行搬到了一个更直观的界面里。

1. Cockpit 更适合做什么？

Cockpit 是一个 Linux Web 管理控制台。

它最适合我日常做的几类事情：

• 看 CPU、内存、磁盘、网络状态；
• 查看 systemd 服务；
• 翻系统日志；
• 管用户；
• 进内置终端；
• 在支持的环境里继续扩展容器、虚拟机等模块。

我不会把它理解成“以后彻底不用命令行”。

更实用的定位是：

先用 Web 页面快速看全局，需要深入排查时再进终端。

这样既降低了日常查看成本，也不会把复杂运维问题过度简化。

2. 先安装 epel-release

这次环境使用 CentOS 7。

先执行：

yum install epel-release

安装完成以后，继续准备 KVM / libvirt 相关组件。

3. 准备 KVM 和 libvirt

执行：

yum install qemu-kvm libvirt libvirt-daemon virt-install virt-manager libvirt-dbus systemctl start libvirtd.service

这里这条命令把多个 KVM / libvirt 软件包和 systemctl start libvirtd.service 写在了同一行，我按当前步骤保留。

随后再单独执行一次：

systemctl start libvirtd.service

这一步用于启动 libvirtd 服务。

虽然前面功能介绍里提到了 Cockpit 的虚拟机管理扩展，但这次后面的实际演示重点并不在 KVM，而是系统、日志、用户、服务和终端页面。

4. 安装 Cockpit

安装 Cockpit 时，这次使用：

sudo yum install -y --disablerepo=pgdg-common cockpit

这里加了：

--disablerepo=pgdg-common

原因是当前环境里 PostgreSQL 仓库曾经出现报错，所以安装时先禁用这个仓库。

安装完成以后启动 Cockpit，并设置开机自启：

systemctl start cockpit
systemctl enable cockpit

然后查看服务状态：

systemctl status cockpit

如果服务已经正常启动，就可以进入浏览器测试。

5. 通过 9090 打开 Cockpit

浏览器访问：

http://IP:9090

这里有一个值得留意的地方。

功能介绍部分写的是：

https://你的服务器IP:9090

而实际部署步骤使用的是：

http://IP:9090

两种写法在这套材料里同时存在，我不主动统一。真正使用时，以当前环境实际能打开的 Cockpit 地址为准。

6. 登录：直接使用 CentOS 7 系统账号

进入登录页以后，使用 CentOS 7 的用户名和密码登录。

登录成功以后进入控制台。

这里我比较喜欢 Cockpit 的一点是：

它没有另外创造一套完全独立的“管理用户逻辑”，而是和系统本身的账号、权限关系绑定在一起。

这也意味着，Web 页面能操作到什么程度，仍然取决于当前登录用户本来就拥有什么系统权限。

7. 系统页面：先看整台机器现在怎么样

系统页面会集中展示服务器资源状态。

这次看到的是名为：

k8s-master

的 CentOS 7 虚拟机。

页面里可以查看一段时间内的：

• CPU 使用率；
• 内存占用；
• 磁盘 I/O；
• 网络流量。

如果只是临时判断“机器是不是资源打满了”，这个页面比我先开终端再分别敲几条命令更快。

但它解决的是“看见状态”，不是替我自动解释所有异常。

8. 日志页面：比先想 journalctl 参数更直观

进入日志页面。

当前页面里能看到不少真实异常：

• blackbox_exporter 和 k8s/home 服务因路径不存在而启动失败；
• NTP 时间同步失败；
• mysql_exporter 启动异常；
• rsyslog 状态文件读取问题。

这一段反而很能说明 Cockpit 的价值。

我不需要先记住该怎么筛 journalctl，先从页面上看到哪类错误在反复出现，再决定后面深入排查哪一个服务。

当然，真正修问题时，还是可能要回到配置文件、systemd 和命令行。

9. 用户页面：账号集中看

进入用户管理页面。

当前能看到：

• elasticserach
• tomcat
• root
• shan

几个账户。

页面还提供创建新账户等入口。

我更愿意把它当成一个“账号视图”：先快速确认服务器上有哪些用户，再决定是否需要进一步调整权限。

10. 服务页面：systemd 状态不用一条条查

进入服务页面。

这里能直接看到不同 systemd 服务的当前状态。

当前截图里：

• alertmanager.service、auditd.service 启动失败；
• AdGuardHome、blackbox_exporter 正在自动重启；
• cockpit、containerd、cpolar 正常运行。

这就是我觉得 Cockpit 最实用的地方之一。

如果只是确认哪几个服务异常，不必先手动执行一串：

systemctl status ...

但真正要修改服务配置、排查依赖或修启动参数，命令行依然少不了。

11. 终端页面：图形化不等于排斥命令行

Cockpit 自己还保留了 Web 终端。

这一点很重要。

我不希望一个“图形化运维工具”把命令行彻底藏起来。

理想状态反而是：

常规查看用 GUI，复杂排障随时进终端。

这比把“零命令行”当成目标更符合真实运维习惯。

12. 局域网能管理以后，再考虑外网访问

Cockpit 默认只能在服务器所在网络里访问时，人一离开局域网，9090 就失去意义。

如果希望出门以后也能查看服务和日志，就需要继续解决公网入口。

这里加入 cpolar。

cpolar 在这套方案里只负责：

把 Cockpit 的 9090 Web 页面提供到公网。

它不负责 CPU 监控、不管理 systemd，也不处理日志。

13. 安装 cpolar

执行：

sudo curl https://get.cpolar.sh | sh

安装完成以后查看服务状态：

sudo systemctl status cpolar

状态正常后，通过：

http://ip:9200

打开 cpolar Web UI。

登录以后开始创建 Cockpit 隧道。

14. 先创建随机公网地址

进入：

隧道管理 → 创建隧道

当前参数为：

• 隧道名称：cockpit
• 协议：http
• 本地地址：9090
• 域名类型：随机域名
• 地区：China Top

创建成功以后打开在线隧道列表。

复制生成的公网地址访问。

Cockpit 页面可以正常打开。

这一层真正验证的是：

Cockpit 9090 → cpolar HTTP 公网地址 → 外部浏览器。

15. 长期远程管理，再切固定二级子域名

随机公网地址适合先测试。

如果以后准备长期远程查看这台服务器，我更希望地址固定。

进入 cpolar 预留页面。

选择：

保留二级子域名

这里使用：

• 地区：china Top
• 二级子域名：cockpitt

保留以后回到：

隧道管理 → 隧道列表

找到需要修改的 Cockpit 隧道。

把：

• 域名类型改成二级子域名；
• Sub Domain 填前面保留成功的名称；
• 地区选择 China Top。

更新以后再次打开在线隧道列表。

随机地址已经切换成固定二级子域名。

最后从浏览器访问。

页面能够正常打开。

到这里，Cockpit 的固定公网入口就配置完成。

16. 我会怎么用 Cockpit，而不是把它当“终端替代品”

Cockpit 对我最有价值的地方，不是让我从此忘掉命令行。

而是把一些频率很高、但信息比较分散的操作集中起来：

想看资源 → 直接进系统页。

想看日志 → 直接进日志页。

想看服务 → 直接进服务页。

需要深入排查 → 再进终端。

这样做的好处是，我不用每次都从“应该敲哪条命令”开始，而是先看到全局，再决定下一步。

总结

这次真正跑通的主线是：

CentOS 7 → epel-release → KVM / libvirt → Cockpit → 9090 → 系统性能 → 日志 → 用户 → systemd 服务 → Web 终端 → cpolar → 随机公网 → 固定二级子域名 cockpitt。

几个边界需要继续留意：

• 安装前的 KVM 命令把 systemctl start libvirtd.service 写进了 yum install 同一行，后面又单独启动了一次 libvirtd；
• Cockpit 的介绍部分写 https://你的服务器IP:9090，实际部署步骤写 http://IP:9090，两种写法都按当前内容保留；
• 这次实际展示了系统、日志、用户、服务和终端页面，并没有继续演示容器或 KVM 虚拟机管理插件；
• 9090 是 Cockpit 的核心访问端口，同时材料里也提醒要注意和其他服务端口冲突；
• cpolar 只负责 Cockpit Web 页面的公网入口，不参与服务器管理本身；
• 固定二级子域名示例继续使用 cockpitt；
• 图形化界面适合降低日常查看成本，但复杂脚本、自动化和深度排障仍然需要命令行或其他工具。

如果只是偶尔管理一台 Linux 服务器，我依然会保留 SSH；但当我想快速看整机状态、日志和服务时，Cockpit 确实能把很多“先想命令、再看结果”的步骤压缩成几个页面。对我来说，这才是它真正有用的地方。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/2501_91062530/article/details/166375185