Wat ass GitOps?

Note. iwwersat.: No enger rezenter Publikatioun Material iwwer Pull- a Push-Methoden an GitOps, hu mir Interessi un dësem Modell am Allgemengen gesinn, awer et waren ganz wéineg russeschsproocheg Publikatiounen iwwer dëst Thema (et ginn einfach keng op Habré). Dofir si mir frou Iech eng Iwwersetzung vun engem aneren Artikel ze bidden - wann och virun bal engem Joer! - vu Weaveworks, de Chef vun deem de Begrëff "GitOps" entwéckelt huet. Den Text erkläert d'Essenz vun der Approche a Schlëssel Differenzen aus existéierenden.

Virun engem Joer hu mir publizéiert Aféierung zu GitOps. Deemools hu mir gedeelt wéi d'Weaveworks Team e SaaS ganz baséiert op Kubernetes lancéiert huet an eng Rei vu preskriptive Best Practices entwéckelt huet fir z'installéieren, ze managen an ze iwwerwaachen an engem Cloud-native Ëmfeld.

Den Artikel huet sech populär gewisen. Aner Leit hunn ugefaang iwwer GitOps ze schwätzen an hunn ugefaang nei Tools fir ze publizéieren Gitt Drécken, Entwécklung vu, Geheimnisser, Funktiounen, kontinuéierlech Integratioun a sou weider. Op eiser Websäit opgetaucht eng grouss Zuel Publikatiounen a GitOps Benotzungsfäll. Awer e puer Leit hunn nach ëmmer Froen. Wéi ënnerscheet de Modell vun der traditioneller? Infrastruktur als Code a kontinuéierlech Liwwerung (kontinuéierlech Liwwerung)? Ass et néideg Kubernetes ze benotzen?

Mir hu séier gemierkt datt eng nei Beschreiwung gebraucht gouf, bitt:

  1. Eng grouss Zuel vu Beispiller a Geschichten;
  2. Spezifesch Definitioun vu GitOps;
  3. Verglach mat traditionell kontinuéierlech Liwwerung.

An dësem Artikel hu mir probéiert all dës Themen ze decken. Et bitt eng aktualiséiert Aféierung zu GitOps an eng Entwéckler an CI / CD Perspektiv. Mir konzentréieren eis haaptsächlech op Kubernetes, obwuel de Modell generaliséiert ka ginn.

Trefft GitOps

Stellt Iech d'Alice vir. Si bedreift Family Insurance, déi Gesondheets-, Auto-, Heem- a Reesversécherung u Leit ubitt, déi ze beschäftegt sinn fir d'Ins an Outs vu Kontrakter selwer erauszefannen. Hir Geschäft huet als Säiteprojet ugefaang wéi d'Alice bei enger Bank als Datewëssenschaftler geschafft huet. Enges Daags huet si gemierkt datt si fortgeschratt Computeralgorithmen benotze kéint fir Daten méi effektiv ze analyséieren an Versécherungspakete ze formuléieren. Investisseuren hunn de Projet finanzéiert, an elo bréngt hir Firma méi wéi $ 20 Milliounen d'Joer an a wiisst séier. De Moment beschäftegt et 180 Leit a verschiddene Positiounen. Dëst beinhalt en Technologieteam dat d'Websäit, d'Datebank entwéckelt, ënnerhält an d'Clientbasis analyséiert. D'Equipe vu 60 Leit gëtt geleet vum Bob, dem techneschen Direkter vun der Firma.

Dem Bob seng Equipe setzt Produktiounssystemer an der Cloud of. Hir Kärapplikatiounen lafen op GKE, profitéiere vu Kubernetes op Google Cloud. Zousätzlech benotze se verschidden Daten an Analyseinstrumenter an hirer Aarbecht.

D'Family Insurance huet sech net op d'Been gestallt fir Container ze benotzen, mä ass an der Docker Begeeschterung agefaangen. D'Firma huet séier entdeckt datt GKE et einfach an einfach gemaach huet Cluster z'installéieren fir nei Features ze testen. Jenkins fir CI a Quay goufe bäigefüügt fir de Containerregister z'organiséieren, Scripte goufen fir Jenkins geschriwwen déi nei Container a Konfiguratiounen op GKE gedréckt hunn.

