Dies ist eine Abschrift der Rede и .
Dies ist die Geschichte eines Projekts, das ein selbst geschriebenes Konfigurationsmanagementsystem verwendete, und warum der Wechsel zu Ansible 18 Monate dauerte.
Tag Nr. -ХХХ: Vor dem Beginn
Ursprünglich bestand die Infrastruktur aus vielen separaten Hosts, auf denen Hyper-V ausgeführt wurde. Das Erstellen einer virtuellen Maschine erforderte viele Schritte: Platzieren der Festplatten an der richtigen Stelle, Registrieren von DNS, Reservieren von DHCP, Einfügen der VM-Konfiguration im Git-Repository. Dieser Prozess war teilweise mechanisiert, aber beispielsweise wurden VMs manuell zwischen Hosts verteilt. Aber Entwickler könnten beispielsweise die VM-Konfiguration in Git korrigieren und durch einen Neustart der VM anwenden.
Benutzerdefinierte Konfigurationsmanagementlösung
Ich vermute, dass die ursprüngliche Idee als IaC konzipiert war: viele zustandslose VMs, die ihren Zustand beim Neustart auf Null zurücksetzen. Was war VM-Konfigurationsmanagement? Schematisch sieht es einfach aus:
- Für die VM wurde ein statischer MAC festgelegt.
- An die VM wurden ein ISO mit CoreOS und eine Bootdiskette angeschlossen.
- CoreOS startet das Anpassungsskript, indem es es basierend auf seiner IP vom WEB-Server herunterlädt.
- Das Skript lädt die VM-Konfiguration über SCP basierend auf der IP-Adresse herunter.
- Die Basis für Systemd-Unit-Dateien und die Basis für Bash-Skripte werden gestartet.
Diese Lösung hatte viele offensichtliche Probleme:
- CoreOS ISO ist veraltet.
- Viele komplexe automatisierte Aktionen und Magie beim Migrieren/Erstellen von VMs.
- Schwierigkeiten bei der Aktualisierung und wenn eine bestimmte Softwareversion benötigt wird. Noch mehr Spaß mit Kernel-Modulen.
- VMs wurden nicht so ohne Daten gewonnen, d.h. VMs wurden mit einer Festplatte angezeigt, auf der zusätzliche Benutzerdaten gemountet waren.
- Jemand hat ständig die Abhängigkeiten der Systemd-Einheiten durcheinander gebracht und CoreOS fror beim Neustart ein. Mit den verfügbaren Tools in CoreOS war es schwierig, dies zu erkennen.
- Geheimnismanagement.
- Es gab kein CM. Es gab Bash- und YML-Konfigurationen für CoreOS.
Um die VM-Konfiguration anzuwenden, müssen Sie sie neu starten, es kann jedoch sein, dass sie nicht neu gestartet wird. Es scheint ein offensichtliches Problem zu sein, aber es gibt keine persistenten Festplatten – es gibt keinen Ort, an dem Protokolle gespeichert werden können. Nun gut, versuchen wir, die Kernel-Ladeoption hinzuzufügen, damit die Protokolle gesendet werden. Aber nein, wie kompliziert ist das alles.
Tag Nr. 0: Erkennen Sie das Problem
Es war die übliche Entwicklungsinfrastruktur: Jenkins, Testumgebungen, Überwachung, Registrierung. CoreOS wurde für das Hosten von k8s-Clustern entwickelt, d. h. Das Problem war, wie CoreOS verwendet wurde. Der erste Schritt war die Auswahl eines Stapels. Wir haben uns für Folgendes entschieden:
- CentOS als Basisverteilung, weil Dies ist die Verteilung, die den Produktionsumgebungen am nächsten kommt.
- Ansible für das Konfigurationsmanagement, weil Es gab eine ausführliche Untersuchung dazu.
- Jenkins als Framework zur Automatisierung bestehender Prozesse, weil es wurde bereits aktiv für Entwicklungsprozesse genutzt
- Hyper-V als Virtualisierungsplattform. Es gibt eine Reihe von Gründen, die den Rahmen der Geschichte sprengen, aber kurz gesagt: Wir können die Clouds nicht nutzen, wir müssen unsere eigene Hardware verwenden.
Tag Nr. 30: Bestehende Vereinbarungen fixieren – Vereinbarungen als Kodex
Als der Stapel frei war, begannen die Vorbereitungen für den Umzug. Bestehende Vereinbarungen in Form von Code fixieren (Vereinbarungen als Kodex!). Übergang Handarbeit -> Mechanisierung -> Automatisierung.
1. VMs konfigurieren
Ansible leistet hier hervorragende Arbeit. Mit einem Minimum an Körperbewegungen können Sie die Kontrolle über VM-Konfigurationen übernehmen:
- Erstellen Sie ein Git-Repository.
- Wir legen die Liste der VMs im Inventar, Konfigurationen in Playbooks und Rollen ab.
- Wir richten einen speziellen Jenkins-Slave ein, von dem aus Sie Ansible ausführen können.
- Wir erstellen einen Job und konfigurieren Jenkins.
Der erste Prozess ist fertig. Die Vereinbarungen sind fix.
2. Neue VM erstellen
Alles hier war nicht sehr praktisch. Es ist nicht sehr praktisch, unter Linux VMs auf Hyper-V zu erstellen. Einer der Versuche, diesen Prozess zu mechanisieren, war:
- Ansbile stellt über WinRM eine Verbindung zum Windows-Host her.
- Ansible führt ein Powershell-Skript aus.
- Powershell-Skript erstellt eine neue VM.
- Bei Verwendung von Hyper-V/ScVMM wird beim Erstellen einer VM im Gastbetriebssystem der Hostname konfiguriert.
- Beim Aktualisieren der DHCP-Lease sendet die VM ihren Hostnamen.
- Die Standard-DDNS- und DHCP-Integration auf der Seite des Domänencontrollers konfiguriert den DNS-Eintrag.
- Sie können Ihrem Inventar eine VM hinzufügen und diese mit Ansible konfigurieren.
3. VM-Vorlage erstellen
Sie haben hier nichts erfunden – sie haben einen Packer genommen.
- Fügen Sie den Packer und die Kickstart-Konfiguration zum Git-Repository hinzu.
- Einrichten eines speziellen Jenkins-Slaves mit Hyper-V und Packer.
- Wir erstellen einen Job und konfigurieren Jenkins.
So funktioniert dieser Link:
- Packer erstellt eine leere VM und holt sich die ISO.
- Die VM bootet, Packer gibt den Befehl in den Bootloader ein, unsere Kickstart-Datei von einer Diskette oder http zu verwenden.
- Anaconda wird mit unserer Konfiguration gestartet und die anfängliche Betriebssystemkonfiguration ist abgeschlossen.
- Packer wartet darauf, dass die VM verfügbar wird.
- Der Packer innerhalb der VM läuft ansible im lokalen Modus.
- Ansible verwendet genau die gleichen Rollen wie in Schritt 1.
- Packer exportiert die VM-Vorlage.
Tag Nr. 75: Überarbeiten Sie die Vereinbarung, ohne sie zu brechen = Test ansible + Testkitchen
Das Erfassen von Konventionen im Code reicht möglicherweise nicht aus. Denn wenn man im Prozess etwas ändern will, kann man auch etwas kaputt machen. Daher erscheint im Fall der Infrastruktur das Testen dieser Infrastruktur. Um das Wissen innerhalb des Teams zu synchronisieren, haben wir mit dem Testen von Ansible-Rollen begonnen. Ich werde nicht näher darauf eingehen, weil... Es gibt einen Artikel, der die damaligen Ereignisse beschreibt (Spoiler, dies war nicht die endgültige Version und später wurde alles komplizierter ).
Tag #130: Vielleicht wird CentOS+ansible nicht benötigt? vielleicht Openshift?
Wir müssen verstehen, dass der Prozess der Einführung der Infrastruktur nicht der einzige war und es Nebenprojekte gab. Beispielsweise kam eine Anfrage, unsere Anwendung in OpenShift zu starten, und dies führte zu einer Recherche von mehr als einer Woche was den Umzugsprozess verlangsamte. Das Ergebnis war, dass OpenShift nicht alle Bedürfnisse abdeckt; man braucht echte Hardware oder zumindest die Möglichkeit, mit dem Kernel zu spielen.
Tag #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 das Windows Azure Pack, das ein Add-on zu SCVMM ist und Azure nachahmt. Doch in Wirklichkeit sieht das Produkt verlassen aus: Die Dokumentation weist defekte Links auf und ist sehr spärlich. Aber im Rahmen der Untersuchung von Optionen zur Vereinfachung des Lebens unserer Cloud haben sie sich auch damit befasst.
Tag Nr. 250: Windows Azure Pack nicht sehr gut. Wir bleiben bei SCVMM
Das Windows Azure Pack sah vielversprechend aus, es wurde jedoch beschlossen, WAP mit seinen Komplexitäten wegen unnötiger Funktionen nicht in das System zu integrieren, und blieb bei SCVMM.
Tag Nr. 360: Den Elefanten Stück für Stück verspeisen
Nur ein Jahr später war die Umzugsplattform fertig und der Umzugsprozess begann. Zu diesem Zweck wurde eine SMART-Aufgabe gestellt. Wir haben alle VMs überprüft und begonnen, die Konfiguration einzeln herauszufinden, sie in Ansible zu beschreiben und sie mit Tests abzudecken.
Tag #450: Was für ein System hast du bekommen?
Der Prozess selbst ist nicht interessant. Es ist Routine, man kann feststellen, dass die meisten Konfigurationen relativ einfach oder isomorph waren und nach dem Pareto-Prinzip 80 % der VM-Konfigurationen 20 % der Zeit benötigten. Nach dem gleichen Prinzip wurden 80 % der Zeit für die Vorbereitung des Umzugs aufgewendet und nur 20 % für den Umzug selbst.
Tag Nr. 540: Finale
Was ist in 18 Monaten passiert?
- Die Vereinbarungen wurden zu einem Kodex.
- Handarbeit -> Mechanisierung -> Automatisierung.
Links
Source: habr.com