🥇Ansible: Migration der Konfiguration von 120 VMs von CoreOS auf CentOS in 18 Monaten

Dies ist die Transkription des Vortrags auf DevopsConf 2019-10-01 und SPbLUG 2019-09-25.

Dies ist die Geschichte eines Projekts, in dem ein selbst entwickeltes Konfigurationsmanagementsystem verwendet wurde und warum der Wechsel zu Ansible sich über 18 Monate hinzog.

Tag Nr. -XXX: Kurz vor dem Beginn

Ursprünglich bestand die Infrastruktur aus vielen eigenständigen 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 ändern und sie auf die VM anwenden, indem sie sie neu starteten.

Benutzerdefinierte Lösung für das Konfigurationsmanagement

Die ursprüngliche Idee, vermute ich, wurde als IaC (Infrastructure as Code) konzipiert: viele stateless VMs, die ihren Zustand beim Neustart zurücksetzten. Wie sah das Konfigurationsmanagement für VMs aus? Schemenhaft sieht es einfach aus:

Für VMs wurde eine statische MAC-Adresse festgelegt.
Eine ISO mit CoreOS und einem Bootlaufwerk wurde an die VM angeschlossen.
CoreOS führt ein Anpassungsskript aus, das es basierend auf seiner IP von einem WEB-Server herunterlädt.
Das Skript lädt die VM-Konfiguration über SCP herunter, basierend auf der IP-Adresse.
Eine Liste von systemd-Unit-Dateien und Bash-Skripten wird gestartet.

Diese Lösung hatte viele offensichtliche Probleme:

Die ISO in CoreOS war veraltet.
Viele komplex automatisierte Schritte und Magie bei der Migration/Erstellung von VMs.
Schwierigkeiten beim Update und wenn eine bestimmte Softwareversion benötigt wird. Besonders hektisch mit Kernelmodulen.
Die VMs waren nicht ganz datenlos, d.h. es gab VMs, die zusätzlich eine mit Benutzerdaten montierte Festplatte hatten.
Ständig hatte jemand Probleme mit den Abhängigkeiten der systemd-Units, und beim Neustart hing CoreOS. Mit den vorhandenen Mitteln in CoreOS war es schwierig, das zu erfassen.
Verwaltung von Geheimnissen.
Es gab im Grunde kein CM. Es gab Bash und YML-Konfigurationen für CoreOS.

Um die VM-Konfiguration anzuwenden, muss sie neu gestartet werden, aber sie könnte sich weigern, neu zu starten. Das scheint ein offensichtliches Problem zu sein, aber es gibt keine persistenten Festplatten – es gibt keinen Ort, um Logs zu speichern. Nun gut, lassen Sie uns versuchen, Kernel-Boot-Optionen hinzuzufügen, um die Logs zu versenden. Aber es ist alles so kompliziert.

Tag Nr. 0: Probleme erkennen

Das war eine gewöhnliche Entwicklungsinfrastruktur: Jenkins, Testumgebungen, Monitorings, Registry. CoreOS war für 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ür:

CentOS als Basis-Distro, da es am nächsten an Produktionsumgebungen ist.
Ansible zur Konfigurationsverwaltung, da es darüber umfangreiche Expertise gab.
Jenkins als Automatisierungsframework bestehender Prozesse, da es bereits aktiv für Entwicklungsprozesse verwendet wurde.
Hyper-V als Virtualisierungsplattform. Es gibt einige Gründe, die über den Rahmen dieser Erzählung hinausgehen, aber kurz gesagt — wir können keine Cloud nutzen, wir müssen unsere eigene Hardware verwenden.

Tag Nr. 30: Festlegung bestehender Vereinbarungen — Agreements as Code

Als der Stack klar war, begann die Vorbereitung für den Umzug. Die Festlegung bestehender Vereinbarungen in Form von Code (Agreements as Code!). Der Übergang manuelle Arbeit -> Mechanisierung -> Automatisierung.

1. VMs konfigurieren

Ansible erledigt diese Aufgabe hervorragend. Mit minimalem Aufwand können die Konfigurationen der VMs verwaltet werden:

Wir erstellen ein Git-Repository.
Wir legen die Liste der VMs im Inventory ab, die Konfigurationen in Playbooks und Rollen.
Wir richten einen speziellen Jenkins-Slave ein, von dem aus Ansible gestartet werden kann.
Wir erstellen einen Job, konfigurieren Jenkins.

