CentOS 7 安装 Mailcow 时 Docker Compose 版本不兼容如何解决？

Question

在 CentOS 7 上安装 Mailcow 时，常见问题为系统默认通过 `yum install docker-compose` 安装的 Docker Compose 版本（v1.18.x）过旧，而 Mailcow 要求 ≥ v2.20.0（推荐 v2.24+），导致 `docker compose up -d` 报错“unknown command ‘compose’”或 YAML 解析失败（如 `version: '3.8'` 不被支持）。根本原因在于：CentOS 7 的 EPEL 仓库仅提供已弃用的 Docker Compose v1（Python 实现），而 Mailcow 依赖现代的 Docker Compose v2（Go 实现，作为 `docker compose` 子命令）。直接升级需卸载旧版，手动下载官方二进制并配置 PATH，同时确保 Docker Engine ≥ v20.10。此外，SELinux 和防火墙策略若未适配，也可能加剧启动失败——这常被误判为纯版本问题。

Answer 1

```html

一、现象层：典型错误输出与表象识别

• ERROR: unknown command "compose" —— 表明系统仍运行 Docker Compose v1（docker-compose 命令），未启用 v2 的子命令模式
• version '3.8' is invalid 或 service.xxx: unsupported option —— v1 解析器不支持 Compose v2+ 的 YAML schema
• Permission denied while trying to connect to the Docker daemon socket —— 常被误认为权限问题，实则可能因 SELinux 拦截或用户未加入 docker 组

二、机制层：Docker Compose v1 vs v2 的本质差异

维度	Docker Compose v1	Docker Compose v2
实现语言	Python（需 pip + setuptools）	Go（静态链接二进制）
命令形式	docker-compose up -d	docker compose up -d（原生命令集成）
YAML 支持	最高 v3.7（version: '3.7'）	原生支持 v3.8+ 及 deploy、profiles 等 Mailcow 必需字段

三、依赖链验证：逐级确认基础组件就绪性

执行以下检查序列（建议封装为验证脚本）：

# 1. Docker Engine ≥ v20.10.0
docker --version          # 应输出类似 "Docker version 24.0.7, build afdd53b"

# 2. Compose v2 是否已作为子命令注册
docker compose version    # 必须返回 v2.24.0+；若报错则未安装或 PATH 错误

# 3. 当前用户是否在 docker 组中
id -nG | grep -q '\bdocker\b' || echo "⚠️  用户未加入 docker 组"

# 4. SELinux 状态与容器上下文
sestatus -b | grep -E "(enforce|container_file_t)" 

四、解决方案层：生产环境安全升级路径

1. 卸载 EPEL 提供的旧版：yum remove docker-compose
2. 下载官方 v2.24.7（Mailcow 2024-Q3 推荐）：curl -SL https://github.com/docker/compose/releases/download/v2.24.7/docker-compose-linux-x86_64 -o /usr/local/bin/docker-compose
3. 赋予可执行权限并建立符号链接：chmod +x /usr/local/bin/docker-compose && ln -sf /usr/local/bin/docker-compose /usr/bin/docker
4. 配置 SELinux 允许容器绑定端口：semanage port -a -t container_port_t -p tcp 25,80,443,587,993,995,4190
5. 开放防火墙策略（firewalld）：firewall-cmd --permanent --add-service={smtp,http,https,imaps,pop3s,sieve} && firewall-cmd --reload

五、深度排障：SELinux 与 Compose 启动失败的耦合分析

当 docker compose up -d 卡在 Starting mailcow-dockerized_mailu_front_1 ... 时，应运行：

ausearch -m avc -ts recent | audit2why   # 查看 AVC 拒绝日志
docker logs mailcow-dockerized_mailu_front_1 --tail 50 | grep -i "permission\|selinux"

常见拒绝模式包括：type=AVC msg=audit(171...): avc: denied { name_bind } for pid=12345 comm="nginx" src=443 scontext=system_u:system_r:container_t:s0:c123,c456 tcontext=system_u:object_r:reserved_port_t:s0 tclass=tcp_socket —— 此即需 semanage port 修复。

六、架构演进视角：为何 Mailcow 强制要求 Compose v2？

graph LR
A[Mailcow v2.4+] --> B[多阶段健康检查]
A --> C[动态 service profiles]
A --> D[跨 stack 依赖引用]
B --> E[依赖 compose v2.20+ 的 healthcheck.restart_policy]
C --> F[依赖 v2.21+ 的 profiles + depends_on.condition]
D --> G[依赖 v2.23+ 的 x-networks + external: true]

七、长期运维建议：构建可审计的 Compose 版本治理机制

• 将 /usr/local/bin/docker-compose 加入 RPM 校验白名单（rpm --setperms docker-ce-cli 防覆盖）
• 编写 /etc/cron.weekly/compose-version-check 自动比对 GitHub 最新 Release 并告警
• 在 Ansible Playbook 中使用 community.docker.docker_compose_v2 模块替代 shell 调用，提升幂等性

```