企业官网建设流程全解析

做企业业务代码发布这几年，我越来越认同一句话：DevOps 的尽头不是工具堆砌，而是把发布这条链路做成一条“有肌肉记忆的流水线”。Docker 容器在这里扮演的角色，不只是把应用打包成镜像，而是把一个团队在部署环境里踩过的坑、依赖的版本关系、启动的先后顺序、故障后的恢复策略，全部固化成了可以版本化、可回滚、可审计的“发布单元”。这篇指南是这套基于 Docker 容器的 DevOps 应用方案中，关于容器部署落地的完整操作篇。前面几篇讲了整体架构、代码仓库和流水线设计，这一篇重点回答一个实际问题：拿到业务代码之后，怎么安全、稳定、可持续地把容器跑起来，并且真正接进发布流程。适合正在做企业发布系统改造的运维和研发同学，也适合想把容器部署这件事做得规范一些的团队参考。

1. 方案落地前，先理清容器化发布的底层逻辑

1.1 为什么要用容器承载发布链路

传统企业应用发布，最常见的是手工登录服务器，替换 jar 包或者前端文件，然后重启进程。这套做法的问题不在于“能跑”，而在于每次发布的结果都依赖执行人的经验和状态。你在测试环境能跑起来的包，到生产环境可能因为 JDK 版本不一致、环境变量缺失、配置文件忘记同步，就起不来了。容器化发布把应用和它依赖的运行时环境打包成同一个镜像，让“测试跑过的那个包”和“生产要跑的那个包”在二进制层面完全一致。

举个直观的例子，我们有个 Java 微服务，之前发布需要先在服务器上装好 JDK 8，再配置 Tomcat 连接池，还要手工调整 JVM 参数。后来全部改成容器化，Dockerfile 里 FROM 一个固定的 JDK 基础镜像，所有环境变量、启动参数都写死在镜像构建脚本里。研发本地测的是这个镜像，测试环境跑的也是这个镜像，生产环境直接拉取同一个镜像，差别只在于连接数据库的配置项。

从发布稳定性来说，容器化还有一层更实际的价值：进程崩溃后可以自动拉起。以前进程挂了，要靠监控告警再人工介入。现在 Docker 的 restart 策略可以在容器异常退出后秒级恢复，发布系统只需要感知容器状态，而不需要关心进程是怎么被拉起来的。这层“把恢复动作自动化”的能力，才是 DevOpe 流水线里真正提升发布质量的关键。

1.2 方案选型：Docker Compose 还是 Kubernetes

很多团队一开始就纠结要不要直接上 Kubernetes。我的建议是：如果你的业务规模还没到几十个微服务、不需要跨节点调度，那先用 Docker Compose 把发布流程跑通，比上一套 K8s 更实际。Compose 的优势是把多个服务之间的依赖关系写在同一个 YAML 文件里，一条 docker-compose up -d 就能拉起整套业务环境，发布系统可以直接通过服务名访问数据库、缓存、消息队列，链路非常清晰。

Kubernetes 不是不好，而是引入之后会额外增加 kubelet、etcd、CNI 网络插件等一堆组件。这些组件本身也需要运维，对一个小团队来说，学习成本和排障成本会反噬掉容器化带来的效率收益。我们在方案选型时的原则是：能用单机 Docker 解决的，不提前引入集群；只有当单台服务器的资源明显不够、或者需要滚动发布多个副本时，再考虑往 K8s 迁移。而且 Docker Compose 的编排文件可以比较平滑地迁移到 K8s，前期不要把自己锁死在某一个技术栈上。

1.3 一套发布系统的分层架构

在我们这套方案里，容器发布系统分为四层。最底层是基础环境层，包括 Docker 引擎、操作系统参数调整、镜像仓库。第二层是业务运行时层，主要是各类基础组件容器，比如 MySQL、Redis、Nginx，这些不需要频繁发布，但需要稳定。第三层是应用容器层，也就是每次业务代码变更后重新构建的那部分镜像。最上层是发布控制层，负责触发构建、审批、部署、回滚，这一层可以由 Jenkins 或 GitLab CI 来实现。

