从零到 16 容器全绿：在腾讯云 OpenCloudOS 9 上部署 OCManager 的完整踩坑实录

# 从零到 16 容器全绿：在腾讯云 OpenCloudOS 9 上部署 OCManager 的完整踩坑实录

> 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` 都没有。第一步是把工具装齐：

```bash

dnf install -y git

git clone https://gitee.com/OpenCloudOS/ocmanager.git

cd ocmanager

```

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

```bash

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` 有详细注释，标了「必须修改」和「建议修改」。**必须改的就三个网络相关字段**：

```bash

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。

改完后启动：

```bash

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 分钟仍然停在同一步**。

### 5.1 定位过程

先看进程状态：

```bash

ps -o pid,etime,stat,pcpu,cmd -p

# PIDELAPSED STAT %CPU CMD

# 1455848:15 Ss0.0 apk add --no-cache gcc musl-dev

```

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

```bash

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**。

### 5.2 为什么"配了镜像加速"还这么慢？

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

- **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 状态一动不动。

### 5.3 修复：一行 sed 换源

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

以 `tms/asset-manager/Dockerfile` 为例：

```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`。

### 5.4 效果

同一台机器：


| 场景 | `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 月部署。

","createTime":1783487163,"ext":{"closeTextLink":0,"comment_ban":0,"description":"","focusRead":0},"favNum":0,"html":"","isOriginal":0,"likeNum":1,