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 解包比对后才得到可信结论，两种方法交叉确认后才动手。
第十章 Docker Buildx
Docker Buildx 是一个 docker CLI 插件，其扩展了 docker 命令，支持 Moby BuildKit 提供的功能。提供了与 docker build 相同的用户体验，并增加了许多新功能。
Buildx 需要 Docker v23.0+（该版本起 BuildKit 成为默认构建引擎）。推荐使用 Docker v29 及以上版本以获得最完整的 Buildx 功能支持。
本章内容
本章将详细介绍 Docker Buildx 的使用，包括：
供应链安全与存储后端前瞻：现代软件供应链中，镜像来源证明（Provenance，在 BuildKit 中默认以
mode=min添加）和软件物料清单（SBOM，可通过--sbom=true显式开启）已经成为极其重要的构建产出。这些 Attestations 数据会作为 manifest 附着在 镜像索引 (Image Index) 上。 正是基于此诉求，自 Docker Engine 29 起在新安装场景默认启用的containerd image store提供对 Image Index 的完美本地支持能力，解决了传统经典存储后端（Classic Store）无法有效处理带 Attestations 镜像索引的瓶颈。这使得你可以利用docker buildx imagetools inspect等手段，甚至做到无需拉取完整镜像内容即可在 Registry 或本地高效校验镜像的安全元数据。