这四层之间是严格解耦的。基础环境层不常变动，升级 Docker 引擎前只需要做基本的功能验证；业务运行时层通过 docker-compose 管理，版本升级时单独操作；应用容器层跟着代码分支和 tag 走，每次发布只替换这一层的镜像；发布控制层只调用 Docker API 完成容器的创建、更新和删除，不直接触碰宿主机文件。这种分层让团队里的不同角色各管一段，开发关注应用镜像，运维关注基础环境和数据服务，极大减少了发布过程中的互相干扰。

2. 部署前的关键决策：网络、存储与安全

2.1 网络模型选型

Docker 默认创建的 bridge 网络适合单容器测试，但企业发布场景里多个容器之间需要互相通信，而且应用要对外提供服务，网络规划就必须提前想清楚。我的建议是：在 docker-compose.yml 里显式声明一个自定义 bridge 网络，让同项目的容器挂在同一个网络里，通过服务名进行 DNS 解析。这样应用容器访问数据库时，只需要写 db:3306，不需要关心数据库容器的 IP 地址。

如果业务要求容器直接使用宿主机网络（比如有些老旧应用依赖本机回环地址通信），可以给特定服务配置 network_mode: host。但这个方案需要慎用，因为宿主机网络模式下端口隔离失效，多个容器可能会争抢端口，而且容器之间无法通过服务名互通。我们平时的做法是：默认走自定义 bridge 网络，只有极少数确实需要监听特殊协议的组件才用 host 模式，并且单独标注。

在跨宿主机场景下，单纯依赖 Docker 内置网络是不够的，需要结合负载均衡器或者注册中心来做服务发现。单机 Compose 阶段可以不引入 Overlay 网络，但发布系统里访问容器服务的地址应该统一配置成环境变量，避免 IP 写死在代码里。网络问题排查中，七成以上都是因为容器网络模式混用或者防火墙策略没放行宿主机端口导致的。

2.2 数据持久化与目录读写权限

容器是无状态的，但业务数据必须有状态。这里最需要警惕的是把数据库跑在容器里却不配置持久化，一旦容器重建，数据全部丢失。Docker 提供了两种持久化方式：bind mount 和 volume。bind mount 直接把宿主机的某个目录挂载进容器，优势是运维可以直接去宿主机路径下查看文件，缺点是容易因为目录权限不一致导致容器内服务无法写入。volume 是 Docker 管理的存储卷，数据存放在 Docker 数据目录下，权限由 Docker 统一管理，出问题的概率更小。

给容器赋予目录读写权限是实操里踩得最多的坑。核心原因是容器内进程的用户 ID 和宿主机目录的所有者 ID 不一致。比如宿主机上挂载目录的所有者是 uid 1000，容器内服务进程是以 root 运行，看起来应该有权限写，但实际上如果是非 root 用户启动的服务，就可能出现 Permission denied。解决办法有两种：第一种是在 Dockerfile 里显式指定运行用户，让容器进程的 uid 和宿主机挂载目录的所有者一致；第二种是在 compose 文件里加 user: "1000:1000" 强制指定用户。我更推荐前者，因为镜像构建过程中就把用户固定下来，发布时不用额外处理。

对于 MySQL、Redis 这类有状态组件，我的持久化方案是：单独建一个 docker volume，用 docker volume create 命令创建，然后在 compose 文件中通过 volumes 段引用。同时，把备份脚本放在宿主机上，每天定时把 volumen 目录打包归档到备份服务器。容器可以随便重建，但数据卷不能随便删，这是企业发布系统最基本的一条底线。

2.3 镜像仓库与基础镜像规范

