Containers

“Dus wat is het verschil tussen een container en een virtual machine?” Ik krijg deze vraag vaak, meestal van iemand die slim genoeg is om in vergaderingen mee te knikken zonder toe te willen geven dat het vaag is. En het eerlijke antwoord is dat de meeste uitleg het erger maakt. Die gooit in de eerste zin al “hypervisor,” “kernel sharing,” en “hardware abstractie” op tafel, en nu heeft die persoon vier nieuwe termen om over in de war te zijn in plaats van één. ...

Een base image pullen, je code erin kopiëren, naar productie pushen. Die lus draaien de meesten van ons op de automatische piloot. Het stuk waar niemand naar kijkt is de base image zelf, die stilletjes een paar honderd packages meesleept die je nooit gekozen hebt. Eén ervan kan een bekende CVE dragen, en je zou er geen flauw idee van hebben. Dat zit me dwars. Ik draai niet graag dingen die ik niet kan inspecteren, en een container image die je niet gescand hebt is precies dat: een black box die je vertrouwt omdat naar binnen kijken te veel moeite leek. ...

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. ...