Det siste tiåret med programmering har sett en rekke revolusjonerende transformasjoner. En har oppstått fra en klynge av praksis rundt devops, som justerer utviklings- og operasjonsteam i en delt arbeidsprosess, og kontinuerlig integrering og kontinuerlig levering (CI / CD), der devops-team leverer kontinuerlige trinnvise oppdateringer til en kodebase. En annen transformasjon har kommet fra den relaterte bevegelsen fra monolitiske kodebaser til skybaserte mikrotjenester som kjører i containere som administreres av orkestrasjonsplattformer som Kubernetes.
Containerbaserte applikasjoner som kjører på klyngede systemer eller i skyen, kan være komplekse og vanskelige å skaffe og administrere, selv med en plattform som Kubernetes som orkestrerer ting. GitOps er et voksende sett med praksis som tar sikte på å forenkle denne administrasjonsoppgaven ved å bruke teknikker fra devops-verdener og CI / CD.
Nøkkelen til GitOps er ideen om infrastruktur som kode, som tar samme tilnærming til klargjøring av infrastruktur som devops bruker for å levere applikasjoner. Så ikke bare applikasjonen, men også de underliggende vertsmaskiner og nettverk er beskrevet i filer som kan behandles som hvilken som helst annen kode i et versjonskontrollsystem, med automatiserte prosesser som deretter arbeider for å konvergere den virkelige applikasjonen med den som er beskrevet i de filer.
I GitOps-språket er koden i versjonskontrollsystemet én kilde til sannhet om hvordan applikasjonen skal se ut i produksjonen.
GitOps definert
Weaveworks er selskapet som har gjort mest for å popularisere konseptet GitOps. Vi vil gå nærmere inn på detaljene i Weaveworks rolle, men la oss først se på selskapets definisjon av GitOps, som er todelt:
- En driftsmodell for Kubernetes og andre cloud native-teknologier, som gir et sett med beste praksis som forener distribusjon, administrasjon og overvåking av containeriserte klynger og applikasjoner.
- En vei mot en utvikleropplevelse for administrering av applikasjoner; der end-to-end CI / CD-rørledninger og Git-arbeidsflyter brukes på både drift og utvikling.
Med andre ord er GitOps et spesifikt sett med praksis designet for å administrere Kubernetes og lignende plattformer, som også gir seg muligheten for en bredere applikasjon ettersom flere og flere utviklingsbutikker vedtar devops-praksis og migrerer kode til skyen. Men for å forstå den hemmelige sausen til GitOps og problemene den løser, må vi snakke om komponentene som går inn i den.
Git definisjon
De Git i GitOps refererer til det veldig populære distribuerte versjonskontrollsystemet utviklet av Linus Torvalds i 2005. Git er et verktøy som lar team av utviklere jobbe sammen om en applikasjonskodebase, og lagre forskjellige grener av kode som de tukler med før de slås sammen til produksjonskode. Et sentralt konsept innen Git er trekk forespørsel, der en utvikler formelt ber om en kode de har jobbet med for å bli integrert i en annen gren innen kodebasen.
En Git pull-forespørsel gir teammedlemmer en mulighet til å samarbeide og diskutere før de når konsensus om den nye koden skal legges til i applikasjonen. Git lagrer også eldre versjoner av kode, noe som gjør det enkelt å falle tilbake til den siste gode versjonen hvis noe går galt, og lar deg raskt se hva som er endret mellom revisjonene. Git kan være best kjent som understøttelsen av GitHub, et skyhostet versjonskontrollsystem, men Git i seg selv er programvare med åpen kildekode som kan distribueres hvor som helst, fra interne bedriftsservere til din PC.
Vær oppmerksom på at mens vi vanligvis tenker på Git som et dataprogrammeringsverktøy, er det faktisk agnostisk for hvilket innhold du bruker det til. Git vil med glede behandle ethvert sett med tekstfiler som din "kodebase", og den kan for eksempel brukes av forfattere som ønsker å holde rede på endringer i et samarbeidsarbeid. Dette er viktig fordi mye av kodebasen i kjernen av GitOps består av deklarative konfigurasjonsfiler i stedet for kjørbar kode.
En siste ting å si før vi går videre: Til tross for at "Git" er der i navnet, krever GitOps faktisk ikke bruk av Git. Butikker som allerede er investert i annen versjonskontrollprogramvare, for eksempel Subversion, kan også implementere GitOps. Men Git er mye brukt i devops-verdenen for å implementere CI / CD, så de fleste GitOps-prosjekter vil ende opp med å bruke Git.
Hva er CI / CD-prosessen?
En fullstendig titt på CI / CD ligger utenfor omfanget av denne artikkelen - se forklareren om emnet - men vi må si noen ord om CI / CD fordi det er kjernen i hvordan GitOps fungerer. De kontinuerlig integrering halvparten av CI / CD er aktivert av versjonskontrollregister som Git: Utviklere kan gjøre konstant små forbedringer av kodebasen, i stedet for å rulle ut store, monolitiske nye versjoner noen få måneder eller år. De kontinuerlig distribusjon stykke er mulig med automatiserte systemer kalt rørledninger som bygger, tester og distribuerer den nye koden til produksjon.
Igjen fortsetter vi å snakke om kode her, og som vanligvis innkaller visjoner av kjørbar kode skrevet på et programmeringsspråk som C eller Java eller JavaScript. Men i GitOps består "koden" vi i stor grad består av konfigurasjonsfiler. Dette er ikke bare en mindre detalj - det er kjernen i det GitOps gjør. Disse konfigurasjonsfilene er, som vi har sagt, "den eneste kilden til sannheten" som beskriver hvordan systemet vårt skal se ut. De er erklærende heller enn lærerikt. Det betyr at i stedet for å si "start opp ti servere", vil konfigurasjonsfilen bare si "dette systemet inkluderer ti servere."
De CI halvparten av GitOps-ligningen lar utviklere raskt rulle ut tilpasninger og forbedringer av disse konfigurasjonsfilene; de CD halvparten skjer når automatiserte programvareagenter gjør sitt beste for å sikre at liveversjonen av applikasjonen speiler beskrivelsene i konfigurasjonsfilene - at den konvergerer til den deklarative modellen, på språket til GitOps.
GitOps og Kubernetes
Som vi har nevnt, ble konseptene til GitOps opprinnelig utviklet rundt administrering av Kubernetes-applikasjoner. Med det vi nå vet om GitOps, la oss se på Weaveworks 'GitOps-diskusjon og se hvordan de beskriver hvordan du vil gjøre oppdateringer til en Kubernetes som administreres på GitOps-prinsipper. Her er et sammendrag:
- En utvikler gjør en Git pull-forespørsel om en ny funksjon.
- Koden blir gjennomgått og godkjent, og deretter slått sammen til hovedkodebasen.
- Sammenslåingen utløser CI / CD-rørledningen, som automatisk tester og bygger om den nye koden og distribuerer den til et register.
- En programvareagent legger merke til oppdateringen, henter den nye koden fra registeret og oppdaterer konfigurasjonsfilen (skrevet i YAML) i konfigurasjonsdatabasen.
- En programvareagent i Kubernetes-klyngen oppdager at klyngen er utdatert, basert på konfigurasjonsfilen, trekker endringene og distribuerer den nye funksjonen.
Weaveworks og GitOps
Klart trinn 4 og 5 her gjør mye av det tunge løftet. Programvareagentene som magisk synkroniserer "sannhetskilden" i Git-arkivet med den virkelige Kubernetes-applikasjonen, er magien som gjør GitOps mulig. Som vi har sagt, i GitOps-termer kalles prosessen med å gjøre live-systemer mer som de ideelle systemene beskrevet i konfigurasjonsfiler. konvergens. (Når live-systemet og det ideelle systemet ikke er synkronisert, er det divergens.) Ideelt sett ville konvergens oppnås ved automatiserte prosesser, men det er grenser for hva automatisering kan gjøre, og noen ganger er menneskelig inngripen nødvendig.
Vi har beskrevet prosessen her i generelle termer, men hvis du faktisk ser på Weaveworks 'side, er "programvareagenter" vi nevnte en del av selskapets Weave Cloud-plattform. Begrepet "GitOps" ble laget av Weaveworks administrerende direktør Alexis Richardson, og det tjener delvis til å gjøre Weaveworks-plattformen tiltalende for utviklere som allerede er gjennomsyret av devops og CI / CD-verdener.
Men Weaveworks har aldri hevdet monopol på GitOps, som er mer en filosofi og et sett med beste praksis enn et bestemt produkt. Som bloggen for CloudBees, et selskap som tilbyr CI / CD-løsninger, bemerker, representerer GitOps en åpen, leverandørnøytral modell som ble utviklet som reaksjon på administrerte proprietære Kubernetes-løsninger som ble rullet ut av store skyleverandører som Amazon, Google og Microsoft. . CloudBees tilbyr sine egne GitOps-løsninger, det samme gjør en rekke spillere i dette rommet.
GitOps og devops
Atlassian, et selskap som lager en rekke verktøy for smidige utviklere, har et grundig blogginnlegg om historien og formålet med GitOps som er verdt tiden din. Etter deres syn representerer GitOps en logisk utvidelse av ideene som kom sammen som devops. Spesielt er GitOps en utdyping av begrepet infrastruktur som kode, i seg selv en idé som kom ut av devops-miljøet. GitOps, som Atlassian ser det, broet det avgjørende gapet mellom eksisterende devops-teknikker, som hadde utviklet seg for å løse problemer med systemadministrasjon, og de spesifikke behovene til distribuerte, cloud-hosting-applikasjoner. Den automatiserte konvergensen som tilbys av forskjellige skyleverandører, er det som gjør GitOps spesiell.
Og mens GitOps fortsatt er fokusert på Kubernetes i dag, håper vi at vi har gjort det klart hvordan det gjelder den mye bredere verden av distribuerte, skybaserte apper. Et blogginnlegg fra sikkerhetsleverandøren av åpen kildekode WhiteSource skisserer fordelene med GitOps:
- Observerbarhet: GitOps-systemer tilbyr overvåking, logging, sporing og visualisering i komplekse applikasjoner, slik at utviklere kan se hva som går i stykker og hvor.
- Versjonskontroll og endringsledelse: Dette er åpenbart en viktig fordel ved å bruke et versjonskontrollsystem som Git. Feiloppdateringer kan lett rulles tilbake.
- Enkel adopsjon: GitOps bygger på devops-ferdighetene mange utviklere allerede har.
- Produktivitet: GitOps gir produktiviteten som devops og CI / CD har ført til andre riker.
- Revisjon: Takket være Git kan hver handling spores til en bestemt forpliktelse, noe som gjør det enkelt å spore årsaken til feil.
Selv om du ikke bruker Kubernetes, er sjansen god for at GitOps vil være en del av arbeidsflyten din før eller senere.
