Close

Is GitOps het volgende grote succes voor DevOps?

Veel organisaties zien DevOps nu als onderdeel van hun strategie voor digitale transformatie, omdat het een cultuur van gedeelde verantwoordelijkheid, transparantie en snellere feedback bevordert. Maar naarmate de kloof tussen ontwikkelings- en operationele teams kleiner wordt, neemt ook het aantal processen af.

Zo gaat het dus ook met Git, 's werelds meest gebruikte versiebeheersysteem op dit moment. Nu bedrijven DevOps-methodologieën omarmen, geldt dat ook voor de tools, wat een evolutie heeft teweeggebracht voor GitOps, een reeks werkwijzen die ontwikkelaars in staat stellen meer taken uit te voeren die verband houden met IT-handelingen.


Wat is GitOps?


In wezen bestaat GitOps uit op code gebaseerde infrastructuur en operationele procedures die afhankelijk zijn van Git als bronbeheersysteem. Het is een evolutie van Infrastructure as Code (IaC) en een best practice voor DevOps waarbij Git wordt gebruikt als enige bron van waarheid en controlemechanisme voor het aanmaken, bijwerken en verwijderen van een systeemarchitectuur. Eenvoudiger gezegd, het is gebruikelijk om Git-pull-aanvragen te gebruiken om wijzigingen in de systeeminfrastructuur te verifiëren en automatisch te implementeren.

Naast Git als belangrijk DevOps-mechanisme, wordt GitOps ook gebruikt om tools te beschrijven die de standaardfunctionaliteit van Git verbeteren. Deze tools werden voornamelijk gebruikt met operationele modellen voor op Kubernetes gebaseerde infrastructuur en toepassingen. Binnen de DevOps-gemeenschap wordt voortdurend verder ontwikkeld en gediscussieerd om GitOps-tools beschikbaar te maken voor andere niet-Kubernetes-platforms, zoals Terraform.

GitOps zorgt ervoor dat de cloudinfrastructuur van een systeem onmiddellijk reproduceerbaar is op basis van de toestand van een Git-repository. Pull-aanvragen wijzigen de status van de Git-repository. Na goedkeuring en samenvoeging worden de pull-aanvragen automatisch opnieuw geconfigureerd en gesynchroniseerd met de status van de repository. Deze workflow voor live synchronisatie van pull-aanvragen is de kern van GitOps.

Git-logo
gerelateerd materiaal

Git cheat sheet

Logo Bitbucket
Oplossing bekijken

Git leren met Bitbucket Cloud

De geschiedenis van GitOps


Git is een bedrijfskritieke tool voor softwareontwikkeling dat workflows voor pull-aanvragen en codebeoordeling mogelijk maakt. Pull-aanvragen bevorderen de zichtbaarheid van binnenkomende wijzigingen in een codebase en moedigen communicatie, discussie en beoordeling van wijzigingen aan.

Pull-aanvragen zijn een belangrijk onderdeel van samenwerkingsgerichte softwareontwikkeling en hebben de manier veranderd waarop teams en bedrijven software bouwen. Pull-aanvragen zorgen voor transparantie en meetbaarheid in een voorheen ondoorzichtig proces. Pull-aanvragen in Git hebben geholpen de evolutie van DevOps-processen naar softwareontwikkeling mogelijk te maken. Systeembeheerders die doorgaans aarzelden om te veranderen, omarmen nu nieuwe werkwijzen voor softwareontwikkeling, zoals Agile en DevOps.

Als beroep heeft systeembeheer een wat slordige geschiedenis. Vroeger beheerden systeembeheerders de hardware handmatig door verbinding te maken met apparaten in een fysieke serverrack en deze in te richten via een cloudprovisioning-API. Naast het handmatige provisioningproces waren grote hoeveelheden handmatige configuratiewerkzaamheden een normale gang van zaken. Beheerders hielden aangepaste verzamelingen van noodzakelijke scripts en configuraties bij, combineerden ze en plaatsten ze op verschillende plaatsen. Deze scripts konden op elk moment kapot gaan of verloren gaan. Samenwerking was een uitdaging omdat de aangepaste tool chains niet regelmatig werden gedocumenteerd of gedeeld.

De DevOps-beweging is ontstaan uit dit oermoeras van systeembeheer. DevOps gebruikte de beste ideeën uit de software-engineering en paste ze toe op het systeembeheer, waar de bonte verzameling tools versiegestuurde code werden.

IaC is een van de grootste ontwikkelingen op het gebied van DevOps. Voorheen gaven systeembeheerders de voorkeur aan aangepaste imperatieve scripts om systemen te configureren. Imperatieve software volgt een reeks stappen om de gewenste toestand te bereiken, zoals:

Imperatieve software is vaak foutgevoelig en eenvoudig te kraken door de volgorde van de gebeurtenissen te wijzigen. Moderne softwareontwikkeling is van imperatieve patronen overgestapt naar declaratieve softwarepatronen.

