{"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\/sv\/blog\/administrirovanie\/ansible-migracziya-konfiguraczii-120-vm-c-coreos-na-centos-za-18-mesyaczev","title":{"rendered":"Ansible: Migrering av konfigurationen av 120 VM fr\u00e5n CoreOS till CentOS under 18 m\u00e5nader","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ansible:<\/p>\n

<\/p>\n

Detta \u00e4r en transkription av presentationen p\u00e5 DevopsConf 2019-10-01<\/a><\/noindex> och SPbLUG 2019-09-25<\/a><\/noindex>.<\/p>\n

<\/p>\n

Detta \u00e4r historien om projektet d\u00e4r en skr\u00e4ddarsydd konfigurationshanteringssystem anv\u00e4ndes och varf\u00f6r flytten till Ansible drog ut p\u00e5 tiden i 18 m\u00e5nader.<\/p>\n

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

Dag \u2116 -XXX: Innan starten<\/h2>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

I b\u00f6rjan bestod infrastrukturen av m\u00e5nga frist\u00e5ende v\u00e4rdar som styrdes av Hyper-V. Att skapa en virtuell maskin kr\u00e4vde m\u00e5nga steg: placera diskarna p\u00e5 r\u00e4tt plats, ange DNS, reservera DHCP, och l\u00e4gga konfigurationen av VM i git-repositoriet. Denna process var delvis mekaniserad, men exempelvis f\u00f6rdelades VM manuellt mellan v\u00e4rdarna. Men exempelvis kunde utvecklarna, efter att ha justerat VM-konfigurationen i git, till\u00e4mpa den genom att starta om VM.<\/p>\n

<\/p>\n

Anpassad konfigurationshanteringsl\u00f6sning<\/h3>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Den ursprungliga id\u00e9n, misst\u00e4nker jag, var t\u00e4nkt som IaC: m\u00e5nga stateless VMs som \u00e5terst\u00e4llde sitt tillst\u00e5nd vid omstart. Hur s\u00e5g konfigurationshanteringen av VMs ut? Schematisk ser det enkelt ut:<\/p>\n

<\/p>\n

    \n
  1. F\u00f6r VM tilldelades en statisk MAC-adress.<\/li>\n
  2. ISO med CoreOS kopplades till VM och en startdisk.<\/li>\n
  3. CoreOS k\u00f6r ett anpassningsskript genom att h\u00e4mta det fr\u00e5n webbservern baserat p\u00e5 sin IP.<\/li>\n
  4. Skriptet h\u00e4mtar genom SCP konfigurationen av VM baserat p\u00e5 IP-adressen.<\/li>\n
  5. En m\u00e4ngd systemd-enhetsfiler och bash-script k\u00f6rs.<\/li>\n<\/ol>\n

    <\/p>\n

    \"Ansible:<\/p>\n

    <\/p>\n

    Denna l\u00f6sning hade m\u00e5nga uppenbara problem:<\/p>\n

    <\/p>\n

      \n
    1. ISO i CoreOS var f\u00f6r\u00e5ldrad.<\/li>\n
    2. M\u00e5nga komplicerade automatiserade \u00e5tg\u00e4rder och magi vid migrering\/skapande av VM.<\/li>\n
    3. Sv\u00e5righeter med uppdatering av programvara som m\u00e5ste ha en viss version. Det var \u00e4nnu mer problematiskt med k\u00e4rnmoduler.<\/li>\n
    4. VM var inte helt utan data, dvs. det fanns VM som hade en monterad disk med anv\u00e4ndardata dessutom.<\/li>\n
    5. N\u00e5gon gjorde st\u00e4ndigt misstag med beroenden f\u00f6r systemd-enheter och CoreOS h\u00e4ngde vid omstart. Det var problematiskt att f\u00e5nga detta med de befintliga verktygen i CoreOS.<\/li>\n
    6. Hantering av hemligheter.<\/li>\n
    7. CM fanns knappt. Det var bash och YML-konfigurationer f\u00f6r CoreOS.<\/li>\n<\/ol>\n

      <\/p>\n

      F\u00f6r att till\u00e4mpa konfigurationen av VM m\u00e5ste den startas om, men den kanske inte startade om. En r\u00e4tt uppenbar problematik, men det finns inga persistenta diskar \u2013 det finns ingenstans att spara loggar. Okej, l\u00e5t oss f\u00f6rs\u00f6ka l\u00e4gga till alternativ i k\u00e4rnstarten s\u00e5 att loggar skickas. Men nej, allt \u00e4r s\u00e5 komplicerat.<\/p>\n

      <\/p>\n

      Dag \u21160: Erk\u00e4nnande av problemet<\/h2>\n

      <\/p>\n

      \"Ansible:<\/p>\n

      <\/p>\n

      Det var en vanlig utvecklingsinfrastruktur: jenkins, testmilj\u00f6er, \u00f6vervakning, registry. CoreOS var avsett f\u00f6r hosting av k8s kluster, dvs problemet l\u00e5g i hur CoreOS anv\u00e4ndes. Det f\u00f6rsta steget var att v\u00e4lja stack. Vi beslutade att anv\u00e4nda:<\/p>\n

      <\/p>\n

        \n
      1. CentOS<\/strong> som basdistribuering, eftersom det \u00e4r den som ligger n\u00e4rmast produktionsmilj\u00f6er.<\/li>\n
      2. Ansible<\/strong> f\u00f6r att hantera konfigurationer, eftersom det fanns omfattande expertis om det.<\/li>\n
      3. Jenkins<\/strong> som ett ramverk f\u00f6r att automatisera befintliga processer, eftersom det redan anv\u00e4ndes aktivt f\u00f6r utvecklingsprocesser.<\/li>\n
      4. Hyper-V<\/strong> som en virtualiseringsplattform. Det finns flera sk\u00e4l som g\u00e5r utanf\u00f6r ber\u00e4ttelsen, men kort sagt - vi kan inte anv\u00e4nda moln, vi m\u00e5ste anv\u00e4nda v\u00e5r egen h\u00e5rdvara.<\/li>\n<\/ol>\n

        <\/p>\n

        Dag nr 30: Dokumentera befintliga avtal - Agreements as Code<\/h3>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        N\u00e4r stacken var klar b\u00f6rjade f\u00f6rberedelserna f\u00f6r flytten. Dokumentationen av befintliga avtal i form av kod (Agreements as Code<\/strong>!). \u00d6verg\u00e5ngen manuellt arbete<\/em> -> mekanisering<\/em> -> som m\u00f6jligg\u00f6r snabbare testning, distribution och leverans av ny funktionalitet till anv\u00e4ndarna. Till exempel skapas det i alla v\u00e5ra projekt automatiskt en CI-pipeline vid varje commit. I den byggs en avbild, testas, distribueras till olika Kubernetes-milj\u00f6er f\u00f6r fels\u00f6kning och vidare kontroller, och om allt g\u00e5r bra - n\u00e5r f\u00f6r\u00e4ndringarna slutligen anv\u00e4ndaren. Detta \u00e4r inte l\u00e4ngre raketvetenskap, utan en vanlig f\u00f6reteelse f\u00f6r m\u00e5nga - f\u00f6rmodligen \u00e4ven f\u00f6r dig, eftersom du l\u00e4ser denna artikel.<\/em>.<\/p>\n

        <\/p>\n

        1. Konfigurera VM:ar<\/h4>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Ansible hanterar denna uppgift utm\u00e4rkt. Med minimal anstr\u00e4ngning kan man ta \u00f6ver hanteringen av VM-konfigurationer:<\/p>\n

        <\/p>\n

          \n
        1. Skapa ett git-repo.<\/li>\n
        2. L\u00e4gg in listan p\u00e5 VM:ar i inventariet, konfigurationerna i playbooks och roller.<\/li>\n
        3. St\u00e4ll in en speciell jenkins-slave som kan k\u00f6ra ansible.<\/li>\n
        4. Skapa jobb, konfigurera Jenkins.<\/li>\n<\/ol>\n

          <\/p>\n

          Den f\u00f6rsta processen \u00e4r klar. Avtalen \u00e4r dokumenterade.<\/p>\n

          <\/p>\n

          2. Skapa ny VM<\/h4>\n

          <\/p>\n

          \"Ansible:<\/p>\n

          <\/p>\n

          H\u00e4r var det inte s\u00e4rskilt bekv\u00e4mt. Att skapa VM:ar p\u00e5 Hyper-V fr\u00e5n Linux var inte s\u00e5 smidigt. Ett av f\u00f6rs\u00f6ken att automatisera denna process var:<\/p>\n

          <\/p>\n

            \n
          1. Ansible ansluter via WinRM till Windows-v\u00e4rden.<\/li>\n
          2. Ansible k\u00f6r ett powershell-skript.<\/li>\n
          3. Powershell-skriptet skapar en ny VM.<\/li>\n
          4. Med hj\u00e4lp av Hyper-V\/ScVMM konfigureras hostname n\u00e4r VM:ar skapas i g\u00e4st OS.<\/li>\n
          5. VM:en skickar sitt hostname vid uppdatering av DHCP-lease.<\/li>\n
          6. Den inbyggda integrationen av ddns & dhcp p\u00e5 Domains Controller konfigurerar DNS-poster.<\/li>\n
          7. Man kan l\u00e4gga till VM:ar i inventariet och konfigurera dem med Ansible.<\/li>\n<\/ol>\n

            <\/p>\n

            3. Skapa VM-mall<\/h4>\n

            <\/p>\n

            \"Ansible:<\/p>\n

            <\/p>\n

            H\u00e4r uppfann vi ingenting - vi anv\u00e4nde packer.<\/p>\n

            <\/p>\n

              \n
            1. I git-repo laddar vi upp packer-konfigurationen, kickstart.<\/li>\n
            2. St\u00e4ll in en speciell jenkins-slave med hyper-v och Packer.<\/li>\n
            3. Skapa jobb, konfigurera Jenkins.<\/li>\n<\/ol>\n

              <\/p>\n

              S\u00e5 h\u00e4r fungerar denna koppling:<\/p>\n

              <\/p>\n

                \n
              1. Packer skapar en tom VM, kopplar ISO.<\/li>\n
              2. VM:en startar, Packer ger bootloader-kommandot att anv\u00e4nda v\u00e5r kickstart-fil fr\u00e5n floppy eller http.<\/li>\n
              3. Anaconda startas med v\u00e5r konfiguration, den f\u00f6rsta inst\u00e4llningen av OS g\u00f6rs.<\/li>\n
              4. Packer v\u00e4ntar p\u00e5 att VM:en ska bli tillg\u00e4nglig.<\/li>\n
              5. Packer k\u00f6r ansible i lokal l\u00e4ge inuti VM:en.<\/li>\n
              6. Ansible anv\u00e4nder exakt samma roller som i steg \u21161.<\/li>\n
              7. Packer exporterar VM-mallen.<\/li>\n<\/ol>\n

                <\/p>\n

                Dag \u211675: Refaktorerar \u00f6verenskommelser utan att bryta = Testa ansible + Testkitchen<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Att fastst\u00e4lla \u00f6verenskommelser i koden kan vara otillr\u00e4ckligt. Om du vill \u00e4ndra n\u00e5got i grunden kan du riskera att bryta n\u00e5got. D\u00e4rf\u00f6r beh\u00f6vs testning av infrastrukturen. F\u00f6r att synka kunskapen inom teamet b\u00f6rjade vi testa Ansible-roller. Jag ska inte g\u00e5 djupare in p\u00e5 det, d\u00e5 det finns en artikel som beskriver h\u00e4ndelserna vid den tidpunkten. Testa mig om du kan, eller dr\u00f6mmer YML-programmerare om testning av ansible?<\/a><\/noindex>(spoiler, detta var inte den slutgiltiga versionen och senare blev allt mer komplicerat) Hur man b\u00f6rjar testa Ansible, refaktorerar projektet p\u00e5 ett \u00e5r och inte tappar f\u00f6rst\u00e5ndet.<\/a><\/noindex>).<\/p>\n

                <\/p>\n

                Dag \u2116130: Beh\u00f6ver vi verkligen CentOS+ansible? Kanske Openshift?<\/h3>\n

                <\/p>\n

                Det \u00e4r viktigt att f\u00f6rst\u00e5 att processen att implementera infrastrukturer inte var den enda, och det fanns sidoprojekt. Till exempel kom en f\u00f6rfr\u00e5gan om att k\u00f6ra v\u00e5r applikation i Openshift vilket ledde till flera veckors forskning. Vi startar applikationen i Openshift och j\u00e4mf\u00f6r med befintliga verktyg.<\/a><\/noindex> Vad som bromsade flyttprocessen. Slutsatsen blev att Openshift inte t\u00e4cker alla behov, vi beh\u00f6ver riktig h\u00e5rdvara, eller \u00e5tminstone m\u00f6jlighet att experimentera med k\u00e4rnan.<\/p>\n

                <\/p>\n

                Dag \u2116170: Openshift fungerar inte, ska vi satsa p\u00e5 Windows Azure Pack?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Hyper-V \u00e4r inte s\u00e4rskilt anv\u00e4ndarv\u00e4nligt, SCVMM g\u00f6r det inte mycket b\u00e4ttre. Men det finns en produkt som heter Windows Azure Pack, som \u00e4r ett till\u00e4gg till SCVMM och imiterar Azure. Men i verkligheten ser produkten \u00f6vergiven ut: dokumentationen har trasiga l\u00e4nkar och \u00e4r ganska sparsam. Men inom ramen f\u00f6r att utforska alternativ f\u00f6r att f\u00f6renkla v\u00e5rt moln tittade vi \u00e4ven p\u00e5 detta.<\/p>\n

                <\/p>\n

                Dag \u2116250: Windows Azure Pack \u00e4r inte s\u00e5 bra. Vi stannar kvar p\u00e5 SCVMM.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Windows Azure Pack verkade lovande, men det beslutades att inte inf\u00f6ra WAP med dess komplikationer f\u00f6r att f\u00e5 on\u00f6diga funktioner, och vi stannade p\u00e5 SCVMM.<\/p>\n

                <\/p>\n

                Dag \u2116360: \u00c4ter elefanten bit f\u00f6r bit.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                F\u00f6rst efter ett \u00e5r var plattformen redo f\u00f6r flytt och processen b\u00f6rjade. En S.M.A.R.T. uppgift st\u00e4lldes. Vi listade alla VM och b\u00f6rjade g\u00e5 igenom konfigurationen en i taget, beskriva den p\u00e5 Ansible och t\u00e4cka med tester.<\/p>\n

                <\/p>\n

                Dag \u2116450: Vilket system fick vi?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Sj\u00e4lva processen \u00e4r inte intressant. Den \u00e4r rutinm\u00e4ssig, och det kan noteras att de flesta konfigurationerna var relativt enkla eller isomorfa, och enligt Pareto-principen kr\u00e4vde 80 % av konfigurationerna 20 % av tiden. P\u00e5 samma s\u00e4tt gick 80 % av tiden \u00e5t till att f\u00f6rbereda flytten och endast 20 % till sj\u00e4lva flytten. <\/p>\n

                <\/p>\n

                Dag nr 540: Avslutning<\/h2>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Vad har h\u00e4nt under de senaste 18 m\u00e5naderna?<\/p>\n

                <\/p>\n

                  \n
                1. \u00d6verenskommelserna blev kod.<\/li>\n
                2. Manuell arbetskraft<\/em> -> Mekanisering<\/em> -> Automatisering<\/em>.<\/li>\n<\/ol>\n

                  <\/p>\n

                  L\u00e4nkar<\/h2>\n

                  <\/p>\n