Hoe Structureer Je Je GitOps Repository voor AKS?

Dankzij GitOps krijg je heel wat controle, reproduceerbaarheid en automatisering over je AKS cluster… of toch in theorie. Helaas is de praktijk soms anders. Als je geen doordachte structuur hebt voor je Git repository(s), kan je stack al snel ontaarden in een warboel waar het overzicht ver te zoeken is.

Dus hoe voorkom je dat? Hoe deel je je repositories zo op dat je profiteert van de voordelen van GitOps, zonder je te verliezen in complexiteit of securityrisico’s? In deze blog leggen we je uit hoe je tot de juiste structuur komt. 

Waarom is een goede structuur cruciaal? 

Een GitOps repository zonder duidelijke structuur leidt al snel tot chaos. De kern van het probleem ligt bij verantwoordelijkheden en security: wie mag wat aanpassen? Zonder heldere afbakening riskeer je dat ontwikkelaars per ongeluk platforminstellingen wijzigen, of dat het platformteam een bottleneck wordt voor elke kleine update. Dit gebrek aan duidelijke scheiding verhoogt ook het risico op ongeautoriseerde wijzigingen in productie. 

Daarnaast heeft een slechte structuur een directe impact op de efficiëntie. Een onoverzichtelijke repo vertraagt de ontwikkelingssnelheid aanzienlijk, omdat het langer duurt voor teamleden om de structuur te analyseren. En naarmate het aantal applicaties, teams en omgevingen groeit, wordt dit enkel maar erger: de complexiteit neemt toe, merge conflicten worden schering en inslag, en het algemene overzicht raakt zoek.  

Resultaat: in plaats van een gestroomlijnd proces krijg je een bron van frustratie. Een goede repository structuur is dus geen luxe, maar het fundament dat je dwingt na te denken over ownership, workflows en security. 

Platform vs. applicatie 

Alle begin is moeilijk, maar een logisch startpunt voor je structuur is een onderscheid maken tussen de platformcomponenten en de applicatieconfiguraties.  

• Denk bij platformcomponenten aan de basis: ingress controllers, cert-manager, monitoring, secret management tools, … zaken die de hele cluster ondersteunen en vaak door een centraal platform team beheerd worden.  
• Applicatieconfiguraties zijn de specifieke deployments, services, etc. van je business applicaties, doorgaans beheerd door development of platform teams. 

Die splitsing is essentieel omdat de verantwoordelijkheden, frequentie van wijzigingen en de permissies sterk onderling verschillen. Het voorkomt dat teams elkaar in de weg zitten en vormt de basis voor de volgende keuze: ga je voor een mono-repo of multi-repo aanpak? 

Mono-repo vs. multi-repo 

Eens je een onderscheid hebt gemaakt tussen platform en applicatie(s), moet je dus beslissen hoe je ze gaat indelen in Git. Er zijn twee opties: mono-repo en multi-repo. 

Bij mono-repo staat alles (platform, applicaties, misschien zelfs omgevingen) in één grote Git repository. Makkelijker om mee te starten, maar het kan snel lastig worden om permissies goed te regelen en verantwoordelijkheden te scheiden naarmate je groeit. 

Bij multi-repo splits je de configuratie op over meerdere repositories, bijvoorbeeld een aparte repo voor het platform en aparte repo’s per applicatie of team. Dit zorgt voor duidelijkheid in verantwoordelijkheden en maakt permissies managen makkelijker, maar het introduceert wel meer overhead. Je zal meerdere repo’s moeten configureren in AKS, en de globale status van je cluster zal verspreid zitten waardoor platform teams het overzicht kunnen kwijtraken. 

Je vraagt je misschien af waar wij bij CloudFuel meestal voor kiezen, maar dat hangt natuurlijk af van de klant. We gaan altijd in dialoog en wegen samen de voor- en nadelen af om een pragmatische aanpak te vinden die voor hen werkt. 

Praktische tips voor het indelen van je repository 

Of je nu voor mono of multi kiest, de interne structuur van je repo(s) is essentieel.  Hieronder geven we alvast enkele praktische tips om je op weg te helpen. 

Zorg voor een consistente mappenstructuur 

