starpivot/deploy

yunyan-sas 部署

一键发布测试环境（dev）

cd deploy
./dev-deploy-all.sh                  # 交互选公司(环境)，按 app → console → admin 全量发布
./dev-deploy-all.sh along            # 全量发到阿龙测试环境
./dev-deploy-all.sh yunyan app admin # 只发 app 和 admin 到云雁测试环境
./dev-deploy-all.sh along -y -k      # 免确认；某个服务失败也继续发后面的
./dev-deploy-all.sh along -n         # dry-run，只打印会执行什么

公司/环境：lingpu（灵谱·香港）、yunyan（云雁·广州）、along（阿龙），与各服务 dev-deploy.sh 的 ENVS 同名，脚本启动时会交叉校验，一边加了新环境另一边忘了加会直接报错。

它只是按顺序调各服务自己的 deploy/<服务>/dev-deploy.sh <环境> 并汇总结果，部署规则仍然 只有一处；单独发某个服务照旧进服务目录跑 ./dev-deploy.sh <环境>。服务器上还没有真实 .env 时子脚本会推完镜像就停下，汇总表里记为「跳过」而不是「成功」。

以下是早期 deploy.sh <env> [action] 的说明，与现在的 dev-deploy.sh / prod-build.sh / prod-deploy.sh 流程不完全一致，仅供参考。

每个服务目录各一个 deploy.sh，服务名取自所在目录，指令为 <env> [action]。 每个服务自带单服务 compose + 环境模板；依赖服务（PostgreSQL / Redis / NATS） 由目标环境共享提供，不在 compose 内搭建，只在 env 里填连接地址。

服务

• console/ — Go 控制面服务（:8080）
• admin/ — Nuxt 管理前端（:3000，通过 CONSOLE_BACKEND 连 console）

目录结构

deploy/
└── <service>/                    # console / admin
    ├── deploy.sh                 # 本服务部署脚本（服务名 = 目录名）
    ├── docker-compose.yml        # 单服务 compose（变量驱动，无依赖服务）
    ├── env/
    │   ├── local.env.example
    │   ├── dev.env.example
    │   ├── prod.env.example
    │   └── (复制填写后的 local.env / dev.env / prod.env)
    └── (console 额外: confs/console.yaml、log/)

两个服务的 deploy.sh 内容相同，靠所在目录名区分服务。

用法

进入服务目录运行：

cd deploy/console
./deploy.sh local up       # 本机起 console
./deploy.sh dev            # 一键发布 console 到开发服务器（动作默认 deploy）
./deploy.sh prod           # 一键发布 console 到生产服务器
./deploy.sh prod logs      # 看生产 console 日志

cd deploy/admin
./deploy.sh local up       # 本机起 admin
./deploy.sh prod           # 发布 admin 到生产服务器

参数：

• env：local | dev | prod
• action：
  • local：up（默认）| down | restart | logs | ps | pull | build
  • dev / prod：deploy（默认，构建推送+同步+远程拉起）| up（仅远程拉起）| build | down | restart | logs | ps | pull

首次配置（dev / prod）

配置分两处：部署目标/仓库凭据写死在各服务的 deploy.sh，运行时配置放 env 文件。

1. 部署目标 + 私有仓库（改各服务 deploy.sh 顶部 deploy_profile，console / admin）：
   • 按 dev / prod 段填 DEPLOY_HOST(服务器 IP) 和 REGISTRY_PASS(仓库密码)
   • 通用项已给默认：REGISTRY / REGISTRY_USER / DEPLOY_PORT / DEPLOY_USER / DEPLOY_KEY
   • DEPLOY_DIR 自动 = /opt/yunyan/<服务名>，无需填
   • 注：两个 deploy.sh 各填各的，不共享
2. 运行时配置（每个服务、每个环境一份 env）：

   cp console/env/dev.env.example console/env/dev.env
   cp admin/env/dev.env.example   admin/env/dev.env
   

   需要填：

   • 依赖服务连接（console）：POSTGRES_DSN / REDIS_ADDR+REDIS_PASSWORD / NATS_URL
   • 网络与端口：DOCKER_NETWORK / ADMIN_PORT / TAG
3. 目标机要求：装 docker + docker compose v2、能访问私有镜像仓库、SSH 公钥已授权、依赖服务在 DOCKER_NETWORK 网络内可达。

部署顺序

依赖服务（DB/Redis/NATS）共享、由环境预先提供。两个应用服务按序：

1. 先 console（admin 依赖它）
2. 再 admin（同一目标机、同一 DOCKER_NETWORK，用容器名 yunyan-console 连 console）

注意

• env/*.env（真实）含密钥/DSN，已 .gitignore 忽略；仓库只保留 *.example。
• ⚠️ 部署目标/仓库密码写死在各服务 deploy.sh，而它们会进 git——DEPLOY_HOST、REGISTRY_PASS 等会随仓库提交（私有仓库内可接受；公开前务必清理两个 deploy.sh）。
• prod 的 TAG 用固定版本号便于回滚；FIELD_ENCRYPT_KEY / CONSOLE_TOKEN_KEY 用强随机值，环境间不复用。
• 镜像构建复用仓库根目录 build.sh（deploy.sh 在 deploy/build 动作时自动调用，目标=服务名）；当前仓库尚无 build.sh，build/deploy 前需先补。