diff --git a/.gitea/gitea_compose_qnap_all_in_one.md b/.gitea/gitea_compose_qnap_all_in_one.md index 29eea0f..91ae662 100644 --- a/.gitea/gitea_compose_qnap_all_in_one.md +++ b/.gitea/gitea_compose_qnap_all_in_one.md @@ -86,6 +86,17 @@ services: restart: unless-stopped depends_on: - gitea + # WICHTIG: dns am act_runner-Container selbst setzen, NICHT nur in + # container.options (das wirkt nur auf Job-Sub-Container). act_runner + # clont `actions/checkout` etc. aus seinem eigenen Prozess heraus nach + # /data/workflows — dafür zählt seine eigene /etc/resolv.conf. Ohne + # diese Zeilen steht dort 127.0.0.11 (Dockers embedded DNS im + # gitea_gitea-Netz), was auf QNAP unzuverlässig forwarded ("server + # misbehaving") und jedes action-Clone killt. + dns: + - 8.8.8.8 + - 1.1.1.1 + dns_search: [] environment: - GITEA_INSTANCE_URL=http://gitea:3000 - GITEA_RUNNER_REGISTRATION_TOKEN=218iFl8s3a6uJxntyoobzu24pQJBGGVIWmdtJbXh @@ -235,37 +246,70 @@ Zusätzlich: QNAP **Storage & Snapshots** → Volume-Snapshots für `/share/Cont - Fehler `docker: command not found` → Job-Container hat kein Docker-CLI. Runner-Label muss ein Image verwenden, das `docker` mitbringt (z.B. `catthehacker/ubuntu:act-latest`). `node:*`-Images reichen nicht, weil dort nur Node installiert ist - Fehler `Get "https://github.com/..." ... dial tcp: lookup github.com on 127.0.0.11:53: server misbehaving` → Docker-interner DNS im `gitea_gitea`-Netz forwarded unzuverlässig. Fix: `container.options: "--dns 8.8.8.8 --dns 1.1.1.1"` in der Runner-Config setzen, damit Job-Container externen DNS direkt nutzen -**DNS-Timeouts / hängende `git clone` ohne Fehlermeldung:** +**DNS-Timeouts / `server misbehaving` beim `actions/checkout`-Clone — komplette Lösung:** -Symptom: Job steht minutenlang bei `cloning https://github.com/actions/checkout` bzw. `actions/setup-node` ohne weiteren Output; kein `server misbehaving`, kein Timeout. Gleichzeitig scheitern parallele Jobs im selben Run sporadisch sofort mit `lookup github.com on 127.0.0.11:53: server misbehaving`. +Symptom: Jobs scheitern mit -Ursachen (mehrere verketten sich): +```text +Get "https://github.com/actions/checkout/info/refs?service=git-upload-pack": +dial tcp: lookup github.com on 127.0.0.11:53: server misbehaving +``` -1. `127.0.0.11` ist Dockers embedded DNS-Resolver. Er forwarded an die Upstream-Resolver der Docker-Daemon-Config. Auf QNAP ist dieser Upstream häufig ein (langsamer/überlasteter) ISP-DNS oder fehlschlagender Provider-Resolver. -2. `--dns 8.8.8.8 --dns 1.1.1.1` in `container.options` injiziert die DNS-Server in `/etc/resolv.conf` **innerhalb** des Job-Containers — das behebt `server misbehaving`, aber nur wenn der Daemon die Option korrekt anwendet (`act_runner` ≥ 0.2.11). -3. Parallele Job-Starts erzeugen kurzzeitig 5–10 gleichzeitige DNS-Lookups → Upstream drosselt → hängende TCP-Connects ohne sauberes Fail. +oder hängen minutenlang bei `cloning https://github.com/actions/checkout`. -**Dauerhafter Fix:** +### Die Fallstricke (wichtig zum Verstehen, warum es ZWEI Fixes braucht) + +`act_runner` führt beim Start eines Jobs **zwei unabhängige** Clone-Operationen aus: + +1. **Im act_runner-Prozess selbst** (vor Job-Container-Start): clont Actions nach `/data/workflows/...`, benutzt seine eigene `/etc/resolv.conf`. +2. **Im Job-Sub-Container** (während Job-Run): benutzt seine eigene `/etc/resolv.conf`. + +**Beides** zeigt per Default auf `127.0.0.11` (Dockers embedded DNS im `gitea_gitea`-Netz), das wiederum an den QNAP-Host-Upstream forwarded. Dieser Upstream ist auf QNAP oft unzuverlässig → `server misbehaving`. + +Der `container.options: "--dns ..."`-Eintrag in der Runner-`config.yaml` betrifft **nur Fall 2** (Job-Sub-Container). Fall 1 (act_runner selbst) braucht einen separaten Fix am Compose-Service. + +### Copy-Paste-Lösung (beide Ebenen gleichzeitig) + +**1) Am `act_runner`-Service in der compose — setzt seine eigene `/etc/resolv.conf` auf Upstream-DNS** (in der obigen compose.yml schon eingebaut): + +```yaml +act_runner: + image: gitea/act_runner:latest + # ... restliche Config ... + dns: + - 8.8.8.8 + - 1.1.1.1 + dns_search: [] +``` + +**2) In der inline-generierten `/config.yaml` — setzt Upstream-DNS in jedem Job-Sub-Container** (ebenfalls schon eingebaut): ```yaml -# config.yaml des act_runner container: network: gitea_gitea options: "--dns 8.8.8.8 --dns 1.1.1.1 --dns-search ." # `--dns-search .` entfernt jede geerbte Search-Domain → keine verirrten NXDOMAIN-Retries ``` -**Alternative 1 — Host-Network:** +Nach dem Ändern: Stack neu deployen, damit der act_runner-Container mit der neuen DNS-Config startet. -```yaml -container: - network: host - # options: "" entfernen, --dns ist dann irrelevant +### Verifikation nach dem Deploy + +```bash +# 1. DNS aus Sicht des act_runner-Containers selbst — muss sofort eine IP liefern +docker exec gitea-act-runner sh -c 'cat /etc/resolv.conf && nslookup github.com' +# Erwartet: nameserver 8.8.8.8 / 1.1.1.1, nicht 127.0.0.11 +# Name: github.com, Address: 140.82.x.x + +# 2. DNS aus Sicht eines Job-Sub-Containers +docker run --rm --network gitea_gitea --dns 8.8.8.8 alpine:3 \ + sh -c 'apk add --no-cache bind-tools >/dev/null && dig +short github.com' +# Erwartet: sofortige IP-Antwort ``` -Nachteil: Jobs können auf Host-Ports zugreifen (Security-Impact bei Multi-Tenant). +Hängen oder `server misbehaving` → siehe Alternativen unten. -**Alternative 2 — Dockerd default-dns fixieren (macht auch andere Container robuster):** +### Alternative A — Docker-Daemon global fixen (robuster, wirkt auf ALLE Container) In `/etc/docker/daemon.json` auf dem QNAP: @@ -276,34 +320,51 @@ In `/etc/docker/daemon.json` auf dem QNAP: } ``` -Dann Docker-Daemon restart (Container Station → Advanced → Restart Docker). Wirkt auf alle Container, auch ohne `--dns`-Option pro Job. +Dann Docker-Daemon restart (Container Station → Advanced → Restart Docker). Macht die compose-seitigen `dns:`-Einträge überflüssig, hilft aber auch jedem anderen Container. -**Alternative 3 — Pre-warm der Action-Repos (umgeht den Clone):** +### Alternative B — Pre-warm der Action-Repos (umgeht den Clone komplett) `act_runner` cached bereits geklonte Action-Repos unter `/data/cache/actions`. Einmal manuell anstoßen: ```bash -docker exec -it act_runner sh -c ' +docker exec gitea-act-runner sh -c ' mkdir -p /data/cache/actions/github.com/actions && cd /data/cache/actions/github.com/actions && - git clone --depth 1 --branch v4 https://github.com/actions/checkout && - git clone --depth 1 --branch v4.0.4 https://github.com/actions/setup-node && - git clone --depth 1 --branch v4 https://github.com/actions/cache && - git clone --depth 1 --branch v4 https://github.com/actions/upload-artifact + for repo in checkout setup-node cache upload-artifact download-artifact; do + [ -d "$repo" ] || git clone --depth 1 "https://github.com/actions/$repo" + done ' ``` -Danach laufen Jobs ohne DNS-Dependency zu github.com durch (solange der Cache nicht gelöscht wird). +Danach laufen Jobs ohne DNS-Dependency zu github.com durch, solange der Cache nicht gelöscht wird. -**Debug-Check:** +### Alternative C — Host-Network für Job-Container -```bash -# DNS aus Job-Container-Sicht verifizieren -docker run --rm --network gitea_gitea --dns 8.8.8.8 alpine:3 \ - sh -c 'apk add --no-cache bind-tools && dig +short github.com' +```yaml +container: + network: host + # options ohne --dns ``` -Liefert das sofort eine IP, ist DNS OK. Hängt es → DNS-Upstream-Problem (Alternative 2 oder 3 nötig). +Nachteil: Jobs sehen Host-Ports (Security-Impact bei Multi-Tenant). Nur als Notnagel. + +### Parallele-Job-Drosselung + +Parallele Job-Starts erzeugen kurzzeitig 5–10 gleichzeitige DNS-Lookups; wenn dein Upstream-DNS drosselt, hängen Connects ohne sauberes Fail. Dann in der Runner-`config.yaml`: + +```yaml +runner: + capacity: 2 # statt 4 — reduziert parallele Starts +``` + +**Debug-Snippet — wer resolved gerade was:** + +```bash +# Alle Container mit ihrer resolv.conf-Config +for c in $(docker ps --format '{{.Names}}'); do + echo "=== $c ==="; docker exec "$c" cat /etc/resolv.conf 2>/dev/null +done +``` **`uses: actions/checkout@v4` schlägt fehl:**