Cosa hè GitOps?

Nota. transl.: Dopu una publicazione recente materiale nantu à i metudi di pull and push in GitOps, avemu vistu interessu in questu mudellu in generale, ma ci era assai pochi publicazioni in lingua russa nantu à questu tema (ùn ci hè simplicemente nimu nantu à Habré). Dunque, simu piacè di offre à a vostra attenzione una traduzzione di un altru articulu - ancu s'ellu hè quasi un annu fà! - da Weaveworks, u capu di quale hà incunatu u terminu "GitOps". U testu spiega l'essenza di l'approcciu è e differenze chjave da quelli esistenti.

Un annu fà avemu publicatu Introduzione à GitOps. Allora, avemu spartutu cumu a squadra di Weaveworks hà lanciatu un SaaS interamente basatu annantu à Kubernetes è hà sviluppatu un inseme di e migliori pratiche prescriptive per implementà, gestisce è monitorà in un ambiente nativu cloud.

L'articulu hè diventatu populari. Altre persone cuminciaru à parlà di GitOps è cuminciaru à publicà novi strumenti per git push, sviluppu, sicreti, funzioni, integrazione cuntinua eccetera. Apparsu nantu à u nostru situ web una grande quantità publicazioni è casi d'usu di GitOps. Ma certi persone anu sempre dumande. Cumu hè u mudellu difiere da u tradiziunale? infrastruttura cum'è codice è spedizione cuntinuu (cunsegna continuu)? Hè necessariu aduprà Kubernetes?

Prestu avemu capitu chì una nova descrizzione era necessaria, chì offre:

  1. Un gran numaru di esempi è storie;
  2. Definizione specifica di GitOps;
  3. Cunfrontu cù a spedizione cuntinuu tradiziunale.

In questu articulu avemu pruvatu à copre tutti sti temi. Fornisce una introduzione aghjurnata à GitOps è una perspettiva di sviluppatore è CI / CD. Fighjemu principarmenti nantu à Kubernetes, ancu se u mudellu pò esse generalizatu.

Scuntrà GitOps

Imagine Alice. Ella gestisce l'Assicuranza Famiglia, chì offre assicuranza di salute, auto, casa è viaghju à e persone chì sò troppu occupati per capisce l'intruduzioni di i cuntratti stessi. A so attività hà iniziatu cum'è un prughjettu laterale quandu Alice travagliava in un bancu cum'è scientist di dati. Un ghjornu hà capitu chì puderia usà algoritmi avanzati di l'informatica per analizà più efficacemente e dati è furmulà pacchetti d'assicuranza. Investisseur finanzà u prugettu, è avà a so cumpagnia porta in più di $ 20 milioni à l'annu è cresce rapidamente. Attualmente, impiega 180 persone in diverse pusizioni. Questu include un squadra di tecnulugia chì sviluppa, mantene u situ web, basa di dati, è analizà a basa di clienti. A squadra di 60 persone hè guidata da Bob, u direttore tecnicu di a cumpagnia.

A squadra di Bob implementa sistemi di produzzione in u nuvulu. E so applicazioni core funzionanu nantu à GKE, apprufittannu di Kubernetes in Google Cloud. Inoltre, utilizanu diversi strumenti di dati è analitiche in u so travagliu.

L'Assicuranza Famiglia ùn hà micca decisu d'utilizà cuntenituri, ma hè stata presa in l'entusiasmu di Docker. A cumpagnia hà scupertu prestu chì GKE facia faciule è senza sforzu per implementà clusters per pruvà novi funziunalità. Jenkins per CI è Quay sò stati aghjunti per urganizà u registru di u containeru, i scripts sò stati scritti per Jenkins chì spinghjenu novi cuntenituri è cunfigurazioni à GKE.

