GitOps: endnu et buzzword eller et gennembrud inden for automatisering?

De fleste af os, der bemærker et andet nyt udtryk i it-blogsfæren eller konferencen, stiller før eller siden et lignende spørgsmål: "Hvad er det her? Bare endnu et buzzword, et "buzzword" eller noget der virkelig fortjener opmærksomhed, undersøgelse og løfte om nye horisonter? Det samme skete for mig med udtrykket GitOps for noget tid siden. Bevæbnet med mange eksisterende artikler, samt kendskab til kolleger fra virksomheden GitLab, Jeg forsøgte at finde ud af, hvad det er for et udyr, og hvordan det kan se ud i praksis.

Forresten om det nye i udtrykket GitOps Vores seneste undersøgelse siger også: mere end halvdelen af ​​de adspurgte er endnu ikke begyndt at arbejde med dens principper.

Så problemet med infrastrukturstyring er ikke nyt. Mange cloud-udbydere har været tilgængelige for offentligheden i godt en halv snes år, og det ser ud til, at de burde have gjort arbejdet for de teams, der er ansvarlige for infrastrukturen, enkelt og ligetil. Men sammenlignet med applikationsudviklingsprocessen (hvor automatisering når stadig nye niveauer), involverer infrastrukturprojekter stadig ofte mange manuelle opgaver og kræver specialiseret viden og ekspertise, især i lyset af nutidens krav til fejltolerance, fleksibilitet, skalerbarhed og elasticitet.

Cloud-tjenester opfyldte disse krav med stor succes, og det var dem, der gav et væsentligt skub til udviklingen af ​​tilgangen IaC. Det er forståeligt. De gjorde det trods alt muligt at konfigurere et fuldstændig virtuelt datacenter: Der er ingen fysiske servere, racks eller netværkskomponenter; hele infrastrukturen kan beskrives ved hjælp af scripts og konfigurationsfiler.

Så hvad er forskellen præcist? GitOps fra IaC? Det var med dette spørgsmål, jeg begyndte min undersøgelse. Efter at have talt med kolleger, var jeg i stand til at komme frem til følgende sammenligning:

GitOps

IaC

Al kode er gemt i et git-lager

Kodeversionering er valgfri

Deklarativ kode Beskrivelse / Idempotens

Både deklarative og imperative beskrivelser er acceptable

Ændringer træder i kraft ved hjælp af mekanismerne Merge Request / Pull Request

Aftale, godkendelse og samarbejde er valgfrit

Opdateringsudrulningsprocessen er automatiseret

Opdateringsprocessen er ikke standardiseret (automatisk, manuel, kopiering af filer, brug af kommandolinjen osv.)

Med andre ord GitOps blev født netop gennem anvendelsen af ​​principperne IaC. For det første kunne infrastruktur og konfigurationer nu lagres på samme måde som applikationer. Koden er nem at gemme, nem at dele, sammenligne og bruge versionsfunktioner. Versioner, grene, historie. Og alt dette på et sted, der er offentligt tilgængeligt for hele teamet. Derfor blev brugen af ​​versionskontrolsystemer en helt naturlig udvikling. Især git, som den mest populære.

På den anden side blev det muligt at automatisere infrastrukturstyringsprocesser. Nu kan dette gøres hurtigere, mere pålideligt og billigere. Desuden var principperne for CI / CD allerede kendte og populære blandt softwareudviklere. Det var kun nødvendigt at overføre og anvende allerede kendt viden og færdigheder til et nyt område. Denne praksis gik imidlertid ud over standarddefinitionen af ​​Infrastruktur som kode, deraf konceptet GitOps.

Nysgerrighed GitOps, selvfølgelig også i det faktum, at det ikke er et produkt, plugin eller platform, der er tilknyttet nogen leverandør. Det er mere et paradigme og et sæt principper, der ligner et andet udtryk, vi kender: DevOps.

Virksomheden GitLab vi har udviklet to definitioner af dette nye udtryk: teoretisk og praktisk. Lad os starte med det teoretiske:

GitOps er en metode, der tager de bedste DevOps-principper, der bruges til applikationsudvikling, såsom versionskontrol, samarbejde, orkestrering, CI/CD, og ​​anvender dem på udfordringerne ved at automatisere infrastrukturstyring.

Alle processer GitOps Jeg arbejder med eksisterende værktøjer. Al infrastrukturkode er gemt i det allerede velkendte git-lager, ændringer gennemgår den samme godkendelsesproces som enhver anden programkode, og udrulningsprocessen er automatiseret, hvilket giver os mulighed for at minimere menneskelige fejl, øge pålideligheden og reproducerbarheden.

Fra et praktisk synspunkt beskriver vi GitOps som følger:

Vi har allerede diskuteret infrastruktur som kode som en af ​​nøglekomponenterne i denne formel. Lad os præsentere resten af ​​deltagerne.

Merge Request (alternativt navn Pull Request). I procestermer er MR en anmodning om at anvende kodeændringer og derefter flette filialer. Men med hensyn til de værktøjer, vi bruger, er dette mere en mulighed for at få et fuldstændigt billede af alle de ændringer, der foretages: ikke kun kodeforskellen indsamlet fra et bestemt antal commits, men også konteksten, testresultater og endeligt forventet resultat. Hvis vi taler om infrastrukturkode, så er vi interesserede i, hvordan præcis infrastrukturen vil ændre sig, hvor mange nye ressourcer der vil blive tilføjet eller fjernet, ændret. Gerne i noget mere bekvemt og letlæst format. For cloud-udbydere er det en god idé at vide, hvad den økonomiske effekt af denne ændring vil være.

Men MR er også et middel til samarbejde, interaktion og kommunikation. Stedet, hvor systemet med checks og balances kommer i spil. Fra simple kommentarer til formelle godkendelser og godkendelser.

Nå, den sidste komponent: CI/CD, som vi allerede ved, gør det muligt at automatisere processen med at lave infrastrukturændringer og test (fra simpel syntakskontrol til mere kompleks statisk kodeanalyse). Og også i den efterfølgende påvisning af drift: forskelle mellem den reelle og ønskede tilstand af systemet. For eksempel som følge af uautoriserede manuelle ændringer eller systemfejl.

Ja, udtrykket GitOps introducerer os ikke for noget helt nyt, genopfinder ikke hjulet, men anvender blot den allerede akkumulerede erfaring på et nyt område. Men det er her hans styrke ligger.

Og hvis du pludselig bliver interesseret i, hvordan det hele ser ud i praksis, så inviterer jeg dig til at se på vores master klasse, hvor jeg trin for trin fortæller dig, hvordan du bruger GitLab:

• Implementer de grundlæggende principper for GitOps

• Opret og foretag ændringer i cloud-infrastrukturen (ved hjælp af eksemplet med Yandex Cloud)

• Automatiser detektering af systemdrift fra en ønsket tilstand ved hjælp af aktiv overvågning

https://bit.ly/34tRpwZ

Kilde: www.habr.com