De meesten van ons vragen zich рано of laat dezelfde vraag: “Wat is dit? Weer een modeterm, een 'buzzword', of is het echt iets dat onze aandacht en studie waard is en belooft nieuwe horizonten?” Zo ging het ook met mij en de term GitOps een tijdje geleden. Gewapend met een overvloed aan bestaande artikelen, evenals de kennis van collega's binnen het bedrijf , probeerde ik te begrijpen wat dit fenomeen inhoudt en hoe de toepassing ervan eruit kan zien in de praktijk.
Overigens blijkt de nieuwheid van de term GitOps ook uit een recente enquête die we hebben gehouden: meer dan de helft van de ondervraagden is nog niet begonnen met het werken met de principes ervan.
Het probleem van infrastructuurbeheer is overigens niets nieuws. Talrijke cloudproviders zijn sinds een goede tien jaar beschikbaar voor het grote publiek en zouden de werkzaamheden voor infrastructuurteams eenvoudiger en minder problematisch moeten hebben gemaakt. Echter, in vergelijking met het ontwikkelingsproces van applicaties (waarbij het niveau van automatisering steeds nieuwe hoogtes bereikt), omvatten infrastructuurprojecten nog steeds vaak veel handmatige taken en vereisen ze specifieke kennis en specialisten, vooral gezien de moderne eisen aan fouttolerantie, flexibiliteit, schaalbaarheid en elasticiteit.
Cloudservices hebben deze vereisten zeer succesvol vervuld en juist zij hebben een aanzienlijke impuls gegeven aan de ontwikkeling van de aanpak IaC. En dat is begrijpelijk. Want zij hebben ons in staat gesteld om een volledig virtueel datacenter te configureren: geen fysieke servers, racks, netwerkcomponenten, de hele infrastructuur kan worden beschreven met scripts en configuratiebestanden.
Dus wat is eigenlijk het verschil? GitOps van IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:
GitOps
IaC
Al de code wordt opgeslagen in een git-repository
Versiebeheer van de code is niet verplicht
Declaratieve beschrijving van code / Idempotentie
Zowel declaratieve als imperatieve beschrijvingen zijn toegestaan
Wijzigingen worden doorgevoerd met behulp van mechanisme Merge Request / Pull Request
Afstemming, goedkeuring en samenwerking zijn niet verplicht
Het proces van het uitrollen van updates is geautomatiseerd
Het uitrolproces van updates is niet genormaliseerd (automatisch, handmatig, kopiëren van bestanden, met behulp van de commandoregel, enz.)
Met andere woorden GitOps is ontstaan door de toepassing van principes IaC. Ten eerste konden infrastructuren en configuraties nu net zo worden opgeslagen als applicaties. Code kan gemakkelijk worden opgeslagen, gedeeld, vergeleken en er kunnen versies van worden gemaakt. Versies, takken, geschiedenis. En dat alles op een voor het hele team toegankelijke plaats. Daarom was het een logisch gevolg dat versiebeheersystemen werden gebruikt. In het bijzonder git, als de meest populaire.
Aan de andere kant ontstond de mogelijkheid om processen voor infrastructuurbeheer te automatiseren. Dit kan nu sneller, betrouwbaarder en goedkoper. Bovendien waren de principes van CI/CD al bekend en populair onder softwareontwikkelaars. Het enige wat nog moest worden gedaan, was de reeds bekende kennis en vaardigheden naar dit nieuwe domein te verplaatsen en toe te passen. Deze praktijken gingen echter verder dan de standaarddefinitie van Infrastructuur als code, vandaar het ontstaan van het begrip GitOps.
Nieuwsgierigheid GitOps, natuurlijk, ook omdat dit geen product, plugin of platform is dat met een of andere leverancier is verbonden. Het is eerder een paradigma en een set principes, vergelijkbaar met een andere bekende term: DevOps.
In het bedrijf hebben we twee definities van deze nieuwe term ontwikkeld: theoretisch en praktisch. Laten we beginnen met het theoretische:
GitOps is een methodologie die de geavanceerde principes van DevOps gebruikt, die worden toegepast bij de ontwikkeling van applicaties, zoals versiebeheer, samenwerking, afstemming, CI/CD, en deze toepast om taken voor het automatiseren van infrastructuurbeheer op te lossen.
Alle processen GitOps werken met de al beschikbare tools. Alle infrastructuurcode wordt opgeslagen in de al bekende git-repository, wijzigingen ondergaan hetzelfde afstemmingsproces als elke andere programmatuur, en het uitrolproces is geautomatiseerd, wat het risico op menselijke fouten minimaliseert en de betrouwbaarheid en reproduceerbaarheid verhoogt.
Vanuit praktisch oogpunt beschrijven we GitOps het als volgt:
Infrastructuur als code hebben we al besproken als een van de sleutelcomponenten van deze formule. Laten we de andere deelnemers voorstellen.
Merge Request (alternatieve naam Pull Request). In het proces van MR is het een verzoek om wijzigingen in de code aan te brengen en de takken samen te voegen. Maar qua tools die we gebruiken, is het meer een mogelijkheid om een volledig overzicht van alle aangebrachte wijzigingen te krijgen: niet alleen de code diff, samengesteld uit een aantal commits, maar ook de context, testresultaten en het uiteindelijke verwachte resultaat. Als we het hebben over infrastructuurcode, dan is het belangrijk om te weten hoe de infrastructuur precies zal veranderen, hoeveel nieuwe middelen er zullen worden toegevoegd of verwijderd, en welke wijzigingen er zullen plaatsvinden. Bij voorkeur in een beter bruikbare en leesbare indeling. In het geval van cloudproviders is het nuttig om te weten welke financiële gevolgen deze wijziging met zich meebrengt.
Maar MR is ook een middel voor samenwerking, interactie en communicatie. De plek waar het systeem van checks and balances in werking treedt. Van eenvoudige opmerkingen tot formele goedkeuringen en bevestigingen.
En de laatste component: CI/CD, zoals we al weten, biedt de mogelijkheid om het proces van infrastructuurwijzigingen, testen (van eenvoudige syntaxisvalidatie tot complexere statische code-analyse) te automatiseren. En ook in de toekomst de afwijkingen te detecteren: de verschillen tussen de werkelijke en gewenste staat van het systeem. Bijvoorbeeld als gevolg van ongeoorloofde handmatige wijzigingen of systeemfouten.
Ja, de term GitOps introduceert ons niet in iets helemaal nieuws, het uitvindt het wiel niet opnieuw, maar past gewoon de reeds opgebouwde ervaring toe in een nieuw domein. Maar daar ligt ook zijn kracht.
En als je je afvraagt hoe dit alles er in de praktijk uitziet, dan nodig ik je uit om onze te bekijken, waarin ik stap voor stap uitleg hoe je met GitLab:
De basisprincipes van GitOps implementeert
Wijzigingen aanbrengt in de cloudinfrastructuur (aan de hand van Yandex Cloud)
Automatisch het drijfvermogen van het systeem ten opzichte van de gewenste staat detecteert door actief te monitoren
https://bit.ly/34tRpwZ
Bron: habr.com