Declaratieve software volgt een declaratie van een verwachte toestand in plaats van een reeks opdrachten. Hier is een vergelijking van imperatieve en declaratieve DevOps-verklaringen.

De imperatieve verklaringen zouden als volgt kunnen zijn:

  1. Installeer een besturingssysteem op dit apparaat
  2. Installeer deze afhankelijkheden
  3. Download code vanaf deze URL
  4. Verplaats de code naar deze map
  5. Doe dit drie keer voor drie andere apparaten

De declaratieve versie hiervan zou simpelweg als volgt gaan: op vier apparaten is software via deze URL geïnstalleerd in deze map.

IaC stimuleert en promoot tools voor declaratief systeembeheer in plaats van imperatieve oplossingen op maat. Dit heeft geleid tot de opkomst van technologieën zoals Docker-containers, Ansible, Terraform en Kubernetes, die gebruikmaken van statische declaratieve configuratiebestanden. Leesbaarheid en een consistente reproduceerbare toestand zijn hiervan de voordelen. Deze configuratiebestanden zijn uiteraard toegevoegd aan Git om ze te traceren en te controleren. Dit komt een stapje dichterbij, maar is nog niet helemaal wat GitOps inhoudt.

Veel van de traditionele systeembeheerproblemen zijn op dit moment in de geschiedenis van DevOps opgelost. Configuratiebestanden en tools worden nu op een centrale locatie opgeslagen, gedocumenteerd en zijn toegankelijk voor veel teamleden. Commits en pull-aanvragen werden gebruikt om wijzigingen in de configuratie bij te houden en samenwerking, discussie en beoordeling te bevorderen. Het enige resterende probleem met deze fase is dat de configuratie nog steeds los van het live-systeem aanvoelt. Zodra een pull-aanvraag voor de configuratie is goedgekeurd en is samengevoegd met de repo, wordt het actieve systeem handmatig bijgewerkt zodat het overeenkomt met de status van de statische repo. Dit is precies het probleem dat GitOps oplost.

Het idee van GitOps werd voor het eerst bedacht en gedeeld door WeaveWorks, een Kubernetes-managementbedrijf voor ondernemingen, en is sindsdien verspreid in de DevOps-gemeenschap. GitOps is een uitbreiding van de iAC en de declaratieve configuratie zoals hierboven besproken. GitOps voegt wat magie toe aan de workflow voor pull-aanvragen die de status van het live-systeem synchroniseert met die van de repository voor statische configuraties.

De voordelen van GitOps


GitOps heeft veel van dezelfde voordelen als een softwareontwikkelingsworkflow voor agile functie-branches. Het eerste grote voordeel is de eenvoudige implementatie dankzij het gebruik van veelgebruikte tools. Git is de feitelijke standaard voor versiebeheersystemen en is een veelgebruikte tool voor softwareontwikkeling voor de meeste ontwikkelaars en softwareteams. Daardoor kunnen ontwikkelaars die bekend zijn met Git eenvoudig multifunctionele bijdragers worden en deelnemen aan GitOps.

Met behulp van een versiebeheersysteem kan een team alle wijzigingen in de configuratie van een systeem volgen. Dit biedt een 'bron van waarheid' en een waardevol auditspoor om te controleren als iets kapot gaat of zich onverwacht gedraagt. Teams kunnen de geschiedenis van GitOps bekijken en zien wanneer er een regressie is geïntroduceerd. Daarnaast kan dit auditspoor worden gebruikt als referentie voor nalevings- of beveiligingsaudits. De geschiedenis van GitOps kan worden gebruikt als bewijs wanneer bijvoorbeeld coderingscertificaten worden gewijzigd of bijgewerkt.

GitOps levert transparantie en duidelijkheid in de infrastructuurbehoeften van een organisatie met behulp van een centrale repo. Door alle systeemconfiguraties in een centrale repository op te slaan, kan de input van teamleden worden geschaald. Pull-aanvragen die via gehoste Git-services zoals Bitbucket worden gedaan, bieden uitgebreide tools voor codebeoordeling en commentaar bij discussies. Hiermee worden passieve communicatielussen gebouwd waardoor het volledige technische team veranderingen in de infrastructuur kan bekijken en volgen.

GitOps kan de productiviteit van een DevOps-team enorm verhogen. Het stelt hen in staat snel te experimenteren met nieuwe infrastructuurconfiguraties. Als de nieuwe wijzigingen niet werken zoals verwacht, kan een team de geschiedenis van Git gebruiken om de wijzigingen terug te brengen naar een bekende goede staat. Dit is ongelooflijk krachtig omdat het de bekende functionaliteit 'ongedaan maken' mogelijk maakt in een gecompliceerde infrastructuur.

Hoe GitOps werkt


De GitOps-procedures worden uitgevoerd door een onderliggend orkestratiesysteem. GitOps zelf is een agnostisch patroon van best practices. Veel populaire GitOps-oplossingen gebruiken tegenwoordig vooral Kubernetes als orkestratiesysteem. Er komen enkele alternatieve GitOps-toolsets op de markt die directe Terraform-manipulatie ondersteunen.

