Docker多容器部署：Compose打包分发教程

本文深入解析了Docker多容器应用（如LEMP架构）的标准化部署方法，明确指出“合并Nginx与PHP-FPM为单一镜像”不仅技术上不可行，更违背容器化设计哲学；真正高效、可维护、生产就绪的方案是：为每个服务构建自包含、职责单一的专用镜像，通过docker-compose.yml实现声明式编排，并严格分离开发（借助override.yml热重载）与生产（仅依赖镜像标签和编排文件）环境——整套流程让应用真正实现“一次构建、随处运行”，兼具高可靠性、安全性和团队协作友好性。

Docker 本身不支持“合并多个容器为一个镜像”，最佳实践是分别构建、推送 Nginx 和 PHP-FPM 镜像，并通过 docker-compose.yml 统一编排；关键在于镜像自包含、配置可参数化、开发与生产环境分离。

Docker 本身不支持“合并多个容器为一个镜像”，最佳实践是分别构建、推送 Nginx 和 PHP-FPM 镜像，并通过 docker-compose.yml 统一编排；关键在于镜像自包含、配置可参数化、开发与生产环境分离。

在微服务或 LEMP 类架构中，常见将 Nginx（反向代理/静态服务）与 PHP-FPM（动态逻辑）拆分为两个独立容器——这符合 Docker “一个容器一个进程”的核心原则，也便于水平扩展、独立升级和故障隔离。试图将它们“合并”成单个镜像不仅违背设计哲学，还会导致职责混乱、调试困难、资源争用及安全风险上升。 正确路径是：构建可复用、自包含的专用镜像 + 声明式编排 + 环境分层管理。

✅ 推荐架构：双镜像 + Compose 编排

1. 拆分 Dockerfile，各司其职

避免使用多阶段构建中的 target 来“模拟合并”，而应为每个服务提供专属 Dockerfile，确保镜像内含全部运行时依赖与应用代码：

# Dockerfile.nginx
FROM nginx:1.21.6-alpine
COPY ./src/ /var/www/html/
COPY ./nginx/conf.d/app.conf /etc/nginx/conf.d/default.conf
EXPOSE 80

# Dockerfile.php
FROM php:7.4-fpm-alpine
RUN docker-php-ext-install pdo mysqli opcache
COPY ./src/app/ /var/www/html/app/
EXPOSE 9000

⚠️ 注意：COPY 必须将源码直接打入镜像（而非依赖 volume 挂载），才能保证镜像在任意环境拉取后开箱即用。

2. 生产就绪的 docker-compose.yml

该文件用于目标环境部署，仅声明镜像引用与基础网络配置，不含构建逻辑或本地路径：

version: '3.8'
services:
  nginx:
    image: registry.example.com/myapp/nginx:${TAG:-latest}
    ports: ["80:80"]
    depends_on: [php]
  php:
    image: registry.example.com/myapp/php:${TAG:-latest}
    # 不暴露 9000 端口给宿主机 —— Nginx 通过 Docker 内网通信即可

• 使用 ${TAG:-latest} 支持环境变量注入标签（如 export TAG=v1.2.0）
• 移除 container_name 和显式 networks：Compose 默认创建隔离桥接网络，已满足容器间通信需求
• depends_on 仅控制启动顺序（不等待服务就绪），如需健康检查，应配合 healthcheck

3. 开发专用 docker-compose.override.yml

此文件不发布、不提交至生产仓库，仅用于本地快速迭代：

version: '3.8'
services:
  nginx:
    build:
      context: .
      dockerfile: Dockerfile.nginx
    volumes:
      - ./src/:/var/www/html/  # 便于热重载（仅开发用）
  php:
    build:
      context: .
      dockerfile: Dockerfile.php
    ports: ["9000:9000"]  # 方便本地调试 PHP-FPM

✅ Compose 自动合并主文件与 override 文件：docker-compose up 同时生效；docker-compose build 将按 override 中定义构建并打上 registry.example.com/... 标签。

4. 构建、推送与部署全流程

# 1. 构建并打标（自动使用 override 中的 build 配置）
export TAG=20260417
docker-compose build

# 2. 推送至私有仓库（需提前 login）
docker-compose push

# 3. 在目标服务器部署（仅需 docker-compose.yml + TAG）
scp docker-compose.yml user@prod-server:/opt/myapp/
ssh user@prod-server "cd /opt/myapp && export TAG=20260417 && docker-compose up -d"

此时，目标服务器无需源码、Dockerfile 或构建工具链，仅靠 docker-compose.yml 即可拉取并运行完整应用。

? 关键总结

• ❌ 不要尝试“合并容器”：无原生支持，且破坏容器化最佳实践；
• ✅ 镜像必须自包含：所有代码、配置、依赖均 COPY 进镜像，禁用生产环境 volume 覆盖；
• ✅ 分离关注点：docker-compose.yml 是部署契约，override.yml 是开发便利，两者解耦；
• ✅ 标签语义化：优先使用 Git commit hash（$(git rev-parse --short HEAD)）或 ISO 日期（20260417），避免 latest；
• ✅ 安全加固（进阶）：为生产镜像启用非 root 用户、精简基础镜像（如 php:7.4-fpm-alpine）、扫描漏洞（trivy image ...）。

遵循此模式，你的应用将具备高可移植性、可审计性与团队协作友好性——这才是 Docker 化交付的真正成熟形态。

以上就是《Docker多容器部署：Compose打包分发教程》的详细内容，更多关于的资料请关注golang学习网公众号！