{"id":35594,"date":"2019-10-31T22:05:15","date_gmt":"2019-10-31T19:05:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/gitops-sravnenie-metodov-pull-i-push\/"},"modified":"2019-10-31T22:05:15","modified_gmt":"2019-10-31T19:05:15","slug":"gitops-sravnenie-metodov-pull-i-push","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/gitops-sravnenie-metodov-pull-i-push","title":{"rendered":"GitOps: confronto tra i metodi Pull e Push","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nota del traduttore.<\/b>: Nel mondo di Kubernetes, sta guadagnando popolarit\u00e0 una tendenza chiamata GitOps, di cui abbiamo avuto esperienza personale, partecipando<\/a><\/noindex> a KubeCon Europe 2019. Questo termine \u00e8 stato coniato relativamente di recente dal fondatore di Weaveworks \u2014 Alexis Richardson \u2014 e si riferisce all'uso degli strumenti familiari per gli sviluppatori (principalmente Git, da cui il nome) per affrontare le sfide operative. In particolare, si tratta di gestire Kubernetes memorizzando le sue configurazioni in Git e rilasciando automaticamente le modifiche nel cluster. Matthias Jg parla di due approcci a questo rilascio in questo articolo.<\/a><\/noindex> il fondatore di Weaveworks, Alexis Richardson, e implica l'uso di strumenti familiari per gli sviluppatori (soprattutto Git, da cui il nome stesso) per affrontare le sfide operative. In particolare, si tratta della gestione di Kubernetes attraverso la memorizzazione delle sue configurazioni in Git e il rilascio automatico delle modifiche nel cluster. Matthias Jg discute di due approcci a questo rilascio in questo articolo.<\/i><\/p>\n

\"GitOps:
\n
\nLo scorso anno (in realt\u00e0, formalmente \u00e8 accaduto nell'agosto 2017 \u2014 nota del traduttore.)<\/i> \u00e8 emerso un nuovo approccio al deployment delle applicazioni in Kubernetes. Si chiama GitOps e si basa sul concetto fondamentale che il tracciamento delle versioni dei deployment avviene in un ambiente sicuro di un repository Git.<\/a><\/noindex><\/p>\n

I principali vantaggi di questo approccio sono i seguenti<\/b>:<\/p>\n

    \n
  1. Versionamento dei deployment e cronologia delle modifiche<\/b>. Lo stato dell'intero cluster \u00e8 conservato in un repository Git, e i deployment vengono aggiornati solo tramite commit. Inoltre, tutte le modifiche possono essere monitorate grazie alla cronologia dei commit.<\/li>\n
  2. Rollback utilizzando i comandi Git familiari<\/b>. Semplice git reset<\/code> consente di ripristinare le modifiche nei deployment; gli stati precedenti sono sempre disponibili.<\/li>\n
  3. Controllo degli accessi pronto<\/b>. Di norma, un sistema Git contiene molte informazioni riservate, quindi la maggior parte delle aziende presta particolare attenzione alla sua protezione. Di conseguenza, questa protezione si applica anche alle operazioni sui deployment.<\/li>\n
  4. Politiche per i deployment<\/b>. La maggior parte dei sistemi Git supporta fin dall'inizio politiche per diversi branch \u2014 ad esempio, solo i pull request possono aggiornare il master, e le modifiche devono essere verificate e approvate da un altro membro del team. Come nel caso del controllo degli accessi, le stesse politiche si applicano agli aggiornamenti dei deployment.<\/li>\n<\/ol>\n

    \nCome potete vedere, il metodo GitOps ha molti vantaggi. Negli ultimi dodici mesi, due approcci hanno guadagnato particolare popolarit\u00e0. Uno \u00e8 basato su push, l'altro su pull. Prima di esaminarli, vediamo come si presentano i tipici deployment di Kubernetes.<\/p>\n

    Metodi di deployment<\/h2>\n

    \nNegli ultimi anni, sono emersi diversi modi e strumenti per le distribuzioni in Kubernetes:<\/p>\n

      \n
    1. Basati sui modelli nativi di Kubernetes\/Kustomize<\/b>. Questo \u00e8 il modo pi\u00f9 semplice per distribuire applicazioni in Kubernetes. Lo sviluppatore crea file YAML di base e li applica. Per evitare di riscrivere continuamente gli stessi modelli, \u00e8 stato sviluppato Kustomize (che trasforma i modelli di Kubernetes in moduli). Nota del traduttore.<\/b>: Kustomize \u00e8 stato integrato in kubectl con il rilascio di Kubernetes 1.14<\/a><\/noindex>.<\/i><\/li>\n
    2. Chart Helm<\/b>I chart di Helm permettono di creare set di modelli, init-container, sidecar e cos\u00ec via, che vengono utilizzati per il deployment delle applicazioni con maggiori possibilit\u00e0 di configurazione rispetto all'approccio basato su modelli. Al centro di questo metodo ci sono file YAML templated. Helm li compila con vari parametri e poi li invia a Tiller, il componente del cluster che li distribuisce nel cluster e consente aggiornamenti e rollback. \u00c8 importante notare che Helm inserisce semplicemente i valori necessari nei modelli e poi li applica allo stesso modo in cui si farebbe con l'approccio tradizionale. (per ulteriori informazioni su come funziona tutto ci\u00f2 e come \u00e8 possibile utilizzarlo, leggi il nostro articolo su Helm<\/a><\/noindex> \u2014 nota di traduzione)<\/i>. Esiste una grande variet\u00e0 di Helm chart pronti che coprono un'ampia gamma di compiti.<\/li>\n
    3. Strumenti alternativi<\/b>. Ci sono molti strumenti alternativi. Tutti essi condividono il fatto di trasformare alcuni file template in chiari file YAML di Kubernetes e poi applicarli.<\/li>\n<\/ol>\n

      \nNel nostro lavoro utilizziamo costantemente Helm chart per strumenti importanti (dato che molto \u00e8 gi\u00e0 pronto, il che semplifica notevolmente la vita) e file YAML di Kubernetes 'puliti' per implementare le nostre applicazioni.<\/p>\n

      Pull & Push<\/h2>\n

      \nIn una delle mie recenti pubblicazioni sul blog ho presentato uno strumento Weave Flux<\/a><\/noindex>, che consente di effettuare commit di template in un repository Git e aggiornare il deployment dopo ogni commit o push del container. La mia esperienza dimostra che questo strumento \u00e8 uno dei principali nel diffondere l'approccio pull, quindi far\u00f2 spesso riferimento ad esso. Se desideri saperne di pi\u00f9 su come utilizzarlo, ecco il link all'articolo<\/a><\/noindex>.<\/p>\n

      NB!<\/b> Tutti i vantaggi dell'uso di GitOps si applicano a entrambi gli approcci.<\/i><\/p>\n

      Approccio basato su Pull<\/h2>\n

      \n\"GitOps:
      \n
      \nAlla base dell'approccio pull c'\u00e8 il fatto che tutte le modifiche vengono applicate dall'interno del cluster. All'interno del cluster c'\u00e8 un operatore che controlla regolarmente i repository Git e Docker Registry associati. Se ci sono modifiche, lo stato del cluster viene aggiornato dall'interno. Questo processo \u00e8 generalmente considerato molto sicuro, poich\u00e9 nessun cliente esterno ha accesso ai diritti di amministratore del cluster.<\/p>\n

      Vantaggi:<\/b><\/p>\n

        \n
      1. Nessun cliente esterno ha il diritto di apportare modifiche al cluster; tutti gli aggiornamenti vengono applicati dall'interno.<\/li>\n
      2. Al alcuni strumenti consentono anche di sincronizzare gli aggiornamenti degli Helm chart e collegarli al cluster.<\/li>\n
      3. Il Docker Registry pu\u00f2 essere scansionato per nuove versioni. Se appare una nuova immagine, il repository Git e il deployment vengono aggiornati alla nuova versione.<\/li>\n
      4. Gli strumenti di pull possono essere distribuiti in diversi spazi dei nomi con diversi repository Git e diritti di accesso. Questo consente di applicare un modello multi-tenant. Ad esempio, il team A pu\u00f2 utilizzare lo spazio dei nomi A, il team B lo spazio dei nomi B, mentre il team responsabile dell'infrastruttura pu\u00f2 utilizzare uno spazio globale.<\/li>\n
      5. In generale, gli strumenti sono piuttosto leggeri.<\/li>\n
      6. In combinazione con strumenti come l'operatore Bitnami Sealed Secrets<\/a><\/noindex>, i segreti possono essere memorizzati in forma crittografata nel repository Git ed estratti all'interno del cluster.<\/li>\n
      7. Non c'\u00e8 connessione con i pipeline CD, poich\u00e9 i deployment avvengono all'interno del cluster.<\/li>\n<\/ol>\n

        \nSvantaggi<\/b>:<\/p>\n

          \n
        1. Gestire i segreti dei deployment dai chart Helm \u00e8 pi\u00f9 complesso rispetto a quelli normali, poich\u00e9 prima devono essere generati sotto forma di sealed secrets, poi decifrati da un operatore interno e solo dopo diventano disponibili per lo strumento pull. Successivamente, \u00e8 possibile lanciare un rilascio in Helm con i valori gi\u00e0 presenti nei segreti distribuiti. Il modo pi\u00f9 semplice \u00e8 creare un segreto con tutti i valori Helm utilizzati per il deployment, decifrarlo e commettelo in Git.<\/li>\n
        2. Utilizzando un approccio pull, ti trovi legato a strumenti che operano con i pull. Questo limita la possibilit\u00e0 di personalizzare il processo di distribuzione nei deployment del cluster. Ad esempio, lavorare con Kustomize \u00e8 complicato perch\u00e9 deve essere eseguito prima che i modelli finali vengano inviati su Git. Non dico che non si possano usare strumenti separati, ma \u00e8 pi\u00f9 difficile integrarli nel processo di distribuzione.<\/li>\n<\/ol>\n

          <\/p>\n

          Approccio basato su Push<\/h2>\n

          \n\"GitOps:
          \n
          \nNel modello push, un sistema esterno (principalmente pipeline CD) avvia i deployment nel cluster dopo il commit nel repository Git o dopo il successo dell'esecuzione della pipeline CI precedente. In questo approccio, il sistema ha accesso al cluster.<\/p>\n

          Pro<\/b>:<\/p>\n

            \n
          1. La sicurezza \u00e8 determinata dal repository Git e dalla pipeline di build.<\/li>\n
          2. Distribuire i chart Helm \u00e8 pi\u00f9 semplice, con supporto per i plugin Helm.<\/li>\n
          3. Gestire i segreti \u00e8 pi\u00f9 facile, poich\u00e9 possono essere applicati nelle pipeline e conservati in Git in forma crittografata (a seconda delle preferenze dell'utente).<\/li>\n
          4. Assenza di vincoli su strumenti specifici, poich\u00e9 \u00e8 possibile utilizzare qualsiasi tipo.<\/li>\n
          5. Gli aggiornamenti delle versioni dei container possono essere avviati dalla pipeline di build.<\/li>\n<\/ol>\n

            \nSvantaggi<\/b>:<\/p>\n

              \n
            1. I dati per accedere al cluster si trovano all'interno del sistema di build.<\/li>\n
            2. Aggiornare i container dei deployment \u00e8 ancora pi\u00f9 semplice con un processo pull.<\/li>\n
            3. Dipendenza elevata dal sistema CD, poich\u00e9 le pipeline necessarie sono probabilmente scritte inizialmente per Gitlab Runners, e poi il team decide di passare a Azure DevOps o Jenkins... e sar\u00e0 necessario migrare un gran numero di pipeline di build.<\/li>\n<\/ol>\n

              <\/p>\n

              Risultati: Push o Pull?<\/h2>\n

              \nCome spesso accade, ogni approccio ha i suoi pro e contro. Alcuni compiti sono pi\u00f9 facili da realizzare con un metodo e pi\u00f9 complessi con un altro. Inizialmente, eseguivo le distribuzioni manualmente, ma dopo aver scoperto alcuni articoli su Weave Flux, ho deciso di implementare processi GitOps per tutti i progetti. Per i modelli di base, \u00e8 stato facile, ma dopo ho iniziato a riscontrare difficolt\u00e0 nell'utilizzo dei chart di Helm. All'epoca, Weave Flux offriva solo una versione embrionale dell'Helm Chart Operator, ma anche adesso alcune operazioni sono pi\u00f9 complesse a causa della necessit\u00e0 di creare manualmente i segreti e applicarli. Si pu\u00f2 dire che l'approccio pull \u00e8 molto pi\u00f9 sicuro, poich\u00e9 le credenziali del cluster non sono accessibili dall'esterno, il che aumenta la sicurezza al punto da giustificare gli sforzi aggiuntivi.<\/p>\n

              Dopo aver riflettuto un po', sono arrivato a una conclusione inaspettata: non \u00e8 cos\u00ec. Se parliamo di componenti che necessitano di massima protezione, in questa lista ci sarebbero gli archivi di segreti e i sistemi CI\/CD, nonch\u00e9 i repository Git. Le informazioni al loro interno sono estremamente vulnerabili e richiedono protezione. Inoltre, se qualcuno riesce a penetrare nel tuo repository Git e a effettuare push di codice, potr\u00e0 implementare tutto ci\u00f2 che desidera (indipendentemente dal metodo scelto, sia esso pull o push), infiltrandosi nei sistemi del cluster. Pertanto, i componenti pi\u00f9 critici che richiedono protezione sono il repository Git e i sistemi CI\/CD, non le credenziali del cluster. Se hai ben impostate le politiche e le misure di sicurezza per tali sistemi e le credenziali del cluster vengono estratte nei pipeline solo come segreti, la sicurezza aggiuntiva del metodo pull potrebbe rivelarsi meno preziosa di quanto inizialmente previsto.<\/p>\n

              Quindi, se l'approccio pull \u00e8 pi\u00f9 laborioso e non offre vantaggi in termini di sicurezza, non sarebbe logico utilizzare solo l'approccio push? Tuttavia, qualcuno potrebbe sostenere che con l'approccio push si \u00e8 troppo legati al sistema CD e potrebbe essere meglio evitarlo per facilitare future migrazioni.<\/p>\n

              A mio avviso (come sempre), bisogna utilizzare ci\u00f2 che \u00e8 pi\u00f9 adatto al caso specifico o combinarlo. Personalmente, utilizzo entrambi gli approcci: Weave Flux per i deployment basati su pull, che riguardano principalmente i nostri servizi, e un approccio push con Helm e plugin, che semplifica l'applicazione dei chart Helm al cluster e consente di generare segreti senza problemi. Penso che non ci sar\u00e0 mai una soluzione unica adatta a tutti, perch\u00e9 ci sono sempre molte sfumature e dipendono dallo specifico caso d'uso. Detto questo, consiglio vivamente GitOps: rende la vita molto pi\u00f9 facile e aumenta la sicurezza.<\/p>\n

              Spero che la mia esperienza in merito possa aiutarti a decidere quale metodo si adatti meglio al tuo tipo di deployment, e sarei felice di conoscere la tua opinione.<\/p>\n

              P.S. Nota del traduttore<\/h2>\n

              \nTra i difetti del modello pull c'\u00e8 il fatto che \u00e8 difficile inserire in Git i manifesti renderizzati, ma non c'\u00e8 il difetto che il pipeline CD nel modello pull viva separatamente dal rilascio, diventando sostanzialmente un pipeline di categoria. Continuous Apply<\/i>. Pertanto, saranno necessari ancora pi\u00f9 sforzi per raccogliere lo stato di tutti i deployment e fornire l'accesso ai log\/statistiche, preferibilmente con un legame con il sistema CD.<\/p>\n

              In questo senso, il modello push consente di garantire almeno alcune certezze sui release, poich\u00e9 la durata del pipeline pu\u00f2 essere impostata uguale alla durata del release.<\/p>\n

              Abbiamo provato entrambi i modelli e siamo giunti alle stesse conclusioni dell'autore dell'articolo:<\/p>\n

                \n
              1. Il modello pull \u00e8 adatto per l'organizzazione dell'aggiornamento dei componenti di sistema su un gran numero di cluster (vedi l'articolo su addon-operator<\/a><\/noindex>).<\/li>\n
              2. Il modello Push basato su GitLab CI \u00e8 perfetto per il rilascio di applicazioni utilizzando Helm chart. In questo caso, il rilascio dei deployment all'interno dei pipeline viene monitorato tramite uno strumento. werf<\/a><\/noindex>A proposito, nel contesto di questo nostro progetto abbiamo frequentemente sentito parlare di \"GitOps\" quando discutevamo delle problematiche attuali degli ingegneri DevOps al nostro stand a KubeCon Europe '19.<\/li>\n<\/ol>\n

                <\/p>\n

                P.P.S. dal traduttore<\/h2>\n

                \nLeggete anche nel nostro blog:<\/p>\n