有了 Dockerfile 还不够，企业级发布系统必须有自己的镜像仓库。公共仓库不适合存业务镜像，私有仓库才是把容器化落地到生产环境的关键。搭建私有仓库最轻量的方式是跑一个 registry 容器，加一台 Nginx 做 TLS 终结和访问认证。更完整一点可以用 Harbor，支持镜像复制、漏洞扫描和 RBAC 权限控制。我们选择的自建方案是 Harbor，镜像多了之后，垃圾回收和标签保留策略可以自动执行，省了很多手工清理的麻烦。

基础镜像的规范直接决定了镜像的安全性和体积。原则是：能用官方镜像就不用第三方镜像，能用 slim 版本就不用完整版。以 Java 服务为例，构建阶段用 maven 镜像，运行阶段用 eclipse-temurin 的 JRE 镜像，两个阶段分离后最终镜像体积能控制在 200MB 以内。镜像标签必须遵循统一的命名规则，我们采用的是 registry 地址 + 项目名 + 镜像名 + 构建编号的格式。每次发布都生成新的 tag，绝不覆盖线上正在使用的旧 tag，否则一旦需要回滚，会发现旧版本的镜像已经被覆盖了。

3. 核心容器编排与 CI/CD 接入实操

3.1 Dockerfile 多阶段构建：把镜像做小做安全

多阶段构建是企业容器化发布里性价比最高的实践。拿一个典型的 Spring Boot 应用举例，早期我们直接在同一个阶段里装 Maven、编译代码、再复制进 JRE 环境，镜像里残留了大量编译依赖和临时文件，体积动辄上 GB。多阶段构建把“编译”和“运行”两个阶段拆开，最终镜像只保留运行环境和应用 jar 包。

# 构建阶段 FROM maven:3.9-eclipse-temurin-17 AS builder WORKDIR /build COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn clean package -DskipTests # 运行阶段 FROM eclipse-temurin:17-jre RUN useradd -u 1002 -M appuser WORKDIR /app COPY --from=builder /build/target/*.jar app.jar USER appuser EXPOSE 8080 ENTRYPOINT ["java", "-jar", "/app/app.jar"]

这里有几个细节值得注意。首先是 RUN useradd 创建了专用的非 root 用户，容器启动后进程不会以 root 身份运行，降低了安全隐患。其次是用了 ENTRYPOINT 而不是 CMD，避免启动命令被覆盖。还有一个很容易被忽略的点：如果应用需要写日志到目录，那么 /app/logs 应该在 Dockerfile 里先创建并 chown 给 appuser，否则运行时会因为权限不足而报错。多阶段构建完成后，用 docker scan 或者 trivy 扫描一遍镜像漏洞，扫描通过的镜像才会推送进 Harbor。

3.2 docker-compose 编排完整业务环境

一个业务发布项目通常包含应用服务、数据库、缓存和反向代理。用 docker-compose 把所有服务放在同一个文件里管理，发布时只需要替换应用服务的镜像，数据库和缓存服务保持稳定。下面是我们生产环境里实际使用的一个精简版 compose 文件。

version: "3.8" services: db: image: mysql:8.0 container_name: business_db command: - --character-set-server=utf8mb4 - --collation-server=utf8mb4_unicode_ci environment: MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD} MYSQL_DATABASE: business MYSQL_USER: bizuser MYSQL_PASSWORD: ${DB_PASSWORD} volumes: - mysql_data:/var/lib/mysql restart: unless-stopped healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost"] interval: 10s timeout: 5s retries: 5 deploy: resources: limits: memory: 2g cpus: "2" redis: image: redis:7-alpine container_name: business_redis command: redis-server --requirepass ${REDIS_PASSWORD} --appendonly yes volumes: - redis_data:/data restart: unless-stopped healthcheck: test: ["CMD", "redis-cli", "-a", "${REDIS_PASSWORD}", "ping"] interval: 10s timeout: 3s retries: 5 app: image: harbor.example.com/business/app:${BUILD_TAG} container_name: business_app depends_on: db: condition: service_healthy redis: condition: service_healthy environment: SPRING_PROFILES_ACTIVE: prod DB_URL: jdbc:mysql://db:3306/business DB_USER: bizuser DB_PASSWORD: ${DB_PASSWORD} REDIS_HOST: redis REDIS_PORT: 6379 volumes: - app_logs:/app/logs restart: unless-stopped healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8080/actuator/health"] interval: 30s timeout: 5s retries: 3 logging: driver: json-file options: max-size: "50m" max-file: "5" networks: default: name: business_prod_net volumes: mysql_data: external: true redis_data: external: true app_logs: external: true

