# admin 管理前端部署

把 Nuxt 4 SSR 管理后台 **admin** 打成镜像 `starpivot-admin`，推送到私有仓库
`docker-registry.ideapsound.com`，再到目标机拉取重启。它本身不连数据库，只通过
`CONSOLE_BACKEND` 把 `/web/api`、`/console/api` 代理到同网络的 **console** 后端（容器名 `starpivot-console`）。

> 约定（与 console 一致）：仓库**只提交模板**（`*.example`）。部署脚本会把**模板 + `docker-compose.yml`** 同步到服务器，
> 但**绝不上传/覆盖**你在服务器上填好的真实 `.env`（首次需登录服务器照模板复制并填值）。admin 没有 yaml 配置，全靠 `.env`。

## 文件

| 文件 | 说明 |
|---|---|
| `../../apps/admin/Dockerfile` | 镜像构建（Nuxt SSR：pnpm build → node server），构建上下文 = `apps/admin/` |
| `docker-compose.yml` | 运行镜像 `starpivot-admin`，`.env` 注入容器，只 `expose 3000`（经反代对外） |
| `env/env.example` | 运行时环境**模板**（只一份，不分环境）；真实 `.env` 被 gitignore |
| `dev-deploy.sh` | **开发**：构建 dev 镜像 → 推送 → 远端拉取重启（固定 tag `dev-latest`） |
| `prod-build.sh` | **生产①**：构建带版本号镜像并推送（`:版本` + `:latest`），不部署 |
| `prod-deploy.sh` | **生产②**：部署指定版本到生产环境（目前只有 `along`），支持回滚 |

## 用法

### 本地（local）

本机直接起容器（用本目录的 `.env`，自行从 `env/env.example` 复制填写）：

```bash
cd deploy/admin
cp env/env.example .env                       # 填真实值（至少 CONSOLE_BACKEND）
docker compose up -d                          # 本机起 starpivot-admin
```

### 服务器准备（dev / prod，一次性）

脚本每次会同步 `docker-compose.yml` + `env/env.example` 模板到目标机。**首次**需登录服务器把模板复制成真实 `.env` 并填值
（`cp env.example .env`，dev-deploy 缺真实文件时也会打印该命令）：

```
<部署目录>/                       # dev / prod 均默认 /home/work/starpivot/admin
├── docker-compose.yml           # 从本目录拷贝
└── .env                         # 照 env.example 填（CONSOLE_BACKEND / TAG / DOCKER_NETWORK）
```

### 部署

```bash
cd deploy/admin
./dev-deploy.sh along           # 开发：发布到阿龙测试环境（构建 dev-latest → 推送 → 远端拉取重启）
./dev-deploy.sh                 # 不带参数 → 交互选择测试环境
./prod-build.sh 0.1.1 along     # 生产①：构建并推送 starpivot-admin:0.1.1 (+latest)；公司只剩 along，可省略
./prod-deploy.sh 0.2.1 along    # 生产②：部署 0.2.1 到生产环境（目前只有 along，省略即用它）
./prod-deploy.sh rollback along  # 生产回滚到上一版本（与当前版本来回切换）
```

> 改了服务器上的 `.env` 后，必须经 `up`（脚本里的 `docker compose up -d`）**重建容器**才生效，`restart` 不会重读环境变量。
> 生产版本/回滚记录存服务器上的 `.deploy_tag` / `.deploy_tag.prev`，不动你维护的 `.env`。

## 需要填写 / 提供的东西

- **部署目标与凭据**：写死在各脚本顶部。`dev-deploy.sh` 的 `env_profile()`（每个测试环境一套 `REGISTRY/DEV_HOST/DEV_KEY/DEV_DIR`，**目前只有 `along`**；新增环境加一段 case 并写进 `ENVS`）、`prod-deploy.sh` 的 `env_profile()`（每个生产环境一套 `REGISTRY/IMAGE_NAME/DEPLOY_HOST/DEPLOY_KEY/DEPLOY_DIR`，**目前只有 `along`**；新增环境加一段 case 并写进 `PROD_ENVS`）；
  仓库账号 `admin` / 密码已写死；`DEPLOY_KEY` 默认指向阿龙那把钥匙，可用环境变量覆盖：`DEPLOY_KEY=~/Documents/keys/loginscre.pem ./prod-deploy.sh …`。
  - 2026-09-13 移除了云雁/灵谱的部署目标（私钥在另一台开发机上，本机连不上）；2026-09-23 又删掉了它们的镜像仓库档案，现在只能推阿龙仓库。
  - ⚠️ 本目录脚本纳入 git，**公开仓库前务必清空** `*_HOST` 与 `REGISTRY_PASS`。
- **后端地址**：`.env` 的 `CONSOLE_BACKEND`，须指向同网络的 console 容器，默认 `http://starpivot-console:8080`。

## 端口与反代

admin HTTP `3000`（容器内，只 `expose` 不 publish）。须由 **1panel 反代 / NPM** 把后台域名
（如 `console.yunyanservice.xyz`）转发到 `starpivot-admin:3000`。admin 再在内部把 `/web/api`、`/console/api`
代理到 `starpivot-console:8080`，所以**单域名**即可跑通整套（浏览器 → 反代 → starpivot-admin → starpivot-console）。
admin 与 console 须在同一 `DOCKER_NETWORK`（默认 `1panel-network`）。