Qualchì tempu hè passatu. Alice è Bob sò stati dispiaciuti cù u rendiment di u so approcciu sceltu è u so impattu nantu à l'affari. L'intruduzioni di cuntenituri ùn hà micca migliuratu a produtividade quant'è a squadra avia speratu. A volte i dispiegamenti si rompevanu, è ùn era micca chjaru se i cambiamenti di codice eranu a culpa. Hè ancu diventatu difficiule di seguità i cambiamenti di cunfigurazione. Spessu era necessariu di creà un novu cluster è traslassi l'applicazioni à questu, postu chì questu era u modu più faciule per eliminà u mess chì u sistema era diventatu. Alice hà a paura chì a situazione s'aggravarà cum'è l'applicazione si sviluppava (in più, un novu prughjettu basatu annantu à l'apprendimentu di a macchina era in preparazione). Bob avia automatizatu a maiò parte di u travagliu è ùn hà micca capitu perchè u pipeline era sempre inestabile, ùn hà micca scalatu bè, è hà bisognu di l'intervenzione manuale periodicamente?

Allora anu amparatu nantu à GitOps. Sta decisione hè stata esattamente ciò chì avianu bisognu per avanzà cun fiducia.

Alice è Bob anu intesu parlà di Git, DevOps è infrastruttura cum'è flussi di travagliu di codice per anni. Ciò chì hè unicu di GitOps hè chì porta un inseme di e migliori pratiche - sia definitive sia normative - per implementà queste idee in u cuntestu di Kubernetes. Stu tema s'arrizzò ripetutamente, cumpresu in Blog Weaveworks.

Assicuranza Famiglia decide di implementà GitOps. A cumpagnia hà avà un mudellu di operazione automatizatu chì hè cumpatibile cù Kubernetes è combina vitezzastabilitàperchè elli:

  • truvò chì a produtitività di a squadra duppiò senza chì nimu ùn sia pazzi;
  • cessatu di serve scripts. Invece, ponu avà fucalizza nantu à e funzioni novi è migliurà i metudi di l'ingegneria - per esempiu, introducendu rollouts canari è migliurà a prova;
  • avemu migliuratu u prucessu di implementazione in modu chì raramente si rompe;
  • hà avutu l'uppurtunità di restaurà implementazioni dopu fallimenti parziali senza intervenzione manuale;
  • acquistatu usatuоCunfidenza più grande in i sistemi di consegna. Alice è Bob anu scupertu chì puderanu split the team in microservice teams working in parallel;
  • pò fà 30-50 cambiamenti à u prugettu ogni ghjornu attraversu i sforzi di ogni gruppu è pruvate novi tecniche;
  • hè faciule d'attirà novi sviluppatori à u prugettu, chì anu l'uppurtunità di stende l'aghjurnamenti à a pruduzzione usendu pull requests in pochi ore;
  • passà facilmente l'auditu in u quadru di SOC2 (per u rispettu di i fornitori di serviziu cù i requisiti per a gestione sicura di dati; leghjite più, per esempiu, ccà - ca. trad.).

Chì hè accadutu?

GitOps hè duie cose:

  1. U mudellu operativu per Kubernetes è cloud native. Fornisce un inseme di e migliori pratiche per implementà, gestisce è monitorizà clusters è applicazioni containerizzati. Definizione elegante in a forma una diapositiva от Luis Faceira:
  2. A strada per creà un ambiente di gestione di l'applicazioni centratu in u sviluppatore. Applicamu u flussu di travagliu Git sia à l'operazioni sia à u sviluppu. Per piacè nutate chì questu ùn hè micca solu di Git push, ma di urganizà tuttu u set di CI/CD è UI/UX tools.

Uni pochi parolle nantu à Git

Se ùn site micca familiarizatu cù i sistemi di cuntrollu di versione è u flussu di travagliu basatu in Git, ricumandemu assai di amparà nantu à elli. U travagliu cù i rami è e dumande di pull pò parenu cum'è magia negra in prima, ma i benefici valenu a pena. Quì bonu articulu per principià.

Cumu funziona Kubernetes

