Linux运维不想全靠命令行？我用Cockpit把资源、日志和服务集中到浏览器

Linux运维不想全靠命令行？我用Cockpit把资源、日志和服务集中到浏览器

前言

Linux服务器真正让新手头疼的，往往不是某一条命令本身，而是出了问题以后不知道该先看哪里：CPU突然拉高、磁盘快满、某个systemd服务启动失败、日志里不断刷错误，都要在top、systemctl、journalctl、df等命令之间来回切换。命令行当然重要，但日常查看状态和处理常见问题，并不一定每次都要从终端开始。

这次我在CentOS 7上部署Cockpit，把9090作为Web管理入口。安装完成以后，继续用系统账号登录，实际查看系统资源、日志、用户、systemd服务和内置终端，并用页面里真实出现的服务异常作为例子，看看图形化界面能不能帮助快速定位问题。

前面还准备了KVM/libvirt环境，但这篇没有继续完成虚拟机创建和管理；同样也没有实际验证Docker/Podman插件，所以不会把这些扩展能力写成已经跑通。

最后再给9090增加外部访问入口，从随机公网地址切换到固定二级子域名。整篇重点是把Cockpit部署 → 9090登录 → 系统/日志/服务排查 → Web终端 → 远程访问这条链真正跑通。

这类工具真正好用的地方，也不只是“页面更直观”，而是系统状态、日志、服务和终端都在同一个入口里，遇到异常时不用先在多个命令之间来回切换，排查路径会更清楚。

image-20260708161124241

1 Cockpit真正适合解决什么问题

Cockpit更适合被理解成：

Linux服务器的Web管理控制台。

它不是要完全替代命令行，而是把一部分高频操作放进浏览器：

• 查看CPU、内存、磁盘和网络状态；
• 浏览系统日志；
• 查看和操作systemd服务；
• 管理系统用户；
• 打开Web终端；
• 根据插件继续扩展存储、虚拟机或容器等功能。

对于刚开始维护Linux服务器的人来说，最大的价值不是“从此不用学命令”，而是：

先从可视化界面看清楚系统发生了什么。

2 “零命令行”更适合作为使用体验，不是部署事实

这篇安装Cockpit本身仍然需要执行：

• yum安装；
• systemctl启动；
• systemctl查看状态。

后面遇到复杂故障时，Cockpit里的Web终端同样还会回到命令行。

所以更准确的说法是：

日常查看和部分运维操作可以减少对命令行的依赖。

而不是：

服务器运维从此完全不需要命令行。

3 Cockpit默认围绕系统账号和权限工作

Cockpit登录使用的是Linux系统本身的用户。

也就是说：

Cockpit账号权限和系统账号权限直接相关。

如果用高权限账号登录，就具备更高的系统操作能力。

这也是后面做公网访问时必须重点注意的地方。

4 这篇实际验证到哪些功能

实际跑通：

• Cockpit安装；
• 9090 Web页面；
• 系统账号登录；
• 系统资源页面；
• 日志页面；
• 用户页面；
• systemd服务页面；
• Web终端；
• 随机公网访问；
• 固定公网入口。

准备但没有继续实测：

• KVM虚拟机管理；
• Docker/Podman管理插件；
• 多主机聚合；
• LDAP/OIDC等扩展认证。

所以正文只把已经出现操作结果的部分写成实测。

5 先安装epel-release

执行：

yum install epel-release

结果：

29e44abf29c4115c3102666a33750f6e

这一步为后面的相关软件安装准备环境。

6 准备KVM和libvirt环境

执行：

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

页面：

c199177b65b064e01782e5ef37357536

后面还有单独启动libvirtd的步骤：

systemctl start libvirtd.service

这部分主要是在系统里准备虚拟化环境。

但本篇后续没有继续创建KVM虚拟机，所以不能只凭安装这些包，就写成“Cockpit虚拟机管理已经验证”。

7 安装Cockpit

本次安装时因为仓库冲突问题，使用了禁用pgdg-common的方式：

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

结果：

400f77eb2675a9d75922bcdddf3544b4

这里的重点是：

Cockpit已经成功安装到CentOS 7。

8 启动Cockpit并设置开机自启

执行：

systemctl start cockpit
systemctl enable cockpit

结果：

50ee2e9e245dee1abd6827cd2040c3cf

然后继续检查服务状态。

9 查看Cockpit服务状态

执行：

systemctl status cockpit

结果：

29457663a468d9a0197f4856316a4ad9

服务正常以后，再进入浏览器验证9090。

10 浏览器打开Cockpit

访问：

http://服务器IP:9090

页面：

beacf9a8131492ca6068cf849c9ce279

做到这里可以确认：

