79 lines
4.9 KiB
Markdown
79 lines
4.9 KiB
Markdown
# 仅源码部署调整设计
|
||
|
||
- 功能编号：GOV-009
|
||
- 决策日期：2026-08-13
|
||
- 状态：设计已确认，待实施
|
||
- 取代范围：GOV-006、GOV-009 中仍有效的 Docker 部署约定
|
||
|
||
## 结论
|
||
|
||
项目只支持源码部署，不再提供或维护任何 Docker 运行、构建、测试或部署能力。开发环境的 Redis 使用开发机已开机自启的 `127.0.0.1:6379`；生产环境的 Redis、MySQL 5.7.42 和 RocketMQ 均由服务器外部系统服务提供。应用只连接这些基础设施，不负责安装、启动、停止或删除它们。
|
||
|
||
Ubuntu 源码部署是唯一生产交付路径：固定提交在构建机完成依赖安装、测试和 Web/Server 构建，将不可变发布目录部署到服务器，再由 systemd 管理 API、Scheduler、Worker，Nginx 托管 Web 静态文件并代理 `/api/`。
|
||
|
||
## 调整范围
|
||
|
||
### 删除的 Docker 能力
|
||
|
||
- 删除 Web 与 Server Dockerfile、根 `.dockerignore` 和 Web 容器专用 Nginx 配置。
|
||
- 删除开发与生产 Compose 文件；本地 Redis 不再由仓库拉起。
|
||
- 删除生产 Compose 部署文档、Docker 构建验证器、不可变镜像校验器及对应测试。
|
||
- 删除根级 `check:images`、`verify:docker` 等 Docker 专用命令。
|
||
- API E2E 启动器不再在 Redis 不可达时创建临时容器；Redis 不可达必须直接失败并提示本机服务要求。
|
||
|
||
### 保留和加强的源码能力
|
||
|
||
- 保留 `deploy/env/development/` 与 `deploy/env/production/` 的四进程配置契约。
|
||
- 保留并验证 systemd API、Scheduler、Worker 服务文件和生产 Nginx 配置。
|
||
- 保留 Web、API、Scheduler、Worker 的独立构建产物。
|
||
- `verify:release` 只执行源码发布门禁，不调用 Docker。
|
||
- 本地开发文档先验证 `redis-cli -h 127.0.0.1 -p 6379 ping`，再从源码启动应用进程。
|
||
|
||
## 源码部署流程
|
||
|
||
1. 在已固定 Node.js 22.x 与 pnpm 10.25.0 的构建机检出确定提交。
|
||
2. 执行 `pnpm install --frozen-lockfile` 和根级源码发布验证。
|
||
3. 构建 Web dist 与 API、Scheduler、Worker 三个 Server dist 入口。
|
||
4. 将完整、只读的版本发布目录放入 `/opt/a-share-analysis/releases/<版本或提交>/`。
|
||
5. 将 `/opt/a-share-analysis/current` 原子切换到目标发布目录。
|
||
6. systemd 通过 `/etc/a-share-analysis/*.env` 分别向三个 Server 进程注入最小配置。
|
||
7. Nginx 从当前 Web dist 提供静态文件，并把 `/api/` 代理到 API 进程。
|
||
8. 验证 systemd 状态、API 健康接口、Web 首页和同源 API 代理。
|
||
|
||
## 源码发布门禁
|
||
|
||
自动验证必须覆盖以下真实行为：
|
||
|
||
- 仓库不存在 Dockerfile、Compose、`.dockerignore`、Docker 专用验证器和 Docker 命令。
|
||
- README、现行架构、治理规范和部署索引只宣称源码部署。
|
||
- Web、API、Scheduler、Worker 构建产物存在且入口与 systemd `ExecStart` 一致。
|
||
- Nginx 静态目录指向 Web dist，`/api/` 代理指向 API 端口。
|
||
- 三份 systemd 服务使用独立 `EnvironmentFile`、非 root 用户和明确工作目录。
|
||
- 本地开发要求外部 Redis 可达，不存在自动拉起或容器兜底路径。
|
||
- Redis、MySQL 和 RocketMQ 的密码或 Token 不进入仓库、命令参数或构建产物。
|
||
|
||
## 失败处理
|
||
|
||
- 本地 Redis 不可达时，API E2E 和本地启动应快速失败，错误明确说明需要启动本机 Redis 服务；不自动改变用户机器状态。
|
||
- 源码构建任一产物缺失时阻断发布，不允许发布部分进程。
|
||
- systemd 或 Nginx 验证失败时保持上一 `current` 目录，不覆盖外部 env 和基础设施数据。
|
||
- 数据库迁移出现后，迁移必须在切换 `current` 和重启服务前单独执行；继续禁止 TypeORM `synchronize: true`。
|
||
|
||
## 历史追溯
|
||
|
||
GOV-006 与 GOV-009 已发布或已封存材料中的 Docker 记录属于当时真实设计和验证事实，不删除、不改写为“从未支持”。当前设计通过新的决策文档、现行架构、治理规范和发布说明明确取代其 Docker 结论。Git 历史仍可直接比较决策前后的文件和门禁变化。
|
||
|
||
## 回退策略
|
||
|
||
本调整尚未发布版本标签。实施失败时使用中文回退提交恢复本调整前的仓库内容，禁止强推或移动既有标签。外部 Redis、MySQL、RocketMQ、`/etc/a-share-analysis/*.env` 和服务器发布目录不由代码回退删除或覆盖。
|
||
|
||
源码部署调整完成后，应用回退只允许把 `/opt/a-share-analysis/current` 切回上一完整发布目录并重启 systemd 服务；不再提供镜像回退方案。
|
||
|
||
## 验收标准
|
||
|
||
- 仓库和现行文档中不存在仍可执行或仍被宣称支持的 Docker 能力。
|
||
- 本地与生产基础设施均被定义为外部系统服务。
|
||
- 根级完整验证、源码发布门禁、双视口页面验证、代码 Review 和规范 Review 全部通过。
|
||
- GitNexus 开发后分析只出现预期的部署与测试门禁影响。
|
||
- 所有变更以中文 Conventional Commit 提交并推送 Gitea；用户确认架构前仍不创建 `v0.0.8`。
|