Elk project is anders, maar populaire opties zijn om de mappen te organiseren per cluster (bv. clusters/dev, clusters/prod) of per applicatie (apps/app-a, apps/app-b). Binnen die hoofdstructuur kan je dan verder gaan verfijnen, afhankelijk van de tooling die je gebruikt. 

Het belangrijkste is dat je een duidelijke, voorspelbare structuur kiest en die consequent toepast. Dit helpt enorm bij het navigeren, het begrijpen van de configuratie en het opzetten van automatisering. 

Centraliseer de code binnen je repository 

Een veelgemaakte fout is een aparte Git branch maken per omgeving. Maar code tussen omgevingen promoveren kan al snel complex worden, wat het moeilijk maakt om de omgevingen te onderhouden. Daarom raden we doorgaans aan om omgevingsverschillen via de directory-structuur binnen één main branch te beheren. 

Zoals altijd zijn er wel uitzonderingen. GitHub laat bijvoorbeeld permissies op folderniveau toe, wat goed past bij een mono-repo, maar bij Azure DevOps is dit minder evident. Daar kan een branch per omgeving soms wél een goede oplossing zijn, bijvoorbeeld als de workflows voor test en productie sterk verschillen. Hoewel je workflows binnen één branch kunt variëren (bv. lichtere checks voor dev), is dit niet altijd de eenvoudigste weg. Weeg dus de voor- en nadelen af binnen jouw context. 

Vergeet je secrets niet… of skip ze volledig! 

Een laatste, maar cruciaal punt blijft het beheer van secrets. Zoals we in onze blog over secure secret management al benadrukten, wil je in principe altijd zo min mogelijk langlevende secrets gebruiken. Entra Workload ID biedt een uitstekend, secretless alternatief, maar in de praktijk ontkom je nu eenmaal niet altijd aan secrets.  

Gebruik in die gevallen specifieke tools en patronen zoals External Secrets Operator (ESO), Sealed Secrets, of Mozilla SOPS. Zorg ervoor dat alleen de verwijzing (zoals bij ESO) of de versleutelde vorm (Sealed Secrets, SOPS) in je Git repository terechtkomt, nooit het plain text secret zelf.  

Hoe zit het met automatisering? 

Om je Git configuratie ook effectief op je cluster te krijgen, gebruik je een GitOps agent. Bij CloudFuel werken we graag met ArgoCD. Een krachtige feature hiervan zijn Application Sets. Hiermee kun je ArgoCD automatisch nieuwe applicaties of omgevingen laten detecteren en deployen op basis van de mappenstructuur in je Git repo. 

Je definieert bijvoorbeeld een Application Set die zegt: “Kijk in de map apps/ en voor elke submap die je daar vindt, deploy de Kustomize-configuratie uit overlays/production naar de productiecluster.” Voeg je een nieuwe app toe volgens die structuur? Dan pikt ArgoCD die automatisch op. Dit zorgt voor heel wat minder manueel werk, meer consistentie, en schaalt makkelijk.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: appset
namespace: argocd
spec:
goTemplate: true
goTemplateOptions:
- missingkey=error
generators:
- git:
repoURL: <ARGOCD_GITOPSURL_PLACEHOLDER>
revision: HEAD
directories:
- path: apps/*/overlays/dev
template:
metadata:
name: '{{index .path.segments 1}}'
spec:
source:
repoURL: <ARGOCD_GITOPSURL_PLACEHOLDER>
targetRevision: HEAD
path: '{{.path.path}}'
destination:
server: 'https://kubernetes.default.svc'
namespace: '{{index .path.segments 1}}' 

Structuur brengt rust! 

GitOps is heel krachtig, maar de effectiviteit staat of valt met een heldere en consistente repository-structuur. Zonder structuur loop je vast in complexiteit, onduidelijkheid en risico’s. Denk dus goed na over hoe je verantwoordelijkheden scheidt, hoe je omgevingen beheert, welke tooling je inzet, en hoe je automatiseert. 

De belangrijkste boodschap? Consistency is key. Neem de tijd om vooraf een structuur te ontwerpen die past bij jouw organisatie of klant en wees consequent in de toepassing ervan. Dat is de basis voor een schaalbaar, veilig en efficiënt GitOps-proces.

Heb je hulp nodig bij het ontwerpen of implementeren van een GitOps-structuur voor jouw AKS-omgeving? Stuur ons een berichtje, we denken graag met je mee.