Is GitOps het volgende grote succes voor DevOps?

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.

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.

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.

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.

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.