Wat is GitOps? Een eenvoudige gids voor het automatiseren van infrastructuurbeheer

Je hebt vast wel eens gehoord van DevOps (Developer Operations), dat het uitrollen van applicaties automatiseert. Als je data professional bent, ken je waarschijnlijk MLOps (Machine Learning Operations), dat het uitrollen van modellen stroomlijnt. Maar hoe zit het met GitOps?

In deze blog verkennen we GitOps, waarom het belangrijk is, de verschillende GitOps‑modellen en tot slot hoe je GitOps integreert in een project met een large language model. 

Afbeelding door de auteur

Je kunt de theorie achter DevOps‑ en MLOps‑concepten ook leren met twee van onze beste short courses, DevOps Concepts en MLOps Concepts.

Wat is GitOps?

GitOps is een operationeel framework dat DevOps‑principes uitbreidt naar infrastructuurautomatisering. Het legt de nadruk op belangrijke lessen uit DevOps, zoals versiebeheer, samenwerking, compliance, CI/CD en observability, en past die toe op het inrichten en beheren van infrastructuur, vooral in moderne cloudomgevingen.

In de kern automatiseert GitOps het beheer van infrastructuur door configuraties als code te behandelen, vaak aangeduid als Infrastructure as Code (IaC). Net zoals developmentteams broncode gebruiken om applicatiebinaries consistent te bouwen, gebruiken operationsteams configuratiebestanden die zijn opgeslagen in Git‑repositories om ervoor te zorgen dat elke keer dezelfde infrastructuuromgeving wordt uitgerold. Deze aanpak garandeert consistentie, betrouwbaarheid en herhaalbaarheid.

Belangrijke onderdelen van een GitOps‑workflow:

1. Git‑repository: Slaat zowel de broncode van de applicatie als de infrastructuurconfiguratiebestanden op.
2. Continuous delivery (CD)‑pijplijn: Automatiseert het bouwen, testen en uitrollen van de applicatie en infrastructuurwijzigingen.
3. Tool voor applicatie‑deployments: Zorgt ervoor dat applicaties correct en efficiënt worden uitgerold op basis van configuraties in de Git‑repository.
4. Monitoringsysteem: Volgt de prestaties en gezondheid van applicaties om de betrouwbaarheid van het systeem te behouden.

GitOps vs DevOps vs MLOps

Waarom GitOps gebruiken?

Infrastructuurbeheer was traditioneel handmatig, maar moderne cloud vraagt om automatisering om de snelheid en schaal van cloud‑native applicaties aan te kunnen. Met GitOps wordt infrastructuur elastisch en betrouwbaar, waardoor teams snel en consistent wijzigingen kunnen uitrollen. Het elimineert handmatige fouten, verbetert de efficiëntie en zorgt ervoor dat infrastructuur en applicaties altijd in sync zijn, ter ondersteuning van de snelle workflows van moderne ontwikkeling.

Belangrijkste voordelen van GitOps:

1. Versiebeheer: Alle wijzigingen aan infrastructuur en applicaties staan onder versiebeheer in Git, wat eenvoudige rollbacks en volledige audittrails mogelijk maakt.
2. Betere samenwerking: Teams kunnen effectiever samenwerken met vertrouwde Git‑workflows, zoals pull requests.
3. Hogere betrouwbaarheid: Declaratieve configuraties zorgen ervoor dat de gewenste systeemstatus bij een storing automatisch kan worden hersteld.
4. Automatisering: Minimaliseert de noodzaak van handmatige ingrepen en verkleint zo het risico op menselijke fouten.
5. Beveiliging: De commitgeschiedenis van Git biedt een onveranderlijk logboek, wat de beveiliging en traceerbaarheid vergroot.

Pull‑based vs push‑based GitOps‑model

Binnen GitOps zijn er twee primaire modellen voor het uitrollen en beheren van infrastructuur‑ en applicatieconfiguraties: pull‑based en push‑based. Deze modellen verschillen in hoe ze configuratiewijzigingen afhandelen en toepassen op de doelomgeving.

Pull‑based model (typische GitOps)

De pull‑based aanpak berust op het opslaan van de gewenste systeemstatus in een Git‑repository. Een GitOps‑operator, zoals Flux of Argo CD, bewaakt de repository continu op wijzigingen. Wanneer updates worden gedetecteerd, haalt de operator automatisch de bijgewerkte configuratie op en past die toe op de doelomgeving. 

Het pull‑based model biedt ook driftdetectie en self‑healing, omdat het cluster continu de gewenste status uit Git blijft “pullen”. Hierdoor worden onbedoelde wijzigingen of configuratiedrift in de omgeving automatisch gecorrigeerd, wat consistentie en stabiliteit waarborgt