Eng Zäit ass vergaangen. D'Alice an de Bob waren enttäuscht mat der Leeschtung vun hirer gewielter Approche an hiren Impakt op d'Geschäft. D'Aféierung vu Container huet d'Produktivitéit net sou vill verbessert wéi d'Equipe gehofft hat. Heiansdo géifen Deployementer briechen, an et war onkloer ob Code Ännerungen d'Schold waren. Et huet sech och schwéier gewisen Configuratiounsännerungen ze verfolgen. Dacks war et néideg en neie Cluster ze kreéieren an Uwendungen dohinner ze réckelen, well dëst deen einfachste Wee war fir de Chaos ze eliminéieren deen de System gouf. D'Alice huet Angscht datt d'Situatioun verschlechtert gëtt wéi d'Applikatioun entwéckelt (ausserdeem gouf en neie Projet baséiert op Maschinnléiere gebrach). De Bob hat de gréissten Deel vun der Aarbecht automatiséiert an huet net verstan firwat d'Pipeline nach ëmmer onbestänneg war, net gutt skaléiert an periodesch manuell Interventioun erfuerdert?

Dunn hunn se iwwer GitOps geléiert. Dës Entscheedung huet sech genee erausgestallt wat se gebraucht hunn fir zouversiichtlech no vir ze goen.

Alice a Bob hunn iwwer Git, DevOps, an Infrastruktur als Code Workflows fir Joeren héieren. Wat eenzegaarteg ass iwwer GitOps ass datt et eng Rei vu beschten Praktiken bréngt - souwuel definitiv wéi normativ - fir dës Iddien am Kontext vu Kubernetes ëmzesetzen. Dëst Thema ëmmer erëm opgestan, dorënner an Weaveworks Blog.