In a nostra storia, Alice è Bob anu vultatu à GitOps dopu avè travagliatu cù Kubernetes per un tempu. Infatti, GitOps hè strettamente ligatu à Kubernetes - hè un mudellu operativu per l'infrastruttura è l'applicazioni basati in Kubernetes.

Cosa dà Kubernetes à l'utilizatori?

Eccu alcuni caratteristiche principali:

  1. In u mudellu Kubernetes, tuttu pò esse discrittu in forma dichjarazione.
  2. U servitore API di Kubernetes piglia sta dichjarazione cum'è input è poi prova continuamente à purtà u cluster in u statu descrittu in a dichjarazione.
  3. E dichjarazioni sò abbastanza per descriverà è gestisce una larga varietà di carichi di travagliu - "applicazioni".
  4. In u risultatu, i cambiamenti à l'applicazione è u cluster si sò per via di:
    • cambiamenti in l'imaghjini di u containeru;
    • cambiamenti à a specificazione dichjarativa;
    • errori in l'ambiente - per esempiu, crash di container.

Grandi capacità di cunvergenza di Kubernetes

Quandu un amministratore fa cambiamenti di cunfigurazione, l'orchestratore Kubernetes li applicà à u cluster, sempre chì u so statu hè ùn vene micca vicinu à a nova cunfigurazione. Stu mudellu funziona per qualsiasi risorsa Kubernetes è hè estensibile cù Definizioni di Risorse Personalizzate (CRD). Dunque, e implementazioni di Kubernetes anu e seguenti proprietà maravigliose:

  • L'automatizazione: L'aghjurnamenti di Kubernetes furnisce un mecanismu per automatizà u prucessu di applicà cambiamenti grazia è in una manera puntuale.
  • Cunvergenza: Kubernetes continuerà à pruvà l'aghjurnamenti finu à successu.
  • Idempotenza: Applicazioni ripetute di cunvergenza portanu à u listessu risultatu.
  • Determinismu: Quandu i risorse sò abbastanza, u statu di u cluster aghjurnatu dipende solu da u statu desideratu.

Cumu funziona GitOps

Avemu amparatu abbastanza nantu à Kubernetes per spiegà cumu funziona GitOps.

Riturnemu à e squadre di microservizi di Assicuranza Famiglia. Chì sò di solitu anu da fà ? Fighjate à a lista quì sottu (se qualchì articulu in questu pare stranu o scunnisciutu, per piacè tene di criticà è stà cun noi). Quessi sò solu esempi di flussi di travagliu basati in Jenkins. Ci hè parechje altre prucessi quandu u travagliu cù altre arnesi.

A cosa principal hè chì vedemu chì ogni aghjurnamentu finisce cù cambiamenti à i schedarii di cunfigurazione è i repositori Git. Questi cambiamenti à Git causanu l'"operatore GitOps" per aghjurnà u cluster:

1.Processu di travagliu: "Jenkins build - ramu maestru».
Lista di i travaglii:

  • Jenkins spinge l'imaghjini taggate à Quay;
  • Jenkins spinge i charts di cunfigurazione è Helm à u bucket di almacenamiento maestru;
  • A funzione nuvola copia a cunfigurazione è i charts da u bucket di almacenamiento maestru à u repositoriu Git maestru;
  • L'operatore GitOps aghjurnà u cluster.

2. Jenkins build - liberazione o ramu hotfix:

  • Jenkins spinge l'imaghjini senza tag à Quay;
  • Jenkins spinge i charts di cunfigurazione è Helm à u bucket di almacenamiento di staging;
  • A funzione di nuvola copia a cunfigurazione è i charts da u bucket di staging storage à u staging Git repository;
  • L'operatore GitOps aghjurnà u cluster.

3. Jenkins build - sviluppu o ramu di funziunalità:

  • Jenkins spinge l'imaghjini senza tag à Quay;
  • Jenkins spinge i grafici di cunfigurazione è Helm in u bucket di almacenamiento di sviluppu;
  • A funzione di nuvola copia a cunfigurazione è i charts da u bucket di almacenamiento di sviluppu à u repositoriu Git di sviluppu;
  • L'operatore GitOps aghjurnà u cluster.

