{"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\/de\/blog\/administrirovanie\/ansible-migracziya-konfiguraczii-120-vm-c-coreos-na-centos-za-18-mesyaczev","title":{"rendered":"Ansible: Migration der Konfiguration von 120 VMs von CoreOS nach CentOS in 18 Monaten","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ansible:<\/p>\n

<\/p>\n

Dies ist die Abschrift des Vortrags bei DevopsConf 2019-10-01<\/a><\/noindex> und SPbLUG 2019-09-25<\/a><\/noindex>.<\/p>\n

<\/p>\n

Dies ist die Geschichte eines Projekts, in dem ein eigenes Konfigurationsmanagement-System verwendet wurde und warum der Umstieg auf Ansible sich \u00fcber 18 Monate hinzog.<\/p>\n

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

Tag \u2116 -XXX: Vor Beginn<\/h2>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Urspr\u00fcnglich bestand die Infrastruktur aus einer Vielzahl von einzelnen Hosts, die von Hyper-V verwaltet wurden. Die Erstellung einer virtuellen Maschine erforderte viele Schritte: Festplatten an den richtigen Ort legen, DNS eintragen, DHCP reservieren und die VM-Konfiguration in ein Git-Repository einf\u00fcgen. Dieser Prozess war teilweise automatisiert, jedoch wurden beispielsweise die VMs manuell auf die Hosts verteilt. Entwickler konnten die VM-Konfiguration in Git anpassen und sie durch einen Neustart der VM anwenden.<\/p>\n

<\/p>\n

Eingehendes Konfigurationsmanagement-L\u00f6sung<\/h3>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Ich vermute, die urspr\u00fcngliche Idee war als IaC gedacht: viele stateless VMs, die bei einem Neustart ihren Zustand zur\u00fccksetzten. Wie sah das Management von VM-Konfigurationen aus? Schemenhaft sieht es einfach aus:<\/p>\n

<\/p>\n

    \n
  1. F\u00fcr die VMs wurde eine statische MAC-Adresse vergeben.<\/li>\n
  2. Eine ISO mit CoreOS und ein Bootlaufwerk wurden an die VMs angeschlossen.<\/li>\n
  3. CoreOS startet ein Anpassungsskript, indem es dieses basierend auf seiner IP von einem WEB-Server herunterl\u00e4dt.<\/li>\n
  4. Das Skript l\u00e4dt \u00fcber SCP die Konfiguration der VM basierend auf der IP-Adresse herunter.<\/li>\n
  5. Es wird eine Reihe von systemd-Diensteinheiten und eine Reihe von Bash-Skripten gestartet.<\/li>\n<\/ol>\n

    <\/p>\n

    \"Ansible:<\/p>\n

    <\/p>\n

    Diese L\u00f6sung hatte viele offensichtliche Probleme:<\/p>\n

    <\/p>\n

      \n
    1. ISO in CoreOS wurde als veraltet markiert.<\/li>\n
    2. Viele schwer automatisierbare Aktionen und Magie bei der Migration\/Erstellung von VMs.<\/li>\n
    3. Es gab Schwierigkeiten beim Update und wenn eine bestimmten Softwareversion ben\u00f6tigt wurde. Es wird noch komplizierter bei den Kernel-Modulen.<\/li>\n
    4. Die VMs waren nicht so ganz ohne Daten, d.h. es erschienen VMs, bei denen eine Festplatte mit Benutzerdaten zus\u00e4tzlich gemountet war.<\/li>\n
    5. St\u00e4ndig gab es Probleme mit den Abh\u00e4ngigkeiten der systemd-Diensteinheiten, und beim Neustart hing CoreOS. Mit den vorhandenen Mitteln in CoreOS war es schwierig, dies zu erkennen.<\/li>\n
    6. Geheimnisverwaltung.<\/li>\n
    7. Es gab quasi kein Configuration Management. Es gab Bash und YML-Konfigurationen f\u00fcr CoreOS.<\/li>\n<\/ol>\n

      <\/p>\n

      Um die Konfiguration der VM anzuwenden, musste sie neu gestartet werden, aber sie konnte sich m\u00f6glicherweise nicht neu starten. Es scheint ein offensichtliches Problem zu sein, aber es gibt keine persistenten Festplatten \u2013 es gibt keinen Ort, um Logs zu speichern. Na gut, versuchen wir, Kernel-Startoptionen hinzuzuf\u00fcgen, um die Logs zu \u00fcbermitteln. Aber nein, das alles ist so kompliziert.<\/p>\n

      <\/p>\n

      Tag Nr. 0: Problemerkennung<\/h2>\n

      <\/p>\n

      \"Ansible:<\/p>\n

      <\/p>\n

      Das war eine typische Entwicklungsinfrastruktur: Jenkins, Testumgebungen, Monitoring, Registry. CoreOS war f\u00fcr das Hosting von k8s-Clustern gedacht, das Problem lag also in der Nutzung von CoreOS. Der erste Schritt war die Auswahl des Stacks. Wir entschieden uns f\u00fcr:<\/p>\n

      <\/p>\n

        \n
      1. CentOS<\/strong> als Basisdistribution, da sie der Produktionsumgebung am n\u00e4chsten kommt.<\/li>\n
      2. Ansible<\/strong> f\u00fcr das Management von Konfigurationen, da es umfangreiche Expertise in diesem Bereich gab.<\/li>\n
      3. Jenkins<\/strong> als Framework zur Automatisierung bestehender Prozesse, da es bereits aktiv f\u00fcr Entwicklungsprozesse verwendet wurde.<\/li>\n
      4. Hyper-V<\/strong> als Virtualisierungsplattform. Es gibt eine Reihe von Gr\u00fcnden, die \u00fcber den Rahmen dieser Erz\u00e4hlung hinausgehen, aber kurz gesagt \u2013 wir k\u00f6nnen keine Cloud nutzen, wir m\u00fcssen unsere eigene Hardware verwenden.<\/li>\n<\/ol>\n

        <\/p>\n

        Tag Nr. 30: Festlegung bestehender Vereinbarungen \u2013 Agreements as Code<\/h3>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Als der Stack klar war, begann die Vorbereitung auf den Umzug. Die Festlegung bestehender Vereinbarungen in Form von Code (Agreements as Code<\/strong>!). Der \u00dcbergang manuelle Arbeit<\/em> -> Mechanisierung<\/em> -> Automatisierung<\/em>.<\/p>\n

        <\/p>\n

        1. VMs konfigurieren<\/h4>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Ansible \u00fcbernimmt diese Aufgabe hervorragend. Mit minimalem Aufwand k\u00f6nnen die VM-Konfigurationen verwaltet werden:<\/p>\n

        <\/p>\n

          \n
        1. Erstellen eines Git-Repositorys.<\/li>\n
        2. Die Liste der VMs im Inventory ablegen, Konfigurationen in Playbooks und Rollen organisieren.<\/li>\n
        3. Wir richten einen speziellen Jenkins-Slave ein, von dem aus Ansible gestartet werden kann.<\/li>\n
        4. Wir erstellen einen Job und konfigurieren Jenkins.<\/li>\n<\/ol>\n

          <\/p>\n

          Der erste Prozess ist abgeschlossen. Vereinbarungen sind festgehalten.<\/p>\n

          <\/p>\n

          2. Neue VM erstellen<\/h4>\n

          <\/p>\n

          \"Ansible:<\/p>\n

          <\/p>\n

          Hier war es nicht sehr bequem. Es war schwierig, eine VM auf Hyper-V aus Linux zu erstellen. Ein Versuch, diesen Prozess zu automatisieren, war:<\/p>\n

          <\/p>\n

            \n
          1. Ansible verbindet sich \u00fcber WinRM mit dem Windows-Host.<\/li>\n
          2. Ansible f\u00fchrt ein PowerShell-Skript aus.<\/li>\n
          3. Das PowerShell-Skript erstellt eine neue VM.<\/li>\n
          4. Mit Hyper-V\/ScVMM wird beim Erstellen der VM im Gastbetriebssystem der Hostname konfiguriert.<\/li>\n
          5. Die VM sendet ihren Hostname bei der DHCP-Lease-Aktualisierung.<\/li>\n
          6. Die Standardintegration von DDNS & DHCP auf der Seite des Dom\u00e4nencontrollers konfiguriert den DNS-Eintrag.<\/li>\n
          7. VMs k\u00f6nnen im Inventar hinzugef\u00fcgt und mit Ansible konfiguriert werden.<\/li>\n<\/ol>\n

            <\/p>\n

            3. VM-Vorlage erstellen<\/h4>\n

            <\/p>\n

            \"Ansible:<\/p>\n

            <\/p>\n

            Hier haben wir nichts erfunden \u2013 wir haben Packer verwendet.<\/p>\n

            <\/p>\n

              \n
            1. Wir speichern die Packer-Konfiguration und Kickstart im Git-Repository.<\/li>\n
            2. Wir richten einen speziellen Jenkins-Slave mit Hyper-V und Packer ein.<\/li>\n
            3. Wir erstellen einen Job und konfigurieren Jenkins.<\/li>\n<\/ol>\n

              <\/p>\n

              So funktioniert dieses Setup:<\/p>\n

              <\/p>\n

                \n
              1. Packer erstellt eine leere VM und bindet das ISO ein.<\/li>\n
              2. Die VM wird gestartet, Packer gibt dem Bootloader den Befehl, unser Kickstart-Datei von Diskette oder HTTP zu verwenden.<\/li>\n
              3. Anaconda wird mit unserer Konfiguration gestartet, die grundlegende OS-Konfiguration wird durchgef\u00fchrt.<\/li>\n
              4. Packer wartet auf die Verf\u00fcgbarkeit der VM.<\/li>\n
              5. Packer startet Ansible im lokalen Modus innerhalb der VM.<\/li>\n
              6. Ansible verwendet genau dieselben Rollen wie im Schritt Nr. 1.<\/li>\n
              7. Packer exportiert die VM-Vorlage.<\/li>\n<\/ol>\n

                <\/p>\n

                Tag Nr. 75: Refactoring der Vereinbarungen ohne Br\u00fcche = Test ansible + Testkitchen<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Die Festlegung von Vereinbarungen im Code k\u00f6nnte nicht ausreichend sein. Wenn du im laufenden Prozess etwas \u00e4ndern m\u00f6chtest, k\u00f6nntest du etwas kaputt machen. Deshalb wird in der Infrastruktur das Testen dieser gleichen Infrastruktur eingef\u00fchrt. Um das Wissen innerhalb des Teams zu synchronisieren, haben wir begonnen, Ansible-Rollen zu testen. Ich werde nicht n\u00e4her darauf eingehen, da es einen Artikel gibt, der die Ereignisse zu diesem Zeitpunkt beschreibt. Teste mich, wenn du kannst, oder tr\u00e4umen YML-Programmierer von Ansible-Tests?<\/a><\/noindex>(Spoiler: Es war nicht die endg\u00fcltige Version, und sp\u00e4ter wurde alles komplizierter.) Wie man Ansible testet, ein Projekt in einem Jahr refakturiert und nicht den Verstand verliert<\/a><\/noindex>).<\/p>\n

                <\/p>\n

                Tag Nr. 130: Brauchen wir vielleicht CentOS + Ansible? Vielleicht OpenShift?<\/h3>\n

                <\/p>\n

                Es ist wichtig zu verstehen, dass der Prozess der Einf\u00fchrung der Infrastruktur nicht der einzige war und es Nebenprojekte gab. Zum Beispiel gab es eine Anfrage, unsere Anwendung in OpenShift zu starten, was in mehrw\u00f6chige Recherchen m\u00fcndete. Wir starten die Anwendung in OpenShift und vergleichen die vorhandenen Werkzeuge.<\/a><\/noindex> Was den Umzugsprozess verz\u00f6gert hat. Am Ende stellte sich heraus, dass OpenShift nicht alle Bed\u00fcrfnisse abdeckt; es wird tats\u00e4chliche Hardware oder zumindest die M\u00f6glichkeit ben\u00f6tigt, mit dem Kernel zu experimentieren.<\/p>\n

                <\/p>\n

                Tag Nr. 170: Openshift ist ungeeignet, wagen wir es mit Windows Azure Pack?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Hyper-V ist nicht besonders benutzerfreundlich, SCVMM verbessert es nicht wesentlich. Aber es gibt diese Sache namens Windows Azure Pack, das eine Erweiterung von SCVMM ist und sich wie Azure tarnt. In Wirklichkeit wirkt das Produkt jedoch vernachl\u00e4ssigt: die Dokumentation hat defekte Links und ist ziemlich mager. Im Rahmen der Pr\u00fcfung von Optionen zur Vereinfachung unseres Cloud-Lebens haben wir auch einen Blick darauf geworfen.<\/p>\n

                <\/p>\n

                Tag Nr. 250: Windows Azure Pack ist nicht besonders. Wir bleiben bei SCVMM.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Windows Azure Pack sah vielversprechend aus, aber es wurde beschlossen, WAP mit seinen Schwierigkeiten nicht in das System zu integrieren, um unn\u00f6tige Features zu vermeiden, und wir bleiben bei SCVMM.<\/p>\n

                <\/p>\n

                Tag Nr. 360: Wir essen den Elefanten in Portionen.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Erst ein Jahr sp\u00e4ter war die Plattform bereit, auf die wir umziehen konnten, und der Migrationsprozess begann. Daf\u00fcr wurde eine S.M.A.R.T.-Aufgabe gesetzt. Wir haben alle VMs aufgelistet und sind nacheinander die Konfiguration durchgegangen, haben sie in Ansible dokumentiert und Tests abgedeckt.<\/p>\n

                <\/p>\n

                Tag Nr. 450: Was f\u00fcr ein System ist entstanden?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Der Prozess selbst ist nicht interessant. Er ist routinem\u00e4\u00dfig und man kann feststellen, dass die meisten Konfigurationen relativ einfach oder isomorph waren. Nach dem Pareto-Prinzip ben\u00f6tigten 80% der Konfigurationen 20% der Zeit. Ebenso gingen 80% der Zeit f\u00fcr die Vorbereitung des Umzugs drauf, und nur 20% f\u00fcr den Umzug selbst. <\/p>\n

                <\/p>\n

                Tag Nr. 540: Finale<\/h2>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Was ist in den 18 Monaten passiert?<\/p>\n

                <\/p>\n

                  \n
                1. Die Vereinbarungen wurden zum Code.<\/li>\n
                2. Manuelle Arbeit<\/em> -> Mechanisierung<\/em> -> Automatisierung<\/em>.<\/li>\n<\/ol>\n

                  <\/p>\n

                  Links<\/h2>\n

                  <\/p>\n