{"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\/pl\/blog\/administrirovanie\/ansible-migracziya-konfiguraczii-120-vm-c-coreos-na-centos-za-18-mesyaczev","title":{"rendered":"Ansible: Migracja konfiguracji 120 VM z CoreOS na CentOS w ci\u0105gu 18 miesi\u0119cy","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ansible:<\/p>\n

<\/p>\n

To jest transkrypcja wyst\u0105pienia na DevopsConf 2019-10-01<\/a><\/noindex> i SPbLUG 2019-09-25<\/a><\/noindex>.<\/p>\n

<\/p>\n

To jest historia projektu, w kt\u00f3rym u\u017cyto autorskiego systemu zarz\u0105dzania konfiguracj\u0105 i dlaczego migracja do Ansible zaj\u0119\u0142a 18 miesi\u0119cy.<\/p>\n

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

Dzie\u0144 nr -XXX: Przed rozpocz\u0119ciem<\/h2>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Pocz\u0105tkowo infrastruktura sk\u0142ada\u0142a si\u0119 z wielu oddzielnych host\u00f3w zarz\u0105dzanych przez Hyper-V. Tworzenie maszyny wirtualnej wymaga\u0142o wielu dzia\u0142a\u0144: umieszczenia dysk\u00f3w w odpowiednich miejscach, skonfigurowania DNS, zarezerwowania DHCP, umieszczenia konfiguracji VM w repozytorium git. Ten proces by\u0142 cz\u0119\u015bciowo zautomatyzowany, ale na przyk\u0142ad maszyny wirtualne by\u0142y przydzielane mi\u0119dzy hostami manualnie. Na przyk\u0142ad programi\u015bci mogli edytowa\u0107 konfiguracj\u0119 VM w git i zastosowa\u0107 j\u0105, restartuj\u0105c VM.<\/p>\n

<\/p>\n

Custom Configuration Management Solution<\/h3>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Pocz\u0105tkowo zak\u0142ada\u0142em, \u017ce pomys\u0142 by\u0142 planowany jako IaC: wiele maszyn wirtualnych bezstanowych, kt\u00f3re przy ponownym uruchomieniu resetowa\u0142y sw\u00f3j stan. Jakie by\u0142o zarz\u0105dzanie konfiguracjami VM? Schematycznie wygl\u0105da\u0142o to prosto:<\/p>\n

<\/p>\n

    \n
  1. Dla VM przypisywano statyczny adres MAC.<\/li>\n
  2. Do VM pod\u0142\u0105czano ISO z CoreOS i dysk rozruchowy.<\/li>\n
  3. CoreOS uruchamia skrypt dostosowuj\u0105cy, pobieraj\u0105c go z serwera WEB na podstawie swojego adresu IP.<\/li>\n
  4. Skrypt pobiera przez SCP konfiguracj\u0119 VM na podstawie adresu IP.<\/li>\n
  5. Uruchamiana jest sekwencja plik\u00f3w jednostek systemd oraz skrypt\u00f3w bash.<\/li>\n<\/ol>\n

    <\/p>\n

    \"Ansible:<\/p>\n

    <\/p>\n

    To rozwi\u0105zanie mia\u0142o wiele oczywistych problem\u00f3w:<\/p>\n

    <\/p>\n

      \n
    1. ISO w CoreOS zosta\u0142o oznaczone jako przestarza\u0142e.<\/li>\n
    2. Wiele skomplikowanych zautomatyzowanych dzia\u0142a\u0144 i magii podczas migracji\/tworzenia VM.<\/li>\n
    3. Problemy z aktualizacj\u0105 i gdy potrzebne by\u0142o oprogramowanie w konkretnej wersji. Jeszcze wi\u0119cej problem\u00f3w z modu\u0142ami j\u0105dra.<\/li>\n
    4. VM nie by\u0142y tak zupe\u0142nie bezdane, to znaczy powsta\u0142y VM z zamontowanym dodatkowym dyskiem z danymi u\u017cytkownik\u00f3w.<\/li>\n
    5. Kto\u015b zawsze robi\u0142 b\u0142\u0105d z zale\u017cno\u015bciami jednostek systemd, przez co CoreOS si\u0119 zawiesza\u0142 podczas ponownego uruchamiania. Z u\u017cywanych narz\u0119dzi w CoreOS, zdiagnozowanie tego by\u0142o problematyczne.<\/li>\n
    6. Zarz\u0105dzanie sekretami.<\/li>\n
    7. W zasadzie nie by\u0142o CM. By\u0142 bash i konfiguracje YML w CoreOS.<\/li>\n<\/ol>\n

      <\/p>\n

      Aby zastosowa\u0107 konfiguracj\u0119 VM, trzeba j\u0105 by\u0142o zrestartowa\u0107, ale mog\u0142a si\u0119 nie uruchomi\u0107. Wydaje si\u0119 to oczywistym problemem, ale brakowa\u0142o trwa\u0142ych dysk\u00f3w \u2014 nie by\u0142o gdzie zapisywa\u0107 log\u00f3w. No dobrze, spr\u00f3bujmy doda\u0107 opcje do \u0142adowania j\u0105dra, \u017ceby logi by\u0142y przesy\u0142ane. Ale nie, to wszystko jest tak skomplikowane.<\/p>\n

      <\/p>\n

      Dzie\u0144 nr 0: Uzna\u0107 problem<\/h2>\n

      <\/p>\n

      \"Ansible:<\/p>\n

      <\/p>\n

      To by\u0142a zwyk\u0142a infrastruktura deweloperska: jenkins, \u015brodowiska testowe, monitorowanie, registry. CoreOS zosta\u0142a zaprojektowana do hostowania klastr\u00f3w k8s, wi\u0119c problem polega\u0142 na tym, jak u\u017cywano CoreOS. Pierwszym krokiem by\u0142 wyb\u00f3r stacka. Zatrzymali\u015bmy si\u0119 na:<\/p>\n

      <\/p>\n

        \n
      1. CentOS<\/strong> jako podstawowy dystrybucja, poniewa\u017c to najbli\u017csza dystrybucja do \u015brodowisk produkcyjnych.<\/li>\n
      2. Ansible<\/strong> do zarz\u0105dzania konfiguracjami, poniewa\u017c by\u0142a na ten temat obszerna ekspertyza.<\/li>\n
      3. Jenkins<\/strong> jako framework automatyzacji istniej\u0105cych proces\u00f3w, poniewa\u017c by\u0142 ju\u017c aktywnie wykorzystywany w procesach deweloperskich.<\/li>\n
      4. Hyper-V<\/strong> jako platforma wirtualizacji. Istnieje wiele powod\u00f3w, kt\u00f3re wykraczaj\u0105 poza zakres tej historii, ale w skr\u00f3cie - nie mo\u017cemy korzysta\u0107 z chmur, musimy korzysta\u0107 ze swojego sprz\u0119tu.<\/li>\n<\/ol>\n

        <\/p>\n

        Dzie\u0144 nr 30: Utrwalamy istniej\u0105ce umowy \u2014 Agreements as Code<\/h3>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Gdy stack sta\u0142 si\u0119 jasny, rozpocz\u0119\u0142y si\u0119 przygotowania do przeprowadzki. Utrwalenie istniej\u0105cych um\u00f3w w postaci kodu (Agreements as Code<\/strong>!). Przej\u015bcie praca r\u0119czna<\/em> -> mechanizacja<\/em> -> automatyzacja<\/em>.<\/p>\n

        <\/p>\n

        1. Konfiguracja VM<\/h4>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Ansible doskonale radzi sobie z tym zadaniem. Z minimalnym wysi\u0142kiem mo\u017cna przej\u0105\u0107 kontrol\u0119 nad konfiguracjami VM:<\/p>\n

        <\/p>\n

          \n
        1. Tworzymy repozytorium git.<\/li>\n
        2. Umieszczamy list\u0119 VM w inventory, konfiguracje w playbookach i rolach.<\/li>\n
        3. Konfigurujemy specjalnego slave'a jenkinsa, z kt\u00f3rego mo\u017cna b\u0119dzie uruchamia\u0107 ansible.<\/li>\n
        4. Tworzymy job, konfigurujemy Jenkins.<\/li>\n<\/ol>\n

          <\/p>\n

          Pierwszy proces gotowy. Umowy utrwalone.<\/p>\n

          <\/p>\n

          2. Utworzenie nowej VM<\/h4>\n

          <\/p>\n

          \"Ansible:<\/p>\n

          <\/p>\n

          Tutaj wszystko by\u0142o do\u015b\u0107 niewygodne. Z linuksa niewygodnie jest tworzy\u0107 VM na Hyper-V. Jedn\u0105 z pr\u00f3b zmechanizowania tego procesu by\u0142o:<\/p>\n

          <\/p>\n

            \n
          1. Ansible \u0142\u0105czy si\u0119 przez WinRM z hostem windows.<\/li>\n
          2. Ansible uruchamia skrypt powershell.<\/li>\n
          3. Skrypt Powershell tworzy now\u0105 VM.<\/li>\n
          4. Narz\u0119dzia Hyper-V\/ScVMM przy tworzeniu VM w go\u015bciach ustawiaj\u0105 hostname.<\/li>\n
          5. VM podczas aktualizacji DHCP lease wysy\u0142a sw\u00f3j hostname.<\/li>\n
          6. Standardowa integracja ddns & dhcp po stronie Domain Controller konfiguruje rekord DNS.<\/li>\n
          7. Mo\u017cna dodawa\u0107 VM do inventory i konfigurowa\u0107 j\u0105 w Ansible.<\/li>\n<\/ol>\n

            <\/p>\n

            3. Utworzenie szablonu VM<\/h4>\n

            <\/p>\n

            \"Ansible:<\/p>\n

            <\/p>\n

            Tutaj nie wymy\u015blono nic nowego - u\u017cyto packera.<\/p>\n

            <\/p>\n

              \n
            1. W repozytorium git umieszczamy konfiguracj\u0119 packera, kickstart.<\/li>\n
            2. Konfigurujemy specjalnego slave'a jenkinsa z hyper-v i packerem.<\/li>\n
            3. Tworzymy job, konfigurujemy Jenkins.<\/li>\n<\/ol>\n

              <\/p>\n

              Jak dzia\u0142a ta wsp\u00f3\u0142praca:<\/p>\n

              <\/p>\n

                \n
              1. Packer tworzy pust\u0105 VM, pod\u0142\u0105cza ISO.<\/li>\n
              2. VM uruchamia si\u0119, Packer wprowadza do bootloadera polecenie u\u017cycia naszego pliku kickstart z dyskietki lub http.<\/li>\n
              3. Uruchamia si\u0119 anaconda z naszym konfiguracj\u0105, przeprowadzana jest wst\u0119pna konfiguracja OS.<\/li>\n
              4. Packer czeka na dost\u0119pno\u015b\u0107 VM.<\/li>\n
              5. Packer wewn\u0105trz VM uruchamia ansible w trybie lokalnym.<\/li>\n
              6. Ansible dzia\u0142a przy u\u017cyciu dok\u0142adnie tych samych r\u00f3l, co w kroku nr 1.<\/li>\n
              7. Packer eksportuje szablon VM.<\/li>\n<\/ol>\n

                <\/p>\n

                Dzie\u0144 nr 75: Refaktoryzujemy ustalenia, nie \u0142ami\u0105c = Test ansible + Testkitchen.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Utrwalenie ustale\u0144 w kodzie mo\u017ce by\u0107 niewystarczaj\u0105ce. Je\u015bli w procesie w pod\u0142o\u017cu zechcesz co\u015b zmieni\u0107 \u2014 mo\u017cesz co\u015b zepsu\u0107. Dlatego w przypadku infrastruktury pojawia si\u0119 testowanie tej infrastruktury. Aby zsynchronizowa\u0107 wiedz\u0119 w ramach zespo\u0142u, zacz\u0119li\u015bmy testowa\u0107 role Ansible. Nie b\u0119d\u0119 si\u0119 zag\u0142\u0119bia\u0107, poniewa\u017c jest artyku\u0142 opisuj\u0105cy zdarzenia w tamtym czasie. Przetestuj mnie, je\u015bli potrafisz, lub czy programi\u015bci YML marz\u0105 o testowaniu ansible?<\/a><\/noindex>(spoilery, to nie by\u0142a ostateczna wersja, a p\u00f3\u017aniej wszystko sta\u0142o si\u0119 bardziej skomplikowane. Jak zacz\u0105\u0107 testowa\u0107 Ansible, refaktoryzowa\u0107 projekt w ci\u0105gu roku i nie straci\u0107 rozumu.<\/a><\/noindex>).<\/p>\n

                <\/p>\n

                Dzie\u0144 nr 130: A mo\u017ce CentOS + ansible nie jest potrzebne? Mo\u017ce openshift?<\/h3>\n

                <\/p>\n

                Trzeba rozumie\u0107, \u017ce proces wprowadzania infrastruktury nie by\u0142 jedynym, by\u0142y r\u00f3wnie\u017c poboczne podprojekty. Na przyk\u0142ad, pojawi\u0142 si\u0119 wniosek o uruchomienie naszej aplikacji w openshift, co prze\u0142o\u017cy\u0142o si\u0119 na badania trwaj\u0105ce co najmniej tydzie\u0144. Uruchamiamy aplikacj\u0119 w Openshift i por\u00f3wnujemy dost\u0119pne narz\u0119dzia.<\/a><\/noindex> co spowolni\u0142o proces migracji. Okaza\u0142o si\u0119, \u017ce openshift nie zaspokaja wszystkich potrzeb, potrzebny jest prawdziwy sprz\u0119t lub przynajmniej mo\u017cliwo\u015b\u0107 zabawy z j\u0105drem.<\/p>\n

                <\/p>\n

                Dzie\u0144 nr 170: Openshift nie pasuje, zaryzykujemy z Windows Azure Pack?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Hyper-V nie jest zbyt przyjazny, SCVMM nie poprawia sytuacji. Ale jest co\u015b takiego jak Windows Azure Pack, kt\u00f3re jest nak\u0142adk\u0105 na SCVMM i imituje Azure. Jednak w rzeczywisto\u015bci produkt wydaje si\u0119 porzucony: dokumentacja z uszkodzonymi linkami i do\u015b\u0107 uboga. Ale w ramach bada\u0144 nad uproszczeniem \u017cycia naszego chmury, przygl\u0105dali\u015bmy si\u0119 r\u00f3wnie\u017c temu.<\/p>\n

                <\/p>\n

                Dzie\u0144 nr 250: Windows Azure Pack nie jest za dobry. Zostajemy przy SCVMM.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Windows Azure Pack wygl\u0105da\u0142 obiecuj\u0105co, ale zdecydowano si\u0119 nie wprowadza\u0107 WAP z jego z\u0142o\u017cono\u015bciami do systemu dla zb\u0119dnych funkcji i pozosta\u0107 przy SCVMM.<\/p>\n

                <\/p>\n

                Dzie\u0144 nr 360: Jemy s\u0142onia kawa\u0142kami.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Dopiero po roku platforma by\u0142a gotowa do migracji i rozpocz\u0105\u0142 si\u0119 proces przenoszenia. W tym celu zosta\u0142a postawiona zadanie S.M.A.R.T. Spisali\u015bmy wszystkie VMs i zacz\u0119li\u015bmy stopniowo zajmowa\u0107 si\u0119 konfiguracj\u0105, opisywa\u0107 j\u0105 w Ansible, pokrywa\u0107 testami.<\/p>\n

                <\/p>\n

                Dzie\u0144 nr 450: Jaki system otrzymali\u015bmy?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Sam proces nie jest interesuj\u0105cy. Jest rutynowy; mo\u017cna zauwa\u017cy\u0107, \u017ce wi\u0119kszo\u015b\u0107 konfiguracji by\u0142a stosunkowo prosta lub izomorficzna, a wed\u0142ug zasady Pareto 80% konfiguracji w VM zaj\u0119\u0142o 20% czasu. Tym samym 80% czasu posz\u0142o na przygotowanie przeprowadzki, a tylko 20% na sam\u0105 przeprowadzk\u0119. <\/p>\n

                <\/p>\n

                Dzie\u0144 nr 540: Fina\u0142<\/h2>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Co si\u0119 wydarzy\u0142o w ci\u0105gu ostatnich 18 miesi\u0119cy?<\/p>\n

                <\/p>\n

                  \n
                1. Uzgodnienia sta\u0142y si\u0119 kodem.<\/li>\n
                2. Praca r\u0119czna<\/em> -> Mechanizacja<\/em> -> Automatyzacja<\/em>.<\/li>\n<\/ol>\n

                  <\/p>\n

                  Linki<\/h2>\n

                  <\/p>\n