OpenCloudOS 前段时间正式开源了智能运维平台 OCManager，官方介绍称它跑过百万级服务器、日处理 700 万条告警。看到「开源共建活动」后，决定亲自从零部署一遍，看看这套系统到底长什么样。本文记录了一次完全真实的部署过程，包括中途踩的一个大坑——apk 从卡了 50 分钟到 7 秒完成——以及最终跑通后的所见所感。

下图是部署成功后的系统界面：

一、这套系统到底长什么样

OCManager 的定位是「OpenCloudOS 智能管家」，从架构上看由三层组成：

• 前端：Vue 3 + Vite 单页应用
• manager 后端：Go 语言编写的多个业务微服务（footstone 主控、msg-etl 告警管道、sysdiagnose AI 诊断等）
• tms 数据通道：7 个 tRPC 服务，负责 agent 接入、资产/证书、任务下发、物料分发

底层靠 infra/ 目录下的一套 docker-compose 拉起 MySQL / Redis / Kafka / ZooKeeper / ClickHouse 五件套。全栈算下来是 16 个容器。

官方 README 提供了「方式一：一键 Docker 部署」，一行命令 bash scripts/deploy.sh up 全部搞定。听起来简单，但一键部署这件事，只要涉及大量镜像构建和国内网络，往往没那么顺风顺水。

二、环境准备：腾讯云上的一台 OpenCloudOS 9

活动明确要求以 OpenCloudOS 9 为环境，机器选型时做了几点权衡：

• 云厂商：腾讯云 CVM 公共镜像原生就有 OpenCloudOS 9，不用像阿里云那样导入自定义镜像折腾一圈。
• 架构：x86_64。OCManager 的基础镜像默认拉腾讯云加速源的 x86 镜像，别用 ARM 实例找不痛快。
• 规格：官方 README 建议 4C8G。实测 2C8G 也够（check-environment.sh 会警告 CPU 偏少，但完全能跑），后面数据会印证这点。

最终配置：腾讯云 CVM 入门型 2C8G / 80GB SSD / 北京地域 / OpenCloudOS Server 9。

开机后 cat /etc/os-release 显示：

内核 6.6.119，Docker 28.0.1，Go 1.24.0，一切正常。

三、克隆仓库，先给自己配好工具链

OpenCloudOS 9 的公共镜像非常干净——干净到连 git 都没有。第一步是把工具装齐：

dnf install -y git
git clone https://gitee.com/OpenCloudOS/ocmanager.git
cd ocmanager

deploy.sh 还需要 Go 1.24+ 用于本机编译后端二进制（虽然容器构建也会走 Go，但脚本会走一次静态编译的 fallback 路径）。装 Go：

curl -fsSL https://go.dev/dl/go1.24.0.linux-amd64.tar.gz -o /tmp/go.tgz
tar -C /usr/local -xzf /tmp/go.tgz
echo "export PATH=$PATH:/usr/local/go/bin" > /etc/profile.d/go.sh
/usr/local/go/bin/go version
# → go version go1.24.0 linux/amd64

Docker 没有手动装——scripts/check-environment.sh 会自动检测并调用 dnf 安装。这个脚本对 OpenCloudOS 9 的适配挺好，本身就带了 tencentos/opencloudos 分支的判断逻辑。

四、配置 .env，让公网 IP 生效

config/env.example 有详细注释，标了「必须修改」和「建议修改」。必须改的就三个网络相关字段：

cp config/env.example config/.env

# 关键三项：
# SERVER_HOST 用内网 IP（云主机的 eth0 地址）
# CONNECT_HOST 用公网 IP（agent 从外部回连时用）
# FRONTEND_DOMAIN 用公网 IP + 前端端口（浏览器访问）

腾讯云的 CVM 网卡拿到的是内网地址（这里是 10.2.0.4），公网 IP 是 EIP 方式绑定的（49.232.173.18）。这个区分很重要：内部服务之间通信用内网 IP，agent 上报和浏览器访问用公网 IP。

改完后启动：

YES=1 bash scripts/deploy.sh up

YES=1 让脚本跳过所有交互式确认，直接一路往下跑。

五、踩坑：apk add gcc musl-dev 卡了 50 分钟

check-environment.sh 顺畅通过，自动装完 Docker，紧接着进入镜像构建阶段。基础设施镜像秒拉（腾讯云 registry 镜像加速已经生效），tms 层的 api、gateway、heartbeat、data-proxy 几个纯静态编译的服务也很快完成。

然后就卡住了。

看时间戳，zstd-libs → binutils 花了 28 秒。之后就再没下文，进度条一直转。20 分钟过去了，30 分钟、40 分钟……50 分钟仍然停在同一步。

定位过程

先看进程状态：

ps -o pid,etime,stat,pcpu,cmd -p 
# PID ELAPSED STAT %CPU CMD
# 14558 48:15 Ss 0.0 apk add --no-cache gcc musl-dev

S 状态 + 0% CPU——不是死锁，是在等网络 IO。看它的 socket：

ls -l /proc/14558/fd | grep socket
# lrwx------ ... /proc/14558/fd/6 -> socket:[66214]
cat /proc/14558/net/tcp | grep -i established

socket 对端的十六进制 IP 反解回来，指向 dl-cdn.alpinelinux.org——Alpine 的官方 CDN。

为什么「配了镜像加速」还这么慢？

这里有一个国内开发者容易忽视的关键区别：

• Docker Registry 镜像加速（mirror.ccs.tencentyun.com）只影响 docker pull 的镜像层下载。也就是「拉基础镜像」这一步。
• 容器内执行的 apk（或 apt / yum）走的是发行版自己的 HTTP 仓库，跟 Docker Registry 完全是两码事。