Der erste Prozess ist fertig. Die Vereinbarungen sind festgehalten.

2. Neue VM erstellen

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:

Ansible verbindet sich über WinRM mit dem Windows-Host.
Ansible startet das PowerShell-Skript.
Das PowerShell-Skript erstellt eine neue VM.
Mit Hyper-V/ScVMM wird beim Erstellen der VM im Gastbetriebssystem der Hostname konfiguriert.
Die VM sendet beim Aktualisieren des DHCP-Leases ihren Hostnamen.
Die eingebaute Integration von DDNS & DHCP auf der Seite des Domain Controllers konfiguriert den DNS-Eintrag.
Man kann die VMs ins Inventory aufnehmen und sie mit Ansible konfigurieren.

3. VM-Vorlage erstellen

Hier haben wir nichts Neues erfunden – wir haben Packer verwendet.

Wir legen die Konfiguration von Packer und Kickstart ins Git-Repository.
Wir richten einen speziellen Jenkins-Slave mit Hyper-V und Packer ein.
Wir erstellen einen Job, konfigurieren Jenkins.

So funktioniert dieses Zusammenspiel:

Packer erstellt eine leere VM und mountet die ISO.
Die VM bootet, Packer gibt dem Bootloader den Befehl, unsere Kickstart-Datei von Diskette oder http zu verwenden.
Anaconda wird mit unserer Konfiguration gestartet, die grundlegende OS-Einstellungen werden vorgenommen.
Packer wartet auf die Verfügbarkeit der VM.
Packer startet Ansible im lokalen Modus innerhalb der VM.
Ansible verwendet genau die gleichen Rollen wie in Schritt Nr. 1.
Packer exportiert die VM-Vorlage.

Tag Nr. 75: Den Vertrag umstrukturieren, ohne ihn zu brechen = Test ansible + Testkitchen.

Es kann unzureichend sein, die Vereinbarungen im Code festzuhalten. Denn wenn du im Verlauf des Prozesses etwas ändern möchtest, könntest 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äumen YML-Programmierer von Ansible-Tests?(Spoiler: das war nicht die endgültige Version, und später wurde alles komplizierter.) Wie man anfängt, Ansible zu testen, das Projekt innerhalb eines Jahres umstrukturieren kann, ohne den Verstand zu verlieren.).

Tag Nr. 130: Brauchen wir CentOS+ansible überhaupt? Vielleicht openshift?

Es ist wichtig zu verstehen, dass der Prozess der Einführung von Infrastruktur nicht der einzige war und es Nebenprojekte gab. Zum Beispiel gab es eine Anfrage für den Start unserer Anwendung in Openshift, was zu mehrwöchigen Untersuchungen führte. Wir starten die Anwendung in Openshift und vergleichen sie mit dem bestehenden Werkzeug. was den Umzug verzögert hat. Am Ende stellte sich heraus, dass Openshift nicht alle Bedürfnisse erfüllt, man benötigt echte Hardware oder zumindest die Möglichkeit, mit dem Kern zu experimentieren.

Tag Nr. 170: Openshift ist nicht geeignet, wagen wir es mit Windows Azure Pack?

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ächlich sieht das Produkt jedoch vernachlässigt aus: die Dokumentation enthält nicht funktionierende Links und ist ziemlich spärlich. Im Rahmen der Untersuchung von Vereinfachungen unseres Clouds haben wir uns auch das angeschaut.

Tag Nr. 250: Windows Azure Pack ist nicht sehr gut. Wir bleiben bei SCVMM.

Windows Azure Pack sah vielversprechend aus, aber es wurde beschlossen, WAP mit seinen Komplexitäten nicht in das System einzuführen, um unnötige Funktionen zu vermeiden, und wir blieben bei SCVMM.

Tag Nr. 360: Wir essen den Elefanten Stück für Stück.

Erst nach einem Jahr war die Plattform bereit, zu der wir umziehen konnten, und der Umzugsprozess begann. Für 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.

Tag Nr. 450: Was für ein System ist entstanden?

Der gesamte Prozess ist uninteressant. Er ist routiniert und es lässt sich feststellen, dass die meisten Konfigurationen relativ einfach oder isomorph waren und nach dem Pareto-Prinzip 80 % der Konfigurationen 20 % der Zeit benötigten. Nach demselben Prinzip benötigten 80 % der Zeit die Vorbereitung des Umzugs und nur 20 % für den Umzug selbst.