{"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\/it\/blog\/administrirovanie\/chto-zhe-takoe-gitops","title":{"rendered":"Che cos'\u00e8 GitOps?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nota del traduttore.<\/b>: Dopo una recente pubblicazione di materiale<\/a><\/noindex> sui metodi pull e push in GitOps, abbiamo notato un crescente interesse per questo modello in generale. Tuttavia, ci sono pochissime pubblicazioni in lingua russa su questo argomento (non ci sono affatto su Habr). Perci\u00f2, siamo felici di presentare la traduzione di un altro articolo \u2014 anche se quasi un anno fa! \u2014 dell'azienda Weaveworks, il cui fondatore ha coniato il termine \u00abGitOps\u00bb. Nel testo viene spiegata l'essenza dell'approccio e le sue principali differenze rispetto a quelli gi\u00e0 esistenti.<\/i><\/p>\n

\nUn anno fa abbiamo pubblicato un'introduzione a GitOps<\/a><\/noindex>. Allora abbiamo raccontato come il team di Weaveworks ha lanciato un SaaS interamente basato su Kubernetes e ha sviluppato un insieme di best practices normative per l'implementazione, gestione e monitoraggio in un ambiente cloud native.<\/a><\/noindex><\/p>\n

L'articolo \u00e8 stato popolare. Altri hanno iniziato a parlare di GitOps e a pubblicare nuovi strumenti per git push<\/a><\/noindex>, sviluppo<\/a><\/noindex>, segreti<\/a><\/noindex>, funzioni<\/a><\/noindex>, integrazione continua<\/a><\/noindex> ecc. Sul nostro sito \u00e8 apparso un gran numero<\/a><\/noindex> di pubblicazioni e casi d'uso di GitOps. Ma alcune persone hanno ancora domande. Qual \u00e8 la differenza tra questo modello e il tradizionale infrastructure as code<\/a><\/noindex> e la consegna continua (continuous delivery<\/a><\/noindex>)? \u00c8 obbligatorio utilizzare Kubernetes?<\/p>\n

Presto ci siamo resi conto della necessit\u00e0 di una nuova descrizione che offrisse:<\/p>\n

    \n
  1. Un gran numero di esempi e storie;<\/li>\n
  2. Una definizione chiara di GitOps;<\/li>\n
  3. Un confronto con la continuous delivery tradizionale.<\/li>\n<\/ol>\n

    \nIn questo articolo abbiamo cercato di coprire tutti questi temi. Troverete un'introduzione aggiornata su GitOps e una prospettiva da parte degli sviluppatori e del CI\/CD. Ci concentriamo principalmente su Kubernetes, anche se il modello pu\u00f2 essere generalizzato.<\/p>\n

    Presentiamo: GitOps<\/h2>\n

    \nImmagina Alice. Gestisce l'azienda Family Insurance, che offre polizze per assicurazioni sanitarie, auto, immobili e viaggi a persone troppo occupate per districarsi tra le complessit\u00e0 dei contratti da sole. La sua attivit\u00e0 \u00e8 iniziata come un progetto secondario, mentre Alice lavorava in banca come data scientist. Un giorno si \u00e8 resa conto di poter utilizzare algoritmi computazionali avanzati per un'analisi dei dati pi\u00f9 efficace e per la creazione di pacchetti assicurativi. Gli investitori hanno finanziato il progetto e ora la sua azienda genera oltre 20 milioni di dollari all'anno ed \u00e8 in rapida crescita. Attualmente, impiega 180 persone in vari ruoli. Tra di loro c'\u00e8 il team tecnologico che si occupa dello sviluppo, della manutenzione del sito, del database e dell'analisi dei clienti. Il team di 60 persone \u00e8 guidato da Bob, il direttore tecnico dell'azienda.<\/p>\n

    Il team di Bob distribuisce sistemi di produzione nel cloud. Le loro applicazioni principali funzionano su GKE, sfruttando i vantaggi di Kubernetes in Google Cloud. Inoltre, utilizzano vari strumenti per l'elaborazione dei dati e l'analisi.<\/p>\n

    Family Insurance non aveva programmato di utilizzare i contenitori, ma si \u00e8 presto lasciata contagiare dall'entusiasmo per Docker. Ben presto, gli specialisti dell'azienda hanno scoperto che GKE consente di distribuire cluster per testare nuove funzionalit\u00e0 in modo facile e senza sforzo. Sono stati aggiunti Jenkins per CI e Quay per organizzare il registro dei contenitori, e sono stati scritti script per Jenkins che inviavano nuovi contenitori e configurazioni a GKE.<\/p>\n

    \u00c8 passato del tempo. Alice e Bob si sono pentiti delle prestazioni dell'approccio scelto e del suo impatto sul business. L'implementazione dei container non ha migliorato le prestazioni quanto si aspettava il team. A volte i deployment si bloccavano, e non era chiaro se ci\u00f2 fosse dovuto a modifiche nel codice. \u00c8 stato anche difficile monitorare i cambiamenti nelle configurazioni. Spesso era necessario creare un nuovo cluster e spostare le applicazioni poich\u00e9 era il modo pi\u00f9 semplice per risolvere il disastro che si era creato nel sistema. Alice temeva che la situazione sarebbe peggiorata con l'evoluzione dell'applicazione (inoltre, stava nascendo un nuovo progetto basato sull'apprendimento automatico). Bob ha automatizzato gran parte del lavoro e non capiva perch\u00e9 il pipeline fosse ancora instabile, scalasse male e richiedesse periodicamente un intervento manuale.<\/p>\n

    Poi hanno scoperto GitOps. Questa soluzione si \u00e8 rivelata esattamente ci\u00f2 di cui avevano bisogno per procedere con fiducia.<\/b><\/p>\n

    Alice e Bob sentono parlare dei flussi di lavoro basati su Git, DevOps e infrastructure as code da diversi anni. L'unicit\u00e0 di GitOps risiede nel fatto che introduce un insieme di best practice - categoriche e normative - per l'implementazione di queste idee nel contesto di Kubernetes. Questo argomento \u00e8 stato sollevato pi\u00f9 volte<\/a><\/noindex>, incluso nel blog di Weaveworks<\/a><\/noindex>.<\/p>\n

    Family Insurance ha deciso di adottare GitOps. Ora l'azienda dispone di un modello operativo automatizzato, compatibile con Kubernetes, che combina velocit\u00e0<\/i> e stabilit\u00e0<\/i>, poich\u00e9 hanno:<\/p>\n