# 从零到 16 容器全绿：在腾讯云 OpenCloudOS 9 上部署 OCManager 的完整踩坑实录
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-10730009/9c527d74f00611d8b0895f5408aa6e89.png)

> OpenCloudOS 前段时间正式开源了智能运维平台 **OCManager**——号称跑过百万级服务器、日处理 700 万条告警。看到官方的「开源共建活动」我起了个念头：**能不能把它在自己的机器上从零部署一遍**，看看这套系统实际长什么样？本文记录的是一次完全真实的部署过程，包括中途踩的一个坑——**从`apk` 卡了 50 分钟到 7 秒完成**——以及最终跑通后的所见所感。

下图是我部署成功后的系统：
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-10730009/fff22b5fbca3c2987595446ce4d0ccfb.png)

## 一、缘起：这套系统到底长什么样

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` 显示：

![环境信息](https://developer.qcloudimg.com/http-save/yehe-10730009/9e3d8221a708fd1cb9073b46dfa3598b.png)

内核 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` 几个纯静态编译的服务也很快完成。

然后就卡住了。

![apk 卡顿现场](https://developer.qcloudimg.com/http-save/yehe-10730009/6bad5399f0671dd0c17eb8f958dfc2b1.png)

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

### 5.1 定位过程

先看进程状态：

```bash
ps -o pid,etime,stat,pcpu,cmd -p <apk_pid>
#   PID    ELAPSED STAT %CPU CMD
# 14558      48:15 Ss    0.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 效果

同一台机器：

![修复前后对比](https://developer.qcloudimg.com/http-save/yehe-10730009/93aa3aebdd2f005d7fff7e960f608485.png)

| 场景 | `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. 健康检查

最终报告：

![健康检查 17/17 通过](https://developer.qcloudimg.com/http-save/yehe-10730009/7473f782754630a27739c2a401d9ae67.png)

`docker ps` 数一下：

![16 容器全绿](https://developer.qcloudimg.com/http-save/yehe-10730009/a0c0de8bf0091bc678ed2c6ec007bc69.png)

- **基础设施 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`。

资源占用：

![资源占用](https://developer.qcloudimg.com/http-save/yehe-10730009/44c910561119b6ac1fac393bf0e162fa.png)

**内存 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 诊断**：入口在「智能问答」，接入大模型后可用自然语言查询系统状态

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-10730009/45aa9b1659dc536cee511127619d0060.png)

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

**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 月部署。


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

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

服务端开发

人工智能

腾讯云OpenCloudOS9上部署OCManager的完整指南，分享从零到16容器全绿的实战经验。详解环境准备、网络配置、镜像加速优化等关键步骤，特别解决apk卡顿问题（50分钟→7秒）。包含OpenCloudOS9适配技巧、资源占用数据及控制台初体验，适合开发者快速上手这套百万级服务器验证的智能运维系统。

代码解释

服务器

云主机

云安全

Docker

容器

CentOS

2026上云采购 | AI焕新·智启新局

4核4G3M云服务器 新用户低至38元/年！

CDN免费试用


tchousec

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

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

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