4. Aghjunghjendu un novu cliente:

  • U gestore o amministratore (LCM/ops) chjama Gradle per implementà inizialmente è cunfigurà l'equilibriu di carica di rete (NLB);
  • LCM/ops cummette una nova cunfigurazione per preparà a implementazione per l'aghjurnamenti;
  • L'operatore GitOps aghjurnà u cluster.

Breve descrizzione di GitOps

  1. Descrivite u statu desideratu di tuttu u sistema utilizendu specificazioni dichjarative per ogni ambiente (in a nostra storia, a squadra di Bob definisce a cunfigurazione di u sistema tutale in Git).
    • U repository Git hè a sola fonte di verità in quantu à u statu desideratu di tuttu u sistema.
    • Tutti i cambiamenti à u statu desideratu sò fatti cù cummissioni in Git.
    • Tutti i paràmetri di u cluster desideratu sò ancu osservati in u cluster stessu. In questu modu pudemu determinà s'ellu coincidenu (convergenu, cunverghjini) o differisce (diverge, diverghje) stati desiderati è osservati.
  2. Se i stati desiderati è osservati sò diffirenti, allora:
    • Ci hè un mecanismu di cunvergenza chì prima o dopu sincronizza automaticamente i stati di destinazione è osservati. Dentru u cluster, Kubernetes face questu.
    • U prucessu principia immediatamente cù una alerta di "cambiamentu impegnatu".
    • Dopu qualchì periodu di tempu configurabile, una alerta "diff" pò esse mandata se i stati sò diffirenti.
  3. In questu modu, tutti l'impegni in Git causanu aghjurnamenti verificabili è idempotenti à u cluster.
    • Rollback hè a cunvergenza à un statu previamente desideratu.
  4. A cunvergenza hè finale. A so manifestazione hè indicata da:
    • Nisun avvisi diffarenti per un certu periodu di tempu.
    • Alerta "convergente" (per esempiu, webhook, Git writeback event).

Cosa hè a divergenza?

Ripitemu dinò: tutte e proprietà di cluster desiderate devenu esse osservate in u cluster stessu.

Certi esempi di divergenza:

  • Cambia in u schedariu di cunfigurazione per via di a fusione di rami in Git.
  • Un cambiamentu in u schedariu di cunfigurazione per un impegnu Git fattu da u cliente GUI.
  • Diversi cambiamenti à u statu desideratu per via di PR in Git seguitu da custruisce l'imaghjini di u containeru è cambiamenti di cunfigurazione.
  • Un cambiamentu in u statu di u cluster per un errore, un cunflittu di risorse chì risulta in "cumportamentu cattivu", o semplicemente una deviazione aleatoria da u statu originale.

Chì ghjè u mecanismu di cunvergenza?

Qualchi esempi:

  • Per i cuntenituri è i clusters, u mecanismu di cunvergenza hè furnitu da Kubernetes.
  • U listessu mecanismu pò esse usatu per gestisce l'applicazioni è i disinni basati in Kubernetes (cum'è Istio è Kubeflow).
  • Un mecanismu per a gestione di l'interazzione operativa trà Kubernetes, repository d'imaghjini è Git furnisce L'operatore GitOps Weave Flux, chì face parte Weave Cloud.
  • Per e macchine di basa, u mecanismu di cunvergenza deve esse dichjarazione è autonoma. Da a nostra propria sperienza pudemu dì chì Terraform più vicinu à sta definizione, ma hè sempre bisognu di cuntrollu umanu. In questu sensu, GitOps estende a tradizione di Infrastruttura cum'è Code.

GitOps combina Git cù l'eccellente mutore di cunvergenza di Kubernetes per furnisce un mudellu per sfruttamentu.

