Merge remote-tracking branch 'gitea/home' into home

This commit is contained in:
zizi 2026-04-17 17:16:26 +08:00
commit fd3e95ac29
2 changed files with 29 additions and 111 deletions

View File

@ -1,42 +1,9 @@
# Remote Deployment Inventory
# Remote Runtime Notes
This directory stores AGENT-style operational documents for remote hosts and deployed projects.
这个目录记录远程主机运行事实,避免把主机级流水账继续堆回根文档。
## Purpose
约定:
Use this directory to keep host-level deployment facts in one place so they do not get lost across shell history, chat logs, or ad hoc notes.
Keep these documents focused on runtime reality:
- where a service actually runs
- which port is really exposed
- where the real data lives
- which repo is writable versus mirrored
- how to inspect, restart, back up, and upgrade
## File Layout
- `TEMPLATE.AGENT.md` — reusable template for a new remote host or VM
- `<host>.AGENT.md` — filled document for a specific host
## Naming Convention
Use the stable host name in the file name when possible.
Examples:
- `minione-ubuntu-infra-4c16g120g.AGENT.md`
- `prod-k8s-edge-01.AGENT.md`
- `staging-gpu-node-02.AGENT.md`
## Suggested Update Rules
Update the host document whenever one of these changes:
- deployment mode changes, for example Docker to systemd
- runtime ports or hostnames change
- a new database, cache, or volume is introduced
- Git remotes or mirror strategy changes
- backup location or restore procedure changes
- a real incident reveals a hidden dependency or operational trap
## Current Hosts
- `minione-ubuntu-infra-4c16g120g.AGENT.md`
- 一台主机一份 `*.AGENT.md`
- 只写运行事实、入口、路径、端口、依赖和排障命令
- 项目规则仍放在根 `AGENTS.md` / `CLAUDE.md`

View File

@ -1,112 +1,63 @@
# Remote Host AGENT — minione-ubuntu-infra-4c16g120g
## 1. Host Identity
## Host Identity
- Host name: `minione-ubuntu-infra`
- Host role: personal infra VM for `new-api` and `gitea`
- Primary access path: Tabby SSH profile `个人-minione-ubuntu-infra-4c16g120g`
- Tailscale IP: `100.64.0.11`
- LAN IP: `192.168.1.3`
- Access profile: `个人-minione-ubuntu-infra-4c16g120g`
## Runtime Topology
## 2. Runtime Topology
- `new-api` runs as a host `systemd` process
- `gitea` runs in Docker Compose under `/opt/gitea`
- PostgreSQL, Redis, Nginx run as shared Docker infrastructure
- PostgreSQL and Redis run as shared Docker infrastructure
- Shared Docker network: `infra-shared`
## 3. Shared Infrastructure
## Shared Infrastructure
### PostgreSQL
- Container: `infra-postgres`
- Container name: `infra-postgres`
- Host port: `127.0.0.1:5433`
- Docker alias: `infra-postgres:5432`
- Data path: `/srv/infra/postgres/data`
- Backup path: `/srv/infra/postgres/backup`
- Databases:
- `new-api`
- `gitea`
- Data path: `/srv/infra/postgres/data`
- Backup path: `/srv/infra/postgres/backup`
### Redis
- Container: `infra-redis`
- Container name: `infra-redis`
- Host port: `127.0.0.1:6379`
- Docker alias: `infra-redis:6379`
- Data path: `/srv/infra/redis/data`
### Nginx
- Container: `infra-nginx`
- Host ports:
- `80`
- `443`
## new-api
## 4. new-api
- Service name: `new-api`
- Deploy path: `/root/new-api-deploy`
- Runtime env: `/root/new-api-deploy/.env.runtime`
- Binary path: `/root/new-api-deploy/new-api`
- systemd unit: `/etc/systemd/system/new-api.service`
- Health check:
- `curl --noproxy '*' http://127.0.0.1:3000/api/status`
- Health check: `curl --noproxy '*' http://127.0.0.1:3000/api/status`
Host-process connection profile:
### Runtime Profile
- `SQL_DSN=postgresql://root:<password>@127.0.0.1:5433/new-api`
- `REDIS_CONN_STRING=redis://:<password>@127.0.0.1:6379/0`
### Source Build Toolchain
- `go version` -> currently `go1.25.1`
- `bun --version` -> currently `1.3.12`
- `node` / `npm` also exist, but frontend preferred tool is `bun`
## gitea
### Source Upgrade Command
- `/usr/local/bin/new-api-upgrade`
This script currently does:
1. `git fetch origin`
2. `git switch home`
3. `git reset --hard origin/home`
4. `bun install`
5. `bun run build`
6. `go build`
7. `systemctl restart new-api`
8. health check against `127.0.0.1:3000`
### Important Notes
- `web/dist` is required for a valid backend build because `main.go` embeds it
- `VERSION` may be empty in the current branch; the upgrade script falls back to Git commit hash
- deployment checkout is branch-based now; do not go back to the old detached worktree deployment unless you explicitly mean to
## 5. gitea
- Compose path: `/opt/gitea/docker-compose.yml`
- Config path: `/opt/gitea/data/gitea/conf/app.ini`
- Web: `http://100.64.0.11:3001/`
- SSH: `ssh -p 2222 git@100.64.0.11`
- Database host: `infra-postgres:5432`
- Data path: `/opt/gitea/data`
## 6. Git and Repository Strategy
- Writable repo:
- `admin/new-api-dev`
- Mirror repo:
- `admin/new-api`
- Remote deploy checkout:
- `/root/new-api-deploy`
- Deploy branch:
- `home`
## Routine Checks
## 7. Routine Operations
- Check app health:
- `systemctl is-active new-api`
- `journalctl -u new-api -n 200 --no-pager`
- `curl --noproxy '*' http://127.0.0.1:3000/api/status`
- Run source upgrade:
- `/usr/local/bin/new-api-upgrade`
- Check infra:
- `docker ps --format '{{.Names}} | {{.Image}} | {{.Ports}}'`
- `ss -lntp | egrep ':3000|:3001|:2222|:5433|:6379|:80|:443'`
- Check gitea:
- `cd /opt/gitea && docker compose ps`
- `docker logs --tail 200 gitea`
- `curl --noproxy '*' http://127.0.0.1:3001/`
## 8. Current Reality Traps
- Do not treat `new-api/docker-compose.yml` as production truth; production app runtime is `systemd`
- Do not assume PostgreSQL belongs only to `new-api`; `gitea` shares the same PostgreSQL instance
- Do not assume remote host has no source-build capability anymore; Go and Bun are now installed
- `systemctl status new-api`
- `journalctl -u new-api -n 200 --no-pager`
- `docker ps --format '{{.Names}} | {{.Image}} | {{.Ports}}'`
- `ss -lntp | egrep ':3000|:3001|:2222|:5433|:6379'`