{"id":35941,"date":"2019-10-31T22:07:41","date_gmt":"2019-10-31T19:07:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-zhe-takoe-gitops\/"},"modified":"2019-10-31T22:07:41","modified_gmt":"2019-10-31T19:07:41","slug":"chto-zhe-takoe-gitops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/chto-zhe-takoe-gitops","title":{"rendered":"Hva er GitOps?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Obs. overs.<\/b>: Etter den nylige publikasjonen av materialet<\/a><\/noindex> om pull- og push-metodene i GitOps, har vi sett interesse for denne modellen som helhet, men det er sv\u00e6rt f\u00e5 publikasjoner om dette p\u00e5 russisk (de finnes rett og slett ikke p\u00e5 Habr). Derfor er vi glade for \u00e5 tilby dere oversettelsen av en annen artikkel \u2013 selv om den er nesten ett \u00e5r gammel! \u2013 fra selskapet Weaveworks, som er kjent for \u00e5 ha funnet opp termen \u00abGitOps\u00bb. I teksten forklares kjernen i tiln\u00e6rmingen og de viktigste forskjellene fra allerede eksisterende.<\/i><\/p>\n

\nFor ett \u00e5r siden publiserte vi en introduksjon til GitOps<\/a><\/noindex>. Den gang fortalte vi hvordan Weaveworks-teamet lanserte en SaaS fullstendig basert p\u00e5 Kubernetes, og utviklet et sett med foreskrivende beste praksiser for distribusjon, styring og overv\u00e5king i et cloud native-milj\u00f8.<\/a><\/noindex><\/p>\n

Artikkelen viste seg \u00e5 v\u00e6re popul\u00e6r. Andre begynte \u00e5 snakke om GitOps og publiserte nye verkt\u00f8y for git push<\/a><\/noindex>, utvikling<\/a><\/noindex>, av hemmeligheter<\/a><\/noindex>, funksjoner<\/a><\/noindex>, kontinuerlig integrasjon<\/a><\/noindex> osv. P\u00e5 nettstedet v\u00e5rt dukket det opp et stort antall<\/a><\/noindex> publikasjoner og bruksomr\u00e5der for GitOps. Men noen mennesker hadde fortsatt sp\u00f8rsm\u00e5l. Hva skiller modellen fra tradisjonell infrastructure as code<\/a><\/noindex> og kontinuerlig levering (continuous delivery<\/a><\/noindex>)? Er det n\u00f8dvendig \u00e5 bruke Kubernetes?<\/p>\n

Snart inns\u00e5 vi at et nytt beskrivende dokument var n\u00f8dvendig, som tilb\u00f8d:<\/p>\n

    \n
  1. Et stort antall eksempler og historier;<\/li>\n
  2. En konkret definisjon av GitOps;<\/li>\n
  3. Sammenligning med tradisjonell kontinuerlig levering.<\/li>\n<\/ol>\n

    \nI denne artikkelen har vi pr\u00f8vd \u00e5 dekke alle disse temaene. Du vil finne en oppdatert introduksjon til GitOps og et perspektiv p\u00e5 det fra utviklerne og CI\/CD. Vi fokuserer hovedsakelig p\u00e5 Kubernetes, selv om modellen kan generaliseres.<\/p>\n

    M\u00f8t: GitOps<\/h2>\n

    \nTenk deg Alice. Hun driver selskapet Family Insurance, som tilbyr helse-, bil-, eiendom- og reiseforsikring til folk som er for opptatt til \u00e5 h\u00e5ndtere detaljene i kontraktene selv. Forretningen hennes begynte som et sideprosjekt da Alice jobbet i banken som data scientist. En dag inns\u00e5 hun at hun kunne bruke avanserte datamaskinalgoritmer for mer effektiv datanalyse og tilpasning av forsikringspakker. Investorer finansierte prosjektet, og n\u00e5 genererer selskapet hennes over 20 millioner dollar \u00e5rlig og vokser raskt. Per n\u00e5 arbeider 180 personer i ulike stillinger i selskapet. Blant dem er det et teknologiteam som driver utviklingen, vedlikeholdet av nettstedet, databasen, og analyserer kundegrunnlaget. Teamet p\u00e5 60 personer ledes av Bob \u2013 selskapets tekniske direkt\u00f8r.<\/p>\n

    Bobs team distribuerer produksjonssystemer i skyen. Deres hovedapplikasjoner kj\u00f8rer p\u00e5 GKE, og drar nytte av Kubernetes i Google Cloud. I tillegg benytter de seg av ulike verkt\u00f8y for databehandling og analyse.<\/p>\n

    Familieforsikring hadde ikke tenkt \u00e5 bruke containere, men ble smittet av entusiasmen rundt Docker. Snart oppdaget selskapets spesialister at GKE gj\u00f8r det enkelt og uanstrengt \u00e5 rulle ut klynger for testing av nye funksjoner. Jenkins ble lagt til for CI, og Quay for organisering av containerregisteret, og skripter ble skrevet for Jenkins som pusher nye containere og konfigurasjoner til GKE.<\/p>\n

    Det gikk en tid. Alice og Bob ble skuffet over ytelsen til den valgte tiln\u00e6rmingen og dens innvirkning p\u00e5 forretningen. Innf\u00f8ringen av containere hadde ikke forbedret ytelsen s\u00e5 mye som teamet hadde h\u00e5pet. Noen ganger feilet deploymentene, og det var uklart om endringer i koden var \u00e5rsaken. Det viste seg ogs\u00e5 \u00e5 v\u00e6re vanskelig \u00e5 spore endringer i konfigurasjoner. De m\u00e5tte ofte opprette en ny klynge og flytte applikasjoner dit, fordi det var enklest \u00e5 rydde opp i rotet systemet hadde blitt. Alice fryktet at situasjonen ville forverres etter hvert som applikasjonen utviklet seg (i tillegg var det et nytt prosjekt basert p\u00e5 maskinl\u00e6ring i emning). Bob automatiserte mesteparten av arbeidet og kunne ikke forst\u00e5 hvorfor pamplinen fortsatt var ustabil, vanskelig \u00e5 skalere og tidvis krevde manuell inngripen.<\/p>\n

    S\u00e5 l\u00e6rte de om GitOps. Denne l\u00f8sningen viste seg \u00e5 v\u00e6re akkurat det de trengte for \u00e5 bevege seg trygt fremover.<\/b><\/p>\n

    Alice og Bob hadde h\u00f8rt om Git-baserte arbeidsprosesser, DevOps og infrastruktur som kode i flere \u00e5r. Det unike med GitOps er at det bringer inn en rekke beste praksiser - kategoriske og normative - for implementering av disse ideene i konteksten av Kubernetes. Dette temaet har blitt tatt opp flere ganger<\/a><\/noindex>, inkludert i Weaveworks bloggen<\/a><\/noindex>.<\/p>\n

    Family Insurance bestemmer seg for \u00e5 implementere GitOps. N\u00e5 har selskapet en automatisert driftsmodell som er kompatibel med Kubernetes og kombinerer hastighet<\/i> med stabilitet<\/i>, ettersom de:<\/p>\n