OneUptime开发环境Docker Compose配置详解
2025-07-07 08:03:45作者:明树来
概述
OneUptime是一个开源的监控和状态页面平台,其开发环境使用Docker Compose进行容器化部署。本文将深入解析docker-compose.dev.yml
配置文件,帮助开发者理解OneUptime开发环境的架构和组件交互。
核心服务组件
1. 基础服务
Redis服务
- 端口映射:6310(主机)→6379(容器)
- 作为内存数据库,用于缓存和消息队列
- 开发环境下直接暴露端口便于调试
PostgreSQL服务
- 端口映射:5400→5432
- 主关系型数据库,存储结构化数据
- 使用独立volume持久化数据
ClickHouse服务
- 端口映射:9034→9000、8189→8123
- 高性能列式数据库,用于分析型工作负载
- 挂载自定义配置文件
config.xml
2. 监控相关服务
OpenTelemetry Collector
- 构建自定义Docker镜像
- 用于收集、处理和导出遥测数据
- 在监控系统中扮演重要角色
探针服务(Probe)
- 部署了两个实例(probe-1和probe-2)
- 负责主动监控目标服务的可用性
- 使用共享代码但独立运行的架构
3. 数据处理管道
多种数据摄入服务
- ProbeIngest: 处理探针数据(端口9932)
- ServerMonitorIngest: 服务器监控数据(端口9941)
- OpenTelemetryIngest: OpenTelemetry数据(端口9938)
- IncomingRequestIngest: 请求数据(端口9933)
- FluentIngest: 日志数据(端口9937)
这些服务构成了OneUptime的数据处理管道,各自负责特定类型数据的接收和处理。
4. 日志处理
Fluentd
- 端口:24224(TCP/UDP)、8888(HTTP)
- 日志收集和转发系统
- 挂载自定义配置文件
fluent.conf
Fluent Bit
- 端口:24225、24284、2020、8889
- 轻量级日志处理器
- 挂载整个配置目录
/fluent-bit/etc/
前端与用户界面服务
1. 账户服务(Accounts)
- 端口通过环境变量
ACCOUNTS_PORT
配置 - 挂载本地代码目录实现热重载
- 排除node_modules使用容器内版本
2. 仪表盘服务
- Dashboard: 主用户仪表盘
- AdminDashboard: 管理员界面
- StatusPage: 状态页面服务
- 均支持开发环境下的代码热更新
开发专用服务
1. 测试相关
- TestServer: 测试服务器(端口3800)
- E2E: 端到端测试容器
- 挂载测试报告目录
- 独立构建测试环境
2. 文档服务
- Docs: 文档系统(端口8738)
- APIReference: API参考文档(端口8737)
网络配置
- 使用自定义桥接网络
oneuptime
- 所有服务在同一网络内可互相通信
- 驱动类型为bridge(默认)
开发环境特点
-
热重载支持:
- 所有Node.js服务都挂载本地代码目录
- 排除node_modules确保使用容器内依赖
- 实现代码修改后自动重载
-
调试支持:
- 多数服务暴露9229调试端口
- 映射到不同主机端口避免冲突
- 如Worker(8734)、Workflow(8735)等
-
模块化设计:
- 使用
extends
继承基础配置 - 保持
docker-compose.base.yml
的简洁性 - 各服务Dockerfile独立维护
- 使用
最佳实践
-
环境变量管理:
- 关键端口通过环境变量配置(如
ACCOUNTS_PORT
) - 建议使用.env文件统一管理
- 关键端口通过环境变量配置(如
-
开发流程:
- 修改代码后无需重建整个容器
- 利用volume挂载实现即时更新
- 调试端口预先配置方便问题排查
-
资源隔离:
- 数据库使用独立volume
- 网络隔离确保安全性
- 各服务资源限制可在基础配置中定义
总结
OneUptime的Docker Compose开发环境配置展示了现代监控系统的典型架构,通过容器化实现了:
- 服务解耦和独立扩展
- 开发与生产环境一致性
- 高效的本地开发体验
- 完整的监控数据处理管道
理解这份配置文件对于参与OneUptime开发或构建类似系统都具有重要参考价值。开发者可以根据实际需求调整服务配置、资源分配和网络设置,构建适合自己工作流程的开发环境。