Odoo19医疗系统运维部署文档 Odoo19医疗系统运维部署文档 1. 项目概述本项目为 Odoo 19.0 医疗管

Odoo19医疗系统运维部署文档

本项目为 Odoo 19.0 医疗管理系统，采用 Docker+DockerCompose 实现容器化部署，整体为单节点部署架构，包含 2 个核心服务：

所有服务通过自定义 Docker 网络实现内部通信，降低了环境依赖，部署流程标准化，运维成本低。

本次部署仅需要 1 名熟悉 Linux 操作系统、Docker 容器技术的运维工程师 即可独立完成全部工作。该项目为标准化的容器化部署项目，流程标准化程度高，无需多人协作，单人即可完成从环境准备、配置调整到部署验证的全流程工作。

整体部署工期为 0.5 个工作日（半天），各阶段时间拆分如下：

阶段	耗时	工作内容
环境准备	0.1 工作日	完成服务器初始化，安装 Docker 与 DockerCompose，配置防火墙开放 8069 端口
部署文件准备	0.2 工作日	创建工作目录，上传部署文件，调整 Odoo 配置、编写 DockerCompose 编排文件，下载 OCA 医疗模块
部署执行与验证	0.2 工作日	执行 DockerCompose 部署命令，拉取 / 构建镜像，启动所有容器，完成数据库初始化、医疗模块安装与功能可用性验证

部署完成后，运维人员需要开展以下日常与周期性运维工作，保障医疗系统稳定运行：

容器状态监控
- 定期通过 docker ps 检查所有容器的运行状态，确认 PostgreSQL、Odoo 容器无异常退出、重启循环的异常情况；
- 可搭建 Prometheus+Grafana 监控体系，以 10 秒 / 次的频率采集容器与宿主机的运行指标，服务异常时及时触发告警。
资源监控与限制
- 监控宿主机的 CPU、内存、磁盘、网络使用率，Odoo 19 对内存要求较高，当内存使用率超过 80%、磁盘剩余空间不足 20% 时触发告警，及时扩容；
- 为容器配置资源限制（在 docker\-compose\.yml 中添加 mem\_limit、cpus 参数），避免 Odoo 进程耗尽宿主机整体资源，影响其他服务。
健康检查与自启保障
- 为核心容器添加健康检查配置：PostgreSQL 端口检测、Odoo 服务健康接口检测，实现故障自动感知；
- 确认 Docker 服务与所有容器已配置开机自启，避免服务器重启后服务无法自动恢复。

数据库定时备份
- 配置每日定时备份任务，通过 pg\_dump 导出 PostgreSQL 全量业务数据，备份文件本地保留 7 天，同时同步至异地存储，防止宿主机故障导致医疗业务数据丢失。
```
# 备份示例脚本
docker exec odoo19-db-1 pg_dump -U odoo hospital_db > /backup/odoo/db_$(date +%Y%m%d).sql
```
配置与资源备份
- 定期备份宿主机上的挂载目录：PostgreSQL 数据目录、Odoo 附件数据目录、Odoo 配置文件、DockerCompose 编排文件，确保配置丢失后可快速恢复。
备份有效性验证
- 每周对备份文件进行一次恢复测试，验证备份文件的可用性，避免备份失效导致故障时无法恢复医疗业务数据。

日志轮转配置
- 在 Docker 的 daemon\.json 中配置全局日志轮转策略，限制单个日志文件最大为 100M，最多保留 3 个日志文件，避免日志文件持续增长耗尽磁盘空间。
```
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}
```
日志集中管理
- 可将容器日志收集至统一日志平台（如 ELK），实现 Odoo 业务日志、PostgreSQL 数据库日志的集中存储、检索，方便快速定位故障；日常可通过 docker logs 命令实时查看容器运行日志，排查服务异常。

镜像版本管理
- 每次项目迭代更新时，为新构建的 Odoo 镜像打上唯一版本标签（如基于 Git Commit ID），避免使用 latest 标签导致版本混乱，同时保留旧版本镜像，支持故障时快速回滚。
低停机更新
- 更新 Odoo 版本、医疗模块版本时，先停止旧版本容器，上传新的配置与模块，再启动新版本容器，最小化服务停机时间；更新前先备份当前业务数据与配置，防止更新失败。
资源清理
- 定期执行 docker system prune \-af，清理无用的旧镜像、停止的容器、未使用的数据卷，释放磁盘空间。

端口与访问安全
- 调整端口暴露规则，关闭不必要的对外端口：PostgreSQL 的 5432 端口仅需在 Docker 内部网络被 Odoo 服务访问，无需对外暴露，修改防火墙与端口映射规则，避免数据库被外部恶意访问，仅开放 8069 端口对外提供服务。
敏感配置管理
- 将 Odoo 管理员密码、数据库密码等敏感信息从配置文件中剥离，通过环境变量注入，避免敏感信息硬编码在镜像中，防止镜像泄露导致密钥被盗；
- 生产环境使用高强度的数据库、管理员密码，替换测试用的弱密码，避免被暴力破解。
镜像与系统安全
- 定期对使用的基础镜像（PostgreSQL、Odoo 基础镜像）进行安全扫描，修复已知安全漏洞，及时更新镜像版本；
- 定期对宿主机与 Docker 环境进行漏洞扫描，及时修复系统与 Docker 本身的安全漏洞。
权限控制
- 避免使用 root 用户运行容器内的应用，限制容器的权限，减少安全风险；同时管控宿主机的操作权限，避免未授权的操作。

标准化排查流程 遵循 "看状态→查日志→验配置→核资源" 的标准化排查流程：
1. 先通过 docker ps \-a 查看容器状态，判断是否存在异常退出、重启循环的问题；
2. 通过 docker logs 查看 Odoo、PostgreSQL 的容器日志，定位应用层面的报错信息；
3. 检查容器的启动配置、挂载目录、网络配置是否正确；
4. 检查宿主机与容器的资源使用情况，确认是否存在资源耗尽的问题。
故障响应机制 建立故障响应机制，医疗系统服务异常时 5 分钟内响应，15 分钟内定位问题；对于可快速恢复的问题（如容器异常退出），优先重启服务恢复业务，再排查根因避免问题重复发生。

每周例行巡检 每周开展一次例行巡检，检查内容包括：容器运行状态、备份任务执行情况、日志存储情况、安全漏洞情况，输出巡检报告，提前发现潜在风险。
容量规划与性能优化
- 根据监控数据，对 PostgreSQL 参数、Odoo 配置进行调优，提升医疗系统的运行性能；
- 结合业务增长情况，评估服务器资源的剩余容量，医疗系统的附件、病历数据会持续增长，当业务数据增长到单节点无法支撑时，规划升级为集群部署，提升服务的可用性与扩展性。