浏览器 → 9090 → Cockpit Web

已经跑通。

11 使用CentOS 7系统账号登录

登录页：

image-20260708161032229

这里使用的不是另一套独立Cockpit账号。

而是服务器本身的：

Linux用户名和密码。

登录成功：

image-20260708161050321

进入主界面：

b4480494bd55254ff815c69762e17606

12 系统页面先看资源状态

系统监控页：

image-20260708161741716

这次页面里可以看到：

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

对于日常巡检，这比先手动组合多个命令更直观。

但它更适合做：

快速查看和定位方向。

复杂性能分析仍然可能需要继续结合命令、日志或专业监控工具。

13 日志页面真正适合做故障入口

日志页：

image-20260714115829379

这台k8s-master当时并不是“全绿”的状态。

页面里已经能看到多类异常，包括：

• blackbox_exporter相关启动失败；
• k8s/home相关路径问题；
• NTP同步失败；
• mysql_exporter异常；
• rsyslog状态文件问题。

这一页的价值在于：

先把分散的系统日志集中到一个可筛选的界面。

发现异常以后，再决定要不要继续进入终端深入排查。

14 用户页面可以直接看系统账号

页面：

image-20260708163236691

本次可以看到服务器里已有的用户，例如：

• elasticserach；
• tomcat；
• root；
• shan。

这一层适合快速确认：

• 系统里有哪些账号；
• 是否需要新增用户；
• 是否存在不再使用的账号。

用户管理属于高权限操作，公网使用Cockpit时更需要控制登录账号权限。

15 服务页面比记systemctl更直观

服务页面：

image-20260708163334970

页面里能直接看到不同systemd服务的运行状态。

本次截图中也出现了真实异常：

• alertmanager.service启动失败；
• auditd.service异常；
• AdGuardHome重启；
• blackbox_exporter重启；
• cockpit、containerd、cpolar等服务正常。

这比只看到一条：

systemctl status

更适合先做全局巡检。

16 Cockpit不是把故障“自动修好”

服务页面能帮你快速看到：

哪个服务有问题。

日志页面能继续告诉你：

大概因为什么失败。

但真正修复：

• 配置文件；
• 路径；
• 端口；
• 权限；
• 服务依赖；

仍然需要根据具体错误处理。

所以Cockpit更像：

诊断入口 + 常用操作界面。

不是自动运维修复器。

17 内置Web终端仍然很重要

终端页面：

image-20260708163438272

这也是为什么“零命令行”不能理解得太绝对。

当图形界面只能告诉你：

服务失败了

而真正要：

• 查文件；
• 改配置；
• grep日志；
• 执行脚本；

时，还是会回到终端。

Cockpit把终端放进同一个浏览器页面，减少的是来回切工具的成本。

18 安装KVM不等于Cockpit已经能管理虚拟机

前面虽然已经准备：

• qemu-kvm；
• libvirt；
• virt-install；
• virt-manager；

但这篇没有继续展示：

• cockpit-machines安装；
• 创建虚拟机；
• 启停KVM实例；
• 控制台连接。

所以正文只保留KVM环境准备步骤，不把虚拟机管理写成已经完成的结果。

19 容器管理也要看插件和权限

Cockpit可以通过扩展能力管理容器。

但本篇没有实际展示：

• Podman页面；
• Docker插件；
• 容器列表；
• 镜像管理；
• 容器启停。

因此“直接一键管理Docker”不作为这篇已经验证的结论。

本次真正明确验证的是：

系统、日志、用户、systemd服务和终端。

20 到这里，本地Cockpit已经跑通

现在已经完成：

CentOS 7

↓

Cockpit服务

↓

9090

↓

系统账号登录

↓

资源监控

↓

日志

↓

用户

↓

服务

↓

Web终端

如果只在局域网内管理服务器，到这里已经够用。

21 公网开放Cockpit比普通网页更敏感

Cockpit不是博客、导航页或静态网站。

它能：

• 看系统状态；
• 查看日志；
• 管理用户；
• 操作systemd服务；
• 打开终端。

所以一旦开放公网，这本质上是一个：

服务器高权限管理入口。

远程访问时必须比普通Web服务更谨慎。

22 安装cpolar

执行：

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

结果：

image-20250725104019896

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

sudo systemctl status cpolar

结果：

22e5adfaf290a17fc3384bb296055259

cpolar正常运行以后，再打开其Web管理页面。

23 打开cpolar Web UI

浏览器访问：

服务器IP:9200

页面：

8a6698b1bf26d64ba3645827fbfb1c29

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

24 给9090创建随机公网入口

创建参数：

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

页面：

image-20260708170600637

这里真正映射的是：

