部署与安全

编排、迁移、构建锁，以及凭据怎么处理——这一页是运维接手时最该先看的。

编排

deploy/docker-compose.yml 编排 mysql / redis / nacos 与 6 个服务，镜像名固定为 <服务名>:1.0.0。中间件端口仅绑定 127.0.0.1，公网不可达。

# 推源码 → 服务器构建 → 重建容器
docker build -t <svc>:1.0.0 .
docker compose up -d --force-recreate <svc>

镜像 tag 不变时必须加 --force-recreate，否则 compose 认为配置没变、容器不会重建，你会对着旧镜像排查半天。

构建锁

服务器内存有限，并发构建会雪崩。构建须持 flock /var/lock/stack-build.lock 并等负载回落；deploy_serial.sh 已按这个礼数串行化。

数据库与迁移

6 个库；deploy/initdb/*.sql 只在 MySQL 首次初始化时自动执行 （data/ 为空才跑），已有实例必须手动导入。
迁移脚本一律 CREATE TABLE IF NOT EXISTS + 唯一键，保证重跑幂等。
带 USE user_center 这类显式选库，避免「在哪个库执行」变成玄学。

凭据

仓库里不放任何真实凭据。需要时自己生成一份：

cp deploy/.env.example deploy/.env     # .env 已被 .gitignore 排除
git ls-files deploy/.env                # 应输出为空

变量	用途
`MYSQL_ROOT_PASSWORD`	中间件口令，compose 以 `${VAR}` 注入各服务
`REDIS_PASSWORD`	同上
`JWT_SECRET`	令牌签名密钥，gateway 与 user-center 必须一致，长度 ≥ 32 字节
`DEPLOY_HOST` / `DEPLOY_USER` / `DEPLOY_PASSWORD`	本机运维脚本连服务器用；缺 `DEPLOY_PASSWORD` 时脚本直接报错退出

三条硬规矩

JWT_SECRET 泄露等于任何人可自行签发令牌——与数据库口令同级对待，定期轮换，轮换即全员重新登录。
签名密钥库（*.jks / *.keystore / *.p12 / *.pem）入库即视为泄露，必须轮换而不是删文件。
凭据一旦进过 git，改代码抹不掉历史——推送过的提交任何人都能检出，只能轮换。清理历史要重写提交并让所有人重新克隆，代价高，通常不做。

曾入库、现已轮换的历史凭据：MySQL / Redis 口令、JWT 签名密钥、服务器 root 口令、以及一份 workbench-release.jks 签名密钥（随原生端删除而移除，但历史里仍可检出）。这些都应视为已泄露。

本机运维工具

python deploy/ssh.py 'docker ps'                  # 远程执行
python deploy/upload.py <本地> <远端>             # 推送文件或源码
python deploy/tunnel.py 18080 8080                  # 端口转发到远端内网服务

三个脚本的凭据只从环境变量 / 本地 .env 取，缺 DEPLOY_PASSWORD 时立即退出，不拿空密码去撞 ssh——那既慢又像在爆破。

上线前检查清单

JWT_SECRET 走环境变量 / KMS，长度 ≥ 32 字节，没有进 Git
数据库与 Redis 口令只经环境变量注入，compose 文件里没有明文
网关前面有 LB 并由它重写 X-Forwarded-For；网关不信任客户端直接传的那个头
业务服务间不绕网关（东西向走 RPC 直连 + 服务鉴权），避免环路
actuator 不把 gateway 端点暴露到公网
新增 deploy/initdb/*.sql 已在已有实例上手动导入过
git ls-files deploy/.env 输出为空