meldestelle/docs/99_Journal/2026-03-06_Session_Log_Pipeline_502_Fix.md

type	status	owner	date	last_update
Journal	ACTIVE	DevOps	2026-03-06	2026-03-06

Session Log — Pipeline 502 Bad Gateway Fix

Problem

Der Gitea-Runner (VM 102, 10.0.0.23) brach beim Docker-Push mit 502 Bad Gateway ab:

ERROR: failed to push git.mo-code.at/.../ping-service:latest:
  failed to authorize: failed to fetch oauth token:
  unexpected status from POST request to https://git.mo-code.at/v2/token: 502 Bad Gateway

Der Build lief durch (alle Layers gebaut), aber der Push schlug nach ~70 Sekunden fehl.

Root Cause

Der Runner routete den Registry-Push über Pangolin (CT 100, 10.0.0.21) → git.mo-code.at → Gitea (CT 101, 10.0.0.22). Bei großen Image-Layern (70+ Sekunden Upload) brach Pangolin die Verbindung ab und antwortete mit 502 — sowohl beim Blob-Upload (PUT) als auch beim abschließenden OAuth-Token-Fetch für den Manifest-Push.

Zusätzlich: docker/build-push-action generiert standardmäßig Attestation-Manifests (SLSA Provenance + SBOM), die weitere Token-Requests auslösen — jeder davon ein zusätzliches 502-Risiko bei Pangolin.

Änderungen

.gitea/workflows/docker-publish.yaml

1. Pangolin-Bypass via /etc/hosts

- name: Registry intern auflösen (Pangolin-Bypass)
  run: echo "10.0.0.22 git.mo-code.at" | sudo tee -a /etc/hosts

Bewirkt: Der Runner löst git.mo-code.at direkt auf 10.0.0.22 (Gitea intern) auf. Push läuft nun intern 10.0.0.23 → 10.0.0.22, kein Pangolin-Timeout mehr möglich. Image-Tags bleiben git.mo-code.at/... — für externe Pulls weiterhin korrekt.

2. Attestation-Manifeste deaktiviert

provenance: false
sbom: false

Bewirkt: Keine zusätzlichen Manifest-Pushes, kein extra Token-Request am Ende des Builds.

Netz-Topologie (zur Referenz)

Runner (VM 102, 10.0.0.23)
  ↓ /etc/hosts: git.mo-code.at → 10.0.0.22
Gitea (CT 101, 10.0.0.22:3000)   ← direkter Push, kein Pangolin
  ↑
Pangolin (CT 100, 10.0.0.21)     ← nur noch für externe Nutzer
  ↑
git.mo-code.at (Internet)

Gelernt

• Pangolin-Tunnel ist für kurze REST-Calls geeignet, nicht für große Binär-Uploads (Docker Layers)
• Self-hosted Runner sollten Registry-Endpunkte immer intern auflösen
• provenance: false + sbom: false ist Best Practice für private/interne Registries