★ FEATURED ARTICLE 示例工程【免费下载链接】udemy-docker-masteryDocker Mastery Udemy course to build, compose, deploy, and manage containers from local development to high-availability in the cloud项目地址https://gitcode.com/gh_mirrors/ud/udemy-docker-mastery点击查看免费下载本文基于仓库 references/S11 Swarm App Lifecycle.md 课程讲义系统讲解 Docker 应用从开发、构建到部署的全生命周期管理包括在本地 Docker Compose 中使用 Secrets 管理敏感信息、用单一 Compose 设计贯穿开发/测试/生产三套配置、在 Swarm 中对运行中的服务进行滚动更新与扩缩容以及在 Dockerfile、容器和服务三个层级配置健康检查。读完本文你将掌握一套可直接落地的容器应用交付闭环安全传密 → 分环境编排 → 在线更新 → 自动探活。一、使用 Secrets 与本地 Docker Compose把密码从环境变量里解放出来在早期的 Compose 编排中数据库密码通常直接写进environment比如POSTGRES_PASSWORDmypasswd可见于 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.yml基准文件只声明 drupal 与 postgres 两个服务的镜像docker-compose.override.yml开发环境默认覆盖build: .构建本地镜像、暴露 8080 端口、挂载多个命名卷与 themes 目录docker-compose.test.yml测试环境构建镜像、暴露 80 端口、用./sample-data绑定挂载数据库目录做集成测试docker-compose.prod.yml生产环境不再build端口映射为80:80secrets 改为external: true由 Swarm 提供课程讲义中的完整命令序列及逐条说明# 开发阶段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关键机制说明自动合并 overridedocker-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 web5 # 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 web5是声明式扩缩容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.md5 个服务的投票应用拓扑与参考答案 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-cmdpg_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-cmdpg_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 注入镜像内使用targetmode: 0555见 example-voting-app/answer/example-voting-app-stack.yml 中 redis 与 db 两个服务的healthcheckconfigs配置其配套脚本 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 应用生命周期流水线传密本地用 Composesecrets.file上 Swarm 换external: truedocker secret create容器内统一从/run/secrets/读取编排一份基准 compose override/test/prod 三份覆盖文件用docker-compose config渲染验证实现一稿三用更新docker service scale/update --image/--publish-rm/--publish-add/--force支撑运行中的滚动变更探活--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.ymlSwarm Secrets 上云改造练习swarm-secrets-assignment-1/README.md 与答案 swarm-secrets-assignment-1/answer/docker-compose.yml带健康检查的生产级投票应用 Stackexample-voting-app/answer/example-voting-app-stack.yml服务化编排命令参考swarm-app-1/answer/answer.sh、swarm-stack-4/answer/voting-app-placement.yml。赞分享示例工程【免费下载链接】udemy-docker-masteryDocker Mastery Udemy course to build, compose, deploy, and manage containers from local development to high-availability in the cloud项目地址https://gitcode.com/gh_mirrors/ud/udemy-docker-mastery点击查看免费下载相关推荐Docker Swarm 滚动更新服务实战教程Docker Swarm 滚动更新服务实战教程 前言 在现代分布式系统中服务的平滑升级是保证系统高可用的关键能力。Docker Swarm 作为 Docker文档教程gbrain 大脑健康维护实战指南从健康检查、Dream 合成周期到自动修复闭环gbrain 大脑健康维护实战指南从健康检查、Dream 合成周期到自动修复闭环 导读 本文以 gbrain 仓库内置的 maintain 技能 plug人工智能RAGAgent 记忆MCP 服务知识管理Rook Ceph OSD 全生命周期管理实战健康检查、增删替换与迁移Rook Ceph OSD 全生命周期管理实战健康检查、增删替换与迁移 Ceph Object Storage DaemonsOSD是 Ceph 存储平台云原生存储容器编排运维上一篇RuoYi-Cloud 富文本编辑器深度解析与实战指南下一篇NautilusTrader问题排查从崩溃到盈利的实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
