GitOps: nog een modewoord of een doorbraak in automatisering?

De meesten van ons die de volgende nieuwe term in de IT-blogosfeer of -conferentie opmerken, stellen vroeg of laat een soortgelijke vraag: “Wat is het? Nog een buzzword, een ‘buzzword’, of is het echt iets dat de moeite waard is om goed op te letten, te bestuderen en nieuwe horizonten te beloven?” Hetzelfde overkwam mij met de term Gitops een tijdje geleden. Gewapend met veel bestaande artikelen, maar ook met de kennis van collega's uit het bedrijf GitLab, Ik probeerde erachter te komen wat voor soort beest het is en hoe de toepassing ervan er in de praktijk uit zou kunnen zien.

Trouwens, over de nieuwigheid van de term Gitops blijkt ook uit ons recente onderzoek: meer dan de helft van de ondervraagden is nog niet begonnen met de principes ervan te werken.

Het probleem van infrastructuurbeheer is dus niet nieuw. Veel cloudproviders zijn al ruim tien jaar beschikbaar voor het grote publiek en het lijkt erop dat ze het werk van infrastructuurteams eenvoudig en pretentieloos hadden moeten maken. In vergelijking met het applicatieontwikkelingsproces (waar het automatiseringsniveau nieuwe en nieuwe horizonten bereikt), omvatten infrastructuurprojecten echter nog steeds vaak veel handmatige taken en vereisen ze speciale kennis en specialisten, vooral gezien de huidige eisen op het gebied van fouttolerantie, flexibiliteit, schaalbaarheid en elasticiteit. .

Clouddiensten waren zeer succesvol in het voldoen aan deze eisen en zij waren het die een belangrijke impuls gaven aan de ontwikkeling van de aanpak. IaC. Het is begrijpelijk. Zij hebben het immers mogelijk gemaakt om een ​​volledig virtueel datacenter in te richten: er zijn geen fysieke servers, racks, netwerkcomponenten, de hele infrastructuur kan worden beschreven met behulp van scripts en configuratiebestanden.

Wat is dan precies het verschil Gitops van IaC? Met deze vraag begon ik mijn onderzoek. Na overleg met collega's ben ik tot de volgende vergelijking gekomen:

Gitops

IaC

Alle code wordt opgeslagen in een git-repository

Codeversiebeheer is optioneel

Declaratieve codebeschrijving / Idempotentie

Zowel declaratieve als imperatieve beschrijvingen zijn toegestaan

Wijzigingen worden van kracht met behulp van Merge Request / Pull Request-mechanismen

Coördinatie, goedkeuring en samenwerking zijn optioneel

Het proces van het uitrollen van updates is geautomatiseerd

Het proces van het uitrollen van updates is niet gestandaardiseerd (automatisch, handmatig, bestanden kopiëren, gebruik van de opdrachtregel, enz.)

Met andere woorden Gitops ontstond door de toepassing van de principes IaC. Ten eerste konden infrastructuur en configuraties nu net als applicaties worden opgeslagen. De code is gemakkelijk op te slaan, gemakkelijk te delen, te vergelijken en versiebeheerfuncties te gebruiken. Versies, takken, geschiedenis. En dit alles op een openbare plek voor het hele team. Daarom is het gebruik van versiebeheersystemen een vrij natuurlijke ontwikkeling geworden. In het bijzonder is git het populairst.

Aan de andere kant werd het mogelijk om infrastructuurbeheerprocessen te automatiseren. Nu kan het sneller, betrouwbaarder en goedkoper. Bovendien waren de principes van CI/CD al bekend en populair onder softwareontwikkelaars. Het was alleen nodig om reeds bekende kennis en vaardigheden over te dragen en toe te passen op een nieuw gebied. Deze praktijken gingen echter verder dan de standaarddefinitie van infrastructuur als code, vandaar het concept Gitops.

nieuwsgierigheid GitopsNatuurlijk ook in het feit dat dit geen product, plug-in of platform is dat aan een leverancier is gekoppeld. Het is meer een paradigma en een reeks principes, vergelijkbaar met een andere term die we kennen: DevOps.

Het bedrijf GitLab we hebben twee definities van deze nieuwe term ontwikkeld: theoretisch en praktisch. Laten we beginnen met de theorie:

GitOps is een methodologie die de beste DevOps-principes gebruikt voor applicatieontwikkeling, zoals versiebeheer, interoperabiliteit, afstemming, CI/CD, en deze toepast om infrastructuurbeheertaken te automatiseren.

Alle processen Gitops Ik werk met bestaande tools. Alle infrastructuurcode wordt opgeslagen in een vertrouwde git-repository, wijzigingen doorlopen hetzelfde incheckproces als elke andere code, en het uitrolproces is geautomatiseerd, wat menselijke fouten minimaliseert en de betrouwbaarheid en reproduceerbaarheid verbetert.

Vanuit praktisch oogpunt beschrijven we Gitops следующим обрахом:

We hebben infrastructuur als code al besproken als een van de belangrijkste componenten van deze formule. Laten we de rest van de leden even voorstellen.

Merge Request (alternatieve naam voor Pull Request). In termen van het proces is MR een verzoek om codewijzigingen toe te passen en vervolgens vestigingen samen te voegen. Maar in termen van de tools die we gebruiken, is dit meer een kans om een ​​compleet beeld te krijgen van alle veranderingen die worden aangebracht: niet alleen code diff verzameld uit een bepaald aantal commits, maar ook context, testresultaten en de uiteindelijke verwachte resultaten. resultaat. Als we het hebben over de infrastructuurcode, dan zijn we geïnteresseerd in hoe de infrastructuur precies zal veranderen, hoeveel nieuwe bronnen zullen worden toegevoegd of verwijderd, veranderd. Bij voorkeur in een handiger en gemakkelijker leesbaar formaat. In het geval van cloudaanbieders zou het leuk zijn om te weten wat de financiële implicaties van deze verandering zouden zijn.

Maar MR is ook een middel tot samenwerking, interactie, communicatie. De plek waar het systeem van checks and balances in het spel komt. Van eenvoudige opmerkingen tot formele goedkeuringen en verklaringen.

Welnu, het laatste onderdeel: CI / CD maakt het, zoals we al weten, mogelijk om het proces van het aanbrengen van infrastructuurwijzigingen en testen (van eenvoudige syntaxiscontrole tot complexere statische code-analyse) te automatiseren. En ook bij de daaropvolgende driftdetectie: verschillen tussen de werkelijke en gewenste toestand van het systeem. Bijvoorbeeld als gevolg van ongeautoriseerde handmatige wijzigingen of systeemstoringen.

Ja, de termijn Gitops laat ons niets absoluut nieuws zien, vindt het wiel niet opnieuw uit, maar past alleen de ervaring toe die al is opgebouwd op een nieuw gebied. Maar daarin ligt zijn kracht.

En als je ineens geïnteresseerd raakt in hoe het er allemaal in de praktijk uitziet, dan nodig ik je uit om eens bij ons te kijken Masterclass, waarin ik je laat zien hoe je GitLab kunt gebruiken:

• Implementeer de basisprincipes van GitOps

• Creëer en breng wijzigingen aan in de cloudinfrastructuur (naar het voorbeeld van Yandex Cloud)

• Automatiseer de detectie van systeemdrift vanuit een gewenste status door middel van actieve monitoring

https://bit.ly/34tRpwZ

Bron: www.habr.com