企业官网建设流程全解析

• 示例工程

本文基于仓库 references/S11 Swarm App Lifecycle.md 课程讲义，系统讲解 Docker 应用从开发、构建到部署的全生命周期管理：包括在本地 Docker Compose 中使用 Secrets 管理敏感信息、用"单一 Compose 设计"贯穿开发/测试/生产三套配置、在 Swarm 中对运行中的服务进行滚动更新与扩缩容，以及在 Dockerfile、容器和服务三个层级配置健康检查。读完本文，你将掌握一套可直接落地的容器应用交付闭环：安全传密 → 分环境编排 → 在线更新 → 自动探活。

一、使用 Secrets 与本地 Docker Compose：把密码从环境变量里解放出来

在早期的 Compose 编排中，数据库密码通常直接写进environment，比如POSTGRES_PASSWORD=mypasswd（可见于 compose-assignment-1/answer/docker-compose.yml 等示例）。这种方式在本地实验尚可，一旦配置文件进入版本库或分享给他人，凭据就等同于公开。

Compose 提供了一等公民的secrets顶层关键字：以文件形式把敏感信息挂载进容器，容器内以/run/secrets/<secret 名>的路径读取，而不是以环境变量形式暴露（环境变量会被docker inspect、日志或子进程继承轻易看到）。

仓库中的 secrets-sample-2/docker-compose.yml 是一个完整可运行的本地 Secrets 示例：

version: "3.9" services: psql: image: postgres secrets: - psql_user - psql_password environment: POSTGRES_PASSWORD_FILE: /run/secrets/psql_password POSTGRES_USER_FILE: /run/secrets/psql_user secrets: psql_user: file: ./psql_user.txt psql_password: file: ./psql_password.txt

配套的明文种子文件是 secrets-sample-2/psql_user.txt（内容为dbuser）和 secrets-sample-2/psql_password.txt（内容为QpqQcgD7dxVG）。注意：file:指向的本地文本文件是唯一需要保留敏感内容的地方，Compose 会在容器内把它们挂载为只读文件。

配合课程讲义的操作序列，完整实践流程如下：

# 1. 确认当前处于 Swarm 环境（用于后续与本地 Compose 对比） docker node ls # 2. 在 compose 文件所在目录启动服务（后台运行） docker-compose up -d # 3. 进入 psql 容器，直接读取挂载的 secret 文件 docker-compose exec psql cat /run/secrets/psql_user # 4. 查看 compose 项目当前状态 docker-compose ps

要点解释：

• docker-compose up -d会先读取secrets:顶层块中的file:定义，把文件内容注入到对应容器的/run/secrets/目录；
• docker-compose exec psql cat /run/secrets/psql_user用于验证 secret 是否真正以文件形式挂载——这是排查"容器里为什么读不到密码"的第一步；
• 对 PostgreSQL 而言，官方镜像支持POSTGRES_PASSWORD_FILE与POSTGRES_USER_FILE两个特殊环境变量（指向/run/secrets/下的文件路径），它会自动从文件中读取密码/用户名完成初始化，从而彻底避免在environment中明文传递凭据；
• 该模式后续会被 swarm-secrets-assignment-1/answer/docker-compose.yml 升级为 Swarm 场景：把secrets.psql-pw.file替换为external: true，由docker secret create预先在 Swarm 集群中创建，再通过docker stack deploy挂载（详见其 README.md 中的要求与步骤）。

补充：本地 Compose 的secrets与 Swarm Secrets 的语义略有不同——本地模式把文件内容直接挂载为只读文件，Swarm 模式则由集群的 secret store 管理，仅以文件形式下发给调度到对应服务的任务。两者在容器内的读取方式一致（/run/secrets/<name>），这正是一套 Compose 设计可以平滑迁移到 Swarm 的基础。

二、单一 Compose 设计贯穿全生命周期：Dev / Test / Prod 一稿三用

"Full App Lifecycle: Dev, Build and Deploy With a Single Compose Design" 是本章的核心思想：用一份基准docker-compose.yml定义应用拓扑，再通过多个-f追加的覆盖文件（override）区分开发、测试、生产环境，避免维护三份互相漂移的 YAML。

仓库 swarm-stack-3 目录提供了这套设计的完整样例，对应关系如下：

课程讲义中的完整命令序列及逐条说明：