Family Insurance decidéiert GitOps ëmzesetzen. D'Firma huet elo en automatiséierten Operatiounsmodell dee kompatibel ass mat Kubernetes a Kombinatiounen Vitesse mat Stabilitéitwell si:

  • fonnt datt d'Produktivitéit vum Team verduebelt huet ouni datt iergendeen verréckt ass;
  • opgehalen Scripten ze déngen. Amplaz, kënnen se elo op nei Fonctiounen konzentréieren an Déifbau Methoden verbesseren - zum Beispill, Aféierung Kanareschäin Rollouts a verbesseren Testen;
  • mir hunn den Détachement Prozess verbessert sou datt et selten brécht;
  • krut d'Méiglechkeet d'Deployementer no deelweis Feeler ouni manuell Interventioun ze restauréieren;
  • kaaft benotztоMéi Vertrauen an Liwwersystemer. D'Alice an de Bob hunn entdeckt datt se d'Team an d'Mikroservice-Teams opgedeelt hunn, déi parallel schaffen;
  • kann 30-50 Ännerungen am Projet all Dag duerch d'Efforte vun all Grupp maachen an nei Techniken probéieren;
  • et ass einfach nei Entwéckler un de Projet unzezéien, déi d'Méiglechkeet hunn Updates fir d'Produktioun mat Pull-Ufroen bannent e puer Stonnen auszerollen;
  • einfach Audit am Kader vum SOC2 passéieren (fir d'Konformitéit vun den Déngschtleeschter mat Ufuerderunge fir sécher Datemanagement; méi liesen, zum Beispill, hei — ca. Iwwersetzung).

Wat ass geschitt?

GitOps ass zwou Saachen:

  1. Operatiounsmodell fir Kubernetes a Cloud Native. Et bitt eng Rei vu beschten Praktiken fir d'Deploy, d'Gestioun an d'Iwwerwaachung vu containeriséierte Cluster an Uwendungen. Elegant Definitioun an der Form eng Rutsch от Luis Faceira:
  2. De Wee fir en Entwéckler-centric Applikatiounsmanagement Ëmfeld ze kreéieren. Mir applizéieren de Git Workflow fir Operatiounen an Entwécklung. Notéiert w.e.g. datt dëst net nëmmen iwwer Git Push ass, mee iwwer d'Organisatioun vum ganze Set vun CI / CD an UI / UX Tools.

E puer Wierder iwwer Git

Wann Dir net mat Versiounskontrollsystemer a Git-baséiert Workflow vertraut sidd, empfeelen mir Iech iwwer si ze léieren. Schafft mat Filialen a Pull-Ufroen kann am Ufank wéi schwaarz Magie schéngen, awer d'Virdeeler sinn den Effort wäert. Hei gudden Artikel ufänken.

Wéi Kubernetes funktionnéiert

An eiser Geschicht hunn d'Alice an de Bob sech op GitOps gedréit nodeems se eng Zäit laang mat Kubernetes geschafft hunn. Tatsächlech ass GitOps enk verbonne mat Kubernetes - et ass en operationelle Modell fir Infrastruktur an Uwendungen baséiert op Kubernetes.

Wat gëtt de Kubernetes Benotzer?

Hei sinn e puer Haaptfeatures:

  1. Am Kubernetes Modell kann alles an deklarativ Form beschriwwe ginn.
  2. De Kubernetes API Server hëlt dës Deklaratioun als Input a probéiert dann kontinuéierlech de Cluster an den Zoustand ze bréngen, deen an der Deklaratioun beschriwwe gëtt.
  3. Deklaratioune si genuch fir eng breet Varietéit vun Aarbechtsbelaaschtungen ze beschreiwen an ze verwalten - "Applikatiounen."
  4. Als Resultat entstinn Ännerungen un der Applikatioun a Cluster wéinst:
    • Ännerungen am Container Biller;
    • Ännerungen an der deklarativ Spezifizéierung;
    • Feeler an der Ëmwelt - zum Beispill, Container Crash.

Kubernetes 'Grouss Konvergenzfäegkeeten

Wann en Administrateur Konfiguratiounsännerungen mécht, wäert de Kubernetes Orchester se op de Cluster uwenden soulaang säi Staat ass wäert kommen net no bei der neier Configuratioun. Dëse Modell funktionnéiert fir all Kubernetes Ressource an ass erweiderbar mat Custom Resource Definitions (CRDs). Dofir hunn Kubernetes Deployment déi folgend wonnerbar Eegeschaften:

  • Automatioun: Kubernetes Updates bidden e Mechanismus fir de Prozess fir d'Ännerunge graziéis an fristgerecht z'applizéieren ze automatiséieren.
  • Konvergenz: Kubernetes wäert weider Aktualiséierungen probéieren bis erfollegräich.
  • Idempotenz: Widderholl Uwendungen vun der Konvergenz féieren zum selwechte Resultat.
  • Determinismus: Wann Ressourcen genuch sinn, hänkt den Zoustand vum aktualiséierte Stärekoup nëmmen vum gewënschten Zoustand of.

Wéi GitOps funktionnéiert

Mir hu genuch iwwer Kubernetes geléiert fir z'erklären wéi GitOps funktionnéiert.

Komme mer zréck op d'Mikroservicer Teams vun der Family Insurance. Wat musse se normalerweis maachen? Kuckt d'Lëscht hei drënner (wann iergendeng Elementer dran komesch oder onbekannt schéngen, haalt w.e.g. op d'Kritik a bleift bei eis). Dëst si just Beispiller vu Jenkins baséiert Workflows. Et gi vill aner Prozesser wann Dir mat aneren Tools schafft.

Den Haapt Saach ass datt mir gesinn datt all Update mat Ännerungen un de Konfiguratiounsdateien a Git Repositories endet. Dës Ännerungen op Git verursaachen datt den "GitOps Bedreiwer" de Cluster aktualiséieren:

1. Aarbechtsprozess: "Jenkins bauen - Meeschtesch Branche".
Aufgab Lëscht:

  • Jenkins dréckt tagged Biller op Quay;
  • Jenkins dréckt Configuratioun an Helm Charts op de Master-Späichereem;
  • D'Wollekfunktioun kopéiert d'Konfiguratioun an d'Charts vum Master-Späichereemer an de Master Git Repository;
  • De GitOps Bedreiwer aktualiséiert de Cluster.

2. Jenkins bauen - Fräisetzung oder Hotfix Branche:

  • Jenkins dréckt untagged Biller op Quay;
  • Jenkins dréckt Configuratioun an Helm Charts op d'Staging Späichereimer;
  • D'Wollekfunktioun kopéiert d'Konfiguratioun an d'Charts vum Staging-Späichereemer an de Staging Git Repository;
  • De GitOps Bedreiwer aktualiséiert de Cluster.

3. Jenkins bauen - entwéckelen oder Feature Branche:

  • Jenkins dréckt untagged Biller op Quay;
  • Jenkins dréckt Configuratioun an Helm Charts an den Entwéckler Späichereimer;
  • D'Wollekfunktioun kopéiert d'Konfiguratioun an d'Charts vum Entwécklungsspeicher Eemer an d'Entwécklung Git Repository;
  • De GitOps Bedreiwer aktualiséiert de Cluster.

4. En neie Client derbäi:

  • De Manager oder Administrator (LCM / ops) rifft Gradle fir ursprénglech Netzwierklastbalancer (NLBs) z'installéieren an ze konfiguréieren;
  • LCM / ops engagéiert eng nei Configuratioun fir d'Deployment op Updates virzebereeden;
  • De GitOps Bedreiwer aktualiséiert de Cluster.

Kuerz Beschreiwung vu GitOps

  1. Beschreift de gewënschten Zoustand vum ganze System mat deklarativen Spezifikatioune fir all Ëmfeld (an eiser Geschicht definéiert dem Bob seng Equipe déi ganz Systemkonfiguratioun am Git).
    • De Git Repository ass déi eenzeg Quell vun der Wourecht iwwer de gewënschten Zoustand vum ganze System.
    • All Ännerungen am gewënschten Zoustand ginn duerch Verpflichtungen am Git gemaach.
    • All gewënschte Clusterparameter sinn och am Cluster selwer beobachtbar. Op dës Manéier kënne mir bestëmmen ob se zesummekommen (konvergéieren, konvergéieren) oder ënnerscheeden (divergéieren, divergéieren) gewënschte an observéierte Staaten.
  2. Wann déi gewënscht an observéiert Staaten ënnerscheeden, dann:
    • Et gëtt e Konvergenzmechanismus, dee fréier oder spéider automatesch d'Zil an d'observéiert Staaten synchroniséiert. Am Cluster mécht Kubernetes dëst.
    • De Prozess fänkt direkt mat enger "Ännerung engagéiert" Alarm un.
    • No e puer konfiguréierbaren Zäitraum kann eng "diff" Alarm geschéckt ginn wann d'Staaten anescht sinn.
  3. Op dës Manéier verursaache all Verpflichtungen am Git verifizéierbar an idempotent Updates am Cluster.
    • Rollback ass Konvergenz zu engem virdru gewënschten Zoustand.
  4. D'Konvergenz ass definitiv. Seng Optriede gëtt duerch:
    • Keng Diff Alarmer fir eng gewëssen Zäit.
    • "konvergéiert" Alarm (zB Webhook, Git Writeback Event).

Wat ass Divergenz?

Loosst eis nach eng Kéier widderhuelen: all gewënschte Stärekoup Eegeschafte muss am Stärekoup selwer beobachtbar ginn.

E puer Beispiller vun Divergenz:

  • Ännerung an der Konfiguratiounsdatei wéinst Fusiounszweige am Git.
  • Eng Ännerung an der Konfiguratiounsdatei wéinst engem Git Verpflichtung vum GUI Client.
  • Multiple Ännerungen un de gewënschten Zoustand wéinst PR am Git gefollegt vum Bau vum Containerbild a Konfiguratiounsännerungen.
  • Eng Ännerung vum Zoustand vum Stärekoup wéinst engem Feeler, Ressourcekonflikt, deen zu "schlecht Verhalen" resultéiert, oder einfach zoufälleg Ofwäichung vum Originalzoustand.

Wat ass de Mechanismus vun der Konvergenz?

E puer Beispiller:

  • Fir Container a Cluster gëtt de Konvergenzmechanismus vu Kubernetes geliwwert.
  • Dee selwechte Mechanismus ka benotzt ginn fir Kubernetes-baséiert Uwendungen an Designen ze managen (wéi Istio a Kubeflow).
  • E Mechanismus fir déi operationell Interaktioun tëscht Kubernetes, Bildrepositories a Git ze managen GitOps Bedreiwer Weave Flux, deen Deel ass Weave Cloud.
  • Fir Basismaschinne muss de Konvergenzmechanismus deklarativ an autonom sinn. Aus eegener Erfahrung kënne mir dat soen Terraform noosten dëser Definitioun, mee verlaangt nach mënschlech Kontroll. An dësem Sënn verlängert GitOps d'Traditioun vun der Infrastruktur als Code.

GitOps kombinéiert Git mat dem exzellente Konvergenzmotor vu Kubernetes fir e Modell fir Ausbeutung ze bidden.

GitOps erlaabt eis ze soen: Nëmmen déi Systemer déi beschriwwe a observéiert kënne ginn, kënnen automatiséiert a kontrolléiert ginn.

GitOps ass fir de ganze Cloud native Stack geduecht (zum Beispill Terraform, etc.)

GitOps ass net nëmmen Kubernetes. Mir wëllen datt de ganze System deklarativ gedriwwe gëtt a Konvergenz benotzt. Mam ganze System menge mir eng Sammlung vun Ëmfeld déi mat Kubernetes schaffen - zum Beispill "Dev Cluster 1", "Produktioun", etc. All Ëmfeld enthält Maschinnen, Cluster, Uwendungen, souwéi Interfaces fir extern Servicer déi Daten ubidden, Iwwerwaachung. an etc.

Notéiert wéi wichteg Terraform fir de Bootstrapping Problem an dësem Fall ass. Kubernetes muss iergendwou ofgesat ginn, a mat Terraform heescht mir déiselwecht GitOps Workflows benotze fir d'Kontrollschicht ze kreéieren déi Kubernetes an Uwendungen ënnersträicht. Dëst ass eng nëtzlech bescht Praxis.

Et gëtt e staarke Fokus op d'Applikatioun vu GitOps Konzepter op Schichten uewen op Kubernetes. Am Moment ginn et GitOps-Typ Léisunge fir Istio, Helm, Ksonnet, OpenFaaS a Kubeflow, wéi och zum Beispill fir Pulumi, déi eng Schicht erstellen fir Uwendungen fir Cloud native z'entwéckelen.

Kubernetes CI / CD: Vergläicht GitOps mat anere Approche

Wéi gesot, GitOps ass zwou Saachen:

  1. De Betribsmodell fir Kubernetes a Cloud native uewen beschriwwen.
  2. De Wee zu engem Entwéckler-centric Applikatioun Management Ëmfeld.

Fir vill ass GitOps haaptsächlech e Workflow baséiert op Git Push. Mir gefällt hien och. Mee dat ass net alles: loosst eis elo CI/CD Pipelines kucken.

GitOps erméiglecht kontinuéierlech Deployment (CD) fir Kubernetes

GitOps bitt e kontinuéierlechen Deployment Mechanismus deen d'Bedierfnes fir separat "Deployment Management Systemer" eliminéiert. Kubernetes mécht all d'Aarbecht fir Iech.

  • D'Aktualiséierung vun der Applikatioun erfuerdert d'Aktualiséierung am Git. Dëst ass eng Transaktiounsaktualiséierung zum gewënschten Zoustand. "Deployment" gëtt dann am Cluster vu Kubernetes selwer gemaach baséiert op der aktualiséierter Beschreiwung.
  • Wéinst der Natur wéi Kubernetes funktionnéiert, sinn dës Updates konvergent. Dëst bitt e Mechanismus fir kontinuéierlech Deployment an deem all Updates atomar sinn.
  • Opgepasst: Weave Cloud bitt e GitOps Bedreiwer deen Git a Kubernetes integréiert an erlaabt CD ze maachen andeems de gewënschten an aktuellen Zoustand vum Cluster reconciliéiert.

Ouni kubectl a Scripten

Dir sollt vermeide Kubectl ze benotzen fir Äre Stärekoup ze aktualiséieren, a virun allem vermeide Scripten ze benotzen fir kubectl Kommandoen ze gruppéieren. Amplaz, mat der GitOps Pipeline, kann e Benotzer säi Kubernetes Cluster iwwer Git aktualiséieren.

Virdeeler enthalen:

  1. Riets. Eng Grupp vun Updates kënnen ugewannt, konvergéiert a schlussendlech validéiert ginn, wat eis méi no un d'Zil vun der atomarer Deployment bréngt. Am Géigesaz, d'Benotzung vu Skripte bitt keng Garantie vu Konvergenz (méi doriwwer hei ënnen).
  2. Sécherheet. Zitéieren Kelsey Hightower: "Beschränken den Zougang zu Ärem Kubernetes Cluster op Automatisatiounsinstrumenter an Administrateuren, déi verantwortlech sinn fir debugging oder erhalen." kuck och meng Publikatioun iwwer Sécherheet an Konformitéit mat technesch Spezifikatioune, wéi och Artikel iwwer Hacking Homebrew andeems Dir Umeldungsinformatiounen aus engem suergfälteg geschriwwenen Jenkins Skript klaut.
  3. Benotzer Erfahrung. Kubectl beliicht d'Mechanik vum Kubernetes Objektmodell, déi zimlech komplex sinn. Idealerweis sollten d'Benotzer mam System op engem méi héijen Abstraktiounsniveau interagéieren. Hei wäert ech nach eng Kéier op Kelsey referenzéieren a recommandéieren ze kucken esou e Resumé.

Ënnerscheed tëscht CI an CD

GitOps verbessert existent CI / CD Modeller.

E modernen CI Server ass en Orchestratiounsinstrument. Besonnesch ass et e Tool fir CI Pipelines ze orchestréieren. Dozou gehéieren Build, Test, Merge to Trunk, etc. CI Serveren automatiséieren d'Gestioun vu komplexe Multi-Step Pipelines. Eng gemeinsam Versuchung ass e Set vu Kubernetes Updates ze scriptéieren an et als Deel vun enger Pipeline auszeféieren fir Ännerungen am Cluster ze drécken. Tatsächlech ass dat wat vill Experten maachen. Allerdéngs ass dëst net optimal, an hei ass firwat.

CI soll benotzt ginn fir Updates op den Trunk ze drécken, an de Kubernetes Cluster soll sech selwer änneren op Basis vun dësen Updates fir d'CD intern ze verwalten. Mir nennen et zéien Modell fir CD, Am Géigesaz zum CI Push Modell. CD ass Deel Runtime Orchestratioun.

Firwat CI Server sollen net CDen iwwer Direkten Updates a Kubernetes maachen

Benotzt keen CI Server fir direkt Aktualiséierungen op Kubernetes als Set vu CI Aarbechtsplazen ze orchestréieren. Dëst ass d'Anti-Muster vu mir schwätzen scho gesot op Ärem Blog.

Komme mer zréck op Alice a Bob.

Wéi eng Problemer hu si konfrontéiert? Dem Bob säi CI-Server gëlt d'Ännerungen op de Stärekoup, awer wann et am Prozess klappt, weess de Bob net a wéi engem Zoustand de Stärekoup ass (oder soll sinn) oder wéi et fixéiert gëtt. Datselwecht ass wouer am Fall vun Erfolleg.

Loosst eis unhuelen datt dem Bob seng Equipe en neit Bild gebaut huet an duerno hir Deployementer patchéiert huet fir d'Bild z'installéieren (all aus der CI Pipeline).

Wann d'Bild normalerweis baut, awer d'Pipeline feelt, muss d'Team erausfannen:

  • Ass den Update ausgerullt?
  • Mir lancéiere en Neibau? Wäert dëst zu onnéidege Nebenwirkungen féieren - mat der Méiglechkeet zwee Bauten vum selwechte onverännerbare Bild ze hunn?
  • Solle mir op den nächsten Update waarden ier mer de Build lafen?
  • Wat ass genee falsch gaang? Wéi eng Schrëtt musse widderholl ginn (a wéi eng si sécher ze widderhuelen)?

E Git-baséiert Workflow opzebauen garantéiert net datt dem Bob seng Team dës Probleemer net begéint. Si kënnen nach ëmmer e Feeler maachen mam commit Push, dem Tag oder engem anere Parameter; awer, dëser Approche ass nach vill méi no un engem explizit all-oder-näischt Approche.

Fir ze resuméieren, hei ass firwat CI Serveren net mat CD solle beschäftegen:

  • Update Scripten sinn net ëmmer deterministesch; Et ass einfach Feeler an hinnen ze maachen.
  • CI Server konvergéieren net zum deklarative Clustermodell.
  • Et ass schwéier Idempotenz ze garantéieren. D'Benotzer mussen déi déif Semantik vum System verstoen.
  • Et ass méi schwéier vun engem deelweisen Ausfall ze recuperéieren.

Notiz iwwer Helm: Wann Dir Helm benotze wëllt, empfeelen mir et mat engem GitOps Bedreiwer wéi z. Flux-Helm. Dëst wäert hëllefen d'Konvergenz ze garantéieren. Helm selwer ass weder deterministesch nach atomesch.

GitOps als de beschte Wee fir Continuous Delivery fir Kubernetes ëmzesetzen

Dem Alice an dem Bob seng Equipe implementéiert GitOps an entdeckt datt et vill méi einfach ginn ass mat Softwareprodukter ze schaffen, héich Leeschtung a Stabilitéit z'erhalen. Loosst eis dësen Artikel ofschléissen mat enger Illustratioun déi weist wéi hir nei Approche ausgesäit. Denkt drun datt mir meeschtens iwwer Uwendungen a Servicer schwätzen, awer GitOps ka benotzt ginn fir eng ganz Plattform ze managen.

Betribsmodell fir Kubernetes

Kuckt de folgenden Diagramm. Et presentéiert Git an de Container Image Repository als gedeelt Ressourcen fir zwee orchestréiert Liewenszyklen:

  • Eng kontinuéierlech Integratiounspipeline déi Dateien op Git liest a schreift a kann e Repository vu Containerbiller aktualiséieren.
  • Eng Runtime GitOps Pipeline déi Deployment mat Gestioun an Observabilitéit kombinéiert. Et liest a schreift Dateien op Git a kann Container Biller eroflueden.

Wat sinn d'Haaptbefunde?

  1. Trennung vu Bedenken: Notéiert w.e.g. datt béid Pipelines nëmme kënne kommunizéieren andeems Dir Git oder de Bildrepository aktualiséiert. An anere Wierder, et gëtt eng Firewall tëscht CI an dem Runtime Ëmfeld. Mir nennen et d'"Immutability Firewall" (Onverännerbar Firewall), well all Repositoryupdates nei Versiounen erstellen. Fir méi Informatiounen iwwer dëst Thema, kuckt op Rutschen 72-87 dëser Presentatioun.
  2. Dir kënnt all CI a Git Server benotzen: GitOps funktionnéiert mat all Komponent. Dir kënnt weider Är Liiblings CI a Git Serveren, Bildrepositories an Testsuiten benotzen. Bal all aner Continuous Delivery Tools um Maart erfuerderen hiren eegene CI / Git Server oder Image Repository. Dëst kann e limitéierende Faktor an der Entwécklung vu Wollek gebierteg ginn. Mat GitOps kënnt Dir vertraut Tools benotzen.
  3. Eventer als Integratiounsinstrument: Soubal d'Donnéeën am Git aktualiséiert ginn, informéiert Weave Flux (oder de Weave Cloud Bedreiwer) Runtime. Wann ëmmer Kubernetes e Changement Set acceptéiert, gëtt Git aktualiséiert. Dëst bitt en einfachen Integratiounsmodell fir Workflows fir GitOps ze organiséieren, wéi hei ënnendrënner.

Konklusioun

GitOps bitt déi staark Updategarantien, déi vun all modernen CI / CD Tool erfuerderlech sinn:

  • Automatisatioun;
  • Konvergenz;
  • idempotenz;
  • Determinismus.

Dëst ass wichteg well et en operationelle Modell fir Cloud native Entwéckler bitt.

  • Traditionell Tools fir d'Gestioun an d'Iwwerwaachungssystemer si mat Operatiounsteams verbonne mat engem Runbook (eng Rei vu Routineprozeduren an Operatiounen - ongeféier Iwwersetzung), verbonne mat enger spezifescher Deployment.
  • Am Cloud native Management sinn Observatiounsinstrumenter de beschte Wee fir d'Resultater vun den Deployementer ze moossen, sou datt d'Entwécklungsteam séier ka reagéieren.

Stellt Iech vill Cluster vir, déi iwwer verschidde Wolleken a vill Servicer verstreet sinn mat hiren eegene Teams an Deploymentpläng. GitOps bitt e Skala-invariant Modell fir all dësen Iwwerfloss ze managen.

PS vum Iwwersetzer

Liest och op eisem Blog:

Nëmme registréiert Benotzer kënnen un der Ëmfro deelhuelen. Umellen, wann ech glift.

Wousst Dir iwwer GitOps ier dës zwou Iwwersetzungen op Habré opgetaucht sinn?

  • Jo, ech wousst alles

  • Nëmmen iwwerflächlech

  • Nee

35 Benotzer hunn gestëmmt. 10 Benotzer hu sech enthalen.

Source: will.com

Setzt e Commentaire