Cockpit Web的9090端口。

25 查看随机公网地址

进入在线隧道列表：

image-20260708170817268

从其他网络访问：

image-20260708170831164

能够正常打开以后，可以确认：

外部浏览器 → 公网地址 → Cockpit:9090

已经跑通。

26 随机地址更适合先验证

随机地址适合：

• 临时远程运维；
• 先确认网络链路；
• 应急查看。

如果准备长期使用，再继续配置固定二级子域名。

27 保留固定二级子域名

预留页面：

image-20250918151358733

本次示例使用：

cockpitt

结果：

image-20260708171107381

实际名称以自己账号最终成功保留的结果为准。

28 编辑Cockpit隧道

回到隧道列表：

image-20260708170927634

修改：

• 域名类型：二级子域名；
• Sub Domain：已经保留的名称；
• 地区：China Top。

更新：

image-20260708170955884

29 查看固定地址

进入在线隧道列表：

image-20260708171124962

可以看到原来的随机地址已经切换成固定二级子域名形式。

30 最后从外部设备访问

使用固定地址：

image-20260708171138182

页面能够正常打开以后，长期远程入口完成。

整条链现在变成：

外部浏览器 → 固定公网地址 → Cockpit:9090 → Linux服务器管理界面

31 固定地址解决的是入口稳定，不是权限安全

固定二级子域名主要解决：

• 不需要反复查随机地址；
• 浏览器可以长期收藏；
• 运维入口更容易记忆。

它并不能自动解决：

• Linux弱密码；
• root登录风险；
• 用户权限过大；
• Web终端高权限；
• 系统服务误操作；
• 地址泄露。

cpolar负责网络入口。

Cockpit和Linux本身负责认证与权限。

32 9090端口冲突也要提前看

Cockpit使用：

9090

如果服务器上已经有其他服务占用9090，就需要先处理端口冲突。

这篇开头提到与Prometheus等工具共存，也是因为监控类服务很容易集中使用固定端口。

部署前先确认：

9090有没有被占用

会比安装完成以后再排错更省事。

33 这套方案更适合什么人

比较适合：

• Linux新手；
• 个人服务器；
• 小规模运维；
• 想快速看日志和服务状态；
• 不想每次都记systemctl/journalctl；
• 需要浏览器里的Web终端。

如果运维规模扩大到：

• 批量配置；
• 自动化部署；
• 多服务器策略管理；
• 大规模监控告警；

Cockpit就更适合作为其中一个管理入口，而不是替代Ansible、Prometheus等系统。

34 最后把完整技术链重新看一遍

系统：

CentOS 7

准备：

EPEL + KVM/libvirt

Cockpit：

yum安装 → systemctl启动 → 9090

登录：

Linux系统用户

已验证功能：

系统资源 → 日志 → 用户 → 服务 → Web终端

随机远程：

公网随机地址 → 9090

固定远程：

固定二级子域名 → 9090

实际完成：

• epel-release；
• KVM/libvirt环境；
• Cockpit安装；
• cockpit启动；
• 开机自启；
• 服务状态验证；
• 9090本地访问；
• 系统账号登录；
• CPU/内存/磁盘/网络查看；
• 日志浏览；
• 用户查看；
• systemd服务查看；
• Web终端；
• cpolar安装；
• 随机公网访问；
• 固定二级子域名；
• 外部浏览器访问。

这样Cockpit才真正从“一个Linux图形界面”，变成一套可以用来日常巡检、看日志、查服务状态，并在需要时继续进入终端处理问题的Web运维入口。

总结

这次真正跑通的是一条完整的Cockpit运维链：先在CentOS 7上准备相关环境，安装并启动Cockpit，通过9090进入Web页面，再直接使用Linux系统账号登录。

功能验证没有停在“仪表盘能打开”。后面继续查看了CPU、内存、磁盘和网络状态，也进入日志、用户、systemd服务和Web终端页面；而且页面里实际出现了blackbox_exporter、alertmanager、NTP等异常，这让Cockpit真正承担起“先发现问题、再决定怎么排查”的入口作用。

这篇同时保留了KVM/libvirt的准备步骤，但没有继续完成虚拟机创建；也没有实测Docker/Podman插件，所以这些能力没有写成已经跑通。“零命令行”也调整成更准确的“日常常用操作减少命令行依赖”，因为安装、复杂排错和脚本操作仍然离不开终端。

远程部分是在本地Cockpit已经正常以后再增加的能力。随机公网地址先验证9090链路，固定二级子域名再解决长期入口变化的问题；但Cockpit包含用户、服务和Web终端等高权限功能，长期公网开放时，系统账号权限和访问范围比“地址是否固定”更值得优先管理。