GitOps: ein ny moteord eller eit gjennombrudd i automatisering?

De fleste av oss legger merke til et nytt begrep i IT-blogosfæren eller på konferanser, og før eller siden stiller vi oss spørsmålet: “Hva er dette? Nok et moteord, 'buzzword', eller er det faktisk noe verdt å gi oppmerksomhet, studere og lover nye horisonter?” Det samme tenkte jeg om begrepet GitOps for en tid tilbake. Bevæpnet med en rekke eksisterende artikler, samt kunnskap fra kolleger i selskapet GitLab, forsøkte jeg å finne ut hva dette fenomenet er, og hvordan bruken av det kan se ut i praksis.

For øvrig indikerer nyheten av termen GitOps også en nylig gjennomført undersøkelse av oss: mer enn halvparten av de spurte har ikke begynt å jobbe med prinsippene.

Så, problemet med infrastrukturforvaltning er ikke nytt. Mange skytilbydere har vært tilgjengelige for offentligheten i over ti år, og det skulle tilsynelatende ha gjort arbeidet til teamene som har ansvar for infrastrukturen enkelt og uanstrengt. Likevel, sammenlignet med utviklingsprosessen for applikasjoner (hvor automatiseringsnivået når stadig nye høyder), så inneholder infrastrukturprosjekter fortsatt ofte mange manuelle oppgaver og krever spesielle kunnskaper og spesialister, spesielt med tanke på de moderne kravene til pålitelighet, fleksibilitet, skalerbarhet og elastisitet.

Skyen har klart disse kravene veldig godt, og det er nettopp de som har gitt et betydelig driv til utviklingen av tilnærmingen IaC. Det er forståelig. For det er nettopp de som har gjort det mulig å konfigurere et fullt virtuelt datasenter: ingen fysiske servere, hyller, nettverkskomponenter, all infrastrukturen kan beskrives ved hjelp av skript og konfigurasjonsfiler.

Så hva er egentlig forskjellen GitOps fra IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:

GitOps

IaC

All koden er lagret i et git-repositorium

Versionskontroll av koden er ikke nødvendig

Deklarativ beskrivelse av kode / Idempotens

Både deklarativ og imperativ beskrivelse er akseptabelt

Endringer trer i kraft ved hjelp av Merge Request / Pull Request mekanismer

Samordning, godkjenning og samarbeid er ikke påkrevd

Prosessen med å rulle ut oppdateringer er automatisert

Prosessen med å rulle ut oppdateringer er ikke regulert (automatisk, manuell, filkopiering, ved hjelp av kommandolinjen osv.)

Med andre ord GitOps ble født takket være anvendelse av prinsipper IaC. For det første kunne infrastrukturen og konfigurasjonene nå lagres på samme måte som applikasjoner. Koden er enkel å lagre, dele, sammenligne og benytte seg av versjonering. Versjoner, grener, historikk. Og alt dette på et offentlig tilgjengelig sted for hele teamet. Derfor var det en naturlig utvikling å begynne å bruke versjonskontrollsystemer, spesielt git, som det mest populære.

På den annen side ble det mulig å automatisere infrastrukturforvaltningsprosesser. Nå kan dette gjøres raskere, mer pålitelig og billigere. Dessuten var prinsippene for CI / CD allerede kjente og populære blant programvareutviklere. Det gjaldt bare å overføre og anvende kjente kunnskaper og ferdigheter til et nytt område. Disse praksisene overskred imidlertid standarddefinisjonen av Infrastruktur som kode, derav ble begrepet født GitOps.

Nysgjerrighet GitOps, handler selvfølgelig også om at dette ikke er et produkt, en plugin eller en plattform knyttet til noe som helst leverandør. Det er snarere et paradigme og et sett med prinsipper, parallelt med et annet kjent begrep: DevOps.

At the company GitLab vi har utviklet to definisjoner av dette nye begrepet: teoretisk og praktisk. La oss begynne med den teoretiske:

GitOps er en metodologi som bruker avanserte prinsipper fra DevOps, benyttet for applikasjonsutvikling, som versjonskontroll, samarbeid, godkjenning, CI/CD, og anvender dem for å løse oppgaver med automatisering av infrastrukturforvaltning.

Alle prosesser GitOps arbeider ved å bruke allerede eksisterende verktøy. All infrastrukturkode lagres i det allerede kjente git-repositoriet, endringer går gjennom den samme godkjenningsprosessen som all annen programvarekode, og distribusjonsprosessen er automatisert, noe som reduserer menneskelig feil, øker påliteligheten og reproduserbarheten.

Fra et praktisk perspektiv beskriver vi GitOps på følgende måte:

Infrastruktur som kode har vi allerede diskutert som en av de viktigste komponentene i denne formelen. La oss forestille oss de øvrige deltakerne.

Merge Request (alternativt navn Pull Request). I prosessen er MR en forespørsel om å bruke kodeendringer og deretter slå sammen grener. Men når det gjelder verktøyene vi bruker, er det mer et middel for å få en fullstendig oversikt over alle endringene som gjøres: ikke bare code diff, samlet fra ulike commits, men også konteksten, testresultater og det ønskede sluttresultatet. Når vi snakker om infrastrukturkode, er det interessant å vite hvordan infrastrukturen endres, hvor mange nye ressurser som vil legges til eller fjernes, eller endres. Det ville være fint i et mer praktisk og lettlest format. Når det gjelder sky-leverandører, ville det vært bra å vite hvilke økonomiske konsekvenser denne endringen vil ha.

Men MR er også et samarbeid- og kommunikasjonsverktøy. Det er stedet der systemet med maktbalanser trer i kraft. Fra enkle kommentarer til formelle godkjenninger og bekreftelser.

Og den siste delen: CI/CD, som vi allerede vet, gir mulighet for å automatisere prosessen med å gjøre infrastrukturendringer, testing (fra enkel syntaksjekk til mer kompleks statisk kodeanalyse). Og i etterkant oppdage drift: forskjeller mellom systemets faktiske tilstand og ønsket tilstand. For eksempel som følge av uautoriserte manuelle endringer eller systemfeil.

Ja, begrepet GitOps introducerer oss ikke for noe helt nytt, det oppfinner ikke hjulet på nytt, men bruker bare erfaringer fra tidligere i et nytt område. Men dette er nettopp styrken.

Og hvis du blir interessert i hvordan dette ser ut i praksis, inviterer jeg deg til å se vår masterclass, der jeg steg for steg forklarer hvordan man med GitLab:

• Implementere grunnprinsippene for GitOps

• Opprette og gjøre endringer i skyinfrastruktur (med Yandex Cloud som eksempel)

• Automatisere oppdagelsen av drift fra ønsket tilstand gjennom aktiv overvåkning

https://bit.ly/34tRpwZ

Kilde: habr.com