{"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 di traduzione.<\/b>: Nella comunit\u00e0 Kubernetes sta guadagnando sempre pi\u00f9 popolarit\u00e0 una tendenza chiamata GitOps, di cui abbiamo avuto personalmente conferma, visitando<\/a><\/noindex> KubeCon Europe 2019. Questo termine \u00e8 stato coniato relativamente di recente dal capo dell'azienda Weaveworks \u2014 Alexis Richardson \u2014 e si riferisce all'utilizzo di strumenti familiari agli sviluppatori (soprattutto Git, da cui il nome) per risolvere le sfide operative. In particolare, si tratta dell'operativit\u00e0 di Kubernetes tramite l'archiviazione delle sue configurazioni in Git e il rilascio automatico delle modifiche nel cluster. Di due approcci a questo rilascio parla Matthias Jg in questo articolo.<\/a><\/noindex> Lo scorso anno<\/i><\/p>\n

\"GitOps:
\n
\n(in realt\u00e0, formalmente \u00e8 avvenuto ad agosto 2017 \u2014 nota del traduttore) \u00e8 emerso un nuovo approccio per il deployment delle applicazioni in Kubernetes. Si chiama GitOps e si basa sul concetto fondamentale che il monitoraggio delle versioni dei deployment avviene in un ambiente Git sicuro.<\/i> I principali vantaggi di questo approccio sono i seguenti<\/a><\/noindex><\/p>\n

Versionamento dei deployment e cronologia delle modifiche<\/b>:<\/p>\n

    \n
  1. . Lo stato dell'intero cluster \u00e8 archiviato in un repository Git, e i deployment vengono aggiornati solo tramite commit. Inoltre, tutte le modifiche possono essere monitorate grazie alla cronologia dei commit.<\/b>Rollback utilizzando i comandi Git familiari<\/li>\n
  2. . \u00c8 semplice<\/b>restituire modifiche ai deployment; passati stati sono sempre disponibili. git reset<\/code> Controllo degli accessi gi\u00e0 pronto<\/li>\n
  3. . Di solito, un sistema Git contiene molti dati riservati, quindi la maggior parte delle aziende presta particolare attenzione alla sua protezione. Di conseguenza, questa protezione si applica anche alle operazioni sui deployment.<\/b>Politiche per i deployment<\/li>\n
  4. . La maggior parte dei sistemi Git supporta politiche per diversi branch \u2014 ad esempio, solo le pull request possono aggiornare il master, e le modifiche devono essere verificate e approvate da un altro membro del team. Come per il controllo degli accessi, le stesse politiche si applicano agli aggiornamenti dei deployment.<\/b>Come potete vedere, il metodo GitOps ha numerosi vantaggi. Nell'ultimo anno, due approcci hanno guadagnato particolare popolarit\u00e0. Uno \u00e8 basato sul push, l'altro sul pull. Prima di esaminarli, diamo un'occhiata a come appaiono i tradizionali deployment di Kubernetes.<\/li>\n<\/ol>\n

    \nMetodi di deployment<\/p>\n

    Negli ultimi anni, in Kubernetes si sono consolidati diversi metodi e strumenti per i deployment:<\/h2>\n

    \nBasati su modelli nativi Kubernetes\/Kustomize<\/p>\n

      \n
    1. Basato su modelli nativi di Kubernetes\/Kustomize<\/b>. Questo \u00e8 il modo pi\u00f9 semplice per distribuire applicazioni su Kubernetes. Lo sviluppatore crea file YAML di base e li applica. Per evitare di scrivere costantemente gli stessi modelli, \u00e8 stato sviluppato Kustomize (che trasforma i modelli Kubernetes in moduli). Nota di traduzione.<\/b>: Kustomize \u00e8 stato integrato in kubectl con il rilascio di Kubernetes 1.14<\/a><\/noindex>.<\/i><\/li>\n
    2. Chart di Helm<\/b>. I Chart di Helm permettono di creare set di modelli, init-container, sidecar e cos\u00ec via, che vengono applicati per distribuire applicazioni con possibilit\u00e0 di configurazione pi\u00f9 flessibili rispetto all'approccio basato su modelli. Alla base di questo metodo ci sono file YAML templated. Helm li riempie di vari parametri e poi li invia a Tiller \u2014 il componente cluster che li distribuisce nel cluster e consente di eseguire aggiornamenti e rollback. \u00c8 importante notare che sostanzialmente Helm inserisce solo i valori necessari nei modelli e poi li applica proprio come si fa nell'approccio tradizionale (per maggiori dettagli su come funziona tutto ci\u00f2 e come si pu\u00f2 utilizzare, leggi il nostro articolo su Helm<\/a><\/noindex> \u2014 nota del traduttore.)<\/i>. Esiste una grande variet\u00e0 di Chart di Helm pronti, che coprono un ampio spettro di compiti.<\/li>\n
    3. Strumenti alternativi<\/b>. Ci sono molti strumenti alternativi. Tutti loro hanno in comune il fatto che trasformano certi file-modello in chiari file YAML di Kubernetes e poi li applicano.<\/li>\n<\/ol>\n

      \nNel nostro lavoro utilizziamo costantemente i Chart di Helm per strumenti importanti (poich\u00e9 molte cose sono gi\u00e0 pronte, il che semplifica notevolmente la vita) e file YAML 'puliti' di Kubernetes per distribuire le nostre applicazioni.<\/p>\n

      Pull & Push<\/h2>\n

      \nIn uno dei miei recenti post sul blog, ho presentato uno strumento Weave Flux<\/a><\/noindex>, che consente di impegnare i modelli 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 promuovere l'approccio pull, quindi far\u00f2 spesso riferimento ad esso. Se vuoi saperne di pi\u00f9 su come usarlo, ecco il link all'articolo<\/a><\/noindex>.<\/p>\n

      NB!<\/b> Tutti i vantaggi dell'utilizzo di GitOps rimangono per 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 il Docker Registry associati. Se ci sono delle modifiche, lo stato del cluster viene aggiornato dall'interno. Si considera generalmente che questo processo sia piuttosto sicuro, poich\u00e9 nessun cliente esterno ha accesso ai diritti di amministratore del cluster.<\/p>\n

      Pro:<\/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. Alcuni strumenti consentono anche di sincronizzare gli aggiornamenti dei chart di Helm e di collegarli al cluster.<\/li>\n
      3. Il Docker Registry pu\u00f2 essere scansionato per nuove versioni. Se viene rilasciata una nuova immagine, il repository Git e il deployment vengono aggiornati alla nuova versione.<\/li>\n
      4. Gli strumenti pull possono essere distribuiti in diversi spazi dei nomi con repository Git e diritti di accesso diversi. 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 lo 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 archiviati in forma crittografata nel repository Git e estratti all'interno del cluster.<\/li>\n
      7. Non esiste un collegamento con i pipeline CD, poich\u00e9 i deployment avvengono all'interno del cluster.<\/li>\n<\/ol>\n

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

          \n
        1. Gestire i segreti dei deployment dai chart di Helm \u00e8 pi\u00f9 complesso rispetto a quelli normali, poich\u00e9 devono prima essere generati come, ad esempio, sealed secrets, quindi decrittografati dall'operatore interno e solo dopo diventano accessibili per lo strumento pull. Successivamente, \u00e8 possibile eseguire il 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 di Helm utilizzati per il deployment, decrittografarlo e committarlo in Git.<\/li>\n
        2. Applicando un approccio pull, sei legato a strumenti che operano tramite pull. Questo limita la possibilit\u00e0 di personalizzare il processo di distribuzione degli deployment nel cluster. Ad esempio, lavorare con Kustomize \u00e8 complicato perch\u00e9 deve essere eseguito prima che i modelli finali vengano inviati in 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
          \nNell'approccio push, un sistema esterno (principalmente pipeline CD) avvia le distribuzioni nel cluster dopo un commit nel repository Git o in caso di esecuzione riuscita di una pipeline CI precedente. In questo approccio, il sistema ha accesso al cluster.<\/p>\n

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

            \n
          1. La sicurezza \u00e8 definita dal repository Git e dalla pipeline di build.<\/li>\n
          2. Distribuire i chart Helm \u00e8 pi\u00f9 semplice, poich\u00e9 c'\u00e8 supporto per i plugin Helm.<\/li>\n
          3. Gestire i segreti \u00e8 pi\u00f9 facile, poich\u00e9 i segreti possono essere utilizzati nelle pipeline e anche memorizzati in Git in forma crittografata (a seconda delle preferenze dell'utente).<\/li>\n
          4. Assenza di legame con strumenti specifici, poich\u00e9 possono essere utilizzati tutti i loro tipi.<\/li>\n
          5. Gli aggiornamenti delle versioni dei container possono essere avviati dalla pipeline di build.<\/li>\n<\/ol>\n

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

              \n
            1. I dati per accedere al cluster si trovano all'interno del sistema di build.<\/li>\n
            2. L'aggiornamento dei container degli deployment \u00e8 comunque pi\u00f9 facile con un processo pull.<\/li>\n
            3. Forti dipendenze dal sistema CD, poich\u00e9 le pipeline necessarie potrebbero essere state originariamente scritte per i Gitlab Runners, e poi il team decide di passare ad Azure DevOps o Jenkins\u2026 e sar\u00e0 necessario migrare un gran numero di pipeline di build.<\/li>\n<\/ol>\n

              <\/p>\n

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

              \nCome spesso accade, ogni approccio ha i suoi pro e contro. Alcuni compiti sono pi\u00f9 facili da eseguire con un metodo e pi\u00f9 difficili con un altro. All'inizio eseguivo i deployment 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 poi ho iniziato a riscontrare difficolt\u00e0 nel lavoro con i chart di Helm. A quel tempo, Weave Flux offriva solo una versione embrionale dell'Operator per Helm Chart, 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 al di fuori di esso, il che aumenta cos\u00ec tanto la sicurezza da giustificare lo sforzo aggiuntivo.<\/p>\n

              Riflettendo un po', sono giunto a una conclusione inaspettata: non \u00e8 cos\u00ec. Se parliamo di componenti che richiedono la massima protezione, un tale elenco includerebbe i repository di segreti e i sistemi CI\/CD, i repository Git. Le informazioni all'interno di essi sono piuttosto vulnerabili e necessitano di protezione massima. Inoltre, se qualcuno riesce a penetrare nel tuo repository Git e pu\u00f2 pushare del codice, pu\u00f2 implementare qualsiasi cosa desideri (indipendentemente dall'approccio scelto, sia esso pull o push) e infiltrarsi nei sistemi del cluster. Pertanto, i componenti pi\u00f9 critici che necessitano di protezione sono il repository Git e i sistemi CI\/CD, non le credenziali del cluster. Se hai politiche e misure di sicurezza ben configurate per sistemi di questo tipo, e le credenziali del cluster vengono estratte nei pipeline solo come segreti, la protezione aggiuntiva dell'approccio pull potrebbe rivelarsi meno preziosa di quanto inizialmente previsto.<\/p>\n

              Quindi, se l'approccio pull \u00e8 pi\u00f9 laborioso e non offre guadagni in termini di sicurezza, non sarebbe logico utilizzare solo l'approccio push? Ma qualcuno potrebbe obiettare che con l'approccio push sei troppo legato al sistema CD e, forse, sarebbe meglio evitarlo, in modo che in futuro sia pi\u00f9 semplice effettuare migrazioni.<\/p>\n

              A mio avviso (come sempre), \u00e8 opportuno utilizzare ci\u00f2 che si adatta meglio al caso specifico o combinare le opzioni. Personalmente, utilizzo entrambi gli approcci: Weave Flux per i deployment basati su pull, che includono principalmente i nostri servizi, e l'approccio push con Helm e plugin, che semplifica l'applicazione dei chart Helm al cluster e consente di creare facilmente segreti. Penso che non ci sar\u00e0 mai una soluzione unica adatta a tutte le situazioni, perch\u00e9 ci sono sempre molti dettagli da considerare e dipendono dal caso d'uso specifico. A questo proposito, consiglio vivamente GitOps: facilita notevolmente le operazioni e aumenta la sicurezza.<\/p>\n

              Spero che la mia esperienza su questo tema possa aiutarti a decidere quale metodo si adatta 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 contro del modello pull c'\u00e8 il fatto che \u00e8 difficile caricare in Git i manifesti renderizzati, tuttavia non c'\u00e8 lo svantaggio che il pipeline CD nel modello pull vive separatamente dal rilascio e praticamente diventa un pipeline di categoria Continuous Apply<\/i>. Pertanto, sar\u00e0 necessario un ulteriore sforzo per raccogliere lo stato di tutti i deployment e fornire accesso ai log\/stato, preferibilmente con un legame al sistema CD.<\/p>\n

              In questo senso, il modello push consente di fornire alcune garanzie sul rilascio, poich\u00e9 la vita del pipeline pu\u00f2 essere allineata con la vita del rilascio.<\/p>\n

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

                \n
              1. Il modello pull \u00e8 adatto per l'aggiornamento dei componenti di sistema su un gran numero di cluster (vedi l'articolo sul addon-operator<\/a><\/noindex>).<\/li>\n
              2. Il modello push basato su GitLab CI \u00e8 ben adatto per il rilascio delle applicazioni utilizzando i chart Helm. Inoltre, 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 sentito continuamente \"GitOps\" quando discutevamo i problemi urgenti degli ingegneri DevOps al nostro stand di KubeCon Europe '19.<\/li>\n<\/ol>\n

                <\/p>\n

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

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