GitOps ci permette di dì: Solu quelli sistemi chì ponu esse descritti è osservati ponu esse automatizati è cuntrullati.

GitOps hè destinatu à tutta a pila nativa di nuvola (per esempiu, Terraform, etc.)

GitOps ùn hè micca solu Kubernetes. Vulemu chì u sistema tutale sia guidatu in modu dichjarazione è aduprà a cunvergenza. Per u sistema sanu intendemu una cullizzioni di ambienti chì travaglianu cù Kubernetes - per esempiu, "dev cluster 1", "produzione", etc. Ogni ambiente include macchine, clusters, applicazioni, è ancu interfacce per servizii esterni chì furniscenu dati, monitoraghju. è ecc.

Avvisu quantu hè impurtante Terraform à u prublema di bootstrapping in questu casu. Kubernetes deve esse implementatu in qualchì locu, è utilizendu Terraform significa chì pudemu applicà i stessi flussi di travagliu GitOps per creà a capa di cuntrollu chì sustene Kubernetes è l'applicazioni. Questa hè una pratica megliu utile.

Ci hè un forte focusu nantu à l'applicazione di cuncetti GitOps à i strati sopra Kubernetes. À u mumentu, ci sò soluzioni di tipu GitOps per Istio, Helm, Ksonnet, OpenFaaS è Kubeflow, è ancu, per esempiu, per Pulumi, chì creanu una strata per u sviluppu di applicazioni per u cloud native.

Kubernetes CI/CD: paragunà GitOps cù altri approcci

Comu dichjaratu, GitOps hè duie cose:

  1. U mudellu operativu per Kubernetes è cloud native descrittu sopra.
  2. A strada per un ambiente di gestione di l'applicazioni centratu in u sviluppatore.

Per parechji, GitOps hè principarmenti un flussu di travagliu basatu annantu à i spingi Git. Ci piace ancu ellu. Ma ùn hè micca tuttu: guardemu avà i pipelines CI/CD.

GitOps permette l'implementazione continua (CD) per Kubernetes

GitOps offre un mecanismu di implementazione cuntinuu chì elimina a necessità di "sistemi di gestione di implementazione" separati. Kubernetes face tuttu u travagliu per voi.

  • L'aghjurnamentu di l'applicazione richiede l'aghjurnamentu in Git. Questa hè una aghjurnazione transazionale à u statu desideratu. "Implementazione" hè allora fatta in u cluster da Kubernetes stessu basatu annantu à a descrizzione aghjurnata.
  • A causa di a natura di cumu funziona Kubernetes, queste aghjurnamenti sò cunvergenti. Questu furnisce un mecanismu per a implementazione cuntinua in quale tutte l'aghjurnamenti sò atomichi.
  • Nutate bè: Weave Cloud offre un operatore GitOps chì integra Git è Kubernetes è permette à u CD per esse realizatu cunciliendu u statu desideratu è attuale di u cluster.

Senza kubectl è scripts

Duvete evità di utilizà Kubectl per aghjurnà u vostru cluster, è sopratuttu evite d'utilizà scripts per raggruppà i cumandamenti di kubectl. Invece, cù a pipeline GitOps, un utilizatore pò aghjurnà u so cluster Kubernetes via Git.

I benefici includenu:

  1. Diritta. Un gruppu di aghjurnamenti pò esse appiicati, cunvergenti è infine cunvalidati, chì ci avvicinanu à u scopu di implementazione atomica. In cuntrastu, l'usu di script ùn furnisce micca una garanzia di cunvergenza (più nantu à questu quì sottu).
  2. Seguretat. Citendu Kelsey Hightower: "Limita l'accessu à u vostru cluster Kubernetes à l'automatizazione è l'amministratori chì sò rispunsevuli di debugging o di mantene". vede ancu a mo publicazione nantu à a sicurità è u rispettu di e specificazioni tecniche, è ancu articulu nantu à u pirate Homebrew arrubbandu credenziali da un script di Jenkins scrittu senza cura.
  3. Esperienza d'utilizatore. Kubectl espone a meccanica di u mudellu d'ughjettu Kubernetes, chì sò abbastanza cumplessi. Ideale, l'utilizatori devenu interagisce cù u sistema à un livellu più altu di astrazione. Quì mi riferiraghju di novu à Kelsey è ricumanderaghju di fighjà un tali curriculum vitae.

