Det sidste årti af programmering har set en række revolutionerende transformationer. Den ene er opstået fra en klynge af praksis omkring devops, som tilpasser udviklings- og driftsteam til en delt arbejdsproces og kontinuerlig integration og kontinuerlig levering (CI / CD), hvor devops-teams leverer konstant inkrementelle opdateringer til en codebase. En anden transformation er kommet fra den relaterede flytning fra monolitiske kodebaser til skybaserede mikrotjenester, der kører i containere, der administreres af orkestrationsplatforme som Kubernetes.
Containerbaserede applikationer, der kører på klyngede systemer eller i skyen, kan være komplekse og vanskelige at tilvejebringe og administrere, selv med en platform som Kubernetes, der orkestrerer ting. GitOps er et voksende sæt praksis, der har til formål at forenkle denne ledelsesopgave ved at anvende teknikker fra devops-verdener og CI / CD.
Nøglen til GitOps er ideen om infrastruktur som kode, som tager den samme tilgang til tilvejebringelse af infrastruktur som devops bruger til at levere applikationer. Så ikke kun applikationen, men også de underliggende værtsmaskiner og netværk er beskrevet i filer, der kan behandles som enhver anden kode i et versionskontrolsystem, med automatiserede processer, der derefter arbejder på at konvergere den virkelige applikation med den, der er beskrevet i disse filer.
I GitOps-sprog er koden i versionskontrolsystemet én kilde til sandhed om, hvordan applikationen skal se ud i produktionen.
GitOps defineret
Weaveworks er det firma, der har gjort mest for at popularisere konceptet GitOps. Vi går lidt nærmere ind på detaljerne i Weaveworks rolle, men lad os først se på virksomhedens definition af GitOps, som er dobbelt:
- En driftsmodel til Kubernetes og andre cloud-native teknologier, der leverer et sæt bedste praksis, der forener implementering, styring og overvågning af containeriserede klynger og applikationer.
- En vej mod en udvikleroplevelse til administration af applikationer; hvor ende-til-ende CI / CD-rørledninger og Git-arbejdsgange anvendes til både operationer og udvikling.
Med andre ord er GitOps et specifikt sæt praksis, der er designet til at styre Kubernetes og lignende platforme, hvilket også giver mulighed for en bredere anvendelse, da flere og flere udviklingsbutikker anvender devops-praksis og migrerer kode til skyen. Men for at forstå den hemmelige sauce af GitOps og de problemer, den løser, er vi nødt til at tale om de komponenter, der går ind i den.
Git definition
Det Git i GitOps henviser til det vildt populære distribuerede versionskontrolsystem udviklet af Linus Torvalds i 2005. Git er et værktøj, der giver teams af udviklere mulighed for at arbejde sammen om en applikationskodebase og lagre forskellige grene af kode, som de fikser med, før de flettes sammen med produktionskode. Et nøglekoncept inden for Git er træk anmodning, hvor en udvikler formelt beder om en kode, de har arbejdet med, skal integreres i en anden gren inden for kodebasen.
En Git pull-anmodning giver teammedlemmer mulighed for at samarbejde og diskutere, før de når konsensus om, hvorvidt den nye kode skal føjes til applikationen. Git gemmer også ældre versioner af kode, hvilket gør det let at falde tilbage til den sidste gode version, hvis noget går galt, og lader dig hurtigt se, hvad der er ændret mellem revisioner. Git kan være bedst kendt som understøttelsen af GitHub, et cloud-hostet versionskontrolsystem, men Git selv er open source-software, der kan implementeres hvor som helst, fra interne virksomhedsservere til din pc.
Bemærk, at selvom vi normalt tænker på Git som et computerprogrammeringsværktøj, er det faktisk agnostisk med hensyn til hvilket indhold du bruger det til. Git behandler med glæde ethvert sæt tekstfiler som din "codebase", og det kan for eksempel bruges af forfattere, der ønsker at holde styr på redigeringer til et samarbejdsarbejde. Dette er vigtigt, fordi meget af kodebasen i kernen af GitOps består af deklarative konfigurationsfiler snarere end eksekverbar kode.
En sidste ting at sige, inden vi går videre: På trods af at "Git" er lige der i navnet, kræver GitOps faktisk ikke brugen af Git. Butikker, der allerede er investeret i anden versionskontrolsoftware, såsom Subversion, kan også implementere GitOps. Men Git bruges i vid udstrækning inden for devops-verdenen til at implementere CI / CD, så de fleste GitOps-projekter ender med at bruge Git.
Hvad er CI / CD-processen?
Et komplet kig på CI / CD ligger uden for denne artikels anvendelsesområde - se forklareren om emnet - men vi er nødt til at sige et par ord om CI / CD, fordi det er kernen i, hvordan GitOps fungerer. Det kontinuerlig integration halvdelen af CI / CD er aktiveret af versionskontrol repositories som Git: Udviklere kan foretage konstante små forbedringer af deres codebase snarere end at udrulle store, monolitiske nye versioner hvert par måneder eller år. Det kontinuerlig implementering stykke er muliggjort af automatiserede kaldte systemer rørledninger der bygger, tester og implementerer den nye kode til produktion.
Igen fortsætter vi med at tale om kode her, og som normalt indkalder syner af eksekverbar kode skrevet på et programmeringssprog som C eller Java eller JavaScript. Men i GitOps består den "kode", vi administrerer, stort set af konfigurationsfiler. Dette er ikke kun en mindre detalje - det er kernen i, hvad GitOps gør. Disse konfigurationsfiler er, som vi har sagt, den "eneste kilde til sandhed", der beskriver, hvordan vores system skal se ud. De er erklærende snarere end lærerigt. Det betyder, at i stedet for at sige "start ti servere", vil konfigurationsfilen blot sige, "dette system indeholder ti servere."
Det CI halvdelen af GitOps-ligningen giver udviklere mulighed for hurtigt at udrulle justeringer og forbedringer af disse konfigurationsfiler; det CD halvdelen sker, når automatiserede softwareagenter gør deres bedste for at sikre, at liveversionen af applikationen afspejler beskrivelserne i konfigurationsfilerne - at den konvergerer til den deklarative model på GitOps sprog.
GitOps og Kubernetes
Som vi har nævnt, blev begreberne GitOps oprindeligt udviklet omkring styring af Kubernetes-applikationer. Med det, vi nu ved om GitOps, lad os besøge Weaveworks 'GitOps-diskussion igen og se, hvordan de beskriver, hvordan du foretager opdateringer til en Kubernetes, der administreres efter GitOps-principper. Her er en oversigt:
- En udvikler fremsætter en Git pull-anmodning om en ny funktion.
- Koden gennemgås og godkendes og flettes derefter ind i hovedkodebasen.
- Fusionen udløser CI / CD-pipelinen, som automatisk tester og genopbygger den nye kode og distribuerer den til et register.
- En softwareagent bemærker opdateringen, trækker den nye kode fra registreringsdatabasen og opdaterer konfigurationsfilen (skrevet i YAML) i konfigurationsregistret.
- En softwareagent i Kubernetes-klyngen registrerer, at klyngen er forældet, baseret på konfigurationsfilen, trækker ændringerne og implementerer den nye funktion.
Weaveworks og GitOps
Det er klart, at trin 4 og 5 her gør meget af det tunge løft. Softwareagenterne, der magisk synkroniserer ”sandhedskilden” i Git-arkivet med den virkelige verden Kubernetes-applikationen, er den magi, der gør GitOps mulig. Som vi har sagt, kaldes processen med at gøre live-systemer mere som de ideelle systemer, der er beskrevet i konfigurationsfiler, i GitOps-termer konvergens. (Når live-systemet og det ideelle system ikke er synkroniseret, er det divergens.) Ideelt set ville konvergens opnås ved automatiserede processer, men der er grænser for, hvad automatisering kan gøre, og undertiden er menneskelig intervention nødvendig.
Vi har beskrevet processen her i generiske termer, men hvis du faktisk kigger på Weaveworks 'side, er de "softwareagenter", vi nævnte, en del af virksomhedens Weave Cloud-platform. Udtrykket "GitOps" blev opfundet af Weaveworks CEO Alexis Richardson, og det tjener dels til at gøre Weaveworks platformen tiltalende for udviklere, der allerede er gennemsyret af devops og CI / CD verdener.
Men Weaveworks har aldrig hævdet monopol på GitOps, hvilket er mere en filosofi og et sæt af bedste praksis end et specifikt produkt. Som bloggen for CloudBees, et firma, der leverer CI / CD-løsninger, bemærker, repræsenterer GitOps en åben, sælgerneutral model, der blev udviklet som reaktion på administrerede proprietære Kubernetes-løsninger, der blev rullet ud af store cloud-leverandører som Amazon, Google og Microsoft . CloudBees tilbyder sine egne GitOps-løsninger, ligesom et antal spillere i dette rum gør.
GitOps og devops
Atlassian, et firma, der fremstiller en række værktøjer til smidige udviklere, har et dybtgående blogindlæg om historien og formålet med GitOps, der er din tid værd. Efter deres opfattelse repræsenterer GitOps en logisk udvidelse af de ideer, der kom sammen som devops. Specifikt er GitOps en uddybning af begrebet infrastruktur som kode, i sig selv en idé, der kom ud af devops-miljøet. GitOps, som Atlassian ser det, broede den afgørende kløft mellem eksisterende devops-teknikker, som havde udviklet sig til at løse problemer med systemadministration og de specifikke behov for distribuerede cloud-hosting-applikationer. Den automatiserede konvergens, der tilbydes af forskellige cloud-leverandører, gør GitOps speciel.
Og mens GitOps fortsat er fokuseret på Kubernetes i dag, håber vi, at vi har gjort det klart, hvordan det gælder for den meget bredere verden af distribuerede, skybaserede apps. Et blogindlæg fra open source-sikkerhedsleverandøren WhiteSource skitserer fordelene ved GitOps:
- Observerbarhed: GitOps-systemer tilbyder overvågning, logning, sporing og visualisering i komplekse applikationer, så udviklere kan se, hvad der går i stykker, og hvor.
- Versionskontrol og ændringsstyring: Dette er åbenlyst en vigtig fordel ved at bruge et versionskontrolsystem som Git. Fejlagtige opdateringer kan let rulles tilbage.
- Let vedtagelse: GitOps bygger på devops-færdigheder, som mange udviklere allerede har.
- Produktivitet: GitOps giver boost til produktivitet, som devops og CI / CD har bragt til andre områder.
- Revision: Takket være Git kan hver handling spores til en bestemt forpligtelse, hvilket gør det let at spore årsagen til fejl.
Selvom du ikke bruger Kubernetes, er chancerne gode, at GitOps vil være en del af din arbejdsgang før eller senere.
