{"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\/da\/blog\/administrirovanie\/ansible-migracziya-konfiguraczii-120-vm-c-coreos-na-centos-za-18-mesyaczev","title":{"rendered":"Ansible: Migration af konfigurationen af 120 VM'er fra CoreOS til CentOS over 18 m\u00e5neder","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ansible:<\/p>\n

<\/p>\n

Dette er en transkription af pr\u00e6sentationen p\u00e5 DevopsConf 2019-10-01<\/a><\/noindex> og SPbLUG 2019-09-25<\/a><\/noindex>.<\/p>\n

<\/p>\n

Dette er historien om projektet, hvor der blev brugt et skr\u00e6ddersyet konfigurationsstyringssystem, og hvorfor overflytningen til Ansible tog 18 m\u00e5neder.<\/p>\n

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

Dag \u2116 -XXX: F\u00f8r begyndelsen<\/h2>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Oprindeligt bestod infrastrukturen af en r\u00e6kke frist\u00e5ende servere, der blev drevet af Hyper-V. Oprettelse af en virtuel maskine kr\u00e6vede mange handlinger: placere diske det rigtige sted, skrive DNS, reservere DHCP, l\u00e6gge VM-konfigurationen i et git-repositorium. Denne proces var delvist automatiseret, men for eksempel blev VM'er fordelt mellem serverne manuelt. Men udviklerne kunne \u00e6ndre VM-konfigurationen i git og anvende den ved at genstarte VM'en.<\/p>\n

<\/p>\n

Skr\u00e6ddersyet konfigurationsstyringsl\u00f8sning<\/h3>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Den oprindelige id\u00e9, som jeg formoder blev set som IaC: mange stateless VM'er, der nulstillede deres tilstand ved genstart. Hvordan s\u00e5 konfigurationsstyringen af VM'erne ud? Det ser simpelt ud skematisk:<\/p>\n

<\/p>\n

    \n
  1. Der blev tildelt statisk MAC til VM'erne.<\/li>\n
  2. Der blev tilsluttet ISO med CoreOS og en boot-disk til VM'erne.<\/li>\n
  3. CoreOS k\u00f8rer et tilpasningsscript, som den downloader fra WEB-serveren baseret p\u00e5 sin IP.<\/li>\n
  4. Scriptet henter VM-konfigurationen via SCP baseret p\u00e5 IP-adressen.<\/li>\n
  5. En r\u00e6kke systemd enheds-filer og en r\u00e6kke bash-scripts bliver k\u00f8rt.<\/li>\n<\/ol>\n

    <\/p>\n

    \"Ansible:<\/p>\n

    <\/p>\n

    Denne l\u00f8sning havde mange \u00e5benlyse problemer:<\/p>\n

    <\/p>\n

      \n
    1. ISO i CoreOS var deprecated.<\/li>\n
    2. Mange komplekse automatiserede handlinger og magi ved migration\/oprettelse af VM'er.<\/li>\n
    3. Problemer med opdatering, n\u00e5r specifik softwareversion er n\u00f8dvendig. Det bliver endnu sjovere med kernel-moduler.<\/li>\n
    4. VM'erne var ikke helt uden data, dvs. der opstod VM'er, der havde et ekstra monteret disk med brugerdata.<\/li>\n
    5. Nogle gange lavede nogen fejl med afh\u00e6ngighederne af systemd enheden, og ved genstart hang CoreOS. Det var problematisk at fange det med de eksisterende v\u00e6rkt\u00f8jer i CoreOS.<\/li>\n
    6. H\u00e5ndtering af hemmeligheder.<\/li>\n
    7. CM eksisterede n\u00e6rmest ikke. Der var bash og YML-konfigurationer for CoreOS.<\/li>\n<\/ol>\n

      <\/p>\n

      For at anvende VM-konfigurationen skal den genstartes, men den kunne ikke genstarte. Det virker som et \u00e5benlyst problem, men der er ingen persistente diske \u2014 hvor skal logfilerne gemmes? N\u00e5, lad os pr\u00f8ve at tilf\u00f8je indl\u00e6sning af kernel-optioner for at sende loggene. Men nej, det er alt sammen s\u00e5 besv\u00e6rligt.<\/p>\n

      <\/p>\n

      Dag \u21160: Problemet erkendelse<\/h2>\n

      <\/p>\n

      \"Ansible:<\/p>\n

      <\/p>\n

      Det var en almindelig udviklingsinfrastruktur: jenkins, testmilj\u00f8er, overv\u00e5gninger, registry. CoreOS blev designet til hosting af k8s-klynger, s\u00e5 problemet l\u00e5 i, hvordan CoreOS blev brugt. Det f\u00f8rste skridt var valget af stak. Vi valgte:<\/p>\n

      <\/p>\n

        \n
      1. CentOS<\/strong> som basisdistribution, da det er den mest n\u00e6rliggende distribution til produktionsmilj\u00f8er.<\/li>\n
      2. Ansible<\/strong> til konfigurationsstyring, da der var meget ekspertise inden for det.<\/li>\n
      3. Jenkins<\/strong> som et automatiseringsframework for eksisterende processer, da det allerede blev brugt aktivt til udviklingsprocesser.<\/li>\n
      4. Hyper-V<\/strong> som virtualiseringsplatform. Der er en r\u00e6kke \u00e5rsager, der str\u00e6kker sig ud over, hvad der kan fort\u00e6lles her, men kort sagt \u2014 vi kan ikke bruge cloud-l\u00f8sninger, vi er n\u00f8dt til at bruge vores eget udstyr.<\/li>\n<\/ol>\n

        <\/p>\n

        Dag \u211630: Fastsl\u00e5 eksisterende aftaler \u2014 Agreements as Code<\/h3>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        N\u00e5r stakken var klar, begyndte forberedelserne til flytning. Fastl\u00e6ggelse af eksisterende aftaler i form af kode (Agreements as Code<\/strong>!). Overgangen manuelt arbejde<\/em> -> mekanisering<\/em> -> automatisering<\/em>.<\/p>\n

        <\/p>\n

        1. Konfigur\u00e9r VMs<\/h4>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Ansible klarer denne opgave fremragende. Med minimale anstrengelser kan man tage kontrol over VM'ernes konfigurationer:<\/p>\n

        <\/p>\n

          \n
        1. Opret en git-repository.<\/li>\n
        2. L\u00e6g listen over VMs i inventory, konfigurationer i playbooks og roller.<\/li>\n
        3. Konfigurer en s\u00e6rlig jenkins slave, som kan k\u00f8re ansible.<\/li>\n
        4. Opret job, konfigurer Jenkins.<\/li>\n<\/ol>\n

          <\/p>\n

          Den f\u00f8rste proces er klar. Aftalerne er fastsl\u00e5et.<\/p>\n

          <\/p>\n

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

          <\/p>\n

          \"Ansible:<\/p>\n

          <\/p>\n

          Her var alt ikke s\u00e6rlig praktisk. Det var ikke nemt at oprette VMs p\u00e5 Hyper-V fra Linux. Et af fors\u00f8gene p\u00e5 at mekanisere denne proces var:<\/p>\n

          <\/p>\n

            \n
          1. Ansible forbinder via WinRM til windows-v\u00e6rten.<\/li>\n
          2. Ansible k\u00f8rer et powershell-script.<\/li>\n
          3. Powershell-scriptet opretter en ny VM.<\/li>\n
          4. Ved hj\u00e6lp af Hyper-V\/ScVMM indstilles hostname i g\u00e6stesystemet, n\u00e5r VM'en oprettes.<\/li>\n
          5. VM'en sender sit hostname, n\u00e5r den opdaterer DHCP lease.<\/li>\n
          6. Den indbyggede integration af ddns & amp; dhcp p\u00e5 siden af Domain Controller konfigurerer DNS-posten.<\/li>\n
          7. Man kan tilf\u00f8je VMs til inventar og konfigurere dem med Ansible.<\/li>\n<\/ol>\n

            <\/p>\n

            3. Opret VM-skabelon<\/h4>\n

            <\/p>\n

            \"Ansible:<\/p>\n

            <\/p>\n

            Her opfandt vi intet nyt \u2014 vi brugte packer.<\/p>\n

            <\/p>\n

              \n
            1. I git-repository'en l\u00e6gger vi konfigurationen til packer, kickstart.<\/li>\n
            2. Konfigurer en s\u00e6rlig jenkins slave med hyper-v og Packer.<\/li>\n
            3. Opret job, konfigurer Jenkins.<\/li>\n<\/ol>\n

              <\/p>\n

              Hvordan dette setup fungerer:<\/p>\n

              <\/p>\n

                \n
              1. Packer opretter en tom VM, tilslutter ISO.<\/li>\n
              2. VM'en starter, Packer indtaster kommandoen for at bruge vores kickstart-fil fra diskette eller http.<\/li>\n
              3. Anaconda starter med vores konfiguration og laver den indledende ops\u00e6tning af OS.<\/li>\n
              4. Packer venter p\u00e5, at VM'en er tilg\u00e6ngelig.<\/li>\n
              5. Packer k\u00f8rer ansible i lokaltilstand inde i VM'en.<\/li>\n
              6. Ansible anvender n\u00f8jagtig de samme roller som i trin \u21161.<\/li>\n
              7. Packer eksporterer VM-skabelonen.<\/li>\n<\/ol>\n

                <\/p>\n

                Dag \u211675: Refactorering af aftaler uden at bryde = Test ansible + Testkitchen<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                At fasts\u00e6tte aftaler i koden kan v\u00e6re utilstr\u00e6kkeligt. For hvis du undervejs i processen \u00f8nsker at \u00e6ndre noget \u2014 kan du komme til at bryde noget. Derfor, i tilf\u00e6lde af infrastrukturen, er testningen af selve infrastrukturen vigtig. For at synkronisere viden i teamet begyndte vi at teste Ansible-roller. Jeg vil ikke g\u00e5 mere i dybden, da der findes en artikel, der beskriver begivenhederne p\u00e5 det tidspunkt. Test mig, hvis du kan, eller dr\u00f8mmer YML-programm\u00f8rer om at teste ansible?<\/a><\/noindex>(spoiler, det var ikke den endelige version, og senere blev det mere kompliceret) Hvordan man begynder at teste Ansible, refaktorere projektet p\u00e5 et \u00e5r uden at miste besindelsen<\/a><\/noindex>).<\/p>\n

                <\/p>\n

                Dag \u2116130: M\u00e5ske er CentOS+ansible ikke n\u00f8dvendigt? M\u00e5ske openshift?<\/h3>\n

                <\/p>\n

                Det er vigtigt at forst\u00e5, at processen med at integrere infrastrukturen ikke var den eneste, og der var ogs\u00e5 underprojekter. For eksempel kom der en anmodning om at k\u00f8re vores applikation i openshift, hvilket resulterede i unders\u00f8gelser, der tog over en uge. Vi starter applikationen i Openshift og sammenligner med det eksisterende v\u00e6rkt\u00f8j.<\/a><\/noindex> Hvad stoppede flytteprocessen. Konklusionen var, at openshift ikke d\u00e6kkede alle behov; der kr\u00e6ves \u00e6gte hardware eller i det mindste muligheden for at lege med kernen.<\/p>\n

                <\/p>\n

                Dag \u2116170: Openshift er ikke egnet, t\u00f8r vi pr\u00f8ve Windows Azure Pack?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Hyper-V er ikke s\u00e6rlig brugervenlig, og SCVMM g\u00f8r det ikke meget bedre. Men der findes noget, der hedder Windows Azure Pack, som er et lag ovenp\u00e5 SCVMM og efterligner Azure. Men i virkeligheden ser produktet forladt ud: dokumentationen har \u00f8delagte links og er temmelig sparsom. Men i forbindelse med unders\u00f8gelsen af muligheder for at forenkle vores sky, kiggede vi ogs\u00e5 p\u00e5 det.<\/p>\n

                <\/p>\n

                Dag \u2116250: Windows Azure Pack er ikke imponerende. Vi bliver p\u00e5 SCVMM.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Windows Azure Pack s\u00e5 lovende ud, men det blev besluttet ikke at bringe WAP med sine kompleksiteter ind i systemet for un\u00f8dvendige funktioner, og vi blev p\u00e5 SCVMM.<\/p>\n

                <\/p>\n

                Dag \u2116360: Vi spiser elefanten stykke for stykke.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                S\u00e6soner senere var platformen klar til at flytte til, og flytteprocessen begyndte. For dette blev der sat en S.M.A.R.T. opgave. Vi skrev alle VM'er ned og begyndte \u00e9n ad gangen at se p\u00e5 konfigurationen, beskrive den i Ansible og d\u00e6kke den med tests.<\/p>\n

                <\/p>\n

                Dag \u2116450: Hvilket system blev der?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Selve processen er ikke interessant. Den er rutinepr\u00e6get, og man kan bem\u00e6rke, at de fleste konfigurationer var relativt enkle eller isomorfe. If\u00f8lge Pareto-princippet kr\u00e6vede 80% af konfigurationerne 20% af tiden. P\u00e5 samme m\u00e5de gik 80% af tiden til forberedelse af flytningen, og kun 20% gik til selve flytningen. <\/p>\n

                <\/p>\n

                Dag \u2116540: Finale<\/h2>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Hvad er der sket over 18 m\u00e5neder?<\/p>\n

                <\/p>\n

                  \n
                1. Aftalerne er blevet kode.<\/li>\n
                2. Manuel arbejde<\/em> -> Mekanisering<\/em> -> Automatisering<\/em>.<\/li>\n<\/ol>\n

                  <\/p>\n

                  Links<\/h2>\n

                  <\/p>\n