Differenza trà CI è CD

GitOps migliora i mudelli CI/CD esistenti.

Un servitore CI mudernu hè un strumentu d'orchestrazione. In particulare, hè un strumentu per orchestrating pipelines CI. Questi includenu a custruzzione, a prova, a fusione à u troncu, etc. I servitori CI automatizanu a gestione di pipeline cumplessi multi-step. Una tentazione cumuna hè di scrive un inseme di aghjurnamenti Kubernetes è eseguisce cum'è parte di una pipeline per spinghje cambiamenti à u cluster. In verità, questu hè ciò chì facenu parechji esperti. Tuttavia, questu ùn hè micca ottimali, è eccu perchè.

CI deve esse usatu per spinghje l'aghjurnamenti à u troncu, è u cluster Kubernetes deve cambià stessu basatu annantu à quelli aghjurnamenti per gestisce u CD internamente. Chjamemu pull mudellu per CD, à u cuntrariu di u mudellu CI push. CD hè parte orchestrazione runtime.

Perchè i Servitori CI ùn devenu micca fà CD via l'aghjurnamenti diretti in Kubernetes

Ùn aduprate micca un servitore CI per orchestrate l'aghjurnamenti diretti à Kubernetes cum'è un settore di travagliu CI. Questu hè l'anti-pattern chì avemu parlatu digià dettu nant'à u vostru bloggu.

Riturnemu à Alice è Bob.

Chì prublemi anu affruntatu ? U servitore CI di Bob applica i cambiamenti à u cluster, ma s'ellu si crash in u prucessu, Bob ùn saperà micca in quale statu u cluster hè (o duverebbe esse) o cumu si risolve. U listessu hè veru in casu di successu.

Assumimu chì l'equipa di Bob hà custruitu una nova maghjina è poi patched i so implementazioni per implementà l'imaghjini (tuttu da u pipeline CI).

Se l'imaghjini custruite nurmale, ma u pipeline falla, a squadra duverà capisce:

  • L'aghjurnamentu hè stata lanciata?
  • Lancemu una nova custruzione? Questu portarà à effetti latu innecessarii - cù a pussibilità di avè dui custruzzioni di a listessa maghjina immutable?
  • Duvemu aspittà a prossima aghjurnazione prima di eseguisce a custruzione?
  • Cosa hè andatu male esattamente? Quali passi deve esse ripetutu (è quali sò sicuru di ripetiri)?

Stabbilimentu di un flussu di travagliu basatu in Git ùn guarantisci micca chì a squadra di Bob ùn scontru micca questi prublemi. Puderanu ancu fà un sbagliu cù u cummit push, u tag, o qualchì altru paràmetru; in ogni modu, questu approcciu hè sempre assai più vicinu à un approcciu esplicitu di tuttu o nunda.

Per sintetizà, eccu perchè i servitori CI ùn deve micca trattà cun CD:

  • I scripts d'aghjurnà ùn sò micca sempre deterministichi; Hè faciule fà sbaglià in elli.
  • I servitori CI ùn cunvergenu micca à u mudellu di cluster dichjarativu.
  • Hè difficiule di guarantiscia l'idempotenza. L'utilizatori devenu capisce a semantica prufonda di u sistema.
  • Hè più difficiuli di ricuperà da un fallimentu parziale.

Nota nantu à Helm: Se vulete usà Helm, ricumandemu di cumminà cù un operatore GitOps cum'è Flux-Helm. Questu aiutà à assicurà a cunvergenza. Helm stessu ùn hè nè deterministicu nè atomicu.

