De fleste af os, når vi bemærker et nyt begreb i IT-blogosfæren eller på en konference, stiller før eller siden et lignende spørgsmål: "Hvad er dette? Er det et buzzword eller virkelig noget værdifuldt, der fortjener opmærksomhed og undersøgelse, og som lover nye horisonter?" Det samme skete for mig med termen GitOps for nogen tid siden. Udrustet med mange eksisterende artikler samt viden fra kolleger i virksomheden , forsøgte jeg at finde ud af, hvad denne skabning er, og hvordan dens anvendelse kan se ud i praksis.
Forresten tyder nyheden om termen GitOps også på den nyligt gennemførte undersøgelse, vi lavede: Mere end halvdelen af de adspurgte havde endnu ikke begyndt at arbejde med prinsipperne.
Så problemet med infrastrukturstyring er ikke nyt. Mange cloud-udbydere har været tilgængelige for offentligheden i godt ti år, og det burde gøre arbejdet for de teams, der står for infrastrukturen, enkelt og ligetil. Men når man sammenligner med applikationsudviklingsprocessen (hvor automatiseringsniveauet når nye højder), involverer infrastrukturelle projekter stadig ofte mange manuelle opgaver og kræver specifik viden og specialister, især med hensyn til de moderne krav til fejltolerance, fleksibilitet, skalerbarhed og elasticitet.
Cloud-tjenester har med succes opfyldt disse krav og har givet et væsentligt boost til udviklingen af tilgangen IaC. Og det er forståeligt. For netop de har givet mulighed for at konfigurere et fuldstændigt virtuelt datacenter: ingen fysiske servere, kabinetter eller netværkskomponenter; hele infrastrukturen kan beskrives ved hjælp af scripts og konfigurationsfiler.
Så hvad er det reelle forskel GitOps fra IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:
GitOps
IaC
Al koden opbevares i et git-repository
Versionering af koden er ikke obligatorisk
Deklarativ beskrivelse af kode / Idempotens
Både deklarative og imperativ beskrivelser er acceptable
Ændringer træder i kraft ved brug af Merge Request / Pull Request mekanismer
Godkendelse, bekræftelse og samarbejde er ikke obligatorisk
Processen for udrulning af opdateringer er automatiseret
Processen for udrulning af opdateringer er ikke reguleret (automatisk, manuel, filkopiering, ved brug af kommandolinjen osv.)
Med andre ord GitOps blev til på grund af anvendelsen af principper IaC. Først og fremmest kunne infrastrukturen og konfigurationerne nu opbevares på præcis samme måde som applikationerne. Koden kan nemt opbevares, deles, sammenlignes og anvendes med versionskontrol. Versioner, grene, historik. Og alt dette på et offentligt tilgængeligt sted for hele teamet. Derfor blev det en naturlig udvikling at bruge versionskontrolsystemer. Især git, som er det mest populære.
På den anden side opstod muligheden for at automatisere processer til infrastrukturforvaltning. 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 de kendte viden og færdigheder i et nyt område. Disse praksisser gik dog ud over den standardmæssige definition af Infrastruktur som kode, og heraf opstod begrebet. GitOps.
Nysgerrighed GitOps, selvfølgelig, ligger også i, at dette ikke er et produkt, plugin eller platform relateret til en bestemt leverandør. Det er snarere en paradigm og et sæt principper, ligesom det andet velkendte udtryk: DevOps.
I virksomheden har vi udviklet to definitioner af denne nye term: teoretisk og praktisk. Lad os starte med den teoretiske:
GitOps er en metodologi, der anvender de avancerede principper fra DevOps, der bruges til applikationsudvikling, såsom versionskontrol, samarbejde, godkendelse, CI / CD, og anvender dem til at automatisere infrastrukturforvaltning.
Alle processer GitOps arbejder med eksisterende værktøjer. Al infrastrukturkode opbevares i det velkendte git-repository, ændringer gennemgår den samme godkendelsesproces som enhver anden programmeringskode, og implementeringsprocessen er automatiseret, hvilket minimerer menneskelige fejl og øger pålideligheden og reproducerbarheden.
Fra et praktisk perspektiv beskriver vi GitOps som følger:
Infrastruktur som kode har vi allerede diskuteret som en af de nøglekomponenter i denne formel. Lad os præsentere de øvrige deltagere.
Merge Request (det alternative navn Pull Request). I procesplanen er MR en anmodning om at anvende ændringer i koden og efterfølgende sammenføje grene. Men med hensyn til de værktøjer, vi bruger, er det snarere en mulighed for at få et fuldstændigt billede af alle ændringer: ikke kun code diff, der er samlet fra et bestemt antal commits, men også konteksten, testresultaterne og det endelige forventede resultat. Hvis vi taler om infrastrukturkode, er vi interesserede i, hvordan infrastrukturen præcist vil ændre sig, hvor mange nye ressourcer der vil blive tilføjet eller fjernet, ændret. Det ville være ønskeligt i et mere praktisk og letlæseligt format. I tilfælde af cloududbydere ville det være godt at vide, hvilke økonomiske konsekvenser denne ændring vil have.
Men MR er også et middel til samarbejde, interaktion og kommunikation. Det sted, hvor systemet med indbyrdes kontrol og modvægt træder i kraft. Fra enkle kommentarer til formelle godkendelser og godkendelser.
Og den sidste faktor: CI/CD, som vi allerede ved, giver mulighed for at automatisere processen med at foretage infrastrukturændringer, testning (fra simpel syntakscheck til mere kompliceret statisk kodeanalyse). Samt i det efterfølgende at opdage drift: forskelle mellem systemets faktiske og ønskede tilstand. For eksempel som følge af uautoriserede manuelle ændringer eller systemfejl.
Ja, termen GitOps introducerer os ikke for noget absolut nyt, genopfinder ikke cyklen, men anvender blot den akkumulerede erfaring på et nyt område. Men det er netop i dette dens styrke ligger.
Og hvis du pludselig bliver interesseret i, hvordan det hele ser ud i praksis, så inviterer jeg dig til at se vores , hvor jeg trin for trin forklarer, hvordan man ved hjælp af GitLab:
Implementerer de grundlæggende principper for GitOps
Opretter og foretager ændringer i cloud-infrastrukturen (med Yandex Cloud som eksempel)
Automatiserer opdagelsen af systemdrift fra det ønskede tilstand ved hjælp af aktiv overvågning
https://bit.ly/34tRpwZ
Kilde: habr.com
