{"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\/nl\/blog\/administrirovanie\/ansible-migracziya-konfiguraczii-120-vm-c-coreos-na-centos-za-18-mesyaczev","title":{"rendered":"Ansible: Migratie van de configuratie van 120 VM's van CoreOS naar CentOS in 18 maanden","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ansible:<\/p>\n

<\/p>\n

Dit is een transcriptie van de presentatie op DevopsConf 2019-10-01<\/a><\/noindex> en SPbLUG 2019-09-25<\/a><\/noindex>.<\/p>\n

<\/p>\n

Dit is het verhaal van een project waarbij een zelfgebouwd configuratiemanagementsysteem werd gebruikt en waarom de overstap naar Ansible 18 maanden in beslag nam.<\/p>\n

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

Dag \u2116 -XXX: Voor het begin<\/h2>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Oorspronkelijk was de infrastructuur opgebouwd uit een aantal afzonderlijke hosts die werden beheerd door Hyper-V. Het cre\u00ebren van een virtuele machine vereiste veel stappen: schijven op de juiste plaats leggen, DNS registreren, DHCP reserveren, de VM-configuratie in een git-repository plaatsen. Dit proces was gedeeltelijk geautomatiseerd, maar bijvoorbeeld de VM's werden handmatig tussen hosts verdeeld. Ontwikkelaars konden echter de VM-configuratie in git aanpassen en deze toepassen door de VM opnieuw op te starten.<\/p>\n

<\/p>\n

Aangepaste oplossing voor configuratiemanagement<\/h3>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Ik vermoed dat het oorspronkelijke idee bedoeld was als IaC: veel stateless VM's die hun status bij een herstart opnieuw instelden. Wat hield het configuratiemanagement van de VM's in? Schema's zagen er eenvoudig uit:<\/p>\n

<\/p>\n

    \n
  1. Voor de VM's werd een statisch MAC-adres toegewezen.<\/li>\n
  2. Er werd een ISO met CoreOS op de VM's aangesloten en een opstartschijf.<\/li>\n
  3. CoreOS start een aanpassingsscript door deze te downloaden van een WEB-server op basis van zijn IP.<\/li>\n
  4. Het script downloadt via SCP de configuratie van de VM op basis van het IP-adres.<\/li>\n
  5. Een reeks systemd eenheidsbestanden en een reeks bash-scripts worden gestart.<\/li>\n<\/ol>\n

    <\/p>\n

    \"Ansible:<\/p>\n

    <\/p>\n

    Deze oplossing had veel voor de hand liggende problemen:<\/p>\n

    <\/p>\n

      \n
    1. ISO in CoreOS was deprecated.<\/li>\n
    2. Een groot aantal moeilijk te automatiseren acties en magie bij de migratie\/creatie van VM's.<\/li>\n
    3. Moeilijkheden met updates en wanneer een bepaald versie van de software nodig was. Het werd nog lastiger met kernelmodules.<\/li>\n
    4. De VM's bleken niet helemaal stateless te zijn, dat wil zeggen, er verschenen VM's met een gemonteerd schijf voor gebruikersdata.<\/li>\n
    5. Er was altijd wel iemand die problemen had met de afhankelijkheden van de systemd-eenheid, en bij het opnieuw opstarten hing CoreOS. Het was problematisch om dit met de bestaande middelen in CoreOS op te sporen.<\/li>\n
    6. Secret management.<\/li>\n
    7. Er was praktisch geen CM. Er waren bash- en YML-configuraties van CoreOS.<\/li>\n<\/ol>\n

      <\/p>\n

      Om de configuratie van de VM toe te passen, moest deze opnieuw worden opgestart, maar soms startte deze niet opnieuw op. Het lijkt een voor de hand liggend probleem, maar er zijn geen persistente schijven \u2014 er is geen plek om logs op te slaan. Ok\u00e9, laten we proberen opties voor de opstartkernel toe te voegen zodat de logs worden verzonden. Maar nee, het is allemaal zo ingewikkeld.<\/p>\n

      <\/p>\n

      Dag \u21160: Probleemherkenning<\/h2>\n

      <\/p>\n

      \"Ansible:<\/p>\n

      <\/p>\n

      Dit was een typische ontwikkelingsinfrastructuur: Jenkins, testomgevingen, monitoring, registry. CoreOS was bedoeld voor het hosten van k8s-clusters, dus het probleem lag in hoe CoreOS werd gebruikt. De eerste stap was het kiezen van de stack. We kozen voor:<\/p>\n

      <\/p>\n

        \n
      1. CentOS<\/strong> als basisdistributie, aangezien dit de dichtstbijzijnde distributie is voor productieomgevingen.<\/li>\n
      2. Ansible<\/strong> voor configuratiebeheer, aangezien er uitgebreide expertise op dit gebied was.<\/li>\n
      3. Jenkins<\/strong> als een kader voor het automatiseren van bestaande processen, aangezien het al actief werd gebruikt voor ontwikkelingsprocessen.<\/li>\n
      4. Hyper-V<\/strong> als platform voor virtualisatie. Er zijn een aantal redenen waarom dit het geval is, maar in het kort \u2014 we kunnen geen cloudgebruik maken, we moeten onze eigen hardware gebruiken.<\/li>\n<\/ol>\n

        <\/p>\n

        Dag \u211630: Vaste afspraken vastleggen \u2014 Agreements as Code<\/h3>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Toen de stack duidelijk was, begonnen we met de voorbereiding voor de verhuizing. Het vastleggen van bestaande afspraken in de vorm van code (Agreements as Code<\/strong>!). Overgang handmatig werk<\/em> -> mechanisatie<\/em> -> die het mogelijk maakt om veel sneller nieuwe functionaliteit te testen, in te zetten en aan gebruikers te leveren. Bijvoorbeeld, in al onze projecten wordt bij elke commit automatisch een CI-pijplijn aangemaakt. Hierin wordt een beeld opgebouwd, getest, uitgerold in verschillende Kubernetes-omgevingen voor debugging en resterende controles, en als alles goed is \u2014 komen de wijzigingen bij de eindgebruiker aan. En dit is al lang geen rocket science meer, maar dagelijkse kost voor velen \u2014 waarschijnlijk ook voor u, aangezien u dit artikel leest.<\/em>.<\/p>\n

        <\/p>\n

        1. Configureer VMs<\/h4>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Ansible doet deze taak uitstekend. Met minimaal gedoe kun je de configuraties van VMs onder controle krijgen:<\/p>\n

        <\/p>\n

          \n
        1. We maken een git-repository aan.<\/li>\n
        2. We plaatsen de lijst van VMs in de inventory, configuraties in playbooks en rollen.<\/li>\n
        3. We zetten een speciale Jenkins-slaaf op van waaruit we Ansible kunnen uitvoeren.<\/li>\n
        4. We maken een job en configureren Jenkins.<\/li>\n<\/ol>\n

          <\/p>\n

          Het eerste proces is klaar. Afspraken zijn vastgelegd.<\/p>\n

          <\/p>\n

          2. Maak nieuwe VM aan<\/h4>\n

          <\/p>\n

          \"Ansible:<\/p>\n

          <\/p>\n

          Hier was het niet erg handig. Vanuit Linux was het moeilijk om VMs op Hyper-V aan te maken. Een van de pogingen om dit proces te mechaniseren was:<\/p>\n

          <\/p>\n

            \n
          1. Ansible maakt verbinding met de Windows-host via WinRM.<\/li>\n
          2. Ansible voert een PowerShell-script uit.<\/li>\n
          3. Het PowerShell-script maakt een nieuwe VM aan.<\/li>\n
          4. Met Hyper-V\/ScVMM wordt bij het aanmaken van de VM in het gastOS de hostname ingesteld.<\/li>\n
          5. De VM stuurt haar hostname bij het vernieuwen van de DHCP-lease.<\/li>\n
          6. De standaardintegratie van ddns & DHCP aan de kant van de Domain Controller stelt de DNS-records in.<\/li>\n
          7. VMs kunnen aan de inventory worden toegevoegd en Ansible kan worden geconfigureerd.<\/li>\n<\/ol>\n

            <\/p>\n

            3. Maak VM-template aan<\/h4>\n

            <\/p>\n

            \"Ansible:<\/p>\n

            <\/p>\n

            Hier hebben we niets uitgevonden \u2014 we hebben Packer gebruikt.<\/p>\n

            <\/p>\n

              \n
            1. We plaatsen de Packer-configuratie en kickstart in de git-repository.<\/li>\n
            2. We zetten een speciale Jenkins-slaaf met Hyper-V en Packer op.<\/li>\n
            3. We maken een job en configureren Jenkins.<\/li>\n<\/ol>\n

              <\/p>\n

              Hoe deze combinatie werkt:<\/p>\n

              <\/p>\n

                \n
              1. Packer maakt een lege VM aan en koppelt een ISO.<\/li>\n
              2. De VM wordt opgestart, Packer voert het commando uit om ons kickstart-bestand van een floppy of http te gebruiken.<\/li>\n
              3. Anaconda wordt gestart met onze configuratie, de initi\u00eble OS-configuratie wordt uitgevoerd.<\/li>\n
              4. Packer wacht tot de VM beschikbaar is.<\/li>\n
              5. Packer start Ansible in lokale modus binnen de VM.<\/li>\n
              6. Ansible werkt met precies dezelfde rollen als in stap \u21161.<\/li>\n
              7. Packer exporteert de VM-sjabloon.<\/li>\n<\/ol>\n

                <\/p>\n

                Dag \u211675: Refactoren van afspraken zonder te breken = Test Ansible + Testkitchen.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Afspraken in de code vastleggen kan onvoldoende zijn. Als je in het proces iets wilt veranderen, kun je iets breken. Daarom komt er bij infrastructuur ook testen van deze infrastructuur kijken. Om de kennis binnen het team te synchroniseren, zijn we Ansible-rollen gaan testen. Ik ga niet dieper ingaan op dit onderwerp, omdat er een artikel is dat de gebeurtenissen van dat moment beschrijft. Test mij als je kunt, of dromen YML-programmeurs van het testen van Ansible?<\/a><\/noindex>(spoiler: dit was niet de definitieve versie en later werd alles ingewikkelder. Hoe te beginnen met het testen van Ansible, een project refactoren in een jaar en niet gek te worden.<\/a><\/noindex>).<\/p>\n

                <\/p>\n

                Dag \u2116130: Heeft CentOS+Ansible misschien geen zin? Misschien OpenShift?<\/h3>\n

                <\/p>\n

                Je moet begrijpen dat het proces van het inbrengen van infrastructuur niet de enige was en er was een onderliggend subproject. Bijvoorbeeld, er kwam een verzoek om onze applicatie in OpenShift te starten en dat resulteerde in onderzoek dat meer dan een week duurde. We starten de applicatie in OpenShift en vergelijken met de bestaande tools.<\/a><\/noindex> Wat het proces van de verhuizing vertraagde. De uitkomst was dat OpenShift niet aan alle behoeften voldeed; er was echt hardware nodig of op zijn minst de mogelijkheid om te spelen met de kernel.<\/p>\n

                <\/p>\n

                Dag \u2116170: OpenShift is niet geschikt, durven we het met Windows Azure Pack?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Hyper-V is niet erg gebruiksvriendelijk, SCVMM maakt het niet veel beter. Maar er is zo'n ding als Windows Azure Pack, dat een bovenlaag vormt op SCVMM en zich voordoet als Azure. Maar in werkelijkheid lijkt het product verwaarloosd: documentatie met dode links en vrij schaars. Maar in het kader van het onderzoeken van manieren om ons cloud leven te vereenvoudigen, hebben we er ook naar gekeken.<\/p>\n

                <\/p>\n

                Dag \u2116250: Windows Azure Pack is niet zo geweldig. We blijven bij SCVMM.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Windows Azure Pack zag er veelbelovend uit, maar er werd besloten om WAP met zijn complicaties niet in het systeem te introduceren voor onnodige functies en we bleven bij SCVMM.<\/p>\n

                <\/p>\n

                Dag \u2116360: We eten de olifant in stukken.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Pas na een jaar was het platform klaar waar we naartoe konden verhuizen en begon het verhuisproces. Hiervoor werd er een S.M.A.R.T. doelstelling opgesteld. We hebben alle VM's opgeschreven en zijn ze \u00e9\u00e9n voor \u00e9\u00e9n gaan onderzoeken, ze beschrijven in Ansible en van tests voorzien.<\/p>\n

                <\/p>\n

                Dag \u2116450: Wat voor systeem is er ontstaan?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Het proces zelf is niet interessant. Het is routinematig; het valt op dat de meeste configuraties relatief eenvoudig of isomorf waren, en volgens het Pareto-principe kostten 80% van de configuraties 20% van de tijd. Op dezelfde manier ging 80% van de tijd verloren aan de voorbereiding van de verhuizing en slechts 20% aan de verhuizing zelf. <\/p>\n

                <\/p>\n

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

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Wat is er gebeurd in 18 maanden?<\/p>\n

                <\/p>\n

                  \n
                1. De afspraken zijn codificaties geworden.<\/li>\n
                2. Handmatige arbeid<\/em> -> Mechanisatie<\/em> -> Automatisering<\/em>.<\/li>\n<\/ol>\n

                  <\/p>\n

                  Links<\/h2>\n

                  <\/p>\n