Push‑based model (met CI/CD‑tools)

De push‑based aanpak maakt gebruik van tools zoals GitHub Actions of andere CI/CD‑services om updates naar het cluster te pushen zodra er wijzigingen worden gecommit. In tegenstelling tot het pull‑based model ontbreekt hier continue reconciliatie, wat betekent dat er geen ingebouwde driftdetectie of automatische rollback is. Dit maakt het minder veerkrachtig tegen onbedoelde wijzigingen in de omgeving. Wel is de push‑based aanpak vaak eenvoudiger te implementeren en biedt hij fijnmazige controle over deployments.

GitOps integreren in het LLM‑project 

We richten ons op een push‑based GitOps‑aanpak met GitHub Actions, omdat dit eenvoudiger op te zetten is en weinig voorkennis vereist. Hoewel een push‑based systeem niet alle voordelen van een pull‑based aanpak biedt, levert het wel essentiële GitOps‑eigenschappen zoals configuraties onder versiebeheer, geautomatiseerde deployments en vereenvoudigde rollbacks.

In deze sectie passen we GitOps‑principes toe op het project uit de tutorial How to Deploy LLM Applications Using Docker: A Step-by-Step Guide. Dit project bevat de code voor een Gradio‑applicatie, Dockerfile en requirements.txt. Het laat zien hoe je een AI‑applicatie met Docker naar de cloud uitrolt.

Bron: How to Deploy LLM Applications Using Docker: A Step-by-Step Guide

Neem een MLOps‑mindset aan om je machine‑learningmodellen effectief te trainen, documenteren, onderhouden en opschalen door je in te schrijven voor de cursus Developing Machine Learning Models for Production with an MLOps Mindset.

Projectstructuur

Dit GitOps‑project is ontworpen om LLM‑applicaties uit te rollen met Docker, Kubernetes en GitHub Actions. Het project organiseert alle LLM‑projectbestanden in de map app, maakt een map infra voor Kubernetes‑configuraties en gebruikt .github/workflows/ voor CI/CD‑automatisering met GitHub Actions.

• Docker zorgt ervoor dat de app consistent draait in verschillende omgevingen door deze met alle afhankelijkheden te verpakken.
• Kubernetes automatiseert de uitrol, het schalen en het beheer van de app.
• GitHub Actions automatiseert het testen, bouwen en uitrollen van de app.

Volg de cursus Introduction to Kubernetes en leer de basis van Kubernetes, en hoe je containers uitrolt en orkestreert met Manifests en kubectl‑instructies.

Deze structuur zorgt voor geautomatiseerde, schaalbare en omgevingsspecifieke deployments voor je LLM‑applicatie, volgens moderne GitOps‑principes.

Deploying-LLM-Applications-with-Docker/
├── app/
│   ├── requirements.txt      <-- Python dependencies for your LLM app
│   ├── main.py               <-- Your LLM application code
│   └── Dockerfile            <-- Docker instructions for building the app
├── infra/
│   ├── dev/                  <-- Dev environment configs (YAML or Helm)
│   ├── staging/              <-- Staging environment configs
│   └── production/           <-- Production environment configs
└── .github/
    └── workflows/
        ├── ci.yaml           <-- GitHub Actions workflow for continuous integration
        └── cd.yaml           <-- GitHub Actions workflow for continuous deploymentMogelijk gemaakt door

Hier is een eenvoudige toelichting:

• app/: Bevat de applicatiecode (main.py), afhankelijkheden (requirements.txt) en een Dockerfile om de app tot een container te bouwen.
• infra/: Bevat Kubernetes‑configuraties voor verschillende omgevingen:
• mappen dev/, staging/ en production/ voor omgevingsspecifieke instellingen.
• .github/workflows/: Automatiseert CI/CD met GitHub Actions:
• ci.yaml: bouwt de app en Docker‑image.
• cd.yaml: rolt de app uit door Docker‑images te pushen en Kubernetes‑configuraties toe te passen.

Leer het verschil tussen Kubernetes en Docker in de tutorial Kubernetes vs Docker.

Overzicht van de GitHub Actions‑workflow

Dit is wat er gebeurt in de GitHub Actions‑workflow:

Developer commits code + config to GitHub
               |
               v
      GitHub Actions CI (ci.yaml)
       - Builds Docker image
       - (Optional) pushes Docker image
               |
               v
     GitHub Actions CD (cd.yaml)
       - Deploys updated app/config
       - kubectl apply or helm upgrade
               |
               v
      Kubernetes Cluster UpdatedMogelijk gemaakt door

