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

Dies ist die Abschrift des Vortrags bei DevopsConf 2019-10-01 und SPbLUG 2019-09-25.

Dies ist die Geschichte eines Projekts, in dem ein eigenes Konfigurationsmanagement-System verwendet wurde und warum der Umstieg auf Ansible sich über 18 Monate hinzog.

Tag № -XXX: Vor Beginn

Ursprünglich 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ügen. 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.

Eingehendes Konfigurationsmanagement-Lösung

Ich vermute, die ursprüngliche Idee war als IaC gedacht: viele stateless VMs, die bei einem Neustart ihren Zustand zurücksetzten. Wie sah das Management von VM-Konfigurationen aus? Schemenhaft sieht es einfach aus:

Für die VMs wurde eine statische MAC-Adresse vergeben.
Eine ISO mit CoreOS und ein Bootlaufwerk wurden an die VMs angeschlossen.
CoreOS startet ein Anpassungsskript, indem es dieses basierend auf seiner IP von einem WEB-Server herunterlädt.
Das Skript lädt über SCP die Konfiguration der VM basierend auf der IP-Adresse herunter.
Es wird eine Reihe von systemd-Diensteinheiten und eine Reihe von Bash-Skripten gestartet.

Diese Lösung hatte viele offensichtliche Probleme:

ISO in CoreOS wurde als veraltet markiert.
Viele schwer automatisierbare Aktionen und Magie bei der Migration/Erstellung von VMs.
Es gab Schwierigkeiten beim Update und wenn eine bestimmten Softwareversion benötigt wurde. Es wird noch komplizierter bei den Kernel-Modulen.
Die VMs waren nicht so ganz ohne Daten, d.h. es erschienen VMs, bei denen eine Festplatte mit Benutzerdaten zusätzlich gemountet war.
Ständig gab es Probleme mit den Abhängigkeiten der systemd-Diensteinheiten, und beim Neustart hing CoreOS. Mit den vorhandenen Mitteln in CoreOS war es schwierig, dies zu erkennen.
Geheimnisverwaltung.
Es gab quasi kein Configuration Management. Es gab Bash und YML-Konfigurationen für CoreOS.

Um die Konfiguration der VM anzuwenden, musste sie neu gestartet werden, aber sie konnte sich möglicherweise nicht neu starten. Es scheint ein offensichtliches Problem zu sein, aber es gibt keine persistenten Festplatten – es gibt keinen Ort, um Logs zu speichern. Na gut, versuchen wir, Kernel-Startoptionen hinzuzufügen, um die Logs zu übermitteln. Aber nein, das alles ist so kompliziert.

Tag Nr. 0: Problemerkennung

Das war eine typische Entwicklungsinfrastruktur: Jenkins, Testumgebungen, Monitoring, Registry. CoreOS war für 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ür:

CentOS als Basisdistribution, da sie der Produktionsumgebung am nächsten kommt.
Ansible für das Management von Konfigurationen, da es umfangreiche Expertise in diesem Bereich gab.
Jenkins als Framework zur Automatisierung bestehender Prozesse, da es bereits aktiv für Entwicklungsprozesse verwendet wurde.
Hyper-V als Virtualisierungsplattform. Es gibt eine Reihe von Gründen, 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 auf den Umzug. Die Festlegung bestehender Vereinbarungen in Form von Code (Agreements as Code!). Der Übergang manuelle Arbeit -> Mechanisierung -> Automatisierung.

1. VMs konfigurieren

Ansible übernimmt diese Aufgabe hervorragend. Mit minimalem Aufwand können die VM-Konfigurationen verwaltet werden:

Erstellen eines Git-Repositorys.
Die Liste der VMs im Inventory ablegen, Konfigurationen in Playbooks und Rollen organisieren.
Wir richten einen speziellen Jenkins-Slave ein, von dem aus Ansible gestartet werden kann.
Wir erstellen einen Job und konfigurieren Jenkins.

Der erste Prozess ist abgeschlossen. Vereinbarungen sind festgehalten.