所以尽管仓库 README 引导我们把 Docker registry 指向了腾讯云加速源，apk 拉包时依然走 dl-cdn.alpinelinux.org——国内到这个 CDN 的路径极不稳定，最后成了整个部署的瓶颈。

gcc 在 Alpine 上依赖链约 14 个包，加起来几十 MB。理论上再慢也该几分钟能下完，但实际情况是有时候直接卡到无响应，进程停在 sleeping 状态一动不动。

修复：一行 sed 换源

最小侵入的做法：在每个 apk 命令前加一次 sed，把 /etc/apk/repositories 里的默认源替换成腾讯云的 Alpine 镜像 mirrors.tencent.com。

以 tms/asset-manager/Dockerfile 为例：

# Before
RUN apk add --no-cache gcc musl-dev

# After
RUN sed -i 's|dl-cdn.alpinelinux.org|mirrors.tencent.com|g' /etc/apk/repositories 
&& apk add --no-cache gcc musl-dev

翻遍全仓库，一共 9 个 Dockerfile 用 apk 拉包：

• 7 个 tms 服务：tms/{api, asset-manager, data-proxy, file-svc, gateway, heartbeat, task-manager}/Dockerfile
• 2 个 manager 层：manager/backend/Dockerfile.backend、manager/deployments/compose/Dockerfile.frontend

其中 asset-manager / file-svc / task-manager 因需 CGO 编译 sqlite 额外装 gcc musl-dev，是主要卡顿点。

批量替换完后，重新跑 deploy.sh up。

效果

同一台机器上的前后对比：

场景	apk add gcc musl-dev 耗时	deploy.sh up 全流程
修改前	>50 分钟未完成	卡死
修改后	≈ 7 秒	12 分钟完成

50 分钟 → 7 秒。这个坑后来整理成了 Issue 和 PR，提交回了 OpenCloudOS 社区。

六、部署完成：16 容器全绿

修复后再跑 deploy.sh up，脚本自动执行完整流程：

1. 环境自检（check-environment.sh，17 项）
2. 编译 Go 后端二进制
3. 构建 13 个业务镜像
4. docker compose 拉起基础设施 + tms + manager 三层
5. 健康检查

最终报告显示健康检查全部通过。

docker ps 数一下：

• 基础设施 5 个：oc-mysql / oc-redis / oc-kafka / oc-zookeeper / oc-clickhouse
• tms 数据通道 7 个：oc-tms-api / oc-tms-gateway / oc-tms-heartbeat / oc-tms-task-manager / oc-tms-asset-manager / oc-tms-data-proxy / oc-tms-file-svc
• manager 业务 4 个：oc-frontend / oc-footstone / oc-msg-etl / oc-sysdiagnose

合计 16 个容器，全部 Up。

资源占用：内存 2.4G / 7.5G、磁盘 16G / 80G。2C8G 完全 hold 得住，实际负载还有很大余量。这让我对 OCManager 号称的「跑过百万级服务器」有了具象的理解——底层组件的选型和编排是经过实际打磨的，不虚。

七、初见控制台

docker ps 里 oc-frontend 的端口是 0.0.0.0:13070->8080/tcp。在腾讯云安全组放行 13070 后，浏览器打开 http://<公网IP>:13070，默认账号 admin / Admin123456@。

进去第一眼是资产/主机管理界面。侧栏功能模块清晰对应了 README 里描述的四大能力：

• 主机纳管：批量添加/分组，agent 心跳状态一目了然
• 系统监控：CPU/内存/磁盘/网络指标从 ClickHouse 读取
• 批量命令：借助 tms 的 task-manager 服务下发 shell 任务
• AI 诊断：入口在「智能问答」，接入大模型后可用自然语言查询系统状态

八、写在最后：一些真实体会

1. 一键部署脚本的诚意

OCManager 的 deploy.sh 是近期见过写得最细的一键部署脚本之一：

• 环境自检覆盖了 OS/CPU/内存/磁盘/端口/工具链/权限 17 项
• 支持 up / down / restart / logs / ps / clean 完整生命周期
• 对 OpenCloudOS / TencentOS 有专门的分支处理
• 交互式与非交互式（YES=1）都能跑

这不是「能跑就行」的水平，而是有工程化沉淀的东西。

2. 那个 apk 的坑，是国内开源项目的通病

不是 OCManager 特有，是几乎所有基于 Alpine 的镜像构建流程在国内都会遇到。差别在于：有的项目连 Docker registry 加速都没配，有的项目配了但没意识到 apk 是另一套。OCManager 已经做到了第二档，只差最后一步——这也是最终提 PR 的原因：改动小、收益大，属于典型的「该做但没人做」的贡献点。

3. OpenCloudOS 9 作为国产 OS 的完成度

从「装 git」开始，到「apk 换源」结束，全程没遇到任何 OpenCloudOS 特有的兼容问题。dnf 源速度快、systemd 行为规范、Docker CE 一装即用——这是一个成熟到几乎无感的 RHEL 9 生态发行版。要说唯一让人意识到「在 OpenCloudOS 上而不是 CentOS 上」的时刻，是 dnf repolist 里显示的 Extra Packages for OpenCloudOS 9 - EPOL 那一行。

4. 开源共建活动的门槛

活动号称「PR / Bug / 体验通通有奖」，实测下来门槛真的低——这次踩坑的发现-诊断-修复-验证全程 4 小时，产出了 1 个 Issue、1 个 PR、1 篇体验文章，覆盖活动的三种参与方式。只要你愿意认真跑一遍，很难不遇到可贡献的点。

作者环境：腾讯云 CVM 入门型 2C8G，OpenCloudOS 9.4，北京地域，2026 年 7 月部署。