# 开发阶段：docker-compose 默认会自动合并 docker-compose.yml 与 docker-compose.override.yml docker-compose up -d # 用 docker inspect + TAB 补全，快速查看刚启动的容器详情 docker inspect <TAB 自动补全容器名> # 停止并移除当前 compose 项目中的容器（卷与镜像默认保留） docker-compose down # 测试阶段：显式叠加 test 覆盖文件，跑一套独立的测试环境 docker-compose -f docker-compose.yml -f docker-compose.test.yml up -d # 再次用 inspect 查看测试环境的容器 docker inspect <TAB 自动补全容器名> # 生产阶段：先看 config 命令的帮助 docker-compose -f docker-compose.yml -f docker-compose.prod.yml config --help # 把多文件合并渲染后的最终配置打印到终端（只渲染，不启动任何容器） docker-compose -f docker-compose.yml -f docker-compose.prod.yml config # 将渲染结果保存为文件，用于审计、分享或交给 CI 继续处理 docker-compose -f docker-compose.yml -f docker-compose.prod.yml config > output.yml

关键机制说明：

• 自动合并 override：docker-compose up默认隐式追加同目录的docker-compose.override.yml，所以开发时无需写-f；测试/生产环境则必须显式写出全部-f列表，避免误加载开发配置；
• config是"只读渲染器"：它把多份文件按 Compose 规范合并、补齐默认值并校验语法，是部署前必做的"试运行"，> output.yml可将结果落盘供审查；
• 覆盖文件的合并规则：同名服务按"后来者覆盖"合并键值；docker-compose.prod.yml中secrets.psql-pw的external: true（见 docker-compose.prod.yml）意味着密码不再由文件提供，而是直接引用 Swarm 集群中已存在的 secret，这是"单一设计"从本地平滑上云的典型手段；
• 对应的基线 Dockerfile 见 swarm-stack-3/Dockerfile，它从drupal:9出发、安装 git 并把./themes拷贝进镜像，配合docker-compose.override.yml的build: .完成开发期镜像构建。

三、Service Updates：让运行中的 Swarm 服务"动起来"

Compose 解决的是多容器应用的编排，而进入 Swarm 后，应用的运维重心转移到docker service命令族：无需重建整条链路，就能对运行中的服务进行扩缩容、换镜像、改端口、强制重启。课程讲义给出的实战命令如下：

# 1. 创建一个名为 web 的服务，把宿主 8088 端口映射到容器 80 端口 docker service create -p 8088:80 --name web nginx:1.13.7 # 2. 查看当前服务列表 docker service ls # 3. 把 web 服务横向扩到 5 个副本（任务） docker service scale web=5 # 4. 滚动更新：把 web 服务的镜像从 1.13.7 降级到 1.13.6 # Swarm 会按更新策略逐个替换任务，不会一次性全部重启 docker service update --image nginx:1.13.6 web # 5. 滚动更新端口映射：移除旧的 8088 发布端口，新增 9090:80 docker service update --publish-rm 8088 --publish-add 9090:80 web # 6. 强制重新部署：不改变配置，仅触发所有任务重建（常用于 # 在节点间重新调度、或让任务重新拉取镜像内容） docker service update --force web

逐条深化解读：

• docker service create是 Swarm 版"容器运行"，-p 8088:80的发布端口由 Swarm 路由网格（Routing Mesh）承载，无论任务调度到哪个节点，集群内任意节点的 8088 端口都能访问到该服务；
• docker service scale web=5是声明式扩缩容：Swarm 调度器负责补齐/缩减任务数，无需手工逐个启动容器；
• docker service update --image ...触发滚动更新（rolling update），默认一次只替换 1 个任务并等待其就绪，期间服务不中断；更新失败时可配合--update-failure-action rollback自动回滚（该参数在仓库 example-voting-app/answer/example-voting-app-stack.yml 的update_config中有实际配置示例）；
• --publish-rm 8088 --publish-add 9090:80演示了不改镜像、只改网络端口的原地更新能力；
• --force会在不改变任何配置的情况下强制重启所有任务，常用于把任务迁移到新加入的节点、或绕开"配置未变化则不更新"的语义强制重新部署。

多服务、多节点的完整编排案例可参考 swarm-app-1/README.md（5 个服务的投票应用拓扑）与参考答案 swarm-app-1/answer/answer.sh；其 Stack 化版本见 swarm-stack-5/example-voting-app-stack.yml 与带部署约束的 swarm-stack-4/answer/voting-app-placement.yml。

