Lucas Orth
2477365763
act_runner auf dem VPS, steuert den Docker-Daemon des Hosts ueber den Socket. Registrierung ueber die interne Adresse http://gitea:3000 im Netz gitea-ci - die oeffentliche Domain ist aus Containern heraus nicht erreichbar (NAT-Hairpin, host-gateway zusaetzlich von der Firewall geblockt). Bewusst nicht im Netz nginx-proxy-manager_default: der Runner spricht mit Gitea, nicht mit dem Proxy. .env und data/ bleiben aussen vor, beide enthalten Runner-Credentials. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
105 lines
2.6 KiB
Markdown
105 lines
2.6 KiB
Markdown
# gitea-runner
|
|
|
|
Der CI-Runner fuer Gitea Actions auf dem VPS. Baut und deployt die Apps,
|
|
sobald in einem Repo ein Tag `v*` gepusht wird.
|
|
|
|
Die Konventionen fuer die Apps selbst stehen nicht hier, sondern in
|
|
[deploy-kit](https://gitea.lucas-orth.de/lucas.orth/deploy-kit).
|
|
|
|
## Aufbau
|
|
|
|
```
|
|
Tag-Push -> Gitea -> gitea-runner -> Job-Container -> Docker-Daemon des Hosts
|
|
```
|
|
|
|
Der Runner steuert den Docker-Daemon ueber `/var/run/docker.sock`. Er baut
|
|
also nicht in sich selbst, sondern auf dem Host - deshalb laufen die
|
|
gebauten Container ganz normal neben ihm.
|
|
|
|
Zwei getrennte Netze:
|
|
|
|
| Netz | Wer haengt drin |
|
|
|---|---|
|
|
| `gitea-ci` | Gitea, Runner, Job-Container |
|
|
| `nginx-proxy-manager_default` | Proxy, alle App-Container |
|
|
|
|
Der Runner hat im Proxy-Netz nichts verloren - er spricht mit Gitea, nicht
|
|
mit dem Proxy.
|
|
|
|
## Einrichtung
|
|
|
|
### 1. Actions in Gitea aktivieren
|
|
|
|
In der `app.ini`:
|
|
|
|
```ini
|
|
[actions]
|
|
ENABLED = true
|
|
```
|
|
|
|
Ab Gitea 1.21 Default. Danach Gitea neu starten.
|
|
|
|
### 2. Netz anlegen und Gitea daran haengen
|
|
|
|
```bash
|
|
docker network create gitea-ci
|
|
```
|
|
|
|
In **Gitea's** `docker-compose.yml` ergaenzen - beim Service und im
|
|
`networks`-Block:
|
|
|
|
```yaml
|
|
services:
|
|
server:
|
|
networks:
|
|
- nginx-proxy-manager_default
|
|
- gitea-ci
|
|
|
|
networks:
|
|
nginx-proxy-manager_default:
|
|
external: true
|
|
gitea-ci:
|
|
external: true
|
|
```
|
|
|
|
Das ist der Teil, der es dauerhaft macht. `docker network connect` von Hand
|
|
waere beim naechsten Recreate von Gitea wieder weg.
|
|
|
|
Dann in Gitea's Verzeichnis `docker compose up -d` und pruefen:
|
|
|
|
```bash
|
|
docker inspect -f '{{range $n,$v := .NetworkSettings.Networks}}{{$n}} {{end}}' gitea
|
|
```
|
|
|
|
Beide Netze muessen erscheinen.
|
|
|
|
### 3. Runner registrieren
|
|
|
|
Token holen: Gitea -> Site Administration -> Actions -> Runner ->
|
|
"Create new Runner".
|
|
|
|
```bash
|
|
cp .env.example .env && nano .env
|
|
docker compose up -d
|
|
docker compose logs --tail 30 runner
|
|
```
|
|
|
|
`runner registered successfully` muss erscheinen, in Gitea steht der Runner
|
|
danach als **Idle**.
|
|
|
|
## Warum die interne Adresse
|
|
|
|
`GITEA_INSTANCE_URL` zeigt auf `http://gitea:3000`, nicht auf die
|
|
oeffentliche Domain. Gitea laeuft auf demselben Host: ein Container, der die
|
|
oeffentliche IP anspricht, bekommt keine Antwort zurueck (NAT-Hairpin). Der
|
|
Umweg ueber `host-gateway` scheitert zusaetzlich an der Firewall.
|
|
|
|
Aus demselben Grund setzen die Workflows in `actions/checkout` den Input
|
|
`github-server-url: http://gitea:3000` - sonst klont der Job-Container ueber
|
|
die oeffentliche Domain und laeuft in denselben Timeout.
|
|
|
|
## Nicht im Repo
|
|
|
|
`.env` (Registration-Token) und `data/` (enthaelt `.runner` mit dem
|
|
dauerhaften Runner-Token). Beides steht in `.gitignore`.
|