De fleste av oss, som legger merke til det neste nye begrepet i IT-bloggosfæren eller konferansen, stiller før eller siden et lignende spørsmål: «Hva er det? Et annet buzzword, "buzzword" eller er det virkelig noe verdt å følge nøye med på, studere og love nye horisonter? Det samme skjedde med meg med begrepet gitops en stund siden. Bevæpnet med mange eksisterende artikler, samt kunnskapen til kolleger fra selskapet , prøvde jeg å finne ut hva slags beist det er, og hvordan bruken kan se ut i praksis.
Forresten, om nyheten i begrepet gitops sier også vår nylige undersøkelse: mer enn halvparten av de spurte har ennå ikke begynt å jobbe med prinsippene.
Så problemet med infrastrukturstyring er ikke nytt. Mange skyleverandører har vært tilgjengelige for allmennheten i et godt tiår, og det ser ut til at de burde ha gjort arbeidet til infrastrukturteam enkelt og upretensiøst. Men sammenlignet med applikasjonsutviklingsprosessen (hvor automatiseringsnivået når nye og nye horisonter), involverer infrastrukturprosjekter fortsatt mange manuelle oppgaver og krever spesialkunnskap og spesialister, spesielt gitt dagens krav til feiltoleranse, fleksibilitet, skalerbarhet og elastisitet .
Skytjenester var svært vellykkede med å oppfylle disse kravene, og det var de som ga en betydelig drivkraft til utviklingen av tilnærmingen. IaC. Det er forståelig. Tross alt var det de som gjorde det mulig å konfigurere et fullstendig virtuelt datasenter: det er ingen fysiske servere, rack, nettverkskomponenter, hele infrastrukturen kan beskrives ved hjelp av skript og konfigurasjonsfiler.
Så hva er egentlig forskjellen gitops fra IaC? Det var med dette spørsmålet jeg begynte min undersøkelse. Etter å ha snakket med kolleger, klarte jeg å utvikle følgende sammenligning:
gitops
IaC
All kode er lagret i et git-lager
Kodeversjon er valgfritt
Deklarativ kodebeskrivelse / Idempotens
Både deklarative og imperative beskrivelser er tillatt
Endringer trer i kraft ved å bruke Merge Request / Pull Request-mekanismer
Koordinering, godkjenning og samarbeid er valgfritt
Prosessen med å rulle ut oppdateringer er automatisert
Prosessen med å rulle ut oppdateringer er ikke standardisert (automatisk, manuell, kopiering av filer, bruk av kommandolinjen, etc.)
Med andre ord gitops ble til gjennom anvendelse av prinsippene IaC. For det første kan infrastruktur og konfigurasjoner nå lagres akkurat som applikasjoner. Koden er enkel å lagre, enkel å dele, sammenligne, bruke versjonsfunksjoner. Versjoner, grener, historie. Og alt dette på et offentlig sted for hele laget. Derfor har bruken av versjonskontrollsystemer blitt en ganske naturlig utvikling. Spesielt git, som den mest populære.
På den annen side ble det mulig å automatisere infrastrukturforvaltningsprosesser. Nå kan det gjøres raskere, mer pålitelig og billigere. Dessuten var prinsippene for CI / CD allerede kjent og populære blant programvareutviklere. Det var bare nødvendig å overføre og anvende allerede kjente kunnskaper og ferdigheter til et nytt område. Denne praksisen gikk imidlertid utover standarddefinisjonen av Infrastruktur som kode, derav konseptet gitops.
nysgjerrighet gitops, selvfølgelig også i det faktum at dette ikke er et produkt, plug-in eller plattform tilknyttet noen leverandør. Det er mer et paradigme og et sett med prinsipper, som ligner på et annet begrep vi er kjent med: DevOps.
Selskapet vi har utviklet to definisjoner av dette nye begrepet: teoretisk og praktisk. La oss starte med det teoretiske:
GitOps er en metodikk som tar de beste DevOps-prinsippene som brukes for applikasjonsutvikling, som versjonskontroll, interoperasjon, avstemming, CI/CD, og bruker dem for å automatisere infrastrukturadministrasjonsoppgaver.
Alle prosesser gitops Jeg jobber med eksisterende verktøy. All infrastrukturkode lagres i et kjent git-lager, endringer går gjennom den samme innsjekkingsprosessen som enhver annen kode, og utrullingsprosessen er automatisert, noe som minimerer menneskelige feil, forbedrer påliteligheten og reproduserbarheten.
Fra et praktisk synspunkt beskriver vi gitops som følger:
Vi har allerede diskutert infrastruktur som kode som en av nøkkelkomponentene i denne formelen. La oss presentere resten av medlemmene.
Merge Request (alternativt navn for Pull Request). Når det gjelder prosessen, er MR en forespørsel om å bruke kodeendringer og deretter slå sammen grener. Men når det gjelder verktøyene vi bruker, er dette mer en mulighet til å få et fullstendig bilde av alle endringene som gjøres: ikke bare kodeforskjell samlet inn fra et visst antall forpliktelser, men også kontekst, testresultater og den endelige forventede resultat. Hvis vi snakker om infrastrukturkoden, så er vi interessert i hvordan nøyaktig infrastrukturen vil endre seg, hvor mange nye ressurser som vil bli lagt til eller fjernet, endret. Gjerne i et mer praktisk og lettlest format. Når det gjelder skyleverandører, ville det være fint å vite hva de økonomiske konsekvensene av denne endringen ville være.
Men MR er også et middel for samarbeid, samhandling, kommunikasjon. Stedet der systemet med kontroller og balanser kommer inn i bildet. Fra enkle kommentarer til formelle godkjenninger og uttalelser.
Vel, den siste komponenten: CI / CD, som vi allerede vet, gjør det mulig å automatisere prosessen med å gjøre infrastrukturendringer, testing (fra enkel syntakskontroll til mer kompleks statisk kodeanalyse). Og også i den påfølgende driftdeteksjonen: forskjeller mellom den virkelige og ønskede tilstanden til systemet. For eksempel som følge av uautoriserte manuelle endringer eller systemfeil.
Ja, begrepet gitops introduserer oss ikke for noe helt nytt, finner ikke opp hjulet på nytt, men bruker kun erfaringen som allerede er samlet i et nytt område. Men der ligger dens styrke.
Og hvis du plutselig blir interessert i hvordan det hele ser ut i praksis, så inviterer jeg deg til å se på vår , der jeg leder deg gjennom hvordan du bruker GitLab:
-
Implementer de grunnleggende prinsippene til GitOps
-
Opprett og gjør endringer i skyinfrastrukturen (i eksemplet med Yandex Cloud)
-
Automatiser deteksjonen av systemdrift fra ønsket tilstand gjennom aktiv overvåking
https://bit.ly/34tRpwZ
Kilde: www.habr.com