compose 文件里最值得学习的是 depends_on 加 condition: service_healthy。这个写法保证了应用容器会等数据库就绪后才启动，而不是数据库还没起来就尝试连接导致启动失败。实际发布中，很多服务启动失败的根源都不是代码问题，而是依赖的服务没有就绪。healthcheck 的作用不只是启动时的等待，容器起来之后如果 MySQL 挂了，应用容器会退出并触发 restart，无状态组件的故障可以在没有人工干预的情况下自动恢复。

还有一点要特别说明：环境变量用 ${DB_PASSWORD} 的方式从宿主机环境或者 .env 文件读取，不要把密码明文写在 compose 文件里提交到代码仓库。发布系统在调用 docker-compose 命令之前，会从配置中心或密钥管理服务拉取环境变量注入到子进程。密钥不进代码库，这条规矩从第一天上容器化就应该立住。

3.3 接入 GitLab CI 实现代码发布自动闭环

编排文件准备好之后，剩下的事情就是把代码提交到构建、构建后推送镜像、推送后更新容器这三步串成流水线。我们在 GitLab CI 里实现了完整的发布闭环，核心逻辑分三个阶段。

stages: - build - push - deploy variables: IMAGE_TAG: ${CI_COMMIT_SHORT_SHA} build: stage: build script: - docker build -t harbor.example.com/business/app:${IMAGE_TAG} . only: - tags push: stage: push script: - docker login -u ${HARBOR_USER} -p ${HARBOR_PASSWORD} harbor.example.com - docker push harbor.example.com/business/app:${IMAGE_TAG} only: - tags deploy: stage: deploy script: - ssh deployer@${PROD_HOST} "export BUILD_TAG=${IMAGE_TAG}; cd /opt/business_deploy && docker-compose up -d --no-deps app" only: - tags when: manual

这里的关键设计是 deploy 阶段用了 when: manual，也就是说推送到镜像仓库之后，不会马上自动更新生产环境，而是由发布管理员在 GitLab 界面上点一下确认按钮，再执行部署。这个人工确认节点在生产发布里非常必要，避免了开发者在 tag 打完后发现代码有问题，但镜像已经自动推到生产环境里的尴尬。deploy 阶段通过 SSH 远程执行 docker-compose up -d，只更新 app 这一个服务，不触碰 db 和 redis，保证了数据服务不被误操作。

发布脚本我们单独放在一个目录里，不跟业务代码混在一起。具体内容就是先拉取最新镜像、再执行 up -d，之后检查容器 health 状态。这里有一个细节：docker-compose up -d 不会自动删除旧容器，如果镜像 tag 完全相同，Docker 可能不会重建容器。所以发布脚本一定要在 up 之前先 docker-compose pull 强制拉取新镜像，再执行 up -d，必要时加一个 --force-recreate，确保容器是用新镜像创建的。

4. 上线后的运维保障与故障排查

4.1 资源限制与容器监控

容器如果没有资源限制，一个服务出现内存泄漏，理论上可以把整个宿主机的内存吃光，拖垮所有业务。Docker 底层通过 cgroup 做资源隔离和限制，在 compose 文件的 deploy.resources 段里可以直接配置内存和 CPU 上限。配置好之后，哪怕应用真的出现内存溢出，也只是容器被 OOM Killer 杀掉并触发重启，不会影响宿主机上的其他容器。

