{"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: Konfiguratsiooni migreerimine 120 VM-i CoreOS-ilt CentOS-ile 18 kuu jooksul","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ansible:<\/p>\n

<\/p>\n

See on ettekande kokkuv\u00f5te 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 kuni Ansible'ile \u00fcleminek venis 18 kuud.<\/p>\n

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

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

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Alguses koosnes infrastruktuur paljusid eraldiseisvaid hoste, mille haldamiseks kasutati Hyper-V. Virtuaalse masina loomine n\u00f5udis hulgaliselt toiminguid: kettad \u00f5igesse kohta panna, DNS m\u00e4\u00e4rata, DHCP reserveerida, VM-i konfiguratsioon git-repositooriumisse panna. See protsess oli osaliselt mehhaniseeritud, kuid n\u00e4iteks VM-id jagati hostide vahel k\u00e4sitsi. Kuid n\u00e4iteks arendajad said VM-i konfiguratsiooni git-is muutes selle taastada VM-i taask\u00e4ivitamisega.<\/p>\n

<\/p>\n

Kohandatud konfiguratsioonihalduse lahendus<\/h3>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Algne idee, kahtlustan, pidi olema nagu IaC: hulk state'ita VM-e, mis taask\u00e4ivitamisel oma oleku nulliks. Kuidas n\u00e4gi v\u00e4lja VM-i konfiguratsiooni haldamine? Koonduvalt n\u00e4eb see lihtne v\u00e4lja:<\/p>\n

<\/p>\n

    \n
  1. VM-idele kinnitati staatiline MAC.<\/li>\n
  2. VM-idele \u00fchendati ISO koos CoreOS-i ja laadimisdiskiga.<\/li>\n
  3. CoreOS k\u00e4ivitab kohandamisskripti, laadides selle WEB-serverist alla oma IP-aadressi alusel.<\/li>\n
  4. Skript t\u00f5mbab SCP kaudu alla VM-i konfiguratsiooni, tuginedes IP-aadressile.<\/li>\n
  5. K\u00e4ivituvad systemd \u00fcksuste failide jadad ja bash-skriptide jadad.<\/li>\n<\/ol>\n

    <\/p>\n

    \"Ansible:<\/p>\n

    <\/p>\n

    Sellel lahendusel oli mitu ilmset probleemi:<\/p>\n

    <\/p>\n

      \n
    1. ISO CoreOS-is oli vananenud.<\/li>\n
    2. Palju keerukaid automatiseeritud toiminguid ja maagiat VM-i migreerimisel\/loomisel.<\/li>\n
    3. Uuendamisega oli keeruline, eriti kui konkreetses versioonis tarkvara vajati. Veelgi keerulisem oli tuumamoodulitega.<\/li>\n
    4. VM-id ei olnud sugugi andmeta, st ilmusid VM-id, millel oli t\u00e4iendavalt \u00fchendatud kett kasutajate andmetega.<\/li>\n
    5. Keegi tegi pidevalt vigu systemd \u00fcksuste s\u00f5ltuvustega ja CoreOS-i taask\u00e4ivitamisel hangus see. Olemasolevate vahenditega oli CoreOS-is seda probleemset tuvastada keeruline.<\/li>\n
    6. Salajaste andmete haldamine.<\/li>\n
    7. CM ei olnud praktiliselt olemas. Oli bash ja CoreOS-i YML konfiguratsioonid.<\/li>\n<\/ol>\n

      <\/p>\n

      VM-i konfiguratsiooni rakendamiseks on vajalik selle taask\u00e4ivitamine, kuid see ei pruugi taask\u00e4ivituda. Tundub ilmne probleem, kuid p\u00fcsivad kettad puuduvad \u2014 logisid pole kuhugi salvestada. Noh, proovime lisada kernelibootimise valikuid, et logid edastataks. Kuid ei, k\u00f5ik tundub nii keeruline.<\/p>\n

      <\/p>\n

      P\u00e4ev nr 0: Probleemi tunnustamine<\/h2>\n

      <\/p>\n

      \"Ansible:<\/p>\n

      <\/p>\n

      See oli tavaline arenduse infrastruktuur: jenkins, testkeskkonnad, j\u00e4lgimised, registry. CoreOS m\u00f5eldi k8s klastrite hostimiseks, st probleem seisnes selles, kuidas CoreOS'i kasutati. Esimene samm oli steigi valimine. Otsustasime:<\/p>\n

      <\/p>\n

        \n
      1. CentOS<\/strong> kas aluseks olev distributsi, kuna see on k\u00f5ige l\u00e4hedasem tootmisringkondadele.<\/li>\n
      2. Ansible<\/strong> konfiguratsioonide haldamiseks, kuna selle kohta oli ulatuslikku ekspertiisi.<\/li>\n
      3. Jenkins<\/strong> olemasolevate protsesside automatiseerimise raamistiku n\u00e4ol, kuna seda kasutati juba aktiivselt arendusprotsessides.<\/li>\n
      4. Hyper-V<\/strong> virtualiseerimise platvormina. On mitmeid p\u00f5hjuseid, mis \u00fcletavad selle jutu, kuid l\u00fchidalt \u2014 me ei saa kasutada pilvi, peame kasutama oma riistvara.<\/li>\n<\/ol>\n

        <\/p>\n

        P\u00e4ev \u211630: Salvestame olemasolevad lepped \u2014 Agreements as Code<\/h3>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Kui steik oli selge, algas ettevalmistus kolimiseks. Olemasolevate lepingute salvestamine koodina (Agreements as Code<\/strong>!). \u00dcleminek k\u00e4te t\u00f6\u00f6<\/em> -> mehhaniseerimine<\/em> -> automatiseerimine<\/em>.<\/p>\n

        <\/p>\n

        1. Konfigureeri virtuaalmasinad<\/h4>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Ansible teeb selle \u00fclesande suurep\u00e4raselt. Minimalsete pingutustega saab hallata VM-de konfiguratsioone:<\/p>\n

        <\/p>\n

          \n
        1. Loome git reposti.<\/li>\n
        2. Kogume VM-id inventari, konfiguratsioonid playbookidesse ja rollidesse.<\/li>\n
        3. Seame \u00fcles spetsiaalse Jenkins slave'i, millelt on v\u00f5imalik Ansible'i k\u00e4ivitada.<\/li>\n
        4. Loome t\u00f6\u00f6, seadistame Jenkinsit.<\/li>\n<\/ol>\n

          <\/p>\n

          Esimene protsess on valmis. Kokku lepingud on kinnitatud.<\/p>\n

          <\/p>\n

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

          <\/p>\n

          \"Ansible:<\/p>\n

          <\/p>\n

          Siin ei olnud k\u00f5ik v\u00e4ga mugav. Linuxist ei olnud v\u00e4ga mugav luua VM-e Hyper-V-s. \u00dcks proovidest 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-i.<\/li>\n
          4. Hyper-V\/ScVMM abil, kui VM-i luuakse, on k\u00fclalis-OS-is seadistatud hostname.<\/li>\n
          5. VM saadab DHCP lease'i uuendamisel oma hostname'i.<\/li>\n
          6. DDNS ja DHCP standardne integreerimine Domain Controller'i poolest seadistab DNS kirje.<\/li>\n
          7. VM-e saab lisada inventari ja seadistada nende Ansible'i.<\/li>\n<\/ol>\n

            <\/p>\n

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

            <\/p>\n

            \"Ansible:<\/p>\n

            <\/p>\n

            Siin ei hakanud me midagi leiutama \u2014 v\u00f5tsime Packer'i.<\/p>\n

            <\/p>\n

              \n
            1. Paneme Git reposse Packer'i ja kickstarti konfi.<\/li>\n
            2. Seame \u00fcles spetsiaalse Jenkins slave'i Hyper-V ja Packer'i jaoks.<\/li>\n
            3. Loome t\u00f6\u00f6, seadistame Jenkinsit.<\/li>\n<\/ol>\n

              <\/p>\n

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

              <\/p>\n

                \n
              1. Packer loob t\u00fchja VM-i ning \u00fchendab ISO.<\/li>\n
              2. VM k\u00e4ivitub, Packer annab k\u00e4skluse kasutada meie kickstart faili ketasel v\u00f5i http kaudu.<\/li>\n
              3. K\u00e4ivitub Anaconda koos meie konfiguuri, tehakse OS-i esialgne seadistamine.<\/li>\n
              4. Packer ootab VM-i k\u00e4ttesaadavust.<\/li>\n
              5. Packer VM sees ansible running in local mode.<\/li>\n
              6. Ansible uses exactly the same roles as in step \u21161.<\/li>\n
              7. Packer exports the VM template.<\/li>\n<\/ol>\n

                <\/p>\n

                Day \u211675: Refactoring agreements without breaking = Test ansible + Testkitchen<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Simply fixing the agreements in code may not be enough. If during the process you want to change something, you might break something. Therefore, infrastructure testing becomes essential. To synchronize knowledge within the team, we started testing Ansible roles. I won't go into detail as there is an article describing the events at that time. Test me if you can, or do YML programmers dream of testing ansible?<\/a><\/noindex>(spoiler, this was not the final version and things got more complicated later) How to start testing Ansible, refactor a project in a year, and not lose your mind.<\/a><\/noindex>).<\/p>\n

                <\/p>\n

                Day \u2116130: Maybe CentOS+ansible isn't needed? Maybe openshift?<\/h3>\n

                <\/p>\n

                It's important to understand that the infrastructure integration process wasn't the only one, and there were side projects. For instance, a request came to run our application in openshift, which led to research lasting more than a week. K\u00e4ivitame rakenduse Openshiftis ja v\u00f5rdleme olemasolevat t\u00f6\u00f6riistade komplekti<\/a><\/noindex> mis pidurdas kolimise protsessi. Tulemuseks oli, et openshift ei katnud k\u00f5iki vajadusi, vajalik on reaalne riistvara v\u00f5i v\u00e4hemalt v\u00f5imalus m\u00e4ngida tuumaga.<\/p>\n

                <\/p>\n

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

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Hyper-V ei ole eriti s\u00f5bralik, SCVMM ei tee sellest palju paremat. Kuid on olemas selline asi nagu Windows Azure Pack, mis on SCVMM-i pealne ja matkib Azure'i. Kuid tegelikkuses n\u00e4eb toode v\u00e4lja mahaj\u00e4etud: dokumentatsioon on katkenud linkidega ja \u00fcsna vaene. Kuid meie pilve elu lihtsustamise v\u00f5imaluste uurimisel vaatasime ka seda.<\/p>\n

                <\/p>\n

                P\u00e4ev \u2116250: Windows Azure Pack ei ole v\u00e4ga hea. J\u00e4tkame SCVMM-is.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Windows Azure Pack n\u00e4gi v\u00e4lja paljut\u00f5otav, kuid otsustasime mitte tuua WAP-i koos selle raskustega s\u00fcsteemi, et v\u00e4ltida tarbetuid funktsioone, ja j\u00e4ime SCVMM-i.<\/p>\n

                <\/p>\n

                P\u00e4ev \u2116360: S\u00f6\u00f6dame elevanti t\u00fckkhaaval<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Ainult aasta p\u00e4rast oli platvorm valmis, kuhu kolida, ja kolimisprotsess algas. Selleks seati eesm\u00e4rgiks S.M.A.R.T. \u00fclesanne. Kirjutasime \u00fcles k\u00f5ik virtuaalsed masinad ja hakkasime \u00fcksikult nende konfiguratsiooniga tegelema, kirjeldama seda Ansible'is, katma testidega.<\/p>\n

                <\/p>\n

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

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Protsess ise ei ole huvitav. See on rutiinne, v\u00f5ib m\u00e4rkida, et enamus konfiguratsioone olid suhteliselt lihtsad v\u00f5i isomorfsed ning Pareto p\u00f5him\u00f5tte kohaselt n\u00f5udis 80% konfiguratsioone 20% ajast. Sama printsiibi kohaselt kulus 80% ajast ettevalmistamiseks ja ainult 20% \u00fcleviimiseks. <\/p>\n

                <\/p>\n

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

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Mis siis 18 kuu jooksul juhtus?<\/p>\n

                <\/p>\n

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

                  <\/p>\n

                  Lingid<\/h2>\n

                  <\/p>\n