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>
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.
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:
[actions]
ENABLED = true
Ab Gitea 1.21 Default. Danach Gitea neu starten.
2. Netz anlegen und Gitea daran haengen
docker network create gitea-ci
In Gitea's docker-compose.yml ergaenzen - beim Service und im
networks-Block:
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:
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".
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.