CI/CD on Tom Meurs

Supply chain security in GitLab CI: SBOM, cosign en het beleid dat blokkeert

Tue, 29 Sep 2026 09:00:00 +0200

TL;DR Een pipeline die images scant en een SBOM schrijft, zonder dat iets daar bij toelating naar kijkt, stond een jaar op groen en hield niks tegen. Vier stappen hieronder: een SBOM die Trivy kan teruglezen, een cosign-handtekening op de digest met de sleutel in Vault, de SBOM eraan gehangen als attestation, en een Kyverno-policy die de rest weigert. Daarna een tabel van welke SLSA Build L3-eisen een zelfgehoste GitLab-runner haalt, en de twee die hij niet haalt.

Progressive delivery met Argo Rollouts: canary en blue-green deployments

Fri, 20 Jun 2025 10:00:00 +0200

Een standaard Kubernetes Deployment heeft me lang prima gediend. Push een nieuwe image tag, kijk hoe de pods rollen, klaar. Simpel, declaratief, en meestal ging er niks mis. De rolling update gaf me zelfs een warm gevoel van veiligheid: oude pods verdwijnen pas als de nieuwe ready zijn.

Dat gevoel is een leugen. Een rolling update beschermt je tegen pods die niet opstarten. Hij doet niks tegen pods die perfect opstarten en vervolgens kapotte responses serveren. De container is gezond, de readiness probe is groen, en je nieuwe code stuurt stilletjes 500’s naar elke gebruiker. Binnen seconden raakt 100% van je traffic code die niemand onder echte load heeft gevalideerd.

Semantic versioning automatiseren met GitLab CI

Tue, 27 May 2025 19:44:00 +0200

Stel je eerst de eindsituatie voor. Je merget een branch naar main, loopt weg om koffie te halen, en tegen de tijd dat je terug bent heeft het project een nieuwe versie-tag, een verse changelog-entry, en een GitLab release met notes die uit je commits zijn geschreven. Niemand besloot “is dit 1.4.0 of 1.3.5?” omdat niemand dat hoefde. Het versienummer rolde uit het werk zelf.

Daar wil ik in deze post naartoe. Ik draai een self-hosted GitLab en ik wil niet dat versioning iets is waar ik over nadenk. Een versienummer dat iemand met de hand kiest is een klein black box: het hangt ervan af of die persoon de regels onthield, oplette, en het met iedereen eens was over wat als een breaking change telt. Ik heb liever dat het nummer een consequentie van de commits is, iets dat ik kan inspecteren en reproduceren.

GitLab CI voor Kubernetes: van commit tot deployment

Thu, 15 May 2025 20:33:00 +0200

Lange tijd draaide mijn CI op de servers van iemand anders. Push code, wacht op een hosted runner, kijk hoe de minuten aftikken tegen een maandelijks quotum, hoop dat de provider de regels niet verandert volgend kwartaal. Het werkte, tot ik me begon af te vragen waar mijn broncode eigenlijk stond terwijl hij gebouwd werd, en wie er nog meer bij kon.

Dus haalde ik GitLab in huis. Ik draai hem nu self-hosted, op eigen hardware, naast de clusters waarnaar hij deployt. Dat is soevereiniteit toegepast op CI/CD: mijn code, mijn builds, mijn artifacts, geen vendor die prijzen kan veranderen, een feature kan deprecaten waar ik van afhankelijk ben, of mijn repositories kan lezen zonder dat ik het weet.