{"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 delle applicazioni su VM, Nomad e Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao a tutti! Mi chiamo Pavel Agaletsky. Lavoro come team leader in un gruppo 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 deployare sistemi e servizi in diversi ambienti. Partendo dai nostri tempi preistorici, quando deployavamo tutti i sistemi su normali server virtuali, fino al graduale passaggio da Nomad al deploy in Kubernetes. Parler\u00f2 di perch\u00e9 lo abbiamo fatto e quali problemi abbiamo incontrato nel processo.<\/p>\n

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

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

\nIniziamo col dire che 3 anni fa tutti i sistemi e i servizi dell'azienda venivano deployati su normali server virtuali. Tecnologicamente, era organizzato in modo che tutto il codice dei nostri sistemi fosse archiviato e compilato tramite strumenti di build automatizzati, tramite jenkins. Con Ansible, veniva distribuito dalla nostra sistema di controllo versioni ai server virtuali. Ogni sistema presentava almeno 2 server: uno \u2013 il head, e l'altro \u2013 il tail. Questi due sistemi erano assolutamente identici tra loro per quanto riguardava configurazioni, potenza, impostazioni e altro. L'unica differenza era che il head riceveva traffico utente, mentre il tail non riceveva mai traffico degli utenti. <\/p>\n

Perch\u00e9 \u00e8 stato fatto? <\/p>\n

Quando deployavamo nuove versioni della nostra applicazione, volevamo garantire un rollout senza interruzioni, ovvero senza conseguenze visibili per gli utenti. Ci\u00f2 si otteneva distribuendo la versione appena compilata tramite Ansible sul tail. Qui le persone responsabili del deploy potevano controllare e assicurarsi che tutto funzionasse bene: tutte le metriche, i moduli e le applicazioni erano operativi; venivano eseguiti gli script necessari. Solo dopo aver confermato che tutto andava bene, il traffico veniva indirizzato. Cominciava a fluire verso il server che in precedenza era il tail. E quello che prima era il head rimaneva senza traffico utente, mantenendo la versione precedente della nostra applicazione.<\/p>\n

In questo modo, per gli utenti \u00e8 stato fluido. Perch\u00e9 il passaggio \u00e8 istantaneo, poich\u00e9 si tratta semplicemente di cambiare il bilanciatore. \u00c8 molto facile tornare alla versione precedente, semplicemente ripristinando il bilanciatore. Inoltre, abbiamo potuto verificare la capacit\u00e0 dell'applicazione in produzione prima ancora che il traffico degli utenti vi passasse, il che \u00e8 stato piuttosto comodo. <\/p>\n

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

    \n
  1. Prima di tutto, \u00e8 abbastanza facile e funziona.<\/b> \u00c8 chiaro a tutti come funziona uno schema di distribuzione del genere, poich\u00e9 la maggior parte delle persone ha distribuito su normali server virtuali.<\/li>\n
  2. \u00c8 abbastanza affidabile<\/b>, poich\u00e9 la tecnologia di distribuzione \u00e8 semplice, collaudata da migliaia di aziende. Milioni di server vengono distribuiti in questo modo. \u00c8 difficile rompere qualcosa. <\/li>\n
  3. E infine, abbiamo potuto ottenere distribuzioni atomiche<\/b>. Distribuzioni che per gli utenti avvengono istantaneamente, senza un passaggio evidente tra la vecchia e la nuova versione. <\/li>\n<\/ol>\n

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

      \n
    1. Oltre all'ambiente di produzione, ci sono anche ambienti di sviluppo e altri ambienti. Ad esempio, QA e preproduzione. A quel tempo avevamo molti server e circa 60 servizi. Per questa ragione, era necessario mantenere per ogni servizio la versione attuale <\/b>della macchina virtuale. Inoltre, se si desidera aggiornare le librerie o installare nuove dipendenze, \u00e8 necessario farlo in tutti gli ambienti. Era anche necessario sincronizzare il momento in cui si intende distribuire la nuova versione della vostra applicazione con il momento in cui il devops eseguir\u00e0 le necessarie configurazioni ambientali. In tal caso \u00e8 facile trovarsi in una situazione in cui l'ambiente differisce in modo significativo tra tutti gli ambienti consecutivamente. Ad esempio, nell'ambiente QA ci saranno versioni di librerie diverse rispetto a quelle in produzione, il che porter\u00e0 a problemi. <\/li>\n
    2. La complessit\u00e0 nell'aggiornamento delle dipendenze<\/b> della vostra applicazione. Questo dipende da un'altra squadra. Cio\u00e8, dal team devops, che gestisce i server. \u00c8 necessario fornire loro il compito corrispondente e dare una descrizione di cosa si desidera fare.<\/li>\n
    3. In quel periodo volevamo anche suddividere i grandi monoliti che avevamo in servizi pi\u00f9 piccoli, poich\u00e9 comprendevamo che ne sarebbero diventati sempre di pi\u00f9. Avevamo gi\u00e0 pi\u00f9 di 100 di questi. Era necessario creare una nuova macchina virtuale per ogni nuovo servizio, che doveva essere anche gestita e distribuita. Inoltre, non serviva una sola macchina, ma almeno due. A tutto ci\u00f2 si aggiungeva l'ambiente QA. Questo causava problemi e rendeva la creazione e il lancio di nuovi sistemi pi\u00f9 complesso, costoso e lungo.<\/b><\/li>\n<\/ol>\n

      \nPertanto, abbiamo deciso che sarebbe stato pi\u00f9 conveniente passare dalla distribuzione di macchine virtuali classiche alla distribuzione delle nostre applicazioni in contenitori Docker. Con Docker c'\u00e8 bisogno di un sistema in grado di avviare l'applicazione in cluster, poich\u00e9 non \u00e8 possibile avviare semplicemente un contenitore. Di solito si desidera tenere traccia di quanti contenitori siano stati avviati, affinch\u00e9 si alzino automaticamente. Per questo motivo, era necessario scegliere un sistema di gestione. <\/p>\n

      Abbiamo riflettuto a lungo su quale di essi potessimo utilizzare. Il fatto \u00e8 che a quel tempo il nostro stack di distribuzione su normali server virtuali era piuttosto obsoleto, poich\u00e9 conteneva versioni non aggiornate dei sistemi operativi. A un certo punto vi era persino FreeBSD, che non era molto conveniente da mantenere. Comprendevamo che era necessario migrare il prima possibile a Docker. I nostri DevOps hanno analizzato 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 \u201cHashiCorp\u201d. Sono anche noti per le loro altre soluzioni:<\/p>\n

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

      \u00abTerraform\u00bb<\/b> \u00e8 un sistema di gestione dei server che ti consente di configurarli tramite configurazione, nota come infrastructure-as-a-code.<\/p>\n

      \u00abVagrant\u00bb<\/b> ti consente di avviare macchine virtuali localmente o nel cloud tramite file di configurazione specifici. <\/p>\n

      A quel tempo, Nomad ci \u00e8 sembrato una soluzione abbastanza semplice, che consente una transizione rapida senza modificare l'intera infrastruttura. Inoltre, \u00e8 relativamente facile da apprendere. Perci\u00f2, lo abbiamo scelto come sistema per la gestione del nostro contenitore. <\/p>\n

      Cosa serve per distribuire il tuo sistema in Nomad? <\/p>\n

        \n
      1. Prima di tutto, \u00e8 necessario un'immagine Docker<\/b> della tua applicazione. \u00c8 necessario raccoglierlo e posizionarlo nello storage delle immagini docker. Nel nostro caso si tratta di artifactory: un sistema che consente di caricare diversi artefatti di vario tipo. \u00c8 in grado di memorizzare archivi, immagini docker, pacchetti composer PHP, pacchetti NPM e cos\u00ec via. <\/li>\n
      2. \u00c8 inoltre necessario un file di configurazione<\/b>, che dir\u00e0 a Nomad cosa, dove e in quale quantit\u00e0 vuoi implementare. <\/li>\n<\/ol>\n

        \nQuando parliamo di Nomad, usa il linguaggio HCL come formato del file informativo, che si decodifica come HashiCorp Configuration Language<\/i>. Questo \u00e8 un superinsieme di Yaml, che ti consente di descrivere il tuo servizio in termini di Nomad. <\/p>\n

        \"Distribuzione
        \n
        \nTi permette di specificare quanti contenitori desideri implementare, quali immagini utilizzare e di passare loro vari parametri durante l'implementazione. In questo modo, fornisci questo file a Nomad, che avvia i contenitori in produzione in base a quanto specificato. <\/p>\n

        Nel nostro caso, ci siamo resi conto che scrivere file HCL identici per ogni servizio sarebbe stato poco pratico, poich\u00e9 ci sono molti servizi e a volte si desidera aggiornarli. Pu\u00f2 capitare che un servizio sia implementato in pi\u00f9 istanze. Ad esempio, uno dei sistemi che abbiamo in produzione ha oltre 100 istanze operative. Vengono eseguiti dalle stesse immagini, ma differiscono per le impostazioni di configurazione e i file di configurazione. <\/p>\n

        Pertanto, abbiamo deciso che sarebbe stato comodo mantenere tutti i nostri file di configurazione per l'implementazione in un unico repository comune. In questo modo, diventano facilmente consultabili: \u00e8 semplice mantenerli e vedere quali sistemi abbiamo. Inoltre, in caso di necessit\u00e0, non \u00e8 complicato aggiornare o modificare qualcosa. Aggiungere un nuovo sistema non richiede nemmeno troppa fatica: \u00e8 sufficiente creare un file di configurazione all'interno di una nuova directory. All'interno troverai i file: service.hcl, che contiene la descrizione del nostro servizio, e alcuni file .env, che consentono di configurare il servizio stesso una volta implementato in produzione. <\/p>\n

        \"Distribuzione
        \n
        \nTuttavia, alcuni dei nostri sistemi non sono implementati in produzione in un'unica istanza, ma in pi\u00f9. Pertanto, abbiamo ritenuto conveniente conservare non le configurazioni in forma pura, ma la loro versione templated. E come linguaggio di templating abbiamo scelto jinja 2<\/i>. In questo formato, conserviamo sia le configurazioni del servizio stesso che i file env necessari per esso. <\/p>\n

        Inoltre, abbiamo inserito nel repository uno script di deployment condiviso per tutti i progetti, che consente di avviare e distribuire il tuo servizio in produzione, nell'ambiente richiesto, nel target desiderato. Quando abbiamo trasformato la nostra configurazione HCL in un modello, il file HCL, che era prima una configurazione normale di Nomad, \u00e8 apparso un po' diverso.<\/p>\n

        \"Distribuzione
        \n
        \nCio\u00e8, abbiamo sostituito alcune variabili della configurazione con inserzioni di variabili, che vengono prelevate dai file env o da altre fonti. Inoltre, abbiamo acquisito la possibilit\u00e0 di generare file HCL dinamicamente, il che significa che possiamo applicare non solo le normali inserzioni di variabili. Poich\u00e9 jinja supporta cicli e condizioni, \u00e8 possibile creare file di configurazione che cambiano in base a dove stai distribuendo le tue applicazioni. <\/p>\n

        Ad esempio, vuoi distribuire il tuo servizio in pre-produzione e in produzione. Supponiamo che in pre-produzione tu non voglia avviare script cron, ma voglia semplicemente vedere il servizio su un dominio separato per assicurarti che funzioni. Per chiunque distribuisca un servizio, il processo appare molto semplice e trasparente. \u00c8 sufficiente eseguire il file deploy.sh, specificare quale servizio vuoi distribuire e in quale target. Ad esempio, vuoi distribuire un certo sistema in Russia, Bielorussia o Kazakistan. Per farlo, basta cambiare uno dei parametri e ti verr\u00e0 generato il file di configurazione corretto. <\/p>\n

        Quando il servizio Nomad \u00e8 gi\u00e0 stato distribuito nel tuo cluster, appare come segue.<\/p>\n

        \"Distribuzione
        \n
        \nPer iniziare, hai bisogno di un bilanciatore all'esterno, che ricever\u00e0 tutto il traffico degli utenti. Funzioner\u00e0 insieme a Consul e gli chieder\u00e0 dove, su quale nodo, si trova il indirizzo IP<\/a> servizio specifico corrispondente a un certo nome di dominio. I servizi in Consul sorgono da Nomad stesso. Poich\u00e9 sono prodotti della stessa azienda, sono ben integrati tra loro. Si pu\u00f2 dire che Nomad \u00e8 in grado di registrare automaticamente tutti i servizi avviati in esso all'interno di Consul. <\/p>\n

        Dopo che il vostro bilanciatore esterno ha appreso a quale servizio deve inviare il traffico, lo reindirizza nel contenitore corrispondente o in pi\u00f9 contenitori che si adattano alla vostra applicazione. \u00c8 naturale che in questo si debba considerare anche la sicurezza. Anche se tutti i servizi vengono eseguiti sulle stesse macchine virtuali nei contenitori, di solito \u00e8 necessario vietare l'accesso libero da qualsiasi servizio a qualsiasi altro. Abbiamo raggiunto questo obiettivo attraverso la segmentazione. Ogni servizio veniva eseguito nella propria rete virtuale, sulla quale erano definite le regole di routing e le regole di autorizzazione\/divieto di accesso ad altri sistemi e servizi. Questi potevano trovarsi sia all'interno di questo cluster che all'esterno. Ad esempio, se desiderate vietare a un servizio di connettersi a un determinato database, \u00e8 possibile farlo tramite segmentazione a livello di rete. Cio\u00e8, anche per errore, non potete accidentalmente collegarvi dal vostro ambiente di test al vostro database di produzione.<\/p>\n

        Quanto ci \u00e8 costato il processo di transizione in termini di risorse umane? <\/p>\n

        La transizione di tutta l'azienda a Nomad ha impiegato circa 5-6 mesi. Ci siamo spostati servizio per servizio, ma a un ritmo abbastanza veloce. Ogni team doveva creare i propri contenitori per i servizi. <\/p>\n

        Abbiamo adottato un approccio in cui ogni team \u00e8 responsabile autonomamente delle immagini docker dei propri sistemi. I DevOps, invece, forniscono l'infrastruttura generale necessaria per il deployment, ovvero il supporto per il cluster stesso, il supporto per il sistema CI e cos\u00ec via. E a quel tempo oltre 60 sistemi si erano trasferiti in Nomad, con circa 2000 contenitori. <\/p>\n

        I DevOps sono responsabili per l'infrastruttura generale di tutto ci\u00f2 che riguarda il deployment e i server. Ogni team di sviluppo, a sua volta, \u00e8 responsabile dell'implementazione dei contenitori per il proprio sistema specifico, poich\u00e9 \u00e8 proprio il team a sapere cosa necessita esattamente in quel particolare contenitore.<\/p>\n

        Motivi per cui ci siamo allontanati da Nomad<\/h1>\n

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

          \n
        1. Noi abbiamo garantito condizioni uniformi<\/b> per tutti i mezzi. Nel development, nell'ambiente QA, nella pre-produzione e nella produzione si utilizzano le stesse immagini dei container, con le stesse dipendenze. Ne consegue che avete praticamente zero probabilit\u00e0 che in produzione arrivi qualcosa che non avete gi\u00e0 testato localmente o nell'ambiente di test. <\/li>\n
        2. Abbiamo anche scoperto che \u00e8 sufficiente aggiungere un nuovo servizio<\/b>. Qualsiasi nuovo sistema dal punto di vista del deploy pu\u00f2 essere avviato molto facilmente. \u00c8 sufficiente andare nel repository che contiene le configurazioni, aggiungere una nuova configurazione per il vostro sistema e il gioco \u00e8 fatto. Potete distribuire il vostro sistema in produzione senza ulteriori sforzi da parte dei DevOps. <\/li>\n
        3. Tutti file di configurazione<\/b> in un unico repository generale sono risultati consultabili<\/b>. Nel momento in cui distribuivamo i nostri sistemi utilizzando server virtuali<\/a>, utilizzavamo Ansible, dove le configurazioni erano tutte nello stesso repository. Tuttavia, per la maggior parte degli sviluppatori lavorare con questo era un po' pi\u00f9 complicato. Qui il numero di configurazioni e codice che dovete aggiungere per distribuire un servizio \u00e8 diventato molto pi\u00f9 ridotto. Inoltre, per i DevOps \u00e8 molto facile correggerlo o modificarlo. Nel caso di transizioni, ad esempio, su una nuova versione di Nomad, possono prendere e aggiornare in massa tutti i file operativi che si trovano nello stesso posto.<\/li>\n<\/ol>\n

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

          Si \u00e8 rivelato che non siamo riusciti a raggiungere la continuit\u00e0 dei deploy <\/b>nel caso di Nomad. Durante il roll-out dei container in diverse condizioni, pu\u00f2 succedere che un container venga avviato e Nomad lo riconosca come pronto a ricevere traffico. Questo accadeva ancora prima che l'applicazione al suo interno riuscisse ad avviarsi. Per questo motivo, il sistema in breve tempo iniziava a restituire errori 500, poich\u00e9 il traffico iniziava a fluire verso un container che non era ancora pronto ad accoglierlo. <\/p>\n

          Ci siamo imbattuti in alcuni bug<\/b>. Il bug pi\u00f9 significativo \u00e8 che Nomad non gestisce bene i grandi cluster, specialmente se hai molti sistemi e contenitori. Quando vuoi mettere in manutenzione uno dei server inclusi nel cluster Nomad, c'\u00e8 una buona possibilit\u00e0 che il cluster non stia bene e si scomponga. Alcuni contenitori potrebbero, ad esempio, bloccarsi e non ripartire \u2014 questo ti coster\u00e0 molto, soprattutto se tutti i tuoi sistemi in produzione sono nel cluster gestito da Nomad. <\/p>\n

          Perci\u00f2 abbiamo deciso di riflettere su quale direzione prendere. A quel punto eravamo molto pi\u00f9 consapevoli di ci\u00f2 che volevamo ottenere. Vale a dire: desideriamo affidabilit\u00e0, un po' pi\u00f9 di funzionalit\u00e0 rispetto a quelle offerte da Nomad e un sistema pi\u00f9 maturo e stabile. <\/p>\n

          In questo senso, abbiamo scelto Kubernetes come la piattaforma pi\u00f9 popolare per eseguire i cluster. Soprattutto considerando che le dimensioni e il numero dei nostri contenitori erano abbastanza grandi. Per tali scopi, Kubernetes sembrava il sistema pi\u00f9 adatto tra quelli che abbiamo preso in considerazione. <\/p>\n

          Transizione a Kubernetes<\/h1>\n

          \nVoglio raccontarvi quali sono i concetti principali di Kubernetes e come si differenziano da Nomad. <\/p>\n

          \"Distribuzione
          \n
          \nPrima di tutto, il concetto pi\u00f9 basilare in Kubernetes \u00e8 il pod. Pod<\/b> \u2013 \u00e8 un gruppo di uno o pi\u00f9 contenitori che vengono sempre eseguiti insieme. E lavorano come se fossero sempre rigorosamente su una macchina virtuale. Sono accessibili tra loro all'indirizzo IP 127.0.0.1 su porte diverse. <\/p>\n

          Supponiamo che tu abbia un'applicazione PHP che consiste in nginx e php-fpm \u2013 uno schema classico. Probabilmente vorrai che i contenitori nginx e php-fpm siano sempre insieme. Kubernetes consente di farlo descrivendoli come un unico pod comune. Esattamente questo non era possibile farlo con Nomad.<\/p>\n

          Il secondo concetto \u00e8 deployment<\/b>. Infatti, il pod di per s\u00e9 \u00e8 una cosa effimera, viene avviato e poi scompare. Vuoi uccidere prima tutti i tuoi contenitori precedenti e poi avviare subito nuove versioni, o vuoi distribuirli gradualmente \u2013 proprio di questo processo si occupa il concetto di deployment. Descrive come distribuisci i tuoi pod, in quale quantit\u00e0 e come aggiornarli. <\/p>\n

          Il terzo concetto \u00e8 service<\/b>. Il tuo service \u00e8 praticamente il tuo sistema che accoglie un certo traffico e poi lo indirizza verso uno o pi\u00f9 pod che corrispondono al tuo servizio. In altre parole, ti consente di dire che tutto il traffico in ingresso per un determinato servizio con un certo nome deve essere inviato a questi pod specifici. Inoltre, ti offre bilanciamento del traffico. Puoi avviare due pod della tua applicazione e tutto il traffico in ingresso verr\u00e0 bilanciato uniformemente tra i pod associati a questo servizio.<\/p>\n

          E il quarto concetto principale \u2014 Ingress<\/b>. Questo \u00e8 un servizio che viene avviato nel cluster Kubernetes. Funziona come un bilanciatore di carico esterno che raccoglie tutte le richieste. Grazie all'API di Kubernetes, Ingress pu\u00f2 determinare dove devono essere inviate queste richieste. Inoltre, lo fa in modo molto flessibile. Puoi specificare che tutte le richieste su questo host e su un certo URL devono essere inviate a questo servizio. E queste richieste, che arrivano su questo host e su un altro URL, devono essere indirizzate a un altro servizio. <\/p>\n

          La cosa pi\u00f9 interessante per chi sviluppa un'applicazione \u00e8 che sei in grado di gestire tutto questo autonomamente. Stabilendo la configurazione di Ingress, puoi inviare tutto il traffico che arriva su un certo API a contenitori specifici, ad esempio scritti in Go. E questo traffico, che entra nello stesso dominio, ma su un altro URL, deve essere inviato a contenitori scritti in PHP, dove c'\u00e8 molta logica, ma non sono molto veloci.<\/p>\n

          Se confrontiamo tutti questi concetti con Nomad, possiamo dire che i primi tre concetti costituiscono insieme il Service. L'ultimo concetto \u00e8 assente in Nomad. Per questo abbiamo usato un bilanciatore di carico esterno: potrebbe essere haproxy, nginx, nginx+ e cos\u00ec via. Nel caso di Kubernetes, non \u00e8 necessario introdurre questo concetto separatamente. Tuttavia, se si guarda all'Ingress internamente, si tratta di nginx, haproxy o traefik, ma incorporato in Kubernetes. <\/p>\n

          Tutti i concetti che ho descritto sono, in sostanza, risorse che esistono all'interno del cluster Kubernetes. Per descriverle nel cluster viene utilizzato il formato yaml, pi\u00f9 leggibile e familiare rispetto ai file HCL nel caso di Nomad. Ma strutturalmente descrivono, nel caso di un pod, la stessa cosa. Dicono \u2013 voglio distribuire questi pod in questo luogo, con queste immagini, in questa quantit\u00e0. <\/p>\n

          \"Distribuzione
          \n
          \nInoltre, abbiamo capito che non vogliamo creare manualmente ogni singola risorsa: deployment, servizi, Ingress, e altro ancora. Invece, volevamo descrivere ogni nostro sistema durante il deployment in termini di Kubernetes, in modo da non dover ricreare manualmente tutte le dipendenze necessarie in ordine. Per questo scopo, abbiamo scelto Helm come sistema che ci ha permesso di farlo. <\/p>\n

          Concetti fondamentali in Helm<\/h1>\n

          \nHelm \u00e8 un gestore di pacchetti<\/b> per Kubernetes. \u00c8 molto simile a come funzionano i gestori di pacchetti nei linguaggi di programmazione. Permettono di memorizzare un servizio che consiste, ad esempio, in deployment nginx, deployment php-fpm, configurazioni per Ingress, configmaps (questo \u00e8 un'entit\u00e0 che consente di definire env e altri parametri per il sistema) sotto forma di cosiddetti chart. Helm funziona sopra Kubernetes<\/b>. Cio\u00e8, non \u00e8 un sistema esterno, ma semplicemente un altro servizio eseguito all'interno del cluster. Interagisci con esso tramite la sua API attraverso un comando da console. La sua comodit\u00e0 e bellezza stanno nel fatto che anche se Helm si rompe o lo rimuovi dal cluster, i tuoi servizi non scompariranno, poich\u00e9 Helm serve sostanzialmente solo per avviare il sistema. La funzionalit\u00e0 e lo stato dei servizi sono poi gestiti da Kubernetes stesso. <\/p>\n

          Abbiamo anche capito che la templating<\/b>, che in precedenza eravamo costretti a fare manualmente implementando jinja nelle nostre configurazioni, \u00e8 una delle principali funzionalit\u00e0 di Helm. Tutte le configurazioni che crei per i tuoi sistemi sono conservate in Helm come modelli, simili a jinja, ma in realt\u00e0 usano la templating del linguaggio Go, sul quale \u00e8 scritto Helm, proprio come Kubernetes. <\/p>\n

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

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

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

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

          Nel caso in cui utilizziamo helm, le configurazioni standard per Kubernetes si trasformano anch'esse in modelli, nei quali \u00e8 possibile utilizzare variabili, funzioni e applicare operatori condizionali. In questo modo, puoi costruire la configurazione del tuo servizio in base all'ambiente.<\/p>\n

          \"Distribuzione
          \n
          \nIn pratica abbiamo deciso di procedere in modo leggermente diverso rispetto a quanto fatto con Nomad. Se in Nomad le configurazioni per l'implementazione e le variabili necessarie per distribuire il nostro servizio erano memorizzate nello stesso repository, qui abbiamo deciso di separarle in due repository distinti. Nel repository \"deploy\" vengono memorizzate solo le variabili necessarie per l'implementazione, mentre nel repository \"helm\" si trovano le configurazioni o i chart.<\/p>\n

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

          Nonostante nei file di configurazione non memorizziamo dati altamente sensibili, come le password dei database, che sono conservate sotto forma di secrets in Kubernetes, ci sono comunque elementi specifici ai quali non vogliamo 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, si pu\u00f2 concedere l'accesso in modo sicuro a un numero maggiore di persone. <\/p>\n

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

          All'interno di ciascun repository, abbiamo lasciato una suddivisione in directory separate per ciascun servizio. Cio\u00e8, all'interno di ogni directory si trovano i modelli relativi al corrispondente chart e che descrivono le risorse da deployare per avviare il nostro sistema. Nel repository \"deploy\" abbiamo lasciato solo le env. 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 funzioni principali. <\/p>\n

          Abbiamo lasciato uno script per il deployment \u2013 deploy.sh, che semplifica e standardizza l'avvio del deployment tramite helm. Cos\u00ec, per chiunque voglia effettuare il deployment, l'interfaccia di deployment appare esattamente come nel caso del deployment tramite Nomad. Lo stesso deploy.sh, il nome del tuo servizio, e dove desideri deployarlo. Questo fa s\u00ec che si avvii helm. Quest'ultimo raccoglie le configurazioni dai modelli, sostituisce i file values necessari, quindi deploya, lanciandoli 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 in Ingress. Questo \u00e8 il front-controller che gestisce tutte le richieste e le invia successivamente ai servizi corrispondenti ai dati della richiesta. Li identifica in base alle configurazioni che fanno parte della descrizione della tua applicazione in helm e che gli sviluppatori impostano autonomamente. Il servizio poi invia le richieste ai propri pod, cio\u00e8 container specifici, bilanciando il traffico in entrata tra tutti i container appartenenti a quel servizio. E, naturalmente, non dobbiamo dimenticare che in termini di sicurezza a livello di rete, non dobbiamo allontanarci. Pertanto, nel cluster Kubernetes opera la segmentazione basata sul tagging. Tutti i servizi hanno tag specifici a cui sono associati i diritti di accesso ai vari risorse esterni o interni nel cluster. <\/p>\n

          Effettuando il passaggio, abbiamo notato che Kubernetes offre tutte le funzionalit\u00e0 di Nomad, che avevamo utilizzato in precedenza, e aggiunge molte novit\u00e0. Pu\u00f2 essere esteso tramite plugin e, in effetti, tramite tipi di risorse personalizzati. Questo significa che avete la possibilit\u00e0 non solo di utilizzare ci\u00f2 che viene fornito con Kubernetes di default, ma di creare la vostra risorsa e servizio che leggeranno la vostra risorsa. Ci\u00f2 offre ulteriori opportunit\u00e0 di espansione del vostro sistema senza la necessit\u00e0 di reinstallare Kubernetes e senza la necessit\u00e0 di modifiche. <\/p>\n

          Un esempio di tale utilizzo \u00e8 Prometheus, che eseguiamo all'interno del nostro cluster Kubernetes. Affinch\u00e9 inizi a raccogliere metriche da un servizio specifico, dobbiamo aggiungere alla descrizione del servizio un ulteriore tipo di risorsa, il cosiddetto servizio-monitor. Grazie al fatto che Prometheus pu\u00f2 leggere, essendo in esecuzione su Kubernetes, tipi di risorse personalizzati, inizia automaticamente a raccogliere metriche dal nuovo sistema. \u00c8 piuttosto comodo. <\/p>\n

          Il primo deployment che abbiamo fatto in Kubernetes \u00e8 avvenuto a marzo 2018. E in tutto questo tempo non abbiamo mai riscontrato problemi. Funziona in modo abbastanza stabile senza bug significativi. Inoltre, possiamo espanderlo ulteriormente. Ad oggi, abbiamo sufficienti possibilit\u00e0 di cui disporre, e ci piacciono molto i tassi di sviluppo di Kubernetes. Attualmente, ci sono pi\u00f9 di 3000 contenitori in Kubernetes. Il cluster occupa diversi Node. \u00c8 gestito, stabile e molto 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 team che sviluppa il sistema di consegna di Lamoda.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}