Der Nationale Informationsdienst für Satellitendaten zur Umwelt (NESDIS) hat seine Kosten für das Management von Red Hat Enterprise Linux (RHEL) um 35 % gesenkt, indem er von Puppet Enterprise auf Ansible Tower umgestiegen ist. In diesem Video der Kategorie „Wie wir es gemacht haben“ erläutert Systemingenieur Michael Rau die Gründe für diese Migration, teilt nützliche Tipps und Erfahrungen, die er bei dem Übergang von einem SCM zu einem anderen gesammelt hat.
In diesem Video erfahren Sie:
- wie Sie der Führungsebene die Sinnhaftigkeit des Wechsels von Puppet Enterprise zu Ansible Tower erklären;
- welche Strategien Sie für einen möglichst reibungslosen Übergang verwenden sollten;
- Tipps zur Transkodierung von PE-Manifests in Ansible Playbooks;
- Empfehlungen für die optimale Installation von Ansible Tower.
Hallo zusammen, mein Name ist Michael Rau, ich bin Senior Systemingenieur bei ActioNet, das für die National Oceanic and Atmospheric Administration (NOAA) im NESDIS-Dienst tätig ist. Heute sprechen wir über die Migration - meine eigenen Erfahrungen beim Wechsel von Puppet Enterprise zu Ansible Tower. Das Thema dieser Präsentation besteht darin, meine „Narben“ zu zeigen, die nach dem Übergang zu Beginn des Jahres geblieben sind. Ich möchte teilen, was ich aus diesem Prozess gelernt habe. Wenn Sie Ähnliches angehen, können Sie auf Basis meiner Erfahrungen den Übergang ohne viel Mühe durchführen.
Sie sehen Folien ähnlich dieser zu Beginn jeder Präsentation auf der Ansible Fest. Diese Folie beschreibt die Automatisierungsgeschichte meines Unternehmens. Ich bin kein Neuling, da ich Puppet/Puppet Enterprise seit 2007 nutze. Ich habe 2016 mit Ansible begonnen, und mich, wie viele andere Benutzer dieses Produkts, haben die „Tricks“ in der Befehlszeile und die einfachen Playbooks angezogen. Ende 2017 habe ich mein Management um ernsthafte Gründe für den Wechsel zu Ansible Tower gebeten. In einer Minute werde ich die Gründe erläutern, die mich zu diesem Schritt bewegt haben. Nach der Zustimmung des Managements benötigte es einige Monate, um den Plan umzusetzen, und ich vollzog den Wechsel im Januar-Februar dieses Jahres. Also haben wir vollständig auf Puppet verzichtet zugunsten von Ansible, und das ist großartig.
Was mich an Ansible am meisten fasziniert, ist die Möglichkeit, Rollen (roles) und Playbooks zu schreiben und zu verwenden. Rollen eignen sich hervorragend für die Erstellung verschiedener, aber zusammenhängender Aufgaben (tasks) und für die Ablage aller relevanten Daten an einem Ort. Ein Playbook ist ein YAML-Syntaxdatei, die die Aktionen für einen oder mehrere Hosts beschreibt. Ich präsentiere diese Möglichkeiten vor allem Softwareentwicklern. Ansible Tower ermöglicht es zu sagen: „Nein, Sie haben keinen Shell-Zugriff, aber ich gebe Ihnen die Möglichkeit, alle Tower-Prozesse zu starten und den Dienst bei Bedarf neu zu starten.“ Ich werde Ihnen von der Arbeitsumgebung und der verwendeten Hardware erzählen.
Es handelt sich um ein nationales LAN mit 7 physischen Standorten, die über eine Cloud-MPLS verbunden sind, 140 RHEL-Server, von denen 99 % virtuell (vSphere) sind, SuperMicro-Hardware, NexentaStore-Netzwerkspeicher, eine Reihe von Cisco-, Arista- und Cumulus-Switches sowie Fortinet UTM für einheitliches Bedrohungsmanagement an jedem Standort.
Ein nationales Netzwerk bedeutet, dass ich alle Informationssicherheitsmaßnahmen einhalten muss, die durch gesetzliche Bestimmungen vorgeschrieben sind. Sie sollten beachten, dass Puppet Enterprise die meisten der bei uns verwendeten Geräte nicht unterstützt. Wir sind gezwungen, kostengünstige Hardware zu verwenden, da staatliche Stellen Schwierigkeiten mit der Finanzierung dieser Ausgaben haben. Daher kaufen wir SuperMicro-Hardware und bauen unsere Geräte aus einzelnen Komponenten zusammen, deren Wartung durch Regierungsverträge garantiert ist. Wir verwenden Linux, und dies ist einer der wichtigen Gründe für den Umstieg auf Ansible.
Unsere Geschichte mit Puppet ist folgende.
Im Jahr 2007 hatten wir ein kleines Netzwerk von 20-25 Knoten, auf dem wir Puppet implementierten. In der Regel bestanden diese Knoten einfach aus „Kisten“ von RedHat. 2010 begannen wir, das Webinterface Puppet Dashboard für 45 Knoten zu nutzen. Da das Netzwerk weiter wuchs, migrierten wir 2014 auf PE 3.3, indem wir das Manifest für 75 Knoten vollständig umschrieben. Das musste so gemacht werden, weil Puppet gerne die Spielregeln ändert, und in diesem Fall änderten sie die Sprache komplett. Ein Jahr später, als die Unterstützung für die dritte Version von Puppet Enterprise eingestellt wurde, mussten wir auf PE 2015.2 migrieren. Wir mussten erneut das Manifest für die neuen Server umschreiben und eine Lizenz für 100 Knoten im Voraus erwerben, obwohl wir zu diesem Zeitpunkt nur 85 Knoten hatten.
Es vergingen nur 2 Jahre, und wir mussten erneut viel Aufwand für den Übergang zu der neuen Version PE 2016.4 leisten. Wir kauften eine Lizenz für 300 Knoten, obwohl wir nur 130 hatten. Wir mussten erneut erhebliche Änderungen am Manifest vornehmen, da die neue Version der Sprache eine andere Syntax als die Version von 2015 hatte. Letztendlich wechselte unsere SCM von einem Versionskontrollsystem SVN zu Bitbucket (Git). So verliefen unsere „Beziehungen“ zu Puppet.
Also musste ich der Geschäftsleitung erklären, warum wir zu einer anderen SCM wechseln mussten, und verwendete dabei folgende Argumente. Erstens – die hohen Kosten des Services. Ich sprach mit den Leuten von RedHat, und sie sagten, dass die Wartung eines Netzwerks von 300 Knoten mit Ansible Tower nur die Hälfte der Kosten von Puppet Enterprise beträgt. Wenn man noch Ansible Engine kauft, wird der Preis ungefähr gleich sein, aber man erhält dabei viel mehr Funktionen als bei PE. Da wir ein staatliches Unternehmen sind, das aus Mitteln des Bundes finanziert wird, ist das ein erhebliches Argument.
Das zweite Argument ist die Universalität. Puppet unterstützt nur die Hardware, auf der der Puppet-Agent installiert ist. Das bedeutet, dass auf allen Switches der Agent installiert werden muss, und er muss in der neuesten Version vorliegen. Und wenn einige Ihrer Switches eine Version unterstützen, andere jedoch eine andere, müssen Sie die neue Version des PE-Agenten auf diesen installieren, um sicherzustellen, dass sie alle in einem einzigen SCM-System arbeiten können.
Das Ansible Tower-System funktioniert anders, da es keine Agenten hat, sondern Module, die Cisco-Switches und andere Switches unterstützen. Diese SCM unterstützt Qubes OS, Linux und 4.NET UTM. Ansible Tower unterstützt auch die auf dem Illumos-Kernel basierenden NexentaStore-Netzwerkspeicher-Controller – ein Open-Source-Betriebssystem auf Unix-Basis. Das ist eine sehr geringe Unterstützung, aber Ansible Tower bietet sie dennoch.
Das dritte Argument, das für mich und unsere Verwaltung sehr wichtig ist, ist die Benutzerfreundlichkeit. Ich habe über 10 Jahre lang Module und Manifestcode von Puppet erlernt, aber Ansible innerhalb einer Woche verstanden, da diese SCM viel einfacher zu bedienen ist. Wenn Sie ausführbare Dateien ausführen, und natürlich, wenn Sie es nicht unnötig tun, gibt es vernünftige und reaktionsschnelle Handler. Playbook-Skripte, die auf YAML basieren, zeichnen sich durch eine einfache Einarbeitung und schnelle Nutzung aus. Selbst diejenigen, die noch nie von YAML gehört haben, können die Skripte einfach lesen und leicht verstehen, wie es funktioniert.
Um ehrlich zu sein, ist Puppet viel komplizierter für Ihre Arbeit als Entwickler, da es auf der Verwendung von Puppet Master basiert. Dies ist der einzige Computer, der das Recht hat, mit Puppet-Agenten zu kommunizieren. Wenn Sie Änderungen an einem Manifest vorgenommen haben und Ihren Code testen möchten, müssen Sie den Code für Puppet Master neu schreiben, das heißt, die Datei Puppet-master /etc/hosts so konfigurieren, dass alle Clients verbunden werden, und den Puppet Server-Dienst starten. Erst danach können Sie die Netzwerkgeräte auf einem Host testen. Das ist ein ziemlich schmerzhafter Prozess.
Bei Ansible ist alles viel einfacher. Alles, was Sie tun müssen, ist, Code für den Computer zu entwickeln, der per SSH-Protokoll mit dem getesteten Host kommunizieren kann. Damit ist es viel einfacher zu arbeiten.
Ein weiterer großer Vorteil von Ansible Tower ist die Möglichkeit, bereits vorhandene Unterstützungssysteme zu nutzen und die bestehende Hardwarekonfiguration beizubehalten. Diese SCM verwendet ohne zusätzliche Maßnahmen alle verfügbaren Informationen über Ihre Infrastruktur und Hardware, virtuelle Maschinen, Server usw. Sie kann mit Ihren RH Satellite-Servern kommunizieren, wenn vorhanden, und bietet Ihnen eine Integration, die Sie bei der Arbeit mit Puppet niemals erhalten werden.
Eine weitere wichtige Sache ist die detaillierte Kontrolle. Sie wissen, dass Puppet ein modulares System ist, eine Client-Server-Anwendung, daher müssen Sie die bestehenden Aspekte der Funktionsweise aller Ihrer Maschinen in einem langen Manifest definieren. Dabei muss der Zustand jedes einzelnen Elements des Systems alle halbe Stunde getestet werden – dies ist der Standardzeitraum. So funktioniert Puppet.
Tower befreit Sie davon. Sie können ohne Einschränkungen die unterschiedlichsten Prozesse auf unterschiedlichster Hardware ausführen, grundlegende Arbeiten erledigen, andere wichtige Prozesse starten, die Systemsicherheit konfigurieren und mit Datenbanken arbeiten. Sie können alles tun, was in Puppet Enterprise mit bestimmten Schwierigkeiten verbunden ist. Wenn Sie zum Beispiel eine Konfiguration auf einem Host durchgeführt haben, dauert es eine Weile, bis die Änderungen auf den anderen Hosts wirksam werden. Bei Ansible treten alle Änderungen gleichzeitig in Kraft.
Schließlich betrachten wir das Sicherheitsmodul. In Ansible Tower ist es einfach großartig implementiert, mit großer Präzision und Sorgfalt. Sie können Benutzern den Zugang zu bestimmten Diensten oder bestimmten Hosts gewähren. So handhabe ich es mit meinen Mitarbeitern, die an Windows gewöhnt sind, indem ich ihren Zugang zur Linux-Shell einschränke. Ich sorge dafür, dass sie nur Zugang zu Tower haben, um die Arbeiten und Dienste auszuführen, die in ihren Kompetenzbereich fallen.
Lassen Sie uns die Schritte betrachten, die Sie im Voraus unternehmen sollten, um den Übergang zu Ansible Tower zu erleichtern. Zunächst müssen Sie Ihre Hardware vorbereiten. Wenn einige Komponenten Ihrer Infrastruktur noch nicht in der Datenbank vorhanden sind, müssen diese hinzugefügt werden. Es gibt Systeme, die ihre Eigenschaften nicht ändern und deshalb in der Puppet-Datenbank fehlen, aber wenn Sie diese nicht vor dem Wechsel zu Tower hinzufügen, werden Sie einige Vorteile verlieren. Es könnte sich um eine "schmutzige", vorläufige Datenbank handeln, aber sie sollte Informationen über alles enthalten, was Ihnen an Hardware zur Verfügung steht. Daher sollten Sie ein dynamisches Hardware-Skript schreiben, das automatisch alle Infrastrukturänderungen in die Datenbank einpflegt, damit Ansible weiß, welche Hosts im neuen System vorhanden sein sollten. Sie müssen dieser SCM nicht mitteilen, welche Hosts Sie hinzugefügt haben und welche nicht mehr existieren, denn all das wird sie automatisch herausfinden. Je mehr Daten in der Datenbank vorhanden sind, desto nützlicher und flexibler wird Ansible. Es funktioniert so, als würde es einfach den Status der Hardware aus der Datenbank abrufen.
Nehmen Sie sich etwas Zeit, um sich mit der Arbeit in der Ansible-Befehlszeile vertraut zu machen. Führen Sie einige spezielle Befehle aus, um die Funktionsweise des Hardware-Skripts zu überprüfen, schreiben und führen Sie einige einfache, aber nützliche Playbook-Szenarien aus, verwenden Sie Jinja2-Vorlagen, wo es zutreffend ist. Versuchen Sie, eine Rolle und ein Szenario für einen komplexen, mehrstufigen Prozess zu schreiben, indem Sie eine standardisierte, häufige Hardwarekonfiguration verwenden. Experimentieren Sie mit diesen Dingen und testen Sie, wie sie funktionieren. So werden Sie lernen, mit den Werkzeugen zu arbeiten, die für die Erstellung von Bibliotheken in Tower verwendet werden. Ich habe bereits erwähnt, dass es bei mir etwa 3 Monate gedauert hat, um mich auf den Übergang vorzubereiten. Ich denke, basierend auf meiner Erfahrung werden Sie das schneller schaffen. Betrachten Sie diese Zeit nicht als verloren, da Sie später die Vorteile der geleisteten Arbeit spüren werden.
Als Nächstes müssen Sie entscheiden, was Sie von Ansible Tower erwarten und was dieses System für Sie tun soll.
Benötigen Sie die Bereitstellung eines Systems auf leerer Hardware oder auf leeren virtuellen Maschinen? Oder möchten Sie die ursprünglichen Arbeitsbedingungen und Einstellungen der vorhandenen Hardware beibehalten? Dies ist ein sehr wichtiger Aspekt für die Arbeit staatlicher Unternehmen, daher sollten Sie sicher sein, dass es Ihnen gelingt, die Migration durchzuführen und Ansible in der bestehenden Konfiguration bereitzustellen. Bestimmen Sie die administrativen Routinen, die Sie automatisieren möchten. Klären Sie, ob Sie spezifische Anwendungen und Dienste auf dem neuen System bereitstellen müssen. Erstellen Sie eine Liste der Dinge, die Sie tun möchten, und setzen Sie Prioritäten.
Dann beginnen Sie mit dem Schreiben von Skripten und Rollen, die die von Ihnen geplanten Aufgaben ausführen. Fügen Sie sie in Projects zusammen, einer logischen Sammlung passender Playbook-Skripte. Jedes Project wird sich auf ein einzelnes Git-Repository oder ein anderes Repository beziehen, abhängig davon, welchen Code-Manager Sie verwenden. Sie können Playbook-Skripte und -Verzeichnisse verwalten, indem Sie sie manuell in den Project Base Path auf dem Tower-Server platzieren oder das Playbook in ein beliebiges von Tower unterstütztes Quellcodeverwaltungssystem (SCM) einfügen, einschließlich Git, Subversion, Mercurial und Red Hat Insights. Innerhalb eines Projects können Sie so viele Skripte unterbringen, wie Sie möchten. Beispielsweise habe ich ein grundlegendes Project erstellt, in dem ich ein Skript für die grundlegenden Elemente von RedHat, ein Skript für das Linux-Basissystem und Skripte für andere grundlegende Metriken untergebracht habe. So beinhaltete ein Project verschiedene Rollen und Skripte, die aus einem einzigen Git-Repository verwaltet wurden.
Führen Sie all diese Dinge über die Kommandozeile aus, das ist eine gute Möglichkeit, um ihre Funktionalität zu überprüfen. So bereiten Sie sich auf die Installation von Tower vor.
Lassen Sie uns ein wenig über die Transkodierung des Puppet-Manifests sprechen, denn ich habe viel Zeit damit verbracht, bis ich verstand, was tatsächlich notwendig war.
Wie ich bereits erwähnt habe, speichert Puppet alle Einstellungen und Hardwareparameter in einem langen Manifest, das alles enthält, was dieses SCM tun soll. Bei der Migration müssen Sie nicht alle Ihre Aufgaben in eine Liste packen; denken Sie stattdessen über die Struktur des neuen Systems nach: Rollen, Skripte, Tags, Gruppen und was dort enthalten sein sollte. Einige der autonomen Netzwerkelemente sollten in Gruppen zusammengefasst werden, für die Skripte erstellt werden können. Komplexere Infrastrukturelemente, die eine große Menge an Ressourcen beanspruchen, einschließlich eigenständiger Klassen, können in Rollen gebündelt werden. Bevor Sie migrieren, müssen Sie dies klären. Wenn Sie große Rollen oder Skripte erstellen, die nicht auf einen Bildschirm passen, sollten Sie Tags verwenden, um einzelne Teile der Infrastruktur erfassen zu können.
18:00
Ein wenig Werbung 🙂
Danke, dass Sie bei uns bleiben. Gefallen Ihnen unsere Artikel? Möchten Sie mehr interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder uns Freunden empfehlen, , ein einzigartiges Äquivalent zu Einsteigerservern, das wir für Sie entwickelt haben: (es sind Optionen mit RAID1 und RAID10 bis zu 24 Kernen und bis zu 40GB DDR4 verfügbar).
Dell R730xd ist im Equinix Tier IV Rechenzentrum in Amsterdam doppelt so günstig? Nur bei uns in den Niederlanden! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ab $99! Lesen Sie, wie
Quelle: habr.com