日常监控最直接的工具是 docker stats，可以实时查看每个容器的 CPU、内存、网络和磁盘 IO。有条件的团队可以接入 Prometheus + cAdvisor，把容器指标采集后放入 Grafana 展示。我们发布系统里专门加了一个“发布后巡检”的步骤，部署完成后自动执行 docker ps -a 查看容器状态，再调用每个服务的 health API 做一次健康检查，只有所有检查都通过，发布流程才标记为成功。这一层巡检能拦截很大一部分“容器起来了但业务没起来”的发布事故。

日志也是监控的重要一部分。如果不加配置，Docker 的 json-file 日志驱动会把所有 stdout 写到宿主机磁盘上，运行久了磁盘会被填满。每个服务都应该在 compose 里配置 max-size 和 max-file，给日志文件设上限。更规范的做法是收敛到 ELK 或者 Loki 这类集中日志系统，发布系统通过日志关键字实时判断版本是否有异常堆栈。

4.2 典型故障排查与修复

容器部署的常见问题，我整理了一份排查速查表，这里挑几个高频的展开说明。

Windows 上跑 Docker Desktop 报虚拟化检测失败的案例非常多，尤其是老机器或者用虚拟机装 Windows 的机器。遇到这个报错先别急着重装，进 BIOS 确认 virtualization 开关是否打开，然后到“启用或关闭 Windows 功能”里确认 Hyper-V 和“虚拟机平台”已经勾选。装完一定要重启，很多人漏了重启这一步，Docker Desktop 依然起不来。

容器内启动 sshd 失败也是常见的坑。很多运维习惯进入容器排查问题，想在容器里跑 SSH 服务，但容器默认不会加载 systemd，直接 service sshd start 会报错。正确做法是用 docker exec 进入容器而不是启用 SSH。为了最小化攻击面，容器里尽量不装 SSH，需要执行命令时统一走 docker exec，远程操作通过宿主机跳板机。这样可以减少一个端口的暴露，安全性和操作体验都更好。

4.3 版本回滚与灰度发布策略

发布系统最容易被忽略的设计就是回滚。容器化发布的一大优势是回滚速度快，因为新版本和旧版本都是独立的镜像，切换只是改一个 tag 的问题。我们的回滚操作是：进入发布系统的部署记录页面，选择要回退的历史版本，系统会把 compose 文件里的 BUILD_TAG 替换为旧版本镜像的 tag，再执行 docker-compose up -d。

回滚前必须确认一个前提：旧版本的镜像还在镜像仓库里。所以镜像清理策略不能只看时间，要保留最近 N 个版本的镜像。Harbor 里的保留规则我们配置为保留最近 20 个 tag，同时对生产使用的 tag 设置 tag 不可变，防止被仓库侧自动清理删除。

灰度发布方面，单机 Docker Compose 环境下可以用端口映射的方式做简单灰度。部署新版本时用 8081 端口先启动一个测试实例，通过负载均衡切一部分流量过去，验证没问题后再将正式端口切换到新镜像。这种做法不需要引入额外组件，对中小团队足够用。如果后面服务数量变多、需要更细粒度流量管理，再考虑引入 K8s 的 Deployment 和 Service 来做金丝雀发布，但前期没必要为了“灰度”这个概念去增加架构复杂度。

另外提一个容易被忽略的点：容器默认时区是 UTC，很多业务日志打印的时间和实际时间差了 8 个小时，排查问题时会有误导性。可以在 compose 文件中给关键服务加 TZ=Asia/Shanghai 环境变量，或者更彻底一点，在基础镜像层统一修改时区配置。这个细节虽然小，但对发布后的日志排查效率提升非常明显。

从整个方案的设计过程来看，容器部署不只是一个技术动作，更多是把发布策略、数据安全、回滚机制和团队协作的边界固化在一个可执行的体系里。如果你也正在搭建自己的业务代码发布系统，建议最先完善镜像仓库和健康检查，这两块是后续所有自动化发布动作的基石。真正踩过几次线上事故之后，你会体会到，稳定的发布系统不是构建得有多炫酷，而是每一个环节都有明确的检查点、可回退的路径和可以快速定位问题的日志。