mirror of
https://github.com/yeasy/docker_practice.git
synced 2026-10-20 09:46:54 +00:00
yeasy
12c2acca52
跑不起来的五处：
- 11.5:604 的 Compose 示例里 `db:` 顶在第 0 列，是**顶级键而不是服务**。
实测 yaml 解析结果是 `{'services': None, 'db': {...}}`，`docker compose up`
直接报错。同文件其他服务示例都缩进正确。
- 10.3 的 `docker manifest create` 把 `--amend` 当成每个 manifest 的前缀写了
两遍。upstream `docker/cli` 里它是 `BoolVarP(&opts.amend, "amend", "a", ...)`，
不取值；用法是 `create MANIFEST_LIST MANIFEST [MANIFEST...]`。照抄不仅参数
错位，还会打开"修改已有列表"的语义。改为直接跟位置参数。
- 21.7:288 `apk add postgresql-contrib pg-stat-monitor`。核对 Alpine v3.23 的
APKINDEX（427828 行，直接解包官方索引）：这两个包名都**不存在**，Alpine 只
提供带主版本号的 `postgresql16-contrib` 等；`apk add` 遇到未知包会中止，
该 Dockerfile 卡在第二步。改为 postgresql16-contrib 并去掉 pg-stat-monitor，
同时注明原因。
- 19.3:528 用 `pip install --user` 装到 `/root/.local`，运行阶段却 `USER nobody`。
Debian 的 `/root` 是 0700，nobody 无法进入，容器起来就找不到依赖。改为装到
`/opt/pydeps`（PYTHONUSERBASE）并同步 COPY 与 PATH。
- 11.8:202 的 `WORDPRESS_REDIS_HOST` 不被官方镜像识别——`wp-config-docker.php`
只映射固定的一组 WORDPRESS_* 变量，其中没有 Redis 项；Redis Object Cache
插件读的是 PHP 常量 `WP_REDIS_HOST`。改为经 `WORDPRESS_CONFIG_EXTRA` 注入。
违反本书自己规则的四处：
- 全书 21 处 `FROM ... as`（13 处在正文、8 处在 Dockerfile）用小写 as，会被
`docker buildx build --check` 的 FromAsCasing 报
`'as' and 'FROM' keywords' casing do not match`——而本书正是拿 `--check`
当准绳（7.6:16、10.2:23），且自己另有 12 处已经写成大写 AS。统一为 AS，
并把 7.17:174 那句"可以使用 `as` 来为某一阶段命名"一并改掉并附上检查项链接。
- 6.3:137 建议"可替换为 `httpd:latest`"，而同文件 22 行之后就写着"不要使用
`latest`，以保证部署的可重复性"。删去该建议。
- 7.6:253 写"多个 ENV 会创建多层"，而 4.5:5 明确区分过：只改元数据的指令
不新增文件系统层。ENV 正属于后者。改为"多出几条构建历史记录"。
核验方式的一点说明：查 Alpine 包是否存在时，我先用网页搜索接口做了一遍，
结果四个包名全部"命中"（包括本不该存在的那个）——那个页面会把查询词回显。
改用官方 APKINDEX 解包比对后才得到可信结论，两种方法交叉确认后才动手。
第二十一章 实战案例 - DevOps
版本说明
本章示例中使用的镜像版本遵循以下原则：
- GitHub Actions（
actions/checkout@v7等）采用大版本标签，代表最新的功能版本与稳定性的平衡 - 编程语言镜像（
golang:1.26-alpine、rust:1.95-alpine等）采用次版本标签，确保 API 稳定性同时获得安全更新 - 数据库镜像（
postgres:16-alpine、redis:8-alpine等）采用大版本标签，便于获得修复和改进 - 基础镜像（
alpine:3.21、debian:12等）采用大版本或次版本标签，避免latest以确保可再现性 - 实际项目中应根据需求调整版本，生产环境建议定期更新以获取安全补丁
DevOps 背景介绍
DevOps 是一种重要的开发和运维文化，强调开发团队和运维团队之间的协作和自动化。它致力于通过自动化和流程优化，加快软件交付速度，同时提高系统的稳定性和可靠性。Docker 作为容器化技术的领导者，已成为现代 DevOps 工作流中不可或缺的工具。通过容器化应用，开发团队可以确保“一次构建，处处运行”，消除开发、测试和生产环境的差异，大大简化了部署流程。
Docker 在 DevOps 中的角色
Docker 在 DevOps 工作流中承担多个关键角色。首先，它标准化了应用的开发和部署环境，使得团队成员在相同的 Docker 容器中工作，避免了“在我的机器上可以运行”的问题。其次，Docker 与 CI/CD 流程无缝集成，通过自动化的镜像构建、测试和部署，实现快速的迭代周期。此外，Docker 还支持微服务架构和容器编排，使团队能够更灵活地扩展应用和管理基础设施。
CI/CD 管道的重要性
持续集成与持续部署 (CI/CD) 是现代 DevOps 的核心。通过自动化的代码检测、测试、构建和部署流程，团队可以更加频繁地发布新版本，同时保持系统的稳定性和可靠性。Docker 在 CI/CD 中扮演了重要角色：
- 标准化构建环境 - Docker 确保开发、测试和生产环境完全一致，消除了环境差异带来的问题
- 加速流水线 - 容器的快速启动和轻量级特性，大幅加快了 CI/CD 流程的执行效率
- 灵活的测试框架 - 可以轻松创建短生命周期的测试容器，并行运行多个测试
- 自动化镜像发布 - CI/CD 工具可以自动构建、扫描、标记和推送 Docker 镜像到仓库
- 蓝绿部署和金丝雀发布 - 利用容器的隔离性和可重复性，实现高级发布策略
本章将通过介绍 GitHub Actions、Drone 等流行的 CI/CD 工具，展示如何在实际项目中构建完整的自动化流水线。我们还将演示如何在本地开发环境中集成 Docker，使用 IDE 的容器开发插件，加快本地迭代周期。
本章学习目标
通过学习本章内容，你将能够：
- 理解 DevOps 文化、CI/CD 流程和容器化的紧密关系
- 掌握完整的 Docker 工作流，从代码提交到线上部署的每一个环节
- 学习如何使用 GitHub Actions 实现自动化 CI/CD，以及工作流的编写和优化
- 了解 Drone 等第三方 CI/CD 工具的架构、部署和配置方式
- 学会在本地 IDE (VS Code) 中集成 Docker，利用容器开发工具提升开发效率
- 掌握实战中常见的 DevOps 场景、最佳实践和故障排查方法
章节内容导航
- DevOps 完整工作流 — 从代码到部署的全流程
- GitHub Actions — 使用 GitHub Actions 实现 CI/CD
- Drone — Drone CI/CD 平台简介和配置
- Drone Demo — Drone 实战演示和应用
- 在 IDE 中使用 Docker — IDE 与 Docker 集成的好处
- VS Code — Visual Studio Code 容器开发指南
- 实战例子 — 真实项目中的 DevOps 应用案例
- 本章小结