{"id":80289,"date":"2020-05-05T01:42:36","date_gmt":"2020-05-04T23:42:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ansible-migracziya-konfiguraczii-120-vm-c-coreos-na-centos-za-18-mesyaczev"},"modified":"2020-05-05T01:42:36","modified_gmt":"2020-05-04T23:42:36","slug":"ansible-migracziya-konfiguraczii-120-vm-c-coreos-na-centos-za-18-mesyaczev","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ansible-migracziya-konfiguraczii-120-vm-c-coreos-na-centos-za-18-mesyaczev","title":{"rendered":"Ansible: Migrazione della configurazione di 120 VM da CoreOS a CentOS in 18 mesi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ansible:<\/p>\n

<\/p>\n

Questa \u00e8 la trascrizione dell'intervento su DevopsConf 2019-10-01<\/a><\/noindex> e SPbLUG 2019-09-25<\/a><\/noindex>.<\/p>\n

<\/p>\n

Questa \u00e8 la storia di un progetto in cui \u00e8 stata utilizzata un sistema di gestione delle configurazioni personalizzato e perch\u00e9 il trasferimento ad Ansible \u00e8 durato 18 mesi.<\/p>\n

<\/a><\/noindex><\/p>\n

Giorno \u2116 -XXX: Prima dell'inizio<\/h2>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Inizialmente, l'infrastruttura era composta da numerosi host separati gestiti da Hyper-V. Creare una macchina virtuale richiedeva molte operazioni: posizionare i dischi nel giusto posto, configurare DNS, riservare DHCP e inserire la configurazione della VM nel repository git. Questo processo era parzialmente meccanizzato, ma ad esempio le VM venivano distribuite tra gli host manualmente. Tuttavia, gli sviluppatori potevano modificare la configurazione della VM nel git e applicarla riavviando la VM.<\/p>\n

<\/p>\n

Soluzione di gestione delle configurazioni personalizzata<\/h3>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

L'idea iniziale, sospetto, era concepita come IaC: numerose VM stateless che annullavano il loro stato al riavvio. Com'era gestita la configurazione delle VM? Schemamaticamente, sembra semplice:<\/p>\n

<\/p>\n

    \n
  1. Per le VM veniva fissato un MAC statico.<\/li>\n
  2. Alla VM veniva collegato un ISO di CoreOS e un disco di avvio.<\/li>\n
  3. CoreOS esegue uno script di personalizzazione scaricandolo da un server WEB in base al proprio IP.<\/li>\n
  4. Lo script recupera tramite SCP la configurazione della VM basandosi sull'indirizzo IP.<\/li>\n
  5. Viene avviato un insieme di file di unit\u00e0 systemd e un insieme di script bash.<\/li>\n<\/ol>\n

    <\/p>\n

    \"Ansible:<\/p>\n

    <\/p>\n

    Questa soluzione presentava numerosi problemi evidenti:<\/p>\n

    <\/p>\n

      \n
    1. L'ISO in CoreOS era deprecato.<\/li>\n
    2. Molte azioni complesse da automatizzare e magie durante la migrazione\/creazione delle VM.<\/li>\n
    3. Difficolt\u00e0 con gli aggiornamenti e quando \u00e8 necessario un software di una certa versione. Ancora pi\u00f9 complicato con i moduli del kernel.<\/li>\n
    4. Le VM non erano cos\u00ec vuote di dati; ci sono VM che avevano montato un disco con dati utente aggiuntivi.<\/li>\n
    5. Qualcuno commetteva continuamente errori con le dipendenze delle unit\u00e0 systemd e CoreOS si bloccava al riavvio. Era problematico catturarlo con i mezzi disponibili in CoreOS.<\/li>\n
    6. Gestione dei segreti.<\/li>\n
    7. Non c'era una vera gestione della configurazione. C'erano script bash e configurazioni YML per CoreOS.<\/li>\n<\/ol>\n

      <\/p>\n

      Per applicare la configurazione della VM \u00e8 necessario riavviarla, ma potrebbe non riavviarsi. Sembra un problema ovvio, ma non ci sono dischi persistenti \u2014 non c'\u00e8 posto dove salvare i log. Ok, proviamo ad aggiungere opzioni di avvio del kernel per inviare i log. Ma no, \u00e8 tutto cos\u00ec complicato.<\/p>\n

      <\/p>\n

      Giorno n. 0: Riconoscimento del problema<\/h2>\n

      <\/p>\n

      \"Ansible:<\/p>\n

      <\/p>\n

      Si trattava di un'infrastruttura di sviluppo standard: jenkins, ambienti di test, monitoraggio, registry. CoreOS \u00e8 stata progettata per l'hosting di cluster k8s, quindi il problema riguardava l'uso di CoreOS. Il primo passo \u00e8 stata la scelta dello stack. Ci siamo orientati su:<\/p>\n

      <\/p>\n

        \n
      1. CentOS<\/strong> come distribuzione di base, poich\u00e9 \u00e8 la distribuzione pi\u00f9 vicina agli ambienti di produzione.<\/li>\n
      2. Ansible<\/strong> per la gestione delle configurazioni, vista l'ampia esperienza disponibile.<\/li>\n
      3. Jenkins<\/strong> come framework di automazione dei processi esistenti, poich\u00e9 era gi\u00e0 attivamente utilizzato nei processi di sviluppo.<\/li>\n
      4. Hyper-V<\/strong> come piattaforma di virtualizzazione. Ci sono diverse ragioni che esulano dall'argomento, ma in breve \u2014 non possiamo usare il cloud, dobbiamo utilizzare il nostro hardware.<\/li>\n<\/ol>\n

        <\/p>\n

        Giorno n. 30: Fissiamo gli accordi esistenti \u2014 Agreements as Code<\/h3>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Una volta compreso lo stack, \u00e8 iniziata la preparazione al trasferimento. La formalizzazione degli accordi esistenti sotto forma di codice (Agreements as Code<\/strong>!). Il passaggio lavoro manuale<\/em> -> meccanizzazione<\/em> -> automazione<\/em>.<\/p>\n

        <\/p>\n

        1. Configurare le VM<\/h4>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Ansible si occupa perfettamente di questo compito. Con il minimo sforzo, \u00e8 possibile gestire le configurazioni delle VM:<\/p>\n

        <\/p>\n

          \n
        1. Creiamo un repository git.<\/li>\n
        2. Colleghiamo l'elenco delle VM all'inventario, le configurazioni ai playbook e ai ruoli.<\/li>\n
        3. Impostiamo uno slave Jenkins speciale da cui sar\u00e0 possibile avviare Ansible.<\/li>\n
        4. Creiamo un job e configuriamo Jenkins.<\/li>\n<\/ol>\n

          <\/p>\n

          Il primo processo \u00e8 pronto. Gli accordi sono stati confermati.<\/p>\n

          <\/p>\n

          2. Crea una nuova VM<\/h4>\n

          <\/p>\n

          \"Ansible:<\/p>\n

          <\/p>\n

          Qui non era molto comodo. Creare VM su Hyper-V da Linux era poco pratico. Una delle tentativi di meccanizzare questo processo \u00e8 stata:<\/p>\n

          <\/p>\n

            \n
          1. Ansible si connette al host Windows tramite WinRM.<\/li>\n
          2. Ansible avvia uno script PowerShell.<\/li>\n
          3. Lo script PowerShell crea una nuova VM.<\/li>\n
          4. Utilizzando Hyper-V\/ScVMM, quando crei una VM, puoi configurare il hostname nel sistema operativo guest.<\/li>\n
          5. La VM invia il proprio hostname quando aggiorna il lease DHCP.<\/li>\n
          6. L'integrazione standard di DDNS & DHCP sul Domain Controller configura il record DNS.<\/li>\n
          7. Puoi aggiungere VM all'inventario e configurarle con Ansible.<\/li>\n<\/ol>\n

            <\/p>\n

            3. Crea un template VM<\/h4>\n

            <\/p>\n

            \"Ansible:<\/p>\n

            <\/p>\n

            Qui non abbiamo inventato nulla \u2014 abbiamo usato Packer.<\/p>\n

            <\/p>\n

              \n
            1. Nel repository Git mettiamo la configurazione di Packer e kickstart.<\/li>\n
            2. Configuriamo uno slave Jenkins speciale con Hyper-V e Packer.<\/li>\n
            3. Creiamo un job e configuriamo Jenkins.<\/li>\n<\/ol>\n

              <\/p>\n

              Come funziona questa combinazione:<\/p>\n

              <\/p>\n

                \n
              1. Packer crea una VM vuota e collega un file ISO.<\/li>\n
              2. La VM si avvia, Packer inserisce nel bootloader il comando per usare il nostro file kickstart da dischetto o http.<\/li>\n
              3. Anaconda si avvia con la nostra configurazione e esegue la configurazione iniziale del sistema operativo.<\/li>\n
              4. Packer attende la disponibilit\u00e0 della VM.<\/li>\n
              5. Il Packer all'interno della VM esegue ansible in modalit\u00e0 locale.<\/li>\n
              6. Ansible utilizza esattamente gli stessi ruoli del passo n. 1.<\/li>\n
              7. Il Packer esporta il modello VM.<\/li>\n<\/ol>\n

                <\/p>\n

                Giorno n. 75: Ristrutturiamo gli accordi senza rompere = Test ansible + Testkitchen.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Fissare gli accordi nel codice potrebbe non essere sufficiente. Infatti, se durante il processo sottostante desideri cambiare qualcosa, potresti rompere qualcosa. Pertanto, nel caso dell'infrastruttura, \u00e8 necessario testare tale infrastruttura. Per sincronizzare le conoscenze all'interno del team, abbiamo iniziato a testare i ruoli di Ansible. Non approfondir\u00f2 poich\u00e9 c'\u00e8 un articolo che descrive gli eventi in quel momento. Prova a testarmi se puoi, o i programmatori YML sognano di testare ansible?<\/a><\/noindex>(spoiler: questa non era la versione finale e in seguito \u00e8 diventato tutto pi\u00f9 complicato. Come iniziare a testare Ansible, rifattorizzare un progetto in un anno e non perdere la bussola.<\/a><\/noindex>).<\/p>\n

                <\/p>\n

                Giorno n. 130: E se CentOS + ansible non fosse necessario? Magari openshift?<\/h3>\n

                <\/p>\n

                \u00c8 importante capire che il processo di introduzione dell'infrastruttura non \u00e8 stato l'unico e ci sono stati sottoprogetti collaterali. Ad esempio, abbiamo ricevuto una richiesta per eseguire la nostra applicazione in openshift e questo si \u00e8 trasformato in ricerche che sono durate pi\u00f9 di una settimana. Avviamo l'applicazione in Openshift e confrontiamo gli strumenti esistenti<\/a><\/noindex> ci\u00f2 che ha rallentato il processo di migrazione. Alla fine, si \u00e8 scoperto che openshift non soddisfa tutte le esigenze; \u00e8 necessario un hardware reale, o almeno la possibilit\u00e0 di giocare con il kernel.<\/p>\n

                <\/p>\n

                Giorno n. 170: Openshift non \u00e8 adatto, proviamo con Windows Azure Pack?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Hyper-V non \u00e8 molto amichevole, SCVMM non lo migliora molto. Tuttavia, esiste Windows Azure Pack, che \u00e8 un'estensione di SCVMM e si mimetizza come Azure. Ma in realt\u00e0, il prodotto sembra trascurato: la documentazione contiene link rotti ed \u00e8 piuttosto scarsa. Tuttavia, nell'ambito della ricerca di opzioni per semplificare la vita al nostro cloud, lo abbiamo preso in considerazione.<\/p>\n

                <\/p>\n

                Giorno n. 250: Windows Azure Pack non \u00e8 molto. Rimaniamo su SCVMM<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Windows Azure Pack sembrava promettente, ma si \u00e8 deciso di non portare WAP con le sue complessit\u00e0 nel sistema per funzionalit\u00e0 non necessarie, quindi siamo rimasti su SCVMM.<\/p>\n

                <\/p>\n

                Giorno n. 360: Mangiamo l'elefante a pezzi<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Solo dopo un anno \u00e8 stata pronta la piattaforma su cui migrare e ha avuto inizio il processo di migrazione. Per questo \u00e8 stato impostato un compito S.M.A.R.T. Abbiamo elencato tutte le VM e abbiamo iniziato a esaminare una ad una la configurazione, documentandola in Ansible e coprendola con test.<\/p>\n

                <\/p>\n

                Giorno n. 450: Quale sistema \u00e8 stato realizzato?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Il processo in s\u00e9 non \u00e8 interessante. \u00c8 routinario; si pu\u00f2 notare che la maggior parte delle configurazioni era relativamente semplice o isomorfa, e secondo il principio di Pareto, l'80% delle configurazioni ha richiesto il 20% del tempo. Allo stesso modo, l'80% del tempo \u00e8 stato speso per la preparazione del trasferimento e solo il 20% per il trasferimento stesso. <\/p>\n

                <\/p>\n

                Giorno n. 540: Finale<\/h2>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Cosa \u00e8 successo in 18 mesi?<\/p>\n

                <\/p>\n

                  \n
                1. Gli accordi sono diventati codice.<\/li>\n
                2. Lavoro manuale<\/em> -> Meccanizzazione<\/em> -> Automazione<\/em>.<\/li>\n<\/ol>\n

                  <\/p>\n

                  Links<\/h2>\n

                  <\/p>\n