1. Developer commit wijzigingen: Code‑ en configuratie‑updates worden naar GitHub gepusht.
2. CI‑pijplijn (ci.yaml):
• Bouwt de Docker‑image.
• Pusht optioneel de image naar de containerregistry.
• Voert tests uit om de applicatie te valideren.
3. CD‑pijplijn (cd.yaml):
• Rol de bijgewerkte app of configuratie uit.
• Voert kubectl apply of helm upgrade uit om Kubernetes‑manifests te updaten.
4. Kubernetes‑cluster bijgewerkt: Het cluster draait de nieuwe versie van de applicatie.

Leer hoe je modeltraining, evaluatie, versiebeheer en deployment automatiseert met GitHub Actions en maak een bestand aan met de tutorial A Beginner's Guide to CI/CD for Machine Learning.

Belangrijkste voordelen en afwegingen van een push‑based GitOps‑aanpak

Als je al ervaring hebt met GitHub Actions, kan het opzetten van een GitOps‑methodologie met een push‑based aanpak vrij eenvoudig zijn. Je hoeft alleen de infrastructuurconfiguratiebestanden toe te voegen, CI/CD‑pijplijnen in te richten en je kunt aan de slag. Toch zijn er bij deze eenvoudige aanpak enkele belangrijke afwegingen.

Voordelen

• Eenvoudig: Je hebt alleen GitHub Actions nodig om deze aanpak te implementeren—er is geen extra GitOps‑operator zoals Argo CD of Flux nodig.
• Alles‑in‑één: GitHub Actions biedt één platform om je applicatie te bouwen, testen en uit te rollen, wat het hele proces stroomlijnt.

Afwegingen

• Geen echte pull‑based: In tegenstelling tot pull‑based GitOps‑tools zoals Argo CD, ontbreekt bij deze aanpak “continuous reconciliation”. Dat betekent dat de clusterstatus niet automatisch wordt bewaakt en verzoend met de gewenste status in Git.
• Geen driftdetectie: Als iemand resources in het cluster handmatig wijzigt, worden deze wijzigingen niet automatisch teruggedraaid om te voldoen aan de Git‑repository. Dit kan na verloop van tijd tot configuratiedrift leiden.
• Beveiliging: Om GitHub Actions naar je cluster te laten deployen, moet je clustercredentials opslaan in GitHub‑geheimen of een OIDC‑gebaseerde authenticatiemethode gebruiken. Beide vereisen zorgvuldige omgang om beveiligingsrisico’s te vermijden.

Overstappen naar een pull‑based model

Naarmate je project groeit of je eisen zwaarder worden, kan overstappen naar een pull‑based GitOps‑model aanzienlijke voordelen bieden. Als je team functies nodig heeft zoals self‑healing, continuous reconciliation of een visueel dashboard, is een pull‑based tool zoals Argo CD of Flux de logische volgende stap.

• Self‑healing: Zet clusterstatussen automatisch terug bij drift.
• Continuous reconciliation: Houd je Git‑repo 24/7 in de gaten voor configuratiewijzigingen.
• Visueel dashboard: Om app‑statussen en logs te bekijken.

Je kunt overstappen op een pull‑based tool zoals Argo CD of Flux. Zij monitoren je repository voortdurend en zorgen ervoor dat het cluster altijd overeenkomt met wat in Git staat—geen handmatige “push”‑stappen meer nodig na de initiële commit.

Conclusie

Om GitOps effectief te implementeren, begin je het best klein en adopteer je de technologieën stapsgewijs. Start met een eenvoudige Dockerfile om je applicatie te containeriseren en naar de cloud uit te rollen. Introduceer daarna Kubernetes voor schaalbaarheid en betrouwbaarheid via geautomatiseerde uitrol en beheer. 

Als je daar vertrouwd mee bent, neem dan een push‑based GitOps‑aanpak met tools zoals GitHub Actions om zowel cloudinfrastructuur als applicatie‑deployment te automatiseren. Stap ten slotte, wanneer je project volwassen wordt en productie‑stabiliteit vereist, over op een pull‑based model met tools zoals Argo CD of Flux voor continuous reconciliation, driftdetectie en self‑healing. 

Deze stapsgewijze aanpak zorgt voor een geleidelijke leercurve, terwijl je GitOps optimaal inzet voor moderne cloud‑native applicaties.

In deze blog hebben we GitOps, het belang ervan, de verschillende GitOps‑modellen en hoe je GitOps integreert in een AI‑project verkend. Als je nieuw bent in AI, raden we je sterk aan om de skill track AI Fundamentals te volgen, die AI‑basisprincipes behandelt, ingaat op modellen zoals GPT‑4o en de geheimen van generatieve AI onthult om door het veranderende AI‑landschap te navigeren.