GitOps met Argo CD: elke wijziging in je cluster staat eerst in Git

De eerste beslissing is waar de Kubernetes-configuratie staat. Wij houden die bijna altijd in een aparte deploy-repository, los van de applicatiecode. De Magento- of Laravel-repository bouwt een image. De deploy-repository beschrijft welk image waar draait, met welke values en welke resources.

Een aparte repository geeft je een schone geschiedenis van alleen deploys, en je kunt er strengere review-regels op zetten. Wie code mag mergen, bepaalt niet automatisch wat er op productie draait.

Binnen de deploy-repository staan een map met de gedeelde Helm-chart of Kustomize-base, een map per omgeving met values of overlays, en een map met de Argo CD-objecten: AppProjects, Applications en ApplicationSets. Die worden zelf ook door Argo CD beheerd, via het app-of-apps-patroon.

Het image in elke omgeving staat vast op een unieke tag of digest, gekoppeld aan een commit. Nooit latest. Een tag die stilletjes naar een ander image wijst, maakt GitOps zinloos.

Een deploy is meer dan nieuwe pods starten. Bij Magento moet bin/magento setup:upgrade draaien als er nieuwe modules of schemawijzigingen zijn. Bij Laravel moet php artisan migrate --force draaien voordat de nieuwe code de nieuwe kolommen verwacht. De volgorde doet ertoe, en Argo CD geeft je daar twee instrumenten voor: hooks en sync waves.

Hooks bepalen in welke fase een resource wordt toegepast. Met de annotatie argocd.argoproj.io/hook: PreSync draait een Job vóór de rest van de sync. PostSync draait nadat alle resources gezond zijn, bijvoorbeeld voor een cache-warmup of een smoke test. SyncFail draait als de sync mislukt, bijvoorbeeld om een melding te sturen of maintenance mode weer uit te zetten. Met argocd.argoproj.io/hook-delete-policy: BeforeHookCreation ruimt Argo CD de vorige Job op voordat de nieuwe start, zodat je niet tegen een bestaande Job met dezelfde naam aanloopt.

Sync waves bepalen de volgorde binnen een fase. De annotatie argocd.argoproj.io/sync-wave krijgt een getal; lagere waves gaan eerst, en de standaard is 0. Argo CD wacht tot alle resources in een wave gezond zijn voordat de volgende begint. Zo zet je ConfigMaps en ExternalSecrets in wave -1, de migratie-Job als PreSync-hook, de web-Deployment in wave 0 en de queue-workers in wave 1. Workers starten dan pas als de webpods met de nieuwe code gezond zijn.

Bij Magento is er een extra vraag: wat doen de oude pods terwijl setup:upgrade loopt? Die draaien nog oude code tegen een database die op dat moment verandert. Voor kleine releases zonder schemawijziging is dat geen probleem, en kun je de upgrade overslaan als bin/magento setup:db:status meldt dat alles actueel is. Voor releases met schemawijzigingen kiezen we per release: een kort onderhoudsvenster met maintenance mode via een PreSync- en PostSync-hook, of wijzigingen in twee stappen uitrollen zodat oude en nieuwe code allebei met het schema overweg kunnen. Dat laatste is meer werk, maar de shop blijft open.

Bij Laravel ligt het eenvoudiger, mits migraties backward compatible zijn. Een kolom toevoegen kan in dezelfde release. Een kolom hernoemen of verwijderen splitsen we over twee releases. De uitwerking met complete YAML staat in ons artikel over Argo CD sync waves voor migraties.

Argo CD heeft een rollback-functie die een Application terugzet naar een eerdere sync. Die werkt alleen als automated sync uit staat, anders zou Argo CD direct weer naar de laatste commit syncen. Daarom is in een volwassen GitOps-opzet de rollback een Git revert. De revert staat in de historie, met een naam en een reden.

Een rollback van code is niet automatisch een rollback van de database. Heeft de PreSync-hook een migratie uitgevoerd, dan draait de oude code daarna tegen het nieuwe schema. Bij Laravel werkt dat als migraties additief zijn. Bij Magento is terugrollen na een setup:upgrade met schemawijzigingen niet altijd veilig, omdat Magento de moduleversies in de database vergelijkt met de code. Daarom maken we voor zulke releases een databasesnapshot bij de provider als eerste PreSync-stap, en leggen we per release vast of een code-rollback zonder database-restore kan.

Voor echte risicoreductie werkt een rollback na het feit minder goed dan een release die zichzelf afbreekt. Daar komt Argo Rollouts in beeld.

In de standaardopzet past de CI-pipeline na een geslaagde build de imagetag aan in de deploy-repository. Argo CD Image Updater draait het om: een controller in het cluster kijkt in de registry naar nieuwe tags en werkt de Application bij. Sinds versie 1.0 configureer je dat met een ImageUpdater custom resource in plaats van annotaties op de Application.

Je kiest per image een strategie, zoals semver binnen een bereik of de nieuwste build, en een write-back-methode. Met write-back naar Git maakt de Image Updater zelf een commit, zodat Git de bron van waarheid blijft. Met de methode die alleen een parameter-override in Argo CD zet, is dat niet zo, en dat vinden we voor productie te zwak.

Wij zetten het in voor test- en preview-omgevingen. Productie promoveren we bewust met een pull request, zodat in Git ook staat wie het heeft goedgekeurd.

Argo CD is een extra component die je moet upgraden, monitoren en beveiligen. Het heeft een eigen Redis, een repo-server die charts rendert, een applicatie-controller en een API-server met UI. Voor één Laravel-app op één cluster met één omgeving is een nette pipeline met helm upgrade --install en een goed afgeschermd service account vaak genoeg.

Argo CD loont zodra er meer dan één van iets is: meerdere omgevingen, meerdere shops, meerdere clusters of meerdere teams. Of als je moet kunnen aantonen wat er wanneer is uitgerold, bijvoorbeeld voor een audit. En draait je shop gewoon goed op managed hosting zoals Hypernode, dan heb je geen Kubernetes nodig en dus ook geen Argo CD. Ook dat zeggen we.