{"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 auf CentOS \u00fcber 18 Monate","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ansible:<\/p>\n

<\/p>\n

Dies ist die Transkription des Vortrags auf 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 selbst entwickeltes Konfigurationsmanagementsystem verwendet wurde und warum der Wechsel zu Ansible sich \u00fcber 18 Monate hinzog.<\/p>\n

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

Tag Nr. -XXX: Kurz vor dem Beginn<\/h2>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Urspr\u00fcnglich bestand die Infrastruktur aus vielen eigenst\u00e4ndigen Hosts, die von Hyper-V verwaltet wurden. Das Erstellen einer virtuellen Maschine erforderte viele Schritte: Festplatten an den richtigen Ort legen, DNS eintragen, DHCP reservieren, VM-Konfiguration in ein Git-Repository ablegen. Dieser Prozess war teilweise automatisiert, aber beispielsweise wurden die VMs manuell auf die Hosts verteilt. Aber die Entwickler konnten die VM-Konfiguration in Git \u00e4ndern und sie auf die VM anwenden, indem sie sie neu starteten.<\/p>\n

<\/p>\n

Benutzerdefinierte L\u00f6sung f\u00fcr das Konfigurationsmanagement<\/h3>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Die urspr\u00fcngliche Idee, vermute ich, wurde als IaC (Infrastructure as Code) konzipiert: viele stateless VMs, die ihren Zustand beim Neustart zur\u00fccksetzten. Wie sah das Konfigurationsmanagement f\u00fcr VMs aus? Schemenhaft sieht es einfach aus:<\/p>\n

<\/p>\n

    \n
  1. F\u00fcr VMs wurde eine statische MAC-Adresse festgelegt.<\/li>\n
  2. Eine ISO mit CoreOS und einem Bootlaufwerk wurde an die VM angeschlossen.<\/li>\n
  3. CoreOS f\u00fchrt ein Anpassungsskript aus, das es basierend auf seiner IP von einem WEB-Server herunterl\u00e4dt.<\/li>\n
  4. Das Skript l\u00e4dt die VM-Konfiguration \u00fcber SCP herunter, basierend auf der IP-Adresse.<\/li>\n
  5. Eine Liste von systemd-Unit-Dateien und Bash-Skripten wird 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. Die ISO in CoreOS war veraltet.<\/li>\n
    2. Viele komplex automatisierte Schritte und Magie bei der Migration\/Erstellung von VMs.<\/li>\n
    3. Schwierigkeiten beim Update und wenn eine bestimmte Softwareversion ben\u00f6tigt wird. Besonders hektisch mit Kernelmodulen.<\/li>\n
    4. Die VMs waren nicht ganz datenlos, d.h. es gab VMs, die zus\u00e4tzlich eine mit Benutzerdaten montierte Festplatte hatten.<\/li>\n
    5. St\u00e4ndig hatte jemand Probleme mit den Abh\u00e4ngigkeiten der systemd-Units, und beim Neustart hing CoreOS. Mit den vorhandenen Mitteln in CoreOS war es schwierig, das zu erfassen.<\/li>\n
    6. Verwaltung von Geheimnissen.<\/li>\n
    7. Es gab im Grunde kein CM. Es gab Bash und YML-Konfigurationen f\u00fcr CoreOS.<\/li>\n<\/ol>\n

      <\/p>\n

      Um die VM-Konfiguration anzuwenden, muss sie neu gestartet werden, aber sie k\u00f6nnte sich weigern, neu zu starten. Das scheint ein offensichtliches Problem zu sein, aber es gibt keine persistenten Festplatten \u2013 es gibt keinen Ort, um Logs zu speichern. Nun gut, lassen Sie uns versuchen, Kernel-Boot-Optionen hinzuzuf\u00fcgen, um die Logs zu versenden. Aber es ist alles so kompliziert.<\/p>\n

      <\/p>\n

      Tag Nr. 0: Probleme erkennen<\/h2>\n

      <\/p>\n

      \"Ansible:<\/p>\n

      <\/p>\n

      Das war eine gew\u00f6hnliche Entwicklungsinfrastruktur: Jenkins, Testumgebungen, Monitorings, Registry. CoreOS war f\u00fcr das Hosting von k8s-Clustern gedacht, d.h. das Problem lag darin, wie CoreOS verwendet wurde. Der erste Schritt war die Auswahl des Tech-Stacks. Wir entschieden uns f\u00fcr:<\/p>\n

      <\/p>\n

        \n
      1. CentOS<\/strong> als Basis-Distro, da es am n\u00e4chsten an Produktionsumgebungen ist.<\/li>\n
      2. Ansible<\/strong> zur Konfigurationsverwaltung, da es dar\u00fcber umfangreiche Expertise gab.<\/li>\n
      3. Jenkins<\/strong> als Automatisierungsframework bestehender Prozesse, da es bereits aktiv f\u00fcr Entwicklungsprozesse verwendet wurde.<\/li>\n
      4. Hyper-V<\/strong> als Virtualisierungsplattform. Es gibt einige Gr\u00fcnde, die \u00fcber den Rahmen dieser Erz\u00e4hlung hinausgehen, aber kurz gesagt \u2014 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 \u2014 Agreements as Code<\/h3>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Als der Stack klar war, begann die Vorbereitung f\u00fcr 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 erledigt diese Aufgabe hervorragend. Mit minimalem Aufwand k\u00f6nnen die Konfigurationen der VMs verwaltet werden:<\/p>\n

        <\/p>\n

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

          <\/p>\n

          Der erste Prozess ist fertig. Die 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. Aus Linux war es nicht sehr einfach, VMs auf Hyper-V 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 startet das PowerShell-Skript.<\/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 beim Aktualisieren des DHCP-Leases ihren Hostnamen.<\/li>\n
          6. Die eingebaute Integration von DDNS & DHCP auf der Seite des Domain Controllers konfiguriert den DNS-Eintrag.<\/li>\n
          7. Man kann die VMs ins Inventory aufnehmen und sie mit Ansible konfigurieren.<\/li>\n<\/ol>\n

            <\/p>\n

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

            <\/p>\n

            \"Ansible:<\/p>\n

            <\/p>\n

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

            <\/p>\n

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

              <\/p>\n

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

              <\/p>\n

                \n
              1. Packer erstellt eine leere VM und mountet die ISO.<\/li>\n
              2. Die VM bootet, Packer gibt dem Bootloader den Befehl, unsere Kickstart-Datei von Diskette oder http zu verwenden.<\/li>\n
              3. Anaconda wird mit unserer Konfiguration gestartet, die grundlegende OS-Einstellungen werden vorgenommen.<\/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 die gleichen Rollen wie in Schritt Nr. 1.<\/li>\n
              7. Packer exportiert die VM-Vorlage.<\/li>\n<\/ol>\n

                <\/p>\n

                Tag Nr. 75: Den Vertrag umstrukturieren, ohne ihn zu brechen = Test ansible + Testkitchen.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Es kann unzureichend sein, die Vereinbarungen im Code festzuhalten. Denn wenn du im Verlauf des Prozesses etwas \u00e4ndern m\u00f6chtest, k\u00f6nntest du etwas kaputtmachen. Daher kommt das Testen der Infrastruktur ins Spiel. Um das Wissen innerhalb des Teams zu synchronisieren, haben wir begonnen, Ansible-Rollen zu testen. Ich werde nicht weiter ins Detail gehen, 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: das war nicht die endg\u00fcltige Version, und sp\u00e4ter wurde alles komplizierter.) Wie man anf\u00e4ngt, Ansible zu testen, das Projekt innerhalb eines Jahres umstrukturieren kann, ohne den Verstand zu verlieren.<\/a><\/noindex>).<\/p>\n

                <\/p>\n

                Tag Nr. 130: Brauchen wir CentOS+ansible \u00fcberhaupt? Vielleicht openshift?<\/h3>\n

                <\/p>\n

                Es ist wichtig zu verstehen, dass der Prozess der Einf\u00fchrung von Infrastruktur nicht der einzige war und es Nebenprojekte gab. Zum Beispiel gab es eine Anfrage f\u00fcr den Start unserer Anwendung in Openshift, was zu mehrw\u00f6chigen Untersuchungen f\u00fchrte. Wir starten die Anwendung in Openshift und vergleichen sie mit dem bestehenden Werkzeug.<\/a><\/noindex> was den Umzug verz\u00f6gert hat. Am Ende stellte sich heraus, dass Openshift nicht alle Bed\u00fcrfnisse erf\u00fcllt, man ben\u00f6tigt echte Hardware oder zumindest die M\u00f6glichkeit, mit dem Kern zu experimentieren.<\/p>\n

                <\/p>\n

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

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Hyper-V ist nicht sehr benutzerfreundlich, SCVMM macht es nicht viel besser. Aber es gibt so etwas wie Windows Azure Pack, das eine Erweiterung von SCVMM ist und Azure imitiert. Tats\u00e4chlich sieht das Produkt jedoch vernachl\u00e4ssigt aus: die Dokumentation enth\u00e4lt nicht funktionierende Links und ist ziemlich sp\u00e4rlich. Im Rahmen der Untersuchung von Vereinfachungen unseres Clouds haben wir uns auch das angeschaut.<\/p>\n

                <\/p>\n

                Tag Nr. 250: Windows Azure Pack ist nicht sehr gut. 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 Komplexit\u00e4ten nicht in das System einzuf\u00fchren, um unn\u00f6tige Funktionen zu vermeiden, und wir blieben bei SCVMM.<\/p>\n

                <\/p>\n

                Tag Nr. 360: Wir essen den Elefanten St\u00fcck f\u00fcr St\u00fcck.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Erst nach einem Jahr war die Plattform bereit, zu der wir umziehen konnten, und der Umzugsprozess begann. F\u00fcr diesen Zweck wurde eine S.M.A.R.T.-Aufgabe formuliert. Wir haben alle VMs aufgeschrieben und angefangen, sie eine nach der anderen durchzugehen, ihre Konfiguration in Ansible zu beschreiben und sie mit Tests abzudecken.<\/p>\n

                <\/p>\n

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

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Der gesamte Prozess ist uninteressant. Er ist routiniert und es l\u00e4sst sich feststellen, dass die meisten Konfigurationen relativ einfach oder isomorph waren und nach dem Pareto-Prinzip 80 % der Konfigurationen 20 % der Zeit ben\u00f6tigten. Nach demselben Prinzip ben\u00f6tigten 80 % der Zeit die Vorbereitung des Umzugs 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 18 Monaten passiert?<\/p>\n

                <\/p>\n

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

                  <\/p>\n

                  Links<\/h2>\n

                  <\/p>\n