2. Neue VM erstellen

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:

Ansible verbindet sich über WinRM mit dem Windows-Host.
Ansible führt ein PowerShell-Skript aus.
Das PowerShell-Skript erstellt eine neue VM.
Mit Hyper-V/ScVMM wird beim Erstellen der VM im Gastbetriebssystem der Hostname konfiguriert.
Die VM sendet ihren Hostname bei der DHCP-Lease-Aktualisierung.
Die Standardintegration von DDNS & DHCP auf der Seite des Domänencontrollers konfiguriert den DNS-Eintrag.
VMs können im Inventar hinzugefügt und mit Ansible konfiguriert werden.

3. VM-Vorlage erstellen

Hier haben wir nichts erfunden – wir haben Packer verwendet.

Wir speichern die Packer-Konfiguration und Kickstart im Git-Repository.
Wir richten einen speziellen Jenkins-Slave mit Hyper-V und Packer ein.
Wir erstellen einen Job und konfigurieren Jenkins.

So funktioniert dieses Setup:

Packer erstellt eine leere VM und bindet das ISO ein.
Die VM wird gestartet, Packer gibt dem Bootloader den Befehl, unser Kickstart-Datei von Diskette oder HTTP zu verwenden.
Anaconda wird mit unserer Konfiguration gestartet, die grundlegende OS-Konfiguration wird durchgeführt.
Packer wartet auf die Verfügbarkeit der VM.
Packer startet Ansible im lokalen Modus innerhalb der VM.
Ansible verwendet genau dieselben Rollen wie im Schritt Nr. 1.
Packer exportiert die VM-Vorlage.

Tag Nr. 75: Refactoring der Vereinbarungen ohne Brüche = Test ansible + Testkitchen

Die Festlegung von Vereinbarungen im Code könnte nicht ausreichend sein. Wenn du im laufenden Prozess etwas ändern möchtest, könntest du etwas kaputt machen. Deshalb wird in der Infrastruktur das Testen dieser gleichen Infrastruktur eingeführt. Um das Wissen innerhalb des Teams zu synchronisieren, haben wir begonnen, Ansible-Rollen zu testen. Ich werde nicht näher darauf eingehen, 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: Es war nicht die endgültige Version, und später wurde alles komplizierter.) Wie man Ansible testet, ein Projekt in einem Jahr refakturiert und nicht den Verstand verliert).

Tag Nr. 130: Brauchen wir vielleicht CentOS + Ansible? Vielleicht OpenShift?

Es ist wichtig zu verstehen, dass der Prozess der Einführung 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öchige Recherchen mündete. Wir starten die Anwendung in OpenShift und vergleichen die vorhandenen Werkzeuge. Was den Umzugsprozess verzögert hat. Am Ende stellte sich heraus, dass OpenShift nicht alle Bedürfnisse abdeckt; es wird tatsächliche Hardware oder zumindest die Möglichkeit benötigt, mit dem Kernel zu experimentieren.

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

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ässigt: die Dokumentation hat defekte Links und ist ziemlich mager. Im Rahmen der Prüfung von Optionen zur Vereinfachung unseres Cloud-Lebens haben wir auch einen Blick darauf geworfen.

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

Windows Azure Pack sah vielversprechend aus, aber es wurde beschlossen, WAP mit seinen Schwierigkeiten nicht in das System zu integrieren, um unnötige Features zu vermeiden, und wir bleiben bei SCVMM.

Tag Nr. 360: Wir essen den Elefanten in Portionen.

Erst ein Jahr später war die Plattform bereit, auf die wir umziehen konnten, und der Migrationsprozess begann. Dafür 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.

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

Der Prozess selbst ist nicht interessant. Er ist routinemäßig und man kann feststellen, dass die meisten Konfigurationen relativ einfach oder isomorph waren. Nach dem Pareto-Prinzip benötigten 80% der Konfigurationen 20% der Zeit. Ebenso gingen 80% der Zeit für die Vorbereitung des Umzugs drauf, und nur 20% für den Umzug selbst.