四、Healthchecks：在 Dockerfile、容器与服务三层布控"探活"

健康检查是应用生命周期中保障"更新不中断、故障自动处理"的基石。课程讲义用一个 PostgreSQL 容器做对照实验，直观展示有无健康检查的差异：

# 对照组 p1：不带健康检查直接后台启动 postgres docker container run --name p1 -d postgres # 观察容器列表（p1 会显示为 Up，但没有健康状态列） docker container ls # 实验组 p2：通过 --health-cmd 指定健康检查命令 # pg_isready 探测 postgres 是否可接受连接，失败则以 exit 1 上报 docker container run --name p2 -d --health-cmd="pg_isready -U postgres || exit 1" postgres # 再观察：p2 会依次经历 starting -> healthy / unhealthy 状态 docker container ls # 查看健康检查的详细执行历史（exit code、输出、时间戳） docker container inspect p2

同样的机制在 Swarm 服务上同样可用，只是从"单容器健康状态"升级为"调度与更新决策依据"：

# 无健康检查的服务：调度器只能依据进程存活判断任务是否正常 docker service create --name p1 postgres # 带健康检查的服务：任务必须在检查通过后才被视为 healthy # Swarm 会把 unhealthy 任务移出负载均衡，并在滚动更新时等待健康通过 docker service create --name p2 --health-cmd="pg_isready -U postgres || exit 1" postgres

要点说明：

• 健康检查的默认参数：--health-cmd之外，还可通过--health-interval（间隔，默认 30s）、--health-timeout（超时）、--health-retries（连续失败多少次判为 unhealthy）微调探活节奏；docker container inspect p2输出的State.Health字段会记录每次检查的ExitCode、Output与FailingStreak；
• 检查命令的写法：以|| exit 1结尾是为了把"探测失败"显式转化为非零退出码，这是 Docker 判定 unhealthy 的唯一依据；
• 服务级健康检查的意义：在 Swarm 滚动更新与自动恢复中，健康状态是"任务是否真正可用"的准绳——docker service update --image ...只有在健康检查通过后才会继续替换下一个任务；
• 生产化进阶：健康检查脚本也可以作为 Swarm Config 注入镜像内使用（target+mode: 0555），见 example-voting-app/answer/example-voting-app-stack.yml 中 redis 与 db 两个服务的healthcheck+configs配置，其配套脚本 answer/redis-healthcheck 与 answer/postgres-healthcheck 展示了"ping PONG / SELECT 1"等真实探活实现；
• 镜像内默认健康检查：健康检查同样可以在 Dockerfile 中声明（HEALTHCHECK指令），仓库中的 dockerfiles/entrypoint/assignment02/answer/Dockerfile 配合启动脚本 docker-entrypoint.sh 演示了"启动时校验/app/data目录、把 secrets 转成环境变量、最后exec "$@"交给 CMD"的完整入口脚本模式，这正是把健康检查、初始化逻辑与业务启动串成一条链路的标准做法。

五、小结与仓库导航

把四个环节串起来，就得到一条完整的 Swarm 应用生命周期流水线：

1. 传密：本地用 Composesecrets.file，上 Swarm 换external: true+docker secret create，容器内统一从/run/secrets/读取；
2. 编排：一份基准 compose + override/test/prod 三份覆盖文件，用docker-compose config渲染验证，实现"一稿三用"；
3. 更新：docker service scale/update --image/--publish-rm/--publish-add/--force支撑运行中的滚动变更；
4. 探活：--health-cmd与镜像内HEALTHCHECK为容器和服务提供可用性判定，为安全滚动更新兜底。

若需进一步深入，可在仓库中按序研读以下资源：

• 本地 Secrets 完整样例：secrets-sample-2/docker-compose.yml；
• 全生命周期多文件编排：swarm-stack-3（含 docker-compose.yml、docker-compose.override.yml、docker-compose.test.yml、docker-compose.prod.yml）；
• Swarm Secrets 上云改造练习：swarm-secrets-assignment-1/README.md 与答案 swarm-secrets-assignment-1/answer/docker-compose.yml；
• 带健康检查的生产级投票应用 Stack：example-voting-app/answer/example-voting-app-stack.yml；
• 服务化编排命令参考：swarm-app-1/answer/answer.sh、swarm-stack-4/answer/voting-app-placement.yml。

• 示例工程