De webhook die zich verstopte achter NetBird

Vorige week verhuisde de mail naar de meterkast. Deze week deze site. De code-kant was triviaal — Astro genereert HTML, nginx serveert HTML, klaar. De devops-kant kostte drie avonden.

De deploy die niets deed

Eerste run leek goed. git push naar GitLab, GitLab firet de webhook naar Komodo op meterkast, Komodo doet DeployStack. Status: success. Site live.

Een commit later: status nog steeds success. Site nog steeds op de vorige versie.

Komodo’s DeployStack doet standaard docker compose up -d. Geen --build. Voor een stack met build: . betekent dat: git pull wel, image niet. Container blijft draaien op het beeld van twee dagen terug en niemand klaagt. Fix was één API-call: extra_args = ["--build"] op de stack. Maar je moet eerst weten dat het probleem bestaat.

De webhook die er niet was

Dag twee: een nieuwe commit pushen, niets gebeurt. Helemaal niets. Geen Komodo-update, geen container-restart.

Wat ik dacht: token mismatch. Wat het werd: GitLab probeerde de webhook wel te firen, maar de URL wees naar 100.85.254.53 — een NetBird mesh-IP dat ik twee weken eerder had vervangen tijdens een DNS-overhaul. Dat is niet een fout die zichzelf laat zien: recent_failures op de hook bleef 0, omdat GitLab netjes een HTTP-response kreeg (van een totaal andere service die toevallig op dat IP draaide) en dat als success interpreteert.

De enige manier om de echte response te zien: TestHooks::ProjectService in gitlab-rails. Daar stond het er voluit. No gitlab token in headers. 401.

De ene IP-laag dieper

Mesh-IPs hardcoderen in een webhook is per definitie een verlopen-datum. NetBird kan opnieuw geïnstalleerd worden, de IP kan wijzigen, en niets in mijn setup signaleert dat. De juiste laag is niet het mesh — het is Docker.

host.docker.internal:host-gateway toegevoegd aan de GitLab-container via de Komodo gitlab-stack zijn extra_hosts. Vanuit de container resolved dat naar het host-gateway-IP, en dat IP raakt nooit aan NetBird. Webhook-URL omgezet naar http://host.docker.internal:9120/listener/gitlab/stack/pr-website/deploy. Token opnieuw gezet uit /opt/komodo-meterkast/.env. Test: 200.

Drie commits later kreeg ik door dat hook.update! in gitlab-rails stilletjes velden leegt die je niet meegeeft. Een tweede update met alleen een nieuwe URL had de token weer leeggemaakt. Niet documented, gewoon ActiveRecord-gedrag dat me kostte.

Wat ik eraan overhoud

Een paar dingen die ik nu echt geloof:

Een succesvolle status zegt niets. Komodo zei success, GitLab zei success, en de site stond drie dagen stil. Pas een end-to-end test — push, wacht, refresh — bewijst iets.

Je homelab is je beste docent als hij ook je productie is. Een testomgeving die je kunt slopen leert je niets nieuws. Een meterkast waar je eigen site op draait dwingt je om de webhook écht te begrijpen.

En: het feit dat ik dit allemaal kan oplossen zonder ergens een ticket aan te maken — alleen ik, een SSH-verbinding en de logs — is precies waarom de hele migratie van Gmail naar de meterkast de moeite waard was.

← Alle schrijfsels