{"id":33654,"date":"2019-10-31T21:53:58","date_gmt":"2019-10-31T18:53:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/deploj-prilozhenij-v-vm-nomad-i-kubernetes\/"},"modified":"2019-10-31T21:53:58","modified_gmt":"2019-10-31T18:53:58","slug":"deploj-prilozhenij-v-vm-nomad-i-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","title":{"rendered":"Distribuzione di applicazioni in VM, Nomad e Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao a tutti! Mi chiamo Pavel Agaletsky. Lavoro come team leader nel team che sviluppa il sistema di consegna di Lamoda. Nel 2018 ho parlato alla conferenza HighLoad++, e oggi voglio presentarvi la trascrizione della mia presentazione.<\/p>\n

Il mio tema riguarda l'esperienza della nostra azienda nel deploy di sistemi e servizi in diverse ambienti. Cominciando dai nostri tempi preistorici, quando deployavamo tutti i sistemi su normali server virtuali, fino alla transizione graduale da Nomad al deploy su Kubernetes. Parler\u00f2 di perch\u00e9 l'abbiamo fatto e quali problemi abbiamo affrontato nel processo.<\/p>\n

\r\n \"Riproduci\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex><\/p>\n

Deploy delle applicazioni su VM<\/h1>\n

\nTre anni fa, tutti i sistemi e i servizi della nostra azienda venivano distribuiti su normali server virtuali. Dal punto di vista tecnico, era stato organizzato affinch\u00e9 tutto il codice dei nostri sistemi fosse gestito e costruito tramite strumenti di build automatizzati, utilizzando Jenkins. Utilizzando Ansible, veniva distribuito dai nostri sistemi di controllo versione sui server virtuali. Ogni sistema presente nella nostra azienda veniva distribuito almeno su due server: uno di essi era il head e l'altro il tail. Questi due sistemi erano assolutamente identici per quanto riguarda tutte le impostazioni, la potenza, la configurazione e altro. L'unica differenza tra loro era che il head riceveva il traffico degli utenti, mentre il tail non riceveva mai traffico degli utenti. <\/p>\n

A cosa serviva questo? <\/p>\n

Quando distribuivamo nuove versioni della nostra applicazione, volevamo garantire un rollout senza interruzioni, cio\u00e8 senza conseguenze visibili per gli utenti. Questo veniva raggiunto distribuendo ogni rilascio assemblato tramite Ansible sul tail. Qui, le persone impegnate nel deployment potevano controllare e verificare che tutto funzionasse correttamente: tutte le metriche, le sezioni e le applicazioni erano operative; venivano eseguiti gli script necessari. Solo dopo essersi assicurati che tutto fosse a posto, il traffico veniva instradato. Quest'ultimo iniziava a fluire verso il server che in precedenza era tail. Mentre quello che prima era head rimaneva senza traffico utente, sfruttando comunque la versione precedente della nostra applicazione.<\/p>\n

In questo modo, per gli utenti era senza soluzione di continuit\u00e0. Poich\u00e9 il passaggio \u00e8 immediato, trattandosi semplicemente di un cambio del bilanciatore. \u00c8 possibile tornare facilmente a una versione precedente semplicemente ripristinando il bilanciatore. Inoltre, potevamo verificare la capacit\u00e0 dell'applicazione in produzione prima che il traffico degli utenti vi affluissi, il che risultava piuttosto comodo. <\/p>\n

Quali vantaggi abbiamo riscontrato in tutto questo?<\/p>\n

    \n
  1. Innanzitutto, funziona abbastanza semplicemente.<\/b> A tutti \u00e8 chiaro come funzioni un sistema di deployment di questo tipo, poich\u00e9 la maggior parte delle persone ha mai effettuato il deployment su normali server virtuali.<\/li>\n
  2. \u00c8 abbastanza affidabile<\/b>, perch\u00e9 la tecnologia di deployment \u00e8 semplice, testata da migliaia di aziende. Milioni di server vengono distribuiti proprio in questo modo. \u00c8 difficile rompere qualcosa. <\/li>\n
  3. E infine, abbiamo potuto ottenere deploy atomici<\/b>. Deployment che avvengono simultaneamente per gli utenti, senza un evidente passaggio tra la vecchia versione e la nuova. <\/li>\n<\/ol>\n

    \nMa in tutto questo abbiamo anche visto alcuni svantaggi: <\/p>\n

      \n
    1. Oltre all'ambiente di produzione e a quello di sviluppo, ci sono anche altri ambienti. Ad esempio, qa e preproduzione. A quel tempo avevamo molti server e circa 60 servizi. Per questo motivo era necessario mantenere la versione appropriata per ogni servizio <\/b>macchina virtuale. Se desideri aggiornare le librerie o installare nuove dipendenze, devi farlo in tutte le ambienti. \u00c8 inoltre necessario sincronizzare il momento in cui intendi distribuire una nuova versione della tua applicazione con il momento in cui il team devops eseguir\u00e0 le necessarie configurazioni dell'ambiente. In questo modo, \u00e8 facile finire in una situazione in cui l'ambiente differisce in modo significativo tra tutti gli ambienti. Ad esempio, nell'ambiente QA potrebbero esserci versioni di librerie diverse rispetto a quelle in produzione, il che porter\u00e0 a problemi. <\/li>\n
    2. Difficolt\u00e0 nell'aggiornamento delle dipendenze<\/b> della tua applicazione. Questo non dipende da te, ma da un altro team. In particolare, dal team devops che gestisce i server. Devi assegnare loro il compito appropriato e fornire una descrizione di quello che desideri fare.<\/li>\n
    3. All'epoca volevamo anche suddividere i grandi monoliti che avevamo in piccoli servizi, consapevoli che sarebbero diventati sempre pi\u00f9 numerosi. A quel tempo, ne avevamo gi\u00e0 oltre 100. Era necessario creare una nuova macchina virtuale separata per ogni nuovo servizio, da mantenere e distribuire. Inoltre, non era sufficiente avere una sola macchina, ma almeno due. A tutto ci\u00f2 si aggiungeva anche un ambiente QA. Questo crea problemi e rende la creazione e l'avvio di nuovi sistemi pi\u00f9 complesso, costoso e lungo.<\/b><\/li>\n<\/ol>\n

      \nPerci\u00f2 abbiamo deciso che sarebbe stato pi\u00f9 pratico passare dal deployment di normali macchine virtuali al deployment delle nostre applicazioni in container Docker. Con Docker, \u00e8 necessaria una piattaforma che possa avviare l'applicazione in un cluster, dato che non \u00e8 possibile avviare un container cos\u00ec facilmente. Di solito, si desidera monitorare quanti container sono attivi affinch\u00e9 vengano avviati automaticamente. Per questo motivo, era necessario scegliere un sistema di gestione. <\/p>\n

      Abbiamo riflettuto a lungo su quale scegliere. Il fatto \u00e8 che, a quel tempo, questo stack di deployment su normali server virtuali era un po' obsoleto, poich\u00e9 presentava versioni di sistema operativo non recenti. A un certo punto, c'era persino FreeBSD, che era poco conveniente da mantenere. Abbiamo capito che era necessario migrare il prima possibile a Docker. I nostri DevOps hanno esaminato la loro esperienza con diverse soluzioni e hanno scelto un sistema come Nomad. <\/p>\n

      Transizione a Nomad<\/h1>\n

      \nNomad \u00e8 un prodotto dell'azienda \"HashiCorp\". Sono anche noti per altre loro soluzioni:<\/p>\n

      \"Distribuzione
      \n
      \n\"Consul\"<\/b> \u00e8 uno strumento per la scoperta dei servizi.<\/p>\n

      \"Terraform\"<\/b> \u00e8 un sistema di gestione dei server che consente di configurarli tramite configurazioni, note come infrastructure-as-code.<\/p>\n

      \"Vagrant\"<\/b> permette di distribuire macchine virtuali localmente o nel cloud tramite specifici file di configurazione. <\/p>\n

      Nomad si \u00e8 rivelato una soluzione piuttosto semplice da adottare, permettendo un passaggio rapido senza dover modificare completamente l'intera infrastruttura. Inoltre, \u00e8 abbastanza facile da imparare. \u00c8 per questo motivo che lo abbiamo scelto come sistema di filtraggio per il nostro container. <\/p>\n

      Cosa serve per distribuire il vostro sistema su Nomad? <\/p>\n

        \n
      1. Prima di tutto, serve un'immagine docker<\/b> della vostra applicazione. \u00c8 necessario costruirla e caricarla in un repository di immagini docker. Nel nostro caso, utilizziamo artifactory, un sistema che consente di caricare diversi tipi di artefatti. \u00c8 capace di memorizzare archivi, immagini docker, pacchetti composer PHP, pacchetti NPM e cos\u00ec via. <\/li>\n
      2. Sono inoltre necessari un file di configurazione<\/b>, che indica a Nomad cosa, dove e in quale quantit\u00e0 volete distribuire. <\/li>\n<\/ol>\n

        \nQuando parliamo di Nomad, il formato del file di configurazione utilizza il linguaggio HCL, che sta per HashiCorp Configuration Language<\/i>. Questo \u00e8 un superinsieme di YAML, che consente di descrivere il vostro servizio in termini di Nomad. <\/p>\n

        \"Distribuzione
        \n
        \nPermette di specificare quanti contenitori si desidera distribuire e di trasmettere vari parametri durante il deployment attraverso le immagini. In questo modo, fornisci questo file a Nomad, il quale avvia i contenitori in produzione in base a esso. <\/p>\n

        Nel nostro caso, abbiamo capito che scrivere file HCL identici per ogni servizio non sarebbe stato molto pratico, poich\u00e9 ci sono molti servizi e a volte \u00e8 necessario aggiornarli. Pu\u00f2 capitare che un servizio sia distribuito non in un'unica istanza, ma in diverse. Ad esempio, uno dei sistemi in produzione ha pi\u00f9 di 100 istanze attive. Vengono avviati dagli stessi immagini, ma differiscono per impostazioni di configurazione e file di configurazione. <\/p>\n

        Per questo motivo, abbiamo deciso che sarebbe stato comodo conservare tutti i nostri file di configurazione per il deployment in un unico repository comune. In questo modo, sono diventati consultabili: era facile mantenerli e si poteva vedere quali sistemi abbiamo. In caso di necessit\u00e0, non \u00e8 difficile aggiornare o modificare qualcosa. Aggiungere un nuovo sistema non comporta nemmeno difficolt\u00e0: basta creare un file di configurazione all'interno di una nuova directory. Al suo interno ci sono i file: service.hcl, che contiene la descrizione del nostro servizio, e alcuni file env, che consentono di configurare il servizio stesso quando viene deployato in produzione. <\/p>\n

        \"Distribuzione
        \n
        \nTuttavia, alcuni dei nostri sistemi sono deployati in produzione non in un solo esemplare, ma in pi\u00f9 contemporaneamente. Per questo motivo, abbiamo deciso che sarebbe stato pi\u00f9 comodo conservare non i config in forma grezza, ma la loro versione template. E come linguaggio di templating abbiamo scelto jinja 2<\/i>. In questo formato, abbiamo archiviati sia i config del servizio stesso che i file env necessari per esso. <\/p>\n

        Inoltre, abbiamo inserito nel repository comune per tutti i progetti uno script di deployment che consente di avviare e distribuire il tuo servizio in produzione, nell'ambiente desiderato e nel target specifico. Nel caso in cui abbiamo trasformato la nostra configurazione HCL in un modello, il file HCL, che in precedenza era una normale configurazione Nomad, appare ora in modo leggermente diverso.<\/p>\n

        \"Distribuzione
        \n
        \nIn altre parole, abbiamo sostituito alcune variabili nella configurazione con inserimenti di variabili provenienti da file env o da altre fonti. Inoltre, abbiamo ottenuto la possibilit\u00e0 di generare file HCL in modo dinamico, consentendo non solo di applicare normali inserimenti di variabili. Poich\u00e9 jinja supporta i cicli e le condizioni, \u00e8 possibile creare file di configurazione che cambiano a seconda di dove distribuisci le tue applicazioni. <\/p>\n

        Ad esempio, desiderate deployare il vostro servizio in preproduzione e in produzione. Supponiamo che in preproduzione non vogliate eseguire script cron, ma semplicemente vedere il servizio su un dominio separato per assicurarvi che funzioni. Per chiunque stia deployando un servizio, il processo appare molto semplice e trasparente. \u00c8 sufficiente eseguire il file deploy.sh, specificare quale servizio si desidera deployare e in quale target. Ad esempio, si desidera deployare un sistema in Russia, in Bielorussia o in Kazakistan. Per fare ci\u00f2, \u00e8 sufficiente modificare uno dei parametri e otterrete il file di configurazione corretto. <\/p>\n

        Quando il servizio Nomad \u00e8 gi\u00e0 stato deployato nel cluster, si presenta nel seguente modo.<\/p>\n

        \"Distribuzione
        \n
        \nPer prima cosa, avete bisogno di un bilanciatore esterno che accetti tutto il traffico degli utenti. Questo funzioner\u00e0 insieme a Consul e chieder\u00e0 a questo ultimo dove, su quale nodo, per quale indirizzo IP<\/a> c'\u00e8 un servizio specifico che corrisponde a un determinato nome di dominio. I servizi in Consul emergono direttamente da Nomad. Poich\u00e9 sono prodotti della stessa azienda, sono ben collegati tra loro. Si pu\u00f2 dire che Nomad registra automaticamente tutti i servizi avviati al suo interno in Consul. <\/p>\n

        Una volta che il tuo bilanciatore esterno sa a quale servizio deve inviare il traffico, lo reindirizza nel contenitore corrispondente o in pi\u00f9 contenitori associati alla tua applicazione. \u00c8 fondamentale considerare anche la sicurezza. Anche se tutti i servizi sono avviati sulle stesse macchine virtuali nei contenitori, di solito \u00e8 necessario vietare l'accesso libero da un servizio a un altro. Abbiamo raggiunto questo obiettivo attraverso la segmentazione. Ogni servizio veniva eseguito nella propria rete virtuale, sulla quale erano definite regole di instradamento e di autorizzazione\/divieto di accesso ad altri sistemi e servizi. Questi potevano trovarsi sia all'interno che all'esterno di questo cluster. Ad esempio, se vuoi vietare a un servizio di connettersi a un determinato database, puoi farlo tramite la segmentazione a livello di rete. In altre parole, anche per errore non puoi accidentalmente collegarti dal tuo ambiente di test al tuo database di produzione.<\/p>\n

        Qual \u00e8 stato il costo del processo di transizione in termini di risorse umane? <\/p>\n

        Il passaggio di tutta l'azienda a Nomad ha richiesto circa 5-6 mesi. Siamo transitati servizio per servizio, ma a un ritmo piuttosto veloce. Ogni team doveva creare i propri contenitori per i servizi. <\/p>\n

        Adottiamo un approccio in cui ogni team \u00e8 responsabile delle immagini Docker dei propri sistemi. I DevOps forniscono l'infrastruttura generale necessaria per il deployment, cio\u00e8 il supporto per il cluster stesso, il supporto per il sistema CI e cos\u00ec via. Fino a quel momento, oltre 60 sistemi erano stati trasferiti in Nomad, generando circa 2000 contenitori. <\/p>\n

        I DevOps si occupano dell'infrastruttura generale relativa al deployment e ai server. Ogni team di sviluppo, a sua volta, \u00e8 responsabile della realizzazione dei contenitori per il proprio sistema specifico, poich\u00e9 \u00e8 il team che sa esattamente di cosa ha bisogno in ogni contenitore.<\/p>\n

        Motivi per rifiutare Nomad<\/h1>\n

        \nQuali vantaggi abbiamo ottenuto passando al deployment tramite Nomad e Docker?<\/p>\n

          \n
        1. Noi abbiamo garantito condizioni uniformi<\/b> per tutti gli ambienti. Nello sviluppo, nell'ambiente QA, nella pre-produzione e nella produzione vengono utilizzate le stesse immagini dei container, con le stesse dipendenze. Di conseguenza, avete praticamente zero possibilit\u00e0 che in produzione finisca qualcosa di diverso da ci\u00f2 che avete testato localmente o nell'ambiente di test. <\/li>\n
        2. Inoltre, abbiamo scoperto che \u00e8 abbastanza facile aggiungere un nuovo servizio<\/b>. Qualsiasi nuovo sistema, dal punto di vista del deployment, si avvia molto facilmente. Basta andare nel repository che contiene le configurazioni, aggiungere la nuova configurazione per il vostro sistema e il gioco \u00e8 fatto. Potete deployare il vostro sistema in produzione senza sforzi aggiuntivi da parte del DevOps. <\/li>\n
        3. Tutti file di configurazione<\/b> in un unico repository generale risultano visualizzabili<\/b>. Nel momento in cui abbiamo effettuato il deployment dei nostri sistemi tramite server virtuali<\/a>, abbiamo utilizzato Ansible, in cui le configurazioni erano tutte nello stesso repository. Tuttavia, per la maggior parte degli sviluppatori, lavorare con questo era un po' pi\u00f9 complesso. Qui, il volume di configurazioni e codice necessario per l'implementazione del servizio \u00e8 notevolmente diminuito. Inoltre, per i DevOps \u00e8 molto semplice modificarlo o cambiarlo. In caso di aggiornamenti, ad esempio, a una nuova versione di Nomad, possono facilmente aggiornare massivamente tutti i file operativi che si trovano nello stesso posto.<\/li>\n<\/ol>\n

          \nMa ci siamo anche imbattuti in diversi svantaggi: <\/p>\n

          Si \u00e8 rivelato che non siamo riusciti a raggiungere la continuit\u00e0 nelle distribuzioni <\/b>nel caso di Nomad. Durante il rilascio dei container da condizioni diverse, pu\u00f2 accadere che venga avviato e Nomad lo percepisca come pronto a ricevere traffico. Questo avveniva prima che l'applicazione al suo interno avesse avuto il tempo di avviarsi. Per questo motivo, il sistema iniziava a restituire temporaneamente errori 500, poich\u00e9 il traffico cominciava a dirigersi a un container che non era ancora pronto per riceverlo. <\/p>\n

          Abbiamo riscontrato alcuni bug<\/b>. Il principale problema \u00e8 che Nomad non gestisce bene un grande cluster quando hai molte macchine e contenitori. Quando desideri mettere in manutenzione uno dei server che fa parte del cluster Nomad, c'\u00e8 una buona probabilit\u00e0 che il cluster non si senta bene e si rompa. Alcuni contenitori potrebbero, ad esempio, andare in crash e non riavviarsi \u2014 questo ti coster\u00e0 molto, soprattutto se tutti i tuoi sistemi in produzione si trovano all'interno di un cluster gestito da Nomad. <\/p>\n

          Perci\u00f2 abbiamo deciso di riflettere su quale direzione intraprendere. A quel punto, eravamo molto pi\u00f9 consapevoli di ci\u00f2 che volevamo raggiungere. In particolare: desideravamo affidabilit\u00e0, un po' pi\u00f9 di funzionalit\u00e0 rispetto a quelle fornite da Nomad e un sistema pi\u00f9 maturo, pi\u00f9 stabile. <\/p>\n

          In questo senso, la nostra scelta \u00e8 ricaduta su Kubernetes come la piattaforma pi\u00f9 popolare per il lancio di cluster. Soprattutto considerando che la dimensione e il numero dei nostri contenitori erano piuttosto grandi. Per tali scopi, Kubernetes sembrava il sistema pi\u00f9 adatto tra quelli che potevamo esaminare. <\/p>\n

          Transizione a Kubernetes<\/h1>\n

          \nParler\u00f2 un po' dei concetti fondamentali di Kubernetes e di come si differenziano da Nomad. <\/p>\n

          \"Distribuzione
          \n
          \nIl concetto di base in Kubernetes \u00e8 il pod. Pod<\/b> \u00e8 un gruppo di uno o pi\u00f9 contenitori che vengono sempre eseguiti insieme. Funzionano come se fossero sempre rigorosamente su una sola macchina virtuale. Possono comunicare tra loro tramite l'indirizzo IP 127.0.0.1 su porte diverse. <\/p>\n

          Supponiamo di avere un'applicazione PHP composta da nginx e php-fpm \u2013 uno schema classico. Probabilmente vorrete che i contenitori nginx e php-fpm siano sempre insieme. Kubernetes consente di raggiungere questo obiettivo descrivendoli come un unico pod. Questo \u00e8 esattamente ci\u00f2 che non potevamo ottenere usando Nomad.<\/p>\n

          Il secondo concetto \u00e8 deployment<\/b>. Il pod, di per s\u00e9, \u00e8 un'entit\u00e0 effimera, viene avviato e scompare. Volete eliminare prima tutti i vostri contenitori precedenti e poi avviare nuove versioni, oppure desiderate distribuirle gradualmente? \u00c8 per questo processo che si parla di deployment. Esso descrive come si deployano i vostri pod, in quale quantit\u00e0 e come aggiornarli. <\/p>\n

          Il terzo concetto \u00e8 service<\/b>. Il tuo service \u00e8 fondamentalmente il tuo sistema, che riceve un certo traffico e poi lo indirizza a uno o pi\u00f9 pod che corrispondono al tuo servizio. Questo significa che puoi specificare che tutto il traffico in entrata per un determinato servizio con un certo nome deve essere inviato esattamente a questi pod. Inoltre, offre bilanciamento del traffico. Puoi avviare due pod della tua applicazione e tutto il traffico in entrata sar\u00e0 bilanciato uniformemente tra i pod associati a questo servizio.<\/p>\n

          E il quarto concetto fondamentale \u2014 Ingress<\/b>. Questo \u00e8 un servizio che viene eseguito in un cluster Kubernetes. Funziona come un bilanciatore di carico esterno, che riceve tutte le richieste. Grazie all'API Kubernetes Ingress, \u00e8 in grado di determinare dove inviare queste richieste. Lo fa in modo molto flessibile. Puoi specificare che tutte le richieste per questo host e un certo URL devono essere inviate a questo servizio. Mentre queste richieste, che arrivano su questo host e su un altro URL, vengono inviate a un altro servizio. <\/p>\n

          La cosa pi\u00f9 interessante per un sviluppatore \u00e8 che pu\u00f2 gestire tutto autonomamente. Configurando l'Ingress, puoi indirizzare tutto il traffico che arriva su un determinato API a contenitori separati, ad esempio scritti in Go. Mentre quel traffico che arriva sullo stesso dominio, ma su un'altra URL, pu\u00f2 essere reindirizzato a contenitori scritti in PHP, dove c'\u00e8 molta logica, anche se non sono molto veloci.<\/p>\n

          Se confrontiamo tutti questi concetti con Nomad, possiamo dire che i primi tre concetti si uniscono a formare il Service. L'ultimo concetto, invece, non \u00e8 presente in Nomad. Noi lo abbiamo sostituito con un bilanciatore esterno: pu\u00f2 essere haproxy, nginx, nginx+ e cos\u00ec via. Nel caso del cluster, non \u00e8 necessario introdurre questo concetto separatamente. Tuttavia, se guardiamo dentro Ingress, vediamo che \u00e8 o nginx, o haproxy, o traefik, ma integrato in Kubernetes. <\/p>\n

          Tutti i concetti che ho descritto sono, in sostanza, risorse che esistono all'interno di un cluster Kubernetes. Per descriverli in Kubernetes viene utilizzato il formato yaml, che \u00e8 pi\u00f9 leggibile e familiare rispetto ai file HCL in Nomad. Strutturalmente, descrivono lo stesso concetto, ad esempio, di un pod. Indicano - voglio distribuire questi pod in questo luogo, con queste immagini, in questa quantit\u00e0. <\/p>\n

          \"Distribuzione
          \n
          \nInoltre, abbiamo capito che non volevamo creare manualmente ogni singola risorsa: deployment, servizi, Ingress e altro. Invece, volevamo descrivere ogni nostro sistema in termini di Kubernetes al momento della distribuzione, in modo da non dover ricreare manualmente nell'ordine corretto tutte le dipendenze necessarie delle risorse. Per fare questo, abbiamo scelto Helm come sistema. <\/p>\n

          Concetti fondamentali in Helm<\/h1>\n

          \nHelm \u00e8 un gestore di pacchetti<\/b> per Kubernetes. \u00c8 molto simile al funzionamento dei gestori di pacchetti nei linguaggi di programmazione. Permettono di archiviare un servizio composto, ad esempio, da un deployment di nginx, un deployment di php-fpm, una configurazione per Ingress, configmaps (un'entit\u00e0 che consente di impostare variabili d'ambiente e altri parametri per il sistema) sotto forma di cosiddetti chart. In questo processo, Helm opera sopra Kubernetes<\/b>. Cio\u00e8, non \u00e8 un sistema separato, ma solo un altro servizio eseguito all'interno del cluster. Interagisci con esso tramite la sua API attraverso comandi in console. La sua comodit\u00e0 e bellezza risiedono nel fatto che, anche se Helm si guasta o lo rimuovi dal cluster, i tuoi servizi non scompariranno, poich\u00e9 Helm serve sostanzialmente solo per l'avvio del sistema. La funzionalit\u00e0 e lo stato dei servizi vengono gestiti direttamente da Kubernetes. <\/p>\n

          Inoltre, abbiamo compreso che la templating<\/b>, che prima eravamo costretti a fare manualmente tramite l'integrazione di jinja nei nostri configurazioni, \u00e8 una delle funzionalit\u00e0 principali di helm. Tutte le configurazioni che crei per i tuoi sistemi sono memorizzate in helm come modelli, simili a jinja, ma in realt\u00e0 utilizzano il sistema di templating del linguaggio Go, su cui helm \u00e8 scritto, proprio come Kubernetes. <\/p>\n

          Helm ci aggiunge anche alcuni concetti aggiuntivi. <\/p>\n

          Chart<\/b> \u2014 \u00e8 una descrizione del tuo servizio. Negli altri gestori di pacchetti, sarebbe chiamato pacchetto, bundle o qualcosa di simile. Qui si chiama chart. <\/p>\n

          Values <\/b>\u2013 sono le variabili che vuoi utilizzare per costruire le tue configurazioni dai modelli. <\/p>\n

          Release<\/b>. Ogni volta che un servizio viene deployato tramite helm, riceve una versione incrementale del rilascio. Helm ricorda quale fosse la configurazione del servizio nel rilascio precedente, in quello ancora prima, e cos\u00ec via. Pertanto, se \u00e8 necessario tornare indietro, basta eseguire il comando helm callback specificando la versione precedente del rilascio. Anche se al momento del rollback la configurazione corrispondente non \u00e8 disponibile nel tuo repository, helm ricorda comunque qual era, e riporter\u00e0 il tuo sistema allo stato in cui si trovava nel rilascio precedente. <\/p>\n

          Nel caso in cui utilizziamo helm, le normali configurazioni per Kubernetes si trasformano anche in modelli, nei quali \u00e8 possibile utilizzare variabili, funzioni e applicare operatori condizionali. In questo modo, puoi assembleare la configurazione del tuo servizio a seconda dell'ambiente.<\/p>\n

          \"Distribuzione
          \n
          \nIn pratica, abbiamo deciso di procedere in modo leggermente diverso rispetto a quanto fatto con Nomad. Se in Nomad nel medesimo repository erano memorizzati sia i file di configurazione per il deployment che le variabili n necessarie per il deployment del nostro servizio, qui abbiamo deciso di separarle in due repository distinti. Nel repository \"deploy\" sono memorizzate solo le variabili n necessarie per il deployment, mentre nel repository \"helm\" sono conservate le configurazioni o i chart.<\/p>\n

          \"Distribuzione
          \n
          \nCosa ci ha dato questo? <\/p>\n

          Nonostante nei file di configurazione non memorizziamo dati realmente sensibili, come ad esempio le password per i database, che vengono conservate come secrets in Kubernetes, ci sono comunque elementi a cui non desideriamo dare accesso indiscriminato. Pertanto, l'accesso al repository \"deploy\" \u00e8 pi\u00f9 limitato, mentre il repository \"helm\" contiene semplicemente una descrizione del servizio. Per questo motivo, \u00e8 possibile concedere accesso a un numero maggiore di persone in modo sicuro. <\/p>\n

          Poich\u00e9 abbiamo non solo un ambiente di produzione, ma anche altri ambienti, grazie a questa separazione possiamo riutilizzare i nostri helm chart per distribuire i servizi non solo in produzione, ma anche, ad esempio, nell'ambiente QA. Anche per implementarli localmente, usando Minikube<\/i> \u2014 \u00e8 uno strumento per l'esecuzione locale di Kubernetes. <\/p>\n

          All'interno di ogni repository abbiamo mantenuto una suddivisione in directory separate per ogni servizio. In altre parole, all'interno di ogni directory ci sono i modelli relativi al chart corrispondente che descrivono le risorse necessarie per avviare il nostro sistema. Nel repository \"deploy\" abbiamo lasciato solo le variabili ambientali. In questo caso non abbiamo utilizzato la templating con jinja, perch\u00e9 helm fornisce gi\u00e0 la templating out of the box \u2013 \u00e8 una delle sue principali funzionalit\u00e0. <\/p>\n

          Abbiamo fornito uno script per il deployment \u2013 deploy.sh, che semplifica e standardizza l'avvio per il deployment con helm. In questo modo, per chiunque desideri effettuare un deployment, l'interfaccia di deployment appare esattamente come nel caso del deployment tramite Nomad. Lo stesso deploy.sh, il nome del tuo servizio e il luogo in cui vuoi effettuare il deployment. Questo fa s\u00ec che all'interno venga avviato helm. Esso raccoglie i file di configurazione dai modelli, inserisce i file values necessari e poi effettua il deployment, rilasciandoli in Kubernetes. <\/p>\n

          Conclusioni<\/h1>\n

          \nIl servizio Kubernetes appare pi\u00f9 complesso rispetto a Nomad. <\/p>\n

          \"Distribuzione
          \n
          \nQui il traffico in uscita arriva nell'Ingress. Questo funge da controller frontale, che riceve tutte le richieste e poi le inoltra ai servizi corrispondenti ai dati della richiesta. Li determina in base alle configurazioni, che fanno parte della descrizione della tua applicazione in helm e che i programmatori impostano autonomamente. Il servizio invia le richieste ai propri pod, cio\u00e8 ai contenitori specifici, bilanciando il traffico in entrata tra tutti i contenitori associati a quel servizio. E, ovviamente, non dobbiamo dimenticare che la sicurezza a livello di rete \u00e8 fondamentale. Pertanto, nel cluster Kubernetes viene implementata una segmentazione basata sulla marcatura. Tutti i servizi hanno determinati tag, a cui sono associate le autorizzazioni di accesso ai vari risorse esterne\/interne all'interno o all'esterno del cluster. <\/p>\n

          Durante la transizione, abbiamo notato che Kubernetes offre tutte le funzionalit\u00e0 di Nomad, che avevamo utilizzato in precedenza, aggiungendo anche molte novit\u00e0. \u00c8 possibile espanderlo tramite plugin e, di fatto, tramite tipi di risorse personalizzati. Ci\u00f2 significa che non solo \u00e8 possibile utilizzare ci\u00f2 che \u00e8 fornito in Kubernetes di default, ma si pu\u00f2 creare una risorsa e un servizio personalizzati che leggono la vostra risorsa. Questo offre ulteriori opportunit\u00e0 per espandere il vostro sistema senza dover reinstallare Kubernetes o effettuare modifiche. <\/p>\n

          Un esempio di tale utilizzo \u00e8 Prometheus, che viene eseguito all'interno del nostro cluster Kubernetes. Per iniziare a raccogliere metriche da un servizio, dobbiamo aggiungere alla descrizione del servizio un tipo di risorsa aggiuntivo, noto come service-monitor. Prometheus, essendo in grado di leggere tipi di risorse personalizzati mentre \u00e8 in esecuzione su Kubernetes, inizia automaticamente a raccogliere metriche dal nuovo sistema. Questo \u00e8 molto comodo. <\/p>\n

          Il primo deploy che abbiamo fatto in Kubernetes risale a marzo 2018. Da allora, non abbiamo mai riscontrato problemi. Funziona in modo piuttosto stabile senza bug significativi. Inoltre, possiamo espanderlo ulteriormente. Oggi abbiamo a disposizione tutte le funzionalit\u00e0 che ci servono, e siamo molto soddisfatti del ritmo di sviluppo di Kubernetes. Attualmente, pi\u00f9 di 3000 contenitori sono attivi in Kubernetes. Il cluster utilizza diversi nodi. \u00c8 gestibile, stabile e altamente controllato.
          \n
          Fonte:           habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

          \u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041f\u0430\u0432\u0435\u043b \u0410\u0433\u0430\u043b\u0435\u0446\u043a\u0438\u0439. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0442\u0438\u043c\u043b\u0438\u0434\u043e\u043c \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 Lamoda. \u0412 2018 \u0433\u043e\u0434\u0443 \u044f \u0432\u044b\u0441\u0442\u0443\u043f\u0430\u043b \u043d\u0430 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u0438 HighLoad++, \u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0445\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0443 \u0441\u0432\u043e\u0435\u0433\u043e \u0434\u043e\u043a\u043b\u0430\u0434\u0430. \u041c\u043e\u044f \u0442\u0435\u043c\u0430 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u0430 \u043e\u043f\u044b\u0442\u0443 \u043d\u0430\u0448\u0435\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u043f\u043e \u0434\u0435\u043f\u043b\u043e\u044e \u0441\u0438\u0441\u0442\u0435\u043c \u0438 \u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u0432 \u0440\u0430\u0437\u043d\u044b\u0435 \u0441\u0440\u0435\u0434\u044b. \u041d\u0430\u0447\u0438\u043d\u0430\u044f \u043e\u0442 \u043d\u0430\u0448\u0438\u0445 \u0434\u043e\u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0432\u0440\u0435\u043c\u0435\u043d, \u043a\u043e\u0433\u0434\u0430 \u043c\u044b \u0434\u0435\u043f\u043b\u043e\u0438\u043b\u0438 \u0432\u0441\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25343,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33654","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Deploy di applicazioni in VM, Nomad e Kubernetes | ProHoster","description":"Ciao a tutti! Mi chiamo Pavel Agaletski. Lavoro come team leader nel gruppo che sviluppa il sistema di consegna di Lamoda. Nel 2018 ho parlato alla conferenza HighLoad++, e oggi voglio presentare la trascrizione della mia relazione. Il mio argomento \u00e8 dedicato all'esperienza della nostra azienda nel deploy di sistemi e servizi in ambienti diversi, risalendo ai nostri tempi preistorici, quando effettuavamo il deploy di tutti i sistemi.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0414\u0435\u043f\u043b\u043e\u0439 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0432 VM, Nomad \u0438 Kubernetes | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041f\u0430\u0432\u0435\u043b \u0410\u0433\u0430\u043b\u0435\u0446\u043a\u0438\u0439. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0442\u0438\u043c\u043b\u0438\u0434\u043e\u043c \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 Lamoda. \u0412 2018 \u0433\u043e\u0434\u0443 \u044f \u0432\u044b\u0441\u0442\u0443\u043f\u0430\u043b \u043d\u0430 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u0438 HighLoad++, \u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0445\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0443 \u0441\u0432\u043e\u0435\u0433\u043e \u0434\u043e\u043a\u043b\u0430\u0434\u0430. \u041c\u043e\u044f \u0442\u0435\u043c\u0430 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u0430 \u043e\u043f\u044b\u0442\u0443 \u043d\u0430\u0448\u0435\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u043f\u043e \u0434\u0435\u043f\u043b\u043e\u044e \u0441\u0438\u0441\u0442\u0435\u043c \u0438 \u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u0432 \u0440\u0430\u0437\u043d\u044b\u0435 \u0441\u0440\u0435\u0434\u044b. \u041d\u0430\u0447\u0438\u043d\u0430\u044f \u043e\u0442 \u043d\u0430\u0448\u0438\u0445 \u0434\u043e\u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0432\u0440\u0435\u043c\u0435\u043d, \u043a\u043e\u0433\u0434\u0430 \u043c\u044b \u0434\u0435\u043f\u043b\u043e\u0438\u043b\u0438 \u0432\u0441\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:53:58+00:00","article:modified_time":"2019-10-31T18:53:58+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33654","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-08 20:38:40","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:36:34","updated":"2026-02-08 20:38:40"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/33654","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=33654"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/33654\/revisions"}],"predecessor-version":[{"id":157982,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/33654\/revisions\/157982"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/25343"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=33654"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=33654"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=33654"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}