适用于 Laravel、Node 和 WordPress 的 Docker、CI/CD 与 Coolify 部署

"在我机器上能跑"代价很高。Docker + CI/CD + Coolify 的目标是可复现性：通过测试的同一制品进入 staging，做得好则进入生产。

适用于 Laravel API、Node 应用、现代前端（含 Astro SSR），以及在合理情况下的容器化 WordPress。有结账或网关的项目中，流水线是产品的一部分。

推荐的最小流水线

1. PR：lint + typecheck + 单元测试（必要时加关键 e2e）。
2. 多阶段构建：依赖 → 构建 → 精简运行时。
3. 不可变标签：registry/app:gitsha。
4. 基础镜像扫描。
5. 部署到 staging：Coolify 上使用相同变量（不同值）。
6. 冒烟 / healthcheck。
7. 提升到生产：使用相同 digest/tag。

多阶段构建（Laravel / Node）

• deps：带缓存安装 Composer/npm。
• build：npm run build、php artisan optimize、资源。
• runtime：非 root 用户的最终镜像，无工具链，无密钥。

避免事故的细节：

• 分层有序，避免每次变更都使 Composer 缓存失效。
• CI 中使用 npm ci，而非随意的 npm install。
• 非 root 用户 + storage 和 bootstrap/cache 权限。

Laravel 发布检查清单

1. 带 PHP-FPM 或 Octane 的多阶段镜像。
2. 变量在 Coolify/CI secrets 中，绝不在镜像里。
3. 迁移作为明确的部署步骤。
4. 队列和 scheduler 带 restart policy。
5. Healthcheck：廉价路由验证 app + DB。
6. 回滚：重新部署上一个 SHA 标签。

Docker 中的 WordPress

• wp-content/uploads 的持久卷。
• 通过 env / 运行时生成的 wp-config 管理密钥。
• 流量需要时 Redis 作为独立 object cache 服务。
• 多站点：注意域名、cookie 和路径。
• 大版本更新前备份 DB + uploads。

Coolify 配置

• 变量和密钥放在 Dockerfile 外。
• 真实 healthcheck（HTTP 200，而非仅"进程存在"）。
• 域名：规范 apex；www 301 重定向。
• 两个主机均配置 Let's Encrypt SSL。
• Restart policy 和可访问日志。
• staging 与生产分离。

上线前检查清单

• Tag = git SHA（不只是 latest）
• 密钥不在仓库和 Docker 层中
• staging 上 healthcheck 为绿
• 迁移已演练 + 近期备份
• Apex/www 和 SSL 已验证
• 部署后 workers/cron 存活
• 书面回滚计划

常见错误

• 生产环境重建不同，不再知道跑的是什么。
• Healthcheck 访问带 301 的 / 导致 unhealthy 循环。
• WordPress 卷属主为 root。
• 并行两次运行 migrate --force。
• 忘记队列 worker：web 起来了但 webhook 未处理。

部署不当的结账是定时炸弹。本流水线与以下主题相关： 支付和安全审计 .