S4-8G 上的多服务编排实践

发布时间:2026-02-19 12:52

服务一多，手动逐个启停迟早出乱子。在顺云 S4-8G 这类 8G 内存机型上用 docker compose（Docker 官方的多容器编排工具）做分组管理，配合资源限额，能把内存稳定控制在安全线内，重启顺序、依赖关系也都有据可依。步骤如下。 准备条件 机器装好 Docker 与 compose 插件：curl -fsSL https://get.docker.com | bash，随后 docker compose version 确认可用。规划两个目录：/srv/web 存网站类服务，/srv/data 存数据库与缓存，职责分清后面才好管。磁盘留给镜像和数据的部分提前看好，df -h 确认可用空间充足。国内网络拉取镜像慢的，提前配好镜像加速地址再动手，能省下大量等待时间。 第一步：按职责分组 写两个 compose 文件而不是一个大文件。/srv/web/docker-compose.yml 里放 Nginx 与应用容器，/srv/data/docker-compose.yml 里放 MySQL 与 Redis。分组的好处是能单独重启数据组而不影响对外服务，升级应用时数据库不受打扰，反过来维护数据库时用户侧也无感知。两个组各自独立起停，命令里始终带上文件路径：docker compose -f /srv/data/docker-compose.yml restart，避免在错误的目录里执行。 第二步：写限额 每个服务都要设内存上限，示例片段： mysql: image: mysql:8.0 mem_limit: 3g command: --innodb-buffer-pool-size=2G 应用容器给 2g，Redis 给 512m 并设 maxmemory 384mb。全部限额加起来控制在 6G 以内，给系统留余量；限额的总和就是这台机器的内存红线，后续加服务前先看红线还剩多少。 第三步：验证 docker stats --no-stream 看各容器内存是否在限额内；docker inspect 容器名 | grep OOMKilled 确认没有被强杀记录。业务侧再抽点验证一遍核心接口，编排层面的正常不等于功能正常。验证动作写进部署文档，每次变更后照单执行一遍，形成固定习惯。 常见报错与处理 容器反复重启且日志出现 SIGKILL，基本是超限被 OOM（内存耗尽强制回收）杀掉，调低该服务的内存参数或调大限额即可；端口冲突报 address already in use，用 ss -lntp 找到占用进程再改端口映射；数据卷报 permission denied，检查宿主机目录属主与容器内用户是否一致。 建议收尾：限额宁紧勿松，超限的服务单独调参，别一上来就把 8G 分光。编排文件和目录结构进 git 管理，换机器重建环境时能省下大半时间。