Voor een volledige installatie van GitOps is een pipeline-platform vereist. Jenkins, Bitbucket Pipelines en CircleCI zijn enkele populaire pipelinetools die een aanvulling vormen op GitOps. Pipelines automatiseren en overbruggen de kloof tussen pull-aanvragen in Git en het orkestratiesysteem. Zodra pipeline-hooks zijn ingesteld en geactiveerd op basis van pull-aanvragen, worden de opdrachten uitgevoerd naar het orkestratiedeel.

Een nieuw patroon of component dat specifiek met GitOps is geïntroduceerd, is de 'operator' van GitOps, een mechanisme dat zich tussen de pipeline en het orkestratiesysteem bevindt. Met een pull-aanvraag wordt de pipeline gestart die vervolgens de operator activeert. De operator onderzoekt de status van de repository en het begin van de orkestratie en synchroniseert deze. De operator is het magische component van GitOps.

Voorbeelden van GitOps


Stel je voor dat een team een prestatieknelpunt of een piek in het verkeer heeft vastgesteld en het team merkt dat de load balancer niet naar verwachting werkt. Ze bekijken de GitOps-repo die de configuratie van de infrastructuur bevat en vinden een specifiek bestand waarmee de load balancer wordt geconfigureerd en geïmplementeerd. Ze kunnen deze bekijken via hun online Git-hostingsite. Na enig onderzoek en discussie stellen ze vast dat sommige configuratiewaarden voor de load balancer niet optimaal zijn en moeten worden aangepast.

Een lid van het team dient een nieuwe pull-aanvraag in waarmee de waarden van de load balancer worden geoptimaliseerd. De pull-aanvraag wordt beoordeeld en goedgekeurd door een tweede teamlid en samengevoegd in de repository. Door de samenvoeging wordt een GitOps-pipeline gestart, die de GitOps-operator activeert. De operator ziet dat de configuratie van de load balancer is gewijzigd. Met de tool voor systeemorkestratie wordt bevestigd dat dit niet overeenkomt met wat er live is in de cluster van het team.

De operator geeft een signaal aan het orkestratiesysteem om de configuratie van de load balancer bij te werken. Het orkestratiesysteem regelt de rest en implementeert automatisch de nieuw geconfigureerde load balancer. Het team controleert vervolgens het bijgewerkte live-systeem om te zien of het weer gezond is. Dit is een ideaal GitOps-scenario. Laten we het verder verkennen om het nut van GitOps te demonstreren.

Stel je voor dat, in plaats dat de waarden van de load balancer iets aangepast moesten worden om ze te optimaliseren, het team een agressieve beslissing neemt om een geheel nieuw type load balancer te implementeren. Ze vinden dat de huidige load balancer fundamenteel gebrekkig is en willen een andere optie proberen. De workflow is hetzelfde als de waardeaanpassing. Het team maakt een pull-aanvraag die een geheel nieuwe load balancer-configuratie introduceert en de oude configuratie verwijdert. Het is goedgekeurd en via de pipeline geïmplementeerd.

Helaas constateert het team dat dit nieuwe type load balancer niet compatibel is met sommige andere services binnen hun cluster. De nieuwe load balancer veroorzaakt kritieke verkeersstoringen en stopt de activiteiten van gebruikers. Gelukkig kunnen ze, omdat het team een complete GitOps-pipeline heeft, deze wijzigingen aan de load balancer snel ongedaan maken. Het team zal nog een pull-aanvraag indienen om de repository terug te zetten naar de oude bekende load balancer die wel functioneerde. Ook dit wordt geregistreerd door de GitOps-pipeline en automatisch geïmplementeerd. Hierdoor zal de infrastructuur snel verbeteren en de betrouwbaarheidsscore van het team verbeteren.

Samenvatting


GitOps is een ongelooflijk krachtig workflowpatroon voor het beheer van moderne cloudinfrastructuur. Hoewel de DevOps-gemeenschap zich voornamelijk richt op het beheer van Kubernetes-clusters, worden er door de gemeenschap ook GitOps-oplossingen op andere niet-Kubernetes-systemen uitgebracht. GitOps kan een technisch team veel voordelen bieden, waaronder verbeterde communicatie, zichtbaarheid, stabiliteit en betrouwbaarheid van het systeem. Een van de belangrijkste vereisten voor een GitOps-ervaring is een modern gehost Git-platform zoals Bitbucket.


Deel dit artikel
Volgend onderwerp

Aanbevolen artikelen

Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.

Mensen die samenwerken met een muur vol tools

Bitbucket-blog

Toelichting DevOps

DevOps-leertraject

Demo Den Feature-demo's met Atlassian-experts

Hoe Bitbucket Cloud werkt met Atlassian Open DevOps

Meld je aan voor onze DevOps-nieuwsbrief

Thank you for signing up