{"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\/et\/blog\/administrirovanie\/ansible-migracziya-konfiguraczii-120-vm-c-coreos-na-centos-za-18-mesyaczev","title":{"rendered":"Ansible: 120 VM CoreOS-i konfiguratsiooni migreerimine CentOS-ile 18 kuu jooksul","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ansible:<\/p>\n

<\/p>\n

See esitluse t\u00f5lgendus DevopsConf 2019-10-01<\/a><\/noindex> ja SPbLUG 2019-09-25<\/a><\/noindex>.<\/p>\n

<\/p>\n

See on projekti lugu, kus kasutati kohandatud konfiguratsioonihalduse s\u00fcsteemi ja miks \u00fcleminek Ansible'ile venis 18 kuud.<\/p>\n

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

P\u00e4ev \u2116 -\u0425\u0425\u0425: Enne algust<\/h2>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Algne infrastruktuur koosnes paljuski eraldiseisvatest hostidest, mida haldas Hyper-V. Virtuaalmachine'i loomine n\u00f5udis palju samme: diskide paigutamine \u00f5igesse kohta, DNS-i seadistamine, DHCP reservatsioonide tegemine ja VM konfiguratsiooni salvestamine git-iga. See protsess oli osaliselt mehhaniseeritud, kuid n\u00e4iteks VM-id jaotati hostide vahel k\u00e4sitsi. Kuid arendajad said VM-i konfiguratsiooni git-iga muutes rakendada seda VM-i taask\u00e4ivitamise kaudu.<\/p>\n

<\/p>\n

Kohandatud konfiguratsioonihalduse lahendus<\/h3>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Algne idee, kahtlustan, oli m\u00f5eldud nagu IaC: hulk staateless VM-e, mis l\u00e4htestavad oma oleku p\u00e4rast taask\u00e4ivitamist. Kuidas siis tundus VM-ide konfiguratsiooni haldamine? Skeemiliselt n\u00e4eb see lihtne v\u00e4lja:<\/p>\n

<\/p>\n

    \n
  1. VM-idele m\u00e4\u00e4rati staatiline MAC.<\/li>\n
  2. VM-ile \u00fchendati ISO CoreOS ja k\u00e4ivitusdisk.<\/li>\n
  3. CoreOS k\u00e4ivitab kohandamise skripti, laadides selle alla veebiserverist vastavalt oma IP-le.<\/li>\n
  4. Skript t\u00f5mbab l\u00e4bi SCP VM konfiguratsiooni, l\u00e4htudes IP-aadressist.<\/li>\n
  5. K\u00e4ivitub hulk systemd unit faile ja rida bash skripte.<\/li>\n<\/ol>\n

    <\/p>\n

    \"Ansible:<\/p>\n

    <\/p>\n

    Sellel lahendusel oli palju ilmselgeid probleeme:<\/p>\n

    <\/p>\n

      \n
    1. ISO CoreOS-is oli deprecated.<\/li>\n
    2. Palju keerulisi automatiseeritud toiminguid ja maagia VM-ide migreerimisel\/loomisel.<\/li>\n
    3. Probleem uuendamisel ja kui vajalik on teatud versiooni tarkvara. Veelgi keerulisem oli tuumamoodulite puhul.<\/li>\n
    4. VM-id ei olnud nii andmeteta, st ilmusid VM-id, millel oli lisaks monteeritud kettad kasutajate andmetega.<\/li>\n
    5. Keegi eksis pidevalt systemd uniti s\u00f5ltuvustega ja CoreOS hangus taask\u00e4ivitamisel. K\u00e4esolevad vahendid CoreOS-is selle tabamiseks olid problemaatilised.<\/li>\n
    6. Salajase haldamine.<\/li>\n
    7. CM ei olnud sisuliselt olemas. Oli bash ja YML konfiguratsioonid CoreOS-is.<\/li>\n<\/ol>\n

      <\/p>\n

      Kuna VM-i konfiguratsiooni rakendamiseks tuleb seda taask\u00e4ivitada, v\u00f5is see mitte taask\u00e4ivituda. Tundub, et see on ilmne probleem, kuid p\u00fcsiandmeid pole \u2013 logisid ei saa s\u00e4ilitada. No h\u00e4sti, proovime lisada kernelilaadimisvalikuid, et logid edastataks. Kuid ei, see on k\u00f5ik nii keeruline.<\/p>\n

      <\/p>\n

      P\u00e4ev \u21160: Probleemi tunnustamine<\/h2>\n

      <\/p>\n

      \"Ansible:<\/p>\n

      <\/p>\n

      See oli tavaline arenduste infrastruktuur: jenkins, testkeskkonnad, j\u00e4lgimised, registrid. CoreOS oli m\u00f5eldud k8s-klastrite majutamiseks, st probleem oli selles, kuidas CoreOS'i kasutati. Esimene samm oli steki valimine. Peatusime:<\/p>\n

      <\/p>\n

        \n
      1. CentOS<\/strong> kui p\u00f5hijagamine, kuna see on k\u00f5ige l\u00e4hemal tootmisreaktsioonidele.<\/li>\n
      2. Ansible<\/strong> konfiguratsioonide haldamiseks, kuna selle kohta oli suur ekspertteave.<\/li>\n
      3. Jenkinsile<\/strong> automaatika raamistikuna olemasolevate protsesside jaoks, kuna seda kasutati juba aktiivselt arendusprotsesside jaoks.<\/li>\n
      4. Hyper-V<\/strong> virtualiseerimise platvormina. On mitmeid p\u00f5hjuseid, mis \u00fcletavad jutustamise ulatust, kuid l\u00fchidalt - me ei saa kasutada pilvi, peame kasutama oma riistvara.<\/li>\n<\/ol>\n

        <\/p>\n

        P\u00e4ev nr 30: Fikseerime olemasolevad kokkulepped - Agreements as Code<\/h3>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Kui stek oli selge, algas \u00fcleviimise ettevalmistamine. Olemasolevate kokkulepetega koodina fikseerimine (Agreements as Code<\/strong>!). \u00dcleminek k\u00e4sit\u00f6\u00f6<\/em> -> mehhaniseerimine<\/em> -> automaatika<\/em>.<\/p>\n

        <\/p>\n

        1. Konfigureeri VM-id<\/h4>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Ansible teeb selle t\u00f6\u00f6 suurep\u00e4raselt \u00e4ra. Minimaalse vaevaga saab hallata VM-i konfiguratsioone:<\/p>\n

        <\/p>\n

          \n
        1. Loo git-repositoorium.<\/li>\n
        2. Paigutame VM-ide nimekirja inventuuri, konfiguratsioonid m\u00e4ngude ja rollidena.<\/li>\n
        3. Seadistame spetsiaalse jenkins slave'i, mille kaudu saab ansible'it k\u00e4ivitada.<\/li>\n
        4. Loome t\u00f6\u00f6, seadistame Jenkins'i.<\/li>\n<\/ol>\n

          <\/p>\n

          Esimene protsess on valmis. Kokkulepped on fikseeritud.<\/p>\n

          <\/p>\n

          2. Loo uus VM<\/h4>\n

          <\/p>\n

          \"Ansible:<\/p>\n

          <\/p>\n

          Siin polnud k\u00f5ik v\u00e4ga mugav. Linuxist oli ebamugav luua VM-e Hyper-V-s. \u00dcks katse selle protsessi mehhaniseerimiseks oli:<\/p>\n

          <\/p>\n

            \n
          1. Ansible \u00fchendub WinRM kaudu Windowsi hostiga.<\/li>\n
          2. Ansible k\u00e4ivitab powershell skripti.<\/li>\n
          3. Powershell skript loob uue VM.<\/li>\n
          4. Hyper-V\/ScVMM vahenditega seadistatakse vm-i loomisel k\u00fclgoperatsioonis hostname.<\/li>\n
          5. VM saadab uuendades DHCP lease oma hostname'i.<\/li>\n
          6. Eramud integreerimine ddns & dhcp Domaanikontrolleri poole seadistab DNS-i kirje.<\/li>\n
          7. VM-id saab lisada inventuuri ja nende anabse'it seadistada.<\/li>\n<\/ol>\n

            <\/p>\n

            3. Loo VM-i mall<\/h4>\n

            <\/p>\n

            \"Ansible:<\/p>\n

            <\/p>\n

            Siin ei hakatud midagi leiutama - v\u00f5eti packer.<\/p>\n

            <\/p>\n

              \n
            1. Git-repositooriumisse paneme packer'i konfi ja kickstart'i.<\/li>\n
            2. Seadistame spetsiaalse jenkins slave'i hyper-v ja Packer'iga.<\/li>\n
            3. Loome t\u00f6\u00f6, seadistame Jenkins'i.<\/li>\n<\/ol>\n

              <\/p>\n

              Kuidas see kombinatsioon t\u00f6\u00f6tab:<\/p>\n

              <\/p>\n

                \n
              1. Packer loob t\u00fchja VM-i, \u00fchendab ISO-d.<\/li>\n
              2. VM k\u00e4ivitub, Packer annab laadimisprogrammile k\u00e4su kasutada meie kickstart faili diskettidelt v\u00f5i http-st.<\/li>\n
              3. Anaconda k\u00e4ivitub meie konfiguratsiooniga, tehakse algseadistus OS-ile.<\/li>\n
              4. Packer ootab VM-i k\u00e4ttesaadavust.<\/li>\n
              5. Packer k\u00e4ivitab VM-is ansible'i kohalikus re\u017eiimis.<\/li>\n
              6. Ansible kasutab samu rolle nagu 1. sammus.<\/li>\n
              7. Packer ekspordib VM-i \u0161ablooni.<\/li>\n<\/ol>\n

                <\/p>\n

                P\u00e4ev \u211675: Refaktoreerime kokkuleppeid, rikkumata = Testi ansible + Testkitchen<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Kokkulepete koodiks fikseerimine v\u00f5ib olla ebapiisav. Kui sa tahad protsessi k\u00e4igus midagi muuta \u2013 v\u00f5id midagi purustada. Seet\u00f5ttu ilmneb infrastruktuuri testimise vajadus. Meie tiimis, et teadmisi s\u00fcnkroniseerida, hakkasime testima Ansible rolle. Ei hakka s\u00fcvitsi minema, sest on artikkel, mis kirjeldab tol ajal toimunud s\u00fcndmusi. Proovi mind, kui suudad, v\u00f5i unistavad YML-programmeerijad ansible'i testimisest?<\/a><\/noindex>(spoiler: see ei olnud l\u00f5plik variant ja hiljem l\u00e4ks k\u00f5ik keerulisemaks) Kuidas alustada Ansible'i testimist, refaktoreerida projekt aasta jooksul ja mitte \u00e4ra hinge j\u00e4\u00e4da.<\/a><\/noindex>).<\/p>\n

                <\/p>\n

                P\u00e4ev \u2116130: Kas CentOS+ansible polegi vajalik? \u00c4kki openshift?<\/h3>\n

                <\/p>\n

                Tuleb m\u00f5ista, et infrastruktuuri kaasamise protsess ei olnud ainus ja tekkis k\u00f5rvalprojekte. N\u00e4iteks saime taotluse meie rakenduse k\u00e4ivitamiseks openshiftis ja see kujunes v\u00e4lja uuringuteks, mis kestsid \u00fcle n\u00e4dala. K\u00e4ivitame rakenduse Openshiftis ja v\u00f5rdleme olemasolevat t\u00f6\u00f6riistade komplekti.<\/a><\/noindex> mis aeglustas \u00fclemineku protsessi. Tulemuseks selgus, et openshift ei kata k\u00f5iki vajadusi, vajalik on reaalne riistvara, v\u00f5i v\u00e4hemalt v\u00f5imalus tuuma katsetamiseks.<\/p>\n

                <\/p>\n

                P\u00e4ev \u2116170: Openshift ei sobi, kas riskime Windows Azure Packiga?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Hyper-V ei ole just s\u00f5bralik, SCVMM ei tee seda palju paremaks. Kuid olemas on selline asi nagu Windows Azure Pack, mis on SCVMM-i pealiskonstruktsioon ja j\u00e4ljendab Azure'i. Kuid tegelikkuses n\u00e4eb toode v\u00e4lja mahaj\u00e4etud: dokumentatsioon katkendlike linkidega ja \u00fcsna napp. Kuid meie pilve elu lihtsustamise valikute uurimise raames vaatasime ka seda.<\/p>\n

                <\/p>\n

                P\u00e4ev \u2116250: Windows Azure Pack ei ole just parim. J\u00e4\u00e4me SCVMM-ile.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Windows Azure Pack n\u00e4gi v\u00e4lja paljut\u00f5otav, kuid otsustati mitte tuua WAP-i oma s\u00fcsteemi selle keerukustega tarbetute funktsioonide t\u00f5ttu ja j\u00e4\u00e4da SCVMM-ile.<\/p>\n

                <\/p>\n

                P\u00e4ev \u2116360: S\u00f6\u00f6me elevanti t\u00fckkide kaupa.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Alles aasta p\u00e4rast oli platvorm, kuhu kolida, valmis ja algas \u00fclemineku protsess. Selleks pandi paika S.M.A.R.T. \u00fclesanne. K\u00f5ik VM-id loetleti ja hakati \u00fcks haaval nende konfigureerimisega tegelema, kirjeldama seda Ansible'is ning katma testidega.<\/p>\n

                <\/p>\n

                P\u00e4ev \u2116450: Milline s\u00fcsteem v\u00e4lja kujunes?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Protsess ise ei ole huvitav. See on rutiinne, v\u00f5ib m\u00e4rkida, et enamik konfiguratsioone olid suhteliselt lihtsad v\u00f5i isomorfsed ja Pareto printsiibi j\u00e4rgi l\u00e4ks 80% konfiguratsioonide jaoks 20% ajast. Sama printsiibi kohaselt kulus 80% ajast koristust\u00f6\u00f6de ettevalmistamiseks ja ainult 20% ise kolimiseks. <\/p>\n

                <\/p>\n

                P\u00e4ev nr 540: Finaal<\/h2>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Mis toimub 18 kuu jooksul?<\/p>\n

                <\/p>\n

                  \n
                1. Kokkulepped muutusid koodiks.<\/li>\n
                2. K\u00e4sit\u00f6\u00f6<\/em> -> Mehaaniseerimine<\/em> -> Automatiseerimine<\/em>.<\/li>\n<\/ol>\n

                  <\/p>\n

                  Links<\/h2>\n

                  <\/p>\n