GitOps cum'è u megliu modu per implementà a Consegna Continua per Kubernetes

A squadra di Alice è Bob implementa GitOps è scopre chì hè diventatu assai più faciule per travaglià cù prudutti di software, mantene un altu rendiment è stabilità. Finemu stu articulu cù una illustrazione chì mostra ciò chì u so novu approcciu pare. Tenite in mente chì parlemu soprattuttu di applicazioni è servizii, ma GitOps pò esse usatu per gestisce una piattaforma intera.

U mudellu operativu per Kubernetes

Fighjate à u schema seguente. Presenta Git è u repositoriu di l'imaghjini di u containeru cum'è risorse spartute per dui cicli di vita orchestrati:

  • Un pipeline d'integrazione cuntinuu chì leghje è scrive i fugliali in Git è pò aghjurnà un repository di l'imaghjini di u containeru.
  • Un pipeline Runtime GitOps chì combina implementazione cù gestione è osservabilità. Leghje è scrive i fugliali in Git è pò scaricà l'imaghjini di u containeru.

Chì sò i principali risultati?

  1. Separazione di preoccupazioni: Per piacè nutate chì e duie pipeline ponu cumunicà solu aghjurnendu Git o u repositariu di l'imaghjini. In altre parolle, ci hè un firewall trà CI è l'ambiente runtime. Chjamemu u "firewall d'immutabilità" (immutabilità firewall), postu chì tutte l'aghjurnamenti di u repositoriu creanu novi versioni. Per più infurmazione nantu à questu tema, riferite à i slides 72-87 sta presentazione.
  2. Pudete utilizà qualsiasi servitore CI è Git: GitOps funziona cù qualsiasi cumpunente. Pudete cuntinuà à aduprà i vostri servitori CI è Git preferiti, repositori d'imaghjini è suite di teste. Quasi tutti l'altri strumenti di Consegna Continua nantu à u mercatu necessitanu u so propiu servitore CI / Git o repository d'imaghjini. Questu pò diventà un fattore limitante in u sviluppu di u cloud nativu. Cù GitOps, pudete aduprà strumenti familiari.
  3. Avvenimenti cum'è strumentu d'integrazione: Appena i dati in Git sò aghjurnati, Weave Flux (o l'operatore Weave Cloud) notifica u runtime. Ogni volta chì Kubernetes accetta un set di cambiamenti, Git hè aghjurnatu. Questu furnisce un mudellu di integrazione simplice per urganizà i flussi di travagliu per GitOps, cum'è mostratu quì sottu.

cunchiusioni

GitOps furnisce e forti garanzii di aghjurnamentu richieste da qualsiasi strumentu CI/CD mudernu:

  • autumàticu;
  • cunvergenza;
  • idempotenza;
  • determinismu.

Questu hè impurtante perchè offre un mudellu operativu per i sviluppatori nativi di nuvola.

  • Strumenti tradiziunali per a gestione è i sistemi di monitoraghju sò assuciati cù squadre di operazioni chì operanu in un runbook (un inseme di prucedure è operazioni di rutina - circa trad.), liata à una implementazione specifica.
  • In a gestione nativa di nuvola, l'uttine di osservabilità sò u megliu modu per misurà i risultati di implementazioni in modu chì u squadra di sviluppu pò risponde rapidamente.

Imagine parechji clusters spargugliati in diverse nuvole è parechji servizii cù e so squadre è i piani di implementazione. GitOps offre un mudellu invariante di scala per gestisce tutta questa abbundanza.

PS da u traduttore

Leghjite puru nant'à u nostru blog:

Solu l'utilizatori registrati ponu participà à l'indagine. Firmà lu, per piacè.

Sapete GitOps prima chì sti dui traduzzioni apparsu in Habré ?

  • Iè, sapia tuttu

  • Solu superficialmente

  • No

35 utilizatori anu vutatu. 10 utilizatori si sò astenuti.

Source: www.habr.com

Add a comment