{"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 a DevopsConf 2019-10-01<\/a><\/noindex> e SPbLUG 2019-09-25<\/a><\/noindex>.<\/p>\n

<\/p>\n

Questa \u00e8 la storia del progetto che ha utilizzato un sistema di gestione delle configurazioni sviluppato internamente e il motivo per cui la migrazione su Ansible ha impiegato 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 consisteva in un gran numero di host indipendenti gestiti da Hyper-V. La creazione di una macchina virtuale richiedeva molte operazioni: posizionare i dischi nel luogo giusto, configurare il DNS, prenotare il DHCP e inserire la configurazione della VM in un repository Git. Questo processo era parzialmente meccanizzato, ma ad esempio le VM venivano distribuite tra gli host manualmente. Tuttavia, per esempio, gli sviluppatori potevano modificare la configurazione della VM in 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, suppongo, era concepita come IaC: molte VM stateless, che azzeravano il loro stato al riavvio. Come appariva la gestione delle configurazioni delle VM? Schematicamente sembra semplice:<\/p>\n

<\/p>\n

    \n
  1. Per le VM veniva assegnato un MAC statico.<\/li>\n
  2. Alle VM veniva collegato un ISO con 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 avviata una serie di file di unit\u00e0 systemd e una serie di script bash.<\/li>\n<\/ol>\n

    <\/p>\n

    \"Ansible:<\/p>\n

    <\/p>\n

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

    <\/p>\n

      \n
    1. L'ISO in CoreOS era deprecato.<\/li>\n
    2. Numerose azioni e magie difficilmente automatizzabili durante la migrazione\/creazione delle VM.<\/li>\n
    3. Difficolt\u00e0 con l'aggiornamento e quando era necessario del software di una certa versione. Ancora pi\u00f9 divertente con i moduli del kernel.<\/li>\n
    4. Le VM non risultavano cos\u00ec prive di dati, ovvero apparvero VM con un disco montato contenente dati utente aggiuntivi.<\/li>\n
    5. Qualcuno combinava sempre guai con le dipendenze delle unit\u00e0 systemd e al riavvio CoreOS si bloccava. Era problematico catturarlo con i mezzi a disposizione in CoreOS.<\/li>\n
    6. Gestione dei segreti.<\/li>\n
    7. Non c'era un vera e propria CM. C'era bash e i config YML di CoreOS.<\/li>\n<\/ol>\n

      <\/p>\n

      Per applicare la configurazione della VM era necessario riavviarla, ma a volte non si riavviava. Sembra un problema ovvio, ma non ci sono dischi persistenti \u2013 non c\u2019\u00e8 dove salvare i log. Va bene, proviamo ad aggiungere opzioni di avvio del kernel in modo da inviare i log. Ma no, quanto \u00e8 complicato tutto ci\u00f2.<\/p>\n

      <\/p>\n

      Giorno \u21160: Riconoscimento del problema<\/h2>\n

      <\/p>\n

      \"Ansible:<\/p>\n

      <\/p>\n

      Questa era un'infrastruttura di sviluppo abituale: jenkins, ambienti di test, monitoraggi, registry. CoreOS era pensato per l'hosting di cluster k8s, cio\u00e8 il problema stava nel modo in cui veniva utilizzato CoreOS. Il primo passo \u00e8 stato la scelta della stack.<\/p>\n

      <\/p>\n

        \n
      1. CentOS<\/strong> come distribuzione base, poich\u00e9 \u00e8 la distribuzione pi\u00f9 vicina agli ambienti di produzione.<\/li>\n
      2. Ansible<\/strong> per la gestione delle configurazioni, poich\u00e9 si aveva una vasta esperienza a riguardo.<\/li>\n
      3. Jenkins<\/strong> come framework di automazione dei processi esistenti, poich\u00e9 era gi\u00e0 attivamente utilizzato per i processi di sviluppo.<\/li>\n
      4. Hyper-V<\/strong> come piattaforma di virtualizzazione. Ci sono diverse ragioni al di l\u00e0 di quanto descritto, ma per farla breve \u2014 non possiamo utilizzare cloud e 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

        Quando la stack era chiara, \u00e8 iniziata la preparazione per il 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 bene di quest'attivit\u00e0. Con un minimo di sforzi, \u00e8 possibile gestire le configurazioni delle VM:<\/p>\n

        <\/p>\n

          \n
        1. Creiamo un repository git.<\/li>\n
        2. Archiviare l'elenco delle VM nell'inventory, le configurazioni nei playbook e nei ruoli.<\/li>\n
        3. Configurare un slave Jenkins speciale da cui sar\u00e0 possibile eseguire Ansible.<\/li>\n
        4. Creiamo un job, configurando Jenkins.<\/li>\n<\/ol>\n

          <\/p>\n

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

          <\/p>\n

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

          <\/p>\n

          \"Ansible:<\/p>\n

          <\/p>\n

          Qui le cose non erano molto comode. Era difficile creare VM su Hyper-V da Linux. Uno dei tentativi di meccanizzare questo processo \u00e8 stato:<\/p>\n

          <\/p>\n

            \n
          1. Ansible si connette tramite WinRM all'host Windows.<\/li>\n
          2. Ansible esegue uno script PowerShell.<\/li>\n
          3. Lo script PowerShell crea una nuova VM.<\/li>\n
          4. Con gli strumenti Hyper-V\/ScVMM durante la creazione della VM nel guest OS viene configurato il hostname.<\/li>\n
          5. La VM, durante l'aggiornamento del lease DHCP, invia il suo hostname.<\/li>\n
          6. L'integrazione standard ddns & dhcp sul lato del Domain Controller configura il record DNS.<\/li>\n
          7. \u00c8 possibile aggiungere la VM all'inventory e configurarla con Ansible.<\/li>\n<\/ol>\n

            <\/p>\n

            3. Creare 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. Archiviamosi nel repository git la configurazione di packer, kickstart.<\/li>\n
            2. Configurare un slave Jenkins speciale con hyper-v e Packer.<\/li>\n
            3. Creiamo un job, configurando Jenkins.<\/li>\n<\/ol>\n

              <\/p>\n

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

              <\/p>\n

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

                <\/p>\n

                Giorno n. 75: Rifattorizziamo 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 nel profondo del processo vuoi cambiare qualcosa, potresti rompere qualcosa. Ecco perch\u00e9, per l'infrastruttura, entra in gioco il test di quella stessa infrastruttura. Per sincronizzare le conoscenze all'interno del team, abbiamo iniziato a testare i ruoli di Ansible. Non approfondir\u00f2 poich\u00e9 esiste un articolo che descrive gli eventi di quel momento. Testami se ci riesci o sognano gli sviluppatori YML di testare ansible?<\/a><\/noindex>(spoiler: questa non era la versione finale e in seguito tutto \u00e8 diventato pi\u00f9 complicato) Come iniziare a testare Ansible, rifattorizzare un progetto in un anno e non perdere la ragione<\/a><\/noindex>).<\/p>\n

                <\/p>\n

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

                <\/p>\n

                Bisogna capire che il processo di implementazione dell'infrastruttura non \u00e8 stato l'unico e ci sono stati progetti secondari. Ad esempio, \u00e8 arrivata una richiesta per avviare la nostra applicazione in Openshift e questo si \u00e8 tradotto in ricerche non inferiori a una settimana. Avviamo l'applicazione in Openshift e confrontiamo gli strumenti esistenti.<\/a><\/noindex> cosa ha rallentato il processo di migrazione. Il risultato \u00e8 stato che Openshift non soddisfa tutte le esigenze; \u00e8 necessario hardware reale, o almeno la possibilit\u00e0 di giocare con il kernel.<\/p>\n

                <\/p>\n

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

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Hyper-V non \u00e8 molto amichevole, SCVMM non lo migliora significativamente. Ma c'\u00e8 una cosa chiamata Windows Azure Pack, che \u00e8 un'add-on di SCVMM e si mimetizza come Azure. Ma in realt\u00e0 il prodotto appare abbandonato: documentazione con link rotti e piuttosto scarsa. Tuttavia, nel contesto della ricerca di opzioni per semplificare la vita della nostra cloud, lo abbiamo esaminato.<\/p>\n

                <\/p>\n

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

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

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

                <\/p>\n

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

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Solo dopo un anno la piattaforma in cui migrare era pronta e inizi\u00f2 il processo di migrazione. Per questo \u00e8 stato stabilito un obiettivo S.M.A.R.T. Abbiamo elencato tutte le VM e abbiamo iniziato a analizzare una per una le configurazioni, descriverle su Ansible, coprirle di test.<\/p>\n

                <\/p>\n

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

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Il processo stesso 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. Secondo lo stesso principio, l'80% del tempo \u00e8 stato speso per la preparazione del trasloco e solo il 20% per il trasloco stesso. <\/p>\n

                <\/p>\n

                Giorno \u2116540: Finale<\/h2>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

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

                <\/p>\n

                  \n
                1. Le intese sono diventate codice.<\/li>\n
                2. Lavoro manuale<\/em> -> Meccanizzazione<\/em> -> Automazione<\/em>.<\/li>\n<\/ol>\n

                  <\/p>\n

                  Links<\/h2>\n

                  <\/p>\n