Trimmen von Threads: Migration von Puppet Enterprise zu Ansible Tower. Teil 2

Der Nationale Umwelt-Satelliteninformationsdienst (NESDIS) hat die Kosten für das Konfigurationsmanagement von Red Hat Enterprise Linux (RHEL) um 35% gesenkt, indem er von Puppet Enterprise zu Ansible Tower gewechselt ist. In diesem Video der Kategorie „Wie wir es gemacht haben“ begründet der Systemingenieur Michael Rau die Implementierung dieser Migration und gibt nützliche Tipps und Erfahrungen aus dem Übergang von einem SCM zu einem anderen.

Aus diesem Video lernen Sie:

  • Wie kann das Management die Machbarkeit eines Wechsels von Puppet Enterprise zu Ansible Tower rechtfertigen?
  • Welche Strategien sind für den reibungslosesten Übergang zu verwenden?
  • Tipps zum Transcodieren von PE-Manifesten in Ansible Playbook;
  • Best Practices für die Installation von Ansible Tower.



Trimmen von Threads: Migration von Puppet Enterprise zu Ansible Tower. Teil 1



Ich habe Tags für die Erstbereitstellung, die alle ausgeführt werden. Ich habe Tags, die in 20% der Infrastruktur nach Änderungen in 20% der Infrastruktur suchen, die in 80% der Arbeitszeit auftreten. Eine ähnliche Situation mit Rollen. Es gibt einen Wartungscode, einen zweiten Code, der die Bereitstellung organisiert, und einen dritten, der die Geräte beispielsweise einmal am Tag startet. Die Rolle prüft auf Änderungen an allen Geräten, die bereitgestellt werden sollen, und alle zwei Stunden wird nach Geräten gesucht, die Änderungen unterliegen. Dies gilt für die Firewall, einige administrative Dinge und dergleichen.

Verwenden Sie die guten Gewohnheiten, die Sie beim Schreiben von Code für Puppet erworben haben, da diese für Ansible nützlich sind. Zum Beispiel ist so etwas wie Idempotenz eine Eigenschaft eines Objekts oder einer Operation, wenn die Operation erneut auf das Objekt angewendet wird, um das gleiche Ergebnis wie die erste zu erzielen. In unserem Fall bedeutet dies, dass sich nichts ändert, wenn Sie dasselbe Playbook-Skript erneut ausführen, und das System Ihnen mitteilt, dass sich nichts geändert hat. Wenn die Änderungen festgeschrieben werden, bedeutet dies, dass etwas mit Ihrem Code nicht stimmt. Das heißt, Idempotenz hilft Ihnen zu erkennen, wenn etwas schief geht, wenn Sie dieselben Routineoperationen starten.
Verwenden Sie Fakten und Muster, vermeiden Sie fest codierte Daten. Mit Ansible können Sie dies mit Skripten tun, einen Datensatz flexibel verwalten und Änderungen im laufenden Betrieb erfassen. In Puppet gibt es so etwas nicht. Sie müssen alle wichtigen Daten in den Quellcode einfügen. Verwenden Sie daher Rollen, um Ihre Aufgabe erheblich zu erleichtern.

Verwenden Sie Ereignishandler, die durch eine Konfigurationsänderung verursacht werden. Das Gute ist, dass Handler mit geschützten Sequenzen arbeiten können. Dokumentieren Sie alles, was Sie tun. Ich hasse es, wenn ich auf einen Code stoße, den ich vor sechs Monaten geschrieben habe, ohne in diesem Moment etwas zu dokumentieren, und ich kann mich nicht erinnern, warum ich ihn überhaupt geschrieben habe. Daher sollte jede Aufgabe eine Beschreibung haben. Jede Rolle und jedes Skript, die Sie schreiben, sollte über eine eigene ReadMe-Datei verfügen, in der aufgezeichnet wird, wie sie verwendet werden und was sie tun. Glauben Sie mir, später wird dies für Sie sehr nützlich sein.



Sie müssen die neuen Freiheiten nutzen, die Ansible bietet. Sie können dieselbe Datei bei Bedarf mehrmals beeinflussen. Wenn Sie beispielsweise mehrere Parameter der Datei sshd_config in einem Skript ändern müssen, das wichtige Parameter für andere Skripte enthält, können Sie dies tun. Puppet erlaubt das nicht.
Mit Ansible erhalten Sie eine vorhersehbare Programmausführung. Sie funktionieren genau so, wie Sie es von ihnen erwarten, und Sie müssen keine Fehler bei der Codeausführung überwachen. Wenn Sie mit EXEC arbeiten, beachten Sie, dass Ansible-Handler intelligenter sind als Puppet-Handler. Verwenden Sie Ansible-Tricks wie meine bevorzugte Delegierungsfunktion. Sie haben beispielsweise ein Playbook für Server A gestartet, aber ein Teil der Schritte in diesem Skript sollte unabhängig auf Server B ausgeführt werden. Ich habe die Delegierungsfunktion verwendet, um von Puppet zu Ansible zu migrieren. Mit dieser Funktion können Sie die Ausführung der Aufgabe auf einem anderen Host konfigurieren und nicht auf dem Host, der mit dem Schlüssel delegate_to konfiguriert wurde. Das Modul wird weiterhin einmal für jeden Computer ausgeführt, aber anstatt auf dem Zielcomputer zu arbeiten, funktioniert es auf einem delegierten Host.Darüber hinaus gelten alle verfügbaren Fakten für den aktuellen Host. Dadurch wird die Anzahl der manuellen Systemeinstellungen erheblich reduziert.

Ihre Puppet Hiera-Bibliotheksdaten können als Ansible-Fakten verwendet werden, bei denen es sich um Informationen zu verbundenen Knoten handelt. Fakten - Dies ist, was das Modul "Fakten sammeln" während der Ausführung sammelt: Speicherplatz, Version und Typ des Betriebssystems, Hostname, verfügbarer Speicher, Prozessorarchitektur, IP-Adressen, Netzwerkschnittstellen und deren Status. Ich meine nicht, dass Serviceinformationen tief in den Daten verborgen sind - verwenden Sie einfach die Skripte Ihrer Geräte, um Gruppen und variable Knoten zu bilden. Mein Hardware-Skript teilt dem System mit, welche physischen Sites es enthält. Später verwende ich Rollen. Eine der Rollen enthält beispielsweise Infrastrukturinformationen für jeden physischen Standort, z. B. NTP-Ressourcen, DNS-Server, IP-Adressen modularer Geräte, Nessus-Scanner und dergleichen.Sammeln Sie allgemeine Variablen in einer Rolle, wenn Sie sie an mehreren Stellen platzieren, und platzieren Sie sie als Datei /etc/ansible/facts.d/ auf dem Host.

Wir werden also den eigentlichen Migrationsprozess betrachten. Ich wiederhole - für mich hat es viel Zeit gekostet, aber Sie können es reduzieren. Zunächst müssen Sie den Tower kaufen und bereitstellen. Dies ist ein sehr verständlicher Prozess. Befolgen Sie einfach die Installationsdokumentation.



Nach der Installation von Tower erhalten Sie sofort Zugriff auf die Weboberfläche. Als Nächstes müssen Sie ein Inventarskript installieren und eine Liste der Geräte erstellen. Sie können vorhandene Skripte kopieren und in den Tower einfügen.

Legen Sie als Nächstes die Git-Berechtigungen und -Berechtigungen fest, indem Sie Tower direkten Zugriff auf das Git-Repository gewähren, in dem Sie Playbooks speichern. Auf diese Weise können Tower sofort Informationen aus den Skripten über die Änderungen erhalten und diese sofort implementieren. Sie müssen Tower nichts mitteilen, es wird lediglich der Status des Systems überprüft und die neueste Version der Konfiguration ausgeführt.

Installieren Sie ein Standard-Tower-Konto für SSH auf Ihren Hosts. Ich verwende den Fernzugriff, daher verwende ich das Standardkonto und das SUDO-Systemverwaltungsprogramm, um Berechtigungen festzulegen. Natürlich hat Tower ein Passwort, sodass Sie mit dem SUDO-Passwort keine Sicherheit riskieren.

Konfigurieren Sie die Tower-Authentifizierung gemäß der Zugriffsstruktur Ihres Unternehmens. Entscheiden Sie sich für den Zugriff für Abteilungen, Teams, die Verteilung des Zugriffs auf Rollen und behandeln Sie spezielle Berechtigungen. Dies ist eine sehr umfangreiche Aufgabe, abhängig von der Größe Ihres Unternehmens. Denken Sie jedoch daran, dass die Verwaltung des Turms dank der flexiblen Konfiguration der Zugriffe Ihr Leben erheblich vereinfachen kann.

Nachdem Sie das Git-Repository bereitgestellt haben, installieren und konfigurieren Sie Arbeitsvorlagen für Playbooks. Testen Sie die Leistung von allem, was Sie mit Tower tun. Nachdem Sie überprüft haben, ob Ihre Skripte in einwandfreiem Zustand sind, können Sie mit der Hostmigration fortfahren. Verwenden Sie Ansible, um den Puppet-Agenten zu entfernen und den Knoten mithilfe eines speziellen Skripts vom Puppet-Server zu "bereinigen". Es ist sehr einfach.



Ich habe eine Gruppe namens Tower erstellt, sie dem Ansible-Skript hinzugefügt und an alle Hosts gesendet. Danach stoppte dieses Playbook die Puppet-Dienste, deinstallierte alle Puppet Enterprise-Pakete und löschte die Verzeichnisse. Er hat auch die Puppet-Benutzer gelöscht - da wir PE löschen, löschen wir auch PE-Benutzer.

Wir sehen die Delegierungsfunktion in Aktion. Jetzt kann ich in den Puppet Master gehen und die Registrierung mit den 2-3 Befehlen löschen und dann einen Screenshot machen, der zeigt, dass dieser SCM gelöscht wurde. Es wird als dokumentarischer Beweis dafür dienen, dass wir PE nicht mehr verwenden.

Schauen wir uns nun an, was maximale Aufmerksamkeit erhalten sollte - meine Fehler, die vermieden werden sollten. Dies bezieht sich hauptsächlich auf die Abhängigkeit der Szenarien voneinander. Es ist möglich, dass die Variablen eines Spielbuchs von den Variablen eines anderen Spielbuchs abhängen. Denken Sie daran, dass Sie in jedes Szenario Anforderungen einfügen können, die die Verwendung eines anderen Szenarios oder einer anderen Rolle ermöglichen. Ich habe Rollen für die Variablen aller unserer Websites erstellt, und jede dieser Rollen enthielt viele Variablen. Daher habe ich die Datei require.yml verwendet, um allgemeine Variablen zu zentralisieren. Sie können mehrere Ansible-Inhaltssammlungen mit einem Team installieren.



Wenn wir das Standard-Gateway oder den NTP-Server ändern, werden diese Änderungen sofort in allen Elementen der Infrastruktur berücksichtigt.

Vermeiden Sie die Verwendung massiver, umfangreicher Rollen und Skripte. Kurze Szenarien und Rollen für bestimmte Aufgaben sind effizienter und zuverlässiger, einfacher zu verwalten und leichter zu verfolgen.

Beachten Sie noch eines: Wenn Sie Tower starten und zu seiner Seite gehen, werden viele Parameter in Rot angezeigt. Diese Farbe ist ein Alarm, aber hier ist die Sache. Sie starten den Prozess auf Hunderten von Hosts. Wenn 99 von ihnen erfolgreich funktionieren und einer nicht, meldet Tower einen Prozessfehler. Er wird eine leuchtend rote Markierung auf dem Bildschirm platzieren, die diese Arbeit illustriert. Keine Panik, aber versuchen Sie herauszufinden, warum dieser einzelne Knoten nicht funktioniert. Wenn Sie auf den Puppet Master-Bildschirm schauen und 99 grüne und ein rotes Licht sehen, denken Sie, dass alles in Ordnung ist, das System funktioniert einwandfrei. Tower ist strenger, aber weniger informativ über Fehlermeldungen. Vielleicht wird dieses Manko in zukünftigen Versionen von Ansible beseitigt, aber versuchen Sie zunächst, die Ursache des Alarms herauszufinden, und erinnern Sie sichdass ein solcher Alarm nichts Kritisches an sich tragen kann - nur auf diese Weise meldet das System einen Fehler auf einem Host.

Seien Sie vorsichtig, wenn Sie temporäre Hosts haben, die nicht immer online sind. Zum Beispiel hat mein System mehrere Laptops. Wir verwalten sie mit Ansible Tower auf die gleiche Weise wie permanente Hosts. Da es sich jedoch um mobile Geräte handelt, sind sie nicht immer im Netzwerk vorhanden. Wenn Sie bei der Ausführung von Standardprozessen temporäre Hosts verwenden, der Tower diese jedoch beim Starten des Systems im Netzwerk nicht erkennt, werden sofort ein Alarm und eine Prozessfehlermeldung auf dem Bildschirm angezeigt. Tower ist sich nicht bewusst, dass diese Laptops derzeit ausgeschaltet sind. Dies ist kein Problem. Denken Sie jedoch daran, dass eine solche Situation eine Alarmmeldung auslösen kann.

Es gibt eine gute Möglichkeit, die Tower-API zu verwenden. Wenn der Laptop im Rahmen des Standard-Systemstartvorgangs hochfährt, teilt er Tower mithilfe der API mit: „Hey, ich bin hier, gibt es Arbeit für mich?“. Danach sucht der Tower nach Aufgaben für diesen bestimmten Computer, weil weiß, dass sie online ist.

Eine andere Sache, mit der wir anfänglich Probleme hatten, war die Ausführung von Paralleloperationen. Standardmäßig verwendet Ansible 5 parallele Hosts, um einen Job auszuführen. Daher dauert der Start derselben geplanten Arbeit für 100 Computer pro Host bis zu 20 Minuten, indem die Parameter der Hauptkonfiguration überprüft werden. Daher starten wir zuerst die Konfiguration auf 5 Hosts, dann auf weiteren 5, weiteren 5 und so weiter. Dieser Umstand machte uns zunächst sehr nervös, da die Bereitstellung des Systems auf 50 Hosts innerhalb von 2 Stunden erfolgte. Die Lösung für dieses Problem lautet wie folgt.
Stellen Sie einfach die Anzahl der parallelen Hosts auf dem Ansible Tower-Server auf 5 ein. Da 150 Hosts gleichzeitig ausgeführt werden, setze ich diesen Wert auf 25. Danach wurden beispielsweise 6 Patches recht schnell installiert. Wenn Sie möchten, können Sie diesen Parameter auf 50 einstellen - alles hängt davon ab, welche Rechenleistung und wie viel RAM Sie haben. Auf diese Weise können Sie mit Tower die Ausführung paralleler Prozesse an Ihre Bedürfnisse anpassen.



Wenn Sie Fragen zum Thema des Berichts haben, wenden Sie sich bitte an die angegebenen Ansprechpartner. Sie sehen die E-Mail-Adresse, an die Sie eine E-Mail senden können, in der das Problem beschrieben wird, das beim Wechsel von Puppet zu Ansible aufgetreten ist. Ich werde versuchen, Ihnen so schnell wie möglich zu antworten. Ich danke Ihnen für Ihre Teilnahme und wünsche Ihnen eine erfolgreiche Migration!

Ein bisschen Werbung :)


Vielen Dank für Ihren Aufenthalt bei uns. Gefällt dir unser Artikel? Möchten Sie weitere interessante Materialien sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder Ihren Freunden Cloud-basiertes VPS für Entwickler ab 4,99 US-Dollar empfehlen , ein einzigartiges Analogon von Einstiegsservern, das von uns für Sie erfunden wurde: Die ganze Wahrheit über VPS (KVM) E5-2697 v3 (6 Kerne) 10 GB DDR4 480 GB SSD 1 Gbit / s ab 19 $ oder wie teilt man den Server? (Optionen sind mit RAID1 und RAID10, bis zu 24 Kernen und bis zu 40 GB DDR4 verfügbar).

Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur wir haben 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2,6 GHz 14C 64 GB DDR4 4 x 960 GB SSD 1 Gbit / s 100 TV von 199 US-Dollar in den Niederlanden!Dell R420 - 2x E5-2430 2,2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbit / s 100 TB - ab 99 US-Dollar! Lesen Sie, wie Sie eine Infrastruktur aufbauen Klasse C mit Dell R730xd E5-2650 v4-Servern für 9.000 Euro für einen Cent?

All Articles