{"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\/ro\/blog\/administrirovanie\/ansible-migracziya-konfiguraczii-120-vm-c-coreos-na-centos-za-18-mesyaczev","title":{"rendered":"Ansible: Migrarea configura\u021biei a 120 VM de la CoreOS la CentOS \u00een 18 luni","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ansible:<\/p>\n

<\/p>\n

Aceasta este transcrierea prezent\u0103rii de la DevopsConf 2019-10-01<\/a><\/noindex> \u0219i SPbLUG 2019-09-25<\/a><\/noindex>.<\/p>\n

<\/p>\n

Aceasta este povestea proiectului care a folosit un sistem de gestionare a configura\u021biilor personalizat \u0219i de ce migrarea pe Ansible a durat 18 luni.<\/p>\n

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

Ziua \u2116 -XXX: \u00cenainte de \u00eenceput<\/h2>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Ini\u021bial, infrastructura consta dintr-o mul\u021bime de servere independente gestionate de Hyper-V. Crearea unei ma\u0219ini virtuale necesita numeroase ac\u021biuni: a plasa discurile \u00een locul corect, a configura DNS-ul, a rezerva DHCP-ul, a plasa configura\u021bia VM \u00eentr-un repository Git. Acest proces era par\u021bial mecanizat, dar de exemplu, VM-urile erau distribuite manual \u00eentre servere. De exemplu, dezvoltatorii puteau modifica configura\u021bia VM \u00een Git \u0219i s\u0103 o aplice repornind VM-ul.<\/p>\n

<\/p>\n

Solu\u021bie personalizat\u0103 de gestionare a configura\u021biei<\/h3>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Ideea ini\u021bial\u0103, suspectez eu, a fost g\u00e2ndit\u0103 ca IaC: o mul\u021bime de VM-uri stateless, care \u00ee\u0219i resetau starea la repornire. Cum se desf\u0103\u0219ura gestionarea configura\u021biei VM-urilor? Schema p\u0103rea simpl\u0103:<\/p>\n

<\/p>\n

    \n
  1. Pentru VM-uri erau configurate MAC-uri statice.<\/li>\n
  2. Se conecta un ISO la VM cu CoreOS \u0219i un disc de boot.<\/li>\n
  3. CoreOS ruleaz\u0103 un script de personalizare desc\u0103rc\u00e2ndu-l de pe serverul WEB pe baza adresei sale IP.<\/li>\n
  4. Scriptul descarc\u0103 prin SCP configura\u021bia VM-ului baz\u00e2ndu-se pe adresa IP.<\/li>\n
  5. Se lanseaz\u0103 o serie de fi\u0219iere unitate systemd \u0219i o serie de scripturi bash.<\/li>\n<\/ol>\n

    <\/p>\n

    \"Ansible:<\/p>\n

    <\/p>\n

    Aceast\u0103 solu\u021bie avea multe probleme evidente:<\/p>\n

    <\/p>\n

      \n
    1. ISO \u00een CoreOS fusese depreciat.<\/li>\n
    2. Numeroase ac\u021biuni dificil de automatizat \u0219i magie \u00een timpul migra\u021biei\/cre\u0103rii VM-urilor.<\/li>\n
    3. Dificult\u0103\u021bi cu actualizarea \u0219i c\u00e2nd era necesar un software de o anumit\u0103 versiune. Era \u0219i mai complicat cu modulele kernel.<\/li>\n
    4. VM-urile nu erau tocmai f\u0103r\u0103 date, adic\u0103 au ap\u0103rut VM-uri cu un disc montat cu date utilizator.<\/li>\n
    5. Continuau s\u0103 existe probleme cu dependen\u021bele unit\u0103\u021bilor systemd \u0219i CoreOS se bloca la repornire. Era problem\u0103 s\u0103 depistezi asta cu instrumentele existente \u00een CoreOS.<\/li>\n
    6. Gestionarea secretelor.<\/li>\n
    7. CM nu exista, practic. Era bash \u0219i fi\u0219iere de configurare YML pentru CoreOS.<\/li>\n<\/ol>\n

      <\/p>\n

      Pentru a aplica configura\u021bia VM-ului, era nevoie de o repornire, dar aceasta putea s\u0103 nu se reporneasc\u0103. O problem\u0103 aparent evident\u0103, dar nu exist\u0103 discuri persistente - nu aveai unde s\u0103 salvezi jurnalele. Bine, s\u0103 \u00eencerc\u0103m s\u0103 ad\u0103ug\u0103m op\u021biuni de boot pentru a trimite jurnalele. Dar nu, c\u00e2t de complicat e totul.<\/p>\n

      <\/p>\n

      Ziua \u21160: Recunoa\u0219terea problemei<\/h2>\n

      <\/p>\n

      \"Ansible:<\/p>\n

      <\/p>\n

      Aceasta era o infrastructur\u0103 de dezvoltare obi\u0219nuit\u0103: jenkins, medii de testare, monitorizare, registry. CoreOS a fost conceput pentru g\u0103zduirea clusterelor k8s, adic\u0103 problema a fost modul \u00een care era utilizat CoreOS. Primul pas a fost alegerea stivei. Ne-am oprit la:<\/p>\n

      <\/p>\n

        \n
      1. CentOS<\/strong> ca distribu\u021bie de baz\u0103, deoarece este cea mai apropiat\u0103 distribu\u021bie de medii de produc\u021bie.<\/li>\n
      2. Ansible<\/strong> pentru gestionarea configura\u021biilor, deoarece exista o expertiz\u0103 extins\u0103 pe acest subiect.<\/li>\n
      3. Jenkins<\/strong> ca un cadru de automatizare a proceselor existente, deoarece deja era folosit activ pentru procesele de dezvoltare<\/li>\n
      4. Hyper-V<\/strong> ca platform\u0103 de virtualizare. Exist\u0103 o serie de motive dincolo de cele povestite, dar pe scurt \u2014 nu putem utiliza solu\u021bii cloud, trebuie s\u0103 folosim hardware-ul nostru.<\/li>\n<\/ol>\n

        <\/p>\n

        Ziua #30: Document\u0103m acordurile existente \u2014 Agreements as Code<\/h3>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Odat\u0103 ce stiva a fost clar\u0103, a \u00eenceput preg\u0103tirea pentru migrare. Documentarea acordurilor existente sub form\u0103 de cod (Agreements as Code<\/strong>!). Trecerea munc\u0103 manual\u0103<\/em> -> mecanizare<\/em> -> automatizarea<\/em>.<\/p>\n

        <\/p>\n

        1. Configureaz\u0103 VM-uri<\/h4>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Ansible se descurc\u0103 excelent cu aceast\u0103 sarcin\u0103. Cu un minim de efort, putem gestiona configura\u021biile VM-urilor:<\/p>\n

        <\/p>\n

          \n
        1. Cre\u0103m un repository git.<\/li>\n
        2. Adun\u0103m lista VM-urilor \u00een inventory, configura\u021biile \u00een playbook-uri \u0219i roluri.<\/li>\n
        3. Configur\u0103m un slave Jenkins special de pe care putem rula ansible.<\/li>\n
        4. Cre\u0103m un job, configur\u0103m Jenkins.<\/li>\n<\/ol>\n

          <\/p>\n

          Primul proces este gata. Acordurile au fost documentate.<\/p>\n

          <\/p>\n

          2. Creeaz\u0103 un nou VM<\/h4>\n

          <\/p>\n

          \"Ansible:<\/p>\n

          <\/p>\n

          Aici nu era foarte confortabil. Din Linux nu era foarte u\u0219or s\u0103 cre\u0103m VM-uri pe Hyper-V. Una dintre \u00eencerc\u0103rile de a mecaniza acest proces a fost:<\/p>\n

          <\/p>\n

            \n
          1. Ansible se conecteaz\u0103 prin WinRM la gazda Windows.<\/li>\n
          2. Ansible ruleaz\u0103 un script PowerShell.<\/li>\n
          3. Scriptul PowerShell creeaz\u0103 un nou VM.<\/li>\n
          4. Prin intermediul Hyper-V\/ScVMM, la crearea VM-ului pe OS-ul gazd\u0103 se configureaz\u0103 hostname-ul.<\/li>\n
          5. VM-ul, la actualizarea lease-ului DHCP, trimite hostname-ul s\u0103u.<\/li>\n
          6. Integrarea standard ddns & dhcp pe partea Domain Controller configureaz\u0103 \u00eenregistrarea DNS.<\/li>\n
          7. Se pot ad\u0103uga VM-uri \u00een inventory \u0219i se poate configura Ansible pentru acestea.<\/li>\n<\/ol>\n

            <\/p>\n

            3. Creeaz\u0103 un template de VM<\/h4>\n

            <\/p>\n

            \"Ansible:<\/p>\n

            <\/p>\n

            Aici nu am inventat nimic \u2014 am folosit packer.<\/p>\n

            <\/p>\n

              \n
            1. \u00cen repository-ul git, ad\u0103ug\u0103m configura\u021bia packer, kickstart.<\/li>\n
            2. Configur\u0103m un slave Jenkins special cu hyper-v \u0219i Packer.<\/li>\n
            3. Cre\u0103m un job, configur\u0103m Jenkins.<\/li>\n<\/ol>\n

              <\/p>\n

              Cum func\u021bioneaz\u0103 aceast\u0103 combina\u021bie:<\/p>\n

              <\/p>\n

                \n
              1. Packer creeaz\u0103 un VM gol, ata\u0219eaz\u0103 ISO.<\/li>\n
              2. VM-ul se \u00eencarc\u0103, Packer introduce \u00een bootloader comanda de a folosi fi\u0219ierul nostru kickstart de pe dischet\u0103 sau http.<\/li>\n
              3. Se lanseaz\u0103 anaconda cu configura\u021bia noastr\u0103, se face configurarea ini\u021bial\u0103 a OS-ului.<\/li>\n
              4. Packer a\u0219teapt\u0103 disponibilitatea VM-ului.<\/li>\n
              5. Packer ruleaz\u0103 ansible \u00een modul local \u00een interiorul VM-ului.<\/li>\n
              6. Ansible folose\u0219te exact acelea\u0219i roluri ca \u00een pasul nr. 1.<\/li>\n
              7. Packer export\u0103 un \u0219ablon de VM.<\/li>\n<\/ol>\n

                <\/p>\n

                Ziua nr. 75: Refactoriz\u0103m conven\u021biile f\u0103r\u0103 a strica = Test\u0103 ansible + Testkitchen<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                A fixa conven\u021biile \u00een cod poate s\u0103 nu fie suficient. De fapt, dac\u0103 \u00een procesul intern vrei s\u0103 schimbi ceva, s-ar putea s\u0103 strici ceva. De aceea, \u00een cazul infrastructurii, apare nevoia de a testa aceast\u0103 infrastructur\u0103. Pentru a sincroniza cuno\u0219tin\u021bele \u00een cadrul echipei, am \u00eenceput s\u0103 test\u0103m rolurile Ansible. Nu vreau s\u0103 aprofundez, deoarece exist\u0103 un articol care descrie evenimentele din acel moment. Testeaz\u0103-m\u0103 dac\u0103 po\u021bi sau viseaz\u0103 programatorii YML la testarea ansible?<\/a><\/noindex>(spoiler, aceasta nu a fost versiunea final\u0103 \u0219i mai t\u00e2rziu totul a devenit mai complicat) Cum s\u0103 \u00eencepi s\u0103 testezi Ansible, s\u0103 refactorizezi un proiect \u00eentr-un an f\u0103r\u0103 a pierde controlul.<\/a><\/noindex>).<\/p>\n

                <\/p>\n

                Ziua nr. 130: Poate c\u0103 CentOS + ansible nu este necesar? Poate openshift?<\/h3>\n

                <\/p>\n

                Trebuie s\u0103 \u00een\u021belegem c\u0103 procesul de \u00eencorporare a infrastructurii nu a fost singurul \u0219i au fost subproiecte secundare. De exemplu, a ap\u0103rut o solicitare pentru a rula aplica\u021bia noastr\u0103 pe openshift \u0219i aceasta s-a transformat \u00eentr-o cercetare de mai multe s\u0103pt\u0103m\u00e2ni. Rul\u0103m aplica\u021bia \u00een Openshift \u0219i compar\u0103m instrumentele existente.<\/a><\/noindex> ce a \u00eencetinit procesul de mutare. Concluzia a fost c\u0103 openshift nu satisface toate nevoile, este nevoie de hardware real sau cel pu\u021bin de posibilitatea de a experimenta cu nucleul.<\/p>\n

                <\/p>\n

                Ziua nr. 170: Openshift nu se potrive\u0219te, risc\u0103 s\u0103 \u00eencerc\u0103m cu Windows Azure Pack?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Hyper-V nu este foarte prietenos, SCVMM nu \u00eel \u00eembun\u0103t\u0103\u021be\u0219te prea mult. Dar exist\u0103 un lucru numit Windows Azure Pack, care este un addon pentru SCVMM \u0219i imit\u0103 Azure. Dar, \u00een realitate, produsul pare abandonat: documenta\u021bia con\u021bine linkuri rupte \u0219i este destul de s\u0103r\u0103c\u0103cioas\u0103. Dar \u00een cadrul cercet\u0103rii solu\u021biilor pentru a simplifica via\u021ba norului nostru, l-am analizat \u0219i pe acesta.<\/p>\n

                <\/p>\n

                Ziua nr. 250: Windows Azure Pack nu este prea bun. R\u0103m\u00e2nem pe SCVMM.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Windows Azure Pack p\u0103rea promi\u021b\u0103tor, dar s-a decis s\u0103 nu introducem WAP cu dificult\u0103\u021bile sale \u00een sistem pentru caracteristici inutile, a\u0219a c\u0103 am r\u0103mas pe SCVMM.<\/p>\n

                <\/p>\n

                Ziua nr. 360: M\u00e2nc\u0103m elefantul pe buc\u0103\u021bi.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Numai dup\u0103 un an a fost preg\u0103tit\u0103 platforma unde s\u0103 ne mut\u0103m \u0219i a \u00eenceput procesul de mutare. Pentru aceasta, a fost stabilit\u0103 o sarcin\u0103 S.M.A.R.T. Am listat toate VM-urile \u0219i am \u00eenceput s\u0103 ne ocup\u0103m de configurarea lor, s\u0103 o descriem \u00een Ansible \u0219i s\u0103 o acoperim cu teste.<\/p>\n

                <\/p>\n

                Ziua nr. 450: Ce sistem a rezultat?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Procesul \u00een sine nu este interesant. Este rutinier, se poate observa c\u0103 majoritatea configura\u021biilor au fost relativ simple sau izomorfe \u0219i, conform principiului Pareto, 80% din configura\u021bii au necesitat 20% din timp. \u00cen acela\u0219i fel, 80% din timp a fost alocat preg\u0103tirii mut\u0103rii \u0219i doar 20% pentru mutare \u00een sine. <\/p>\n

                <\/p>\n

                Ziua nr. 540: Finalul<\/h2>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Ce s-a \u00eent\u00e2mplat \u00een 18 luni?<\/p>\n

                <\/p>\n

                  \n
                1. Acordurile au devenit cod.<\/li>\n
                2. Munc\u0103 manual\u0103<\/em> -> Mecanizarea<\/em> -> Automatizarea<\/em>.<\/li>\n<\/ol>\n

                  <\/p>\n

                  Linkuri<\/h2>\n

                  <\/p>\n