Die Nationale Informationsstelle für Satellitendaten zur Umwelt (NESDIS) hat ihre Verwaltungskosten für Red Hat Enterprise Linux (RHEL) um 35 % gesenkt, indem sie 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 und teilt nützliche Tipps sowie Erfahrungen, die er beim Wechsel von einem SCM zu einem anderen gesammelt hat.
In diesem Video erfahren Sie:
- wie Sie der Unternehmensleitung die Sinnhaftigkeit des Umstiegs von Puppet Enterprise auf Ansible Tower darlegen;
- welche Strategien für einen möglichst reibungslosen Übergang verwendet werden sollten;
- Tipps zur Transkodierung von PE-Manifests in ein Ansible-Playbook;
- Empfehlungen für die optimale Installation von Ansible Tower.
Hallo zusammen, ich bin Michael Rau, Senior Systems Engineer bei ActioNet, das für die National Oceanic and Atmospheric Administration (NOAA) und den NESDIS-Dienst tätig ist. Heute werden wir über das Thema String-Trimming sprechen – meine persönlichen Erfahrungen mit der Migration von Puppet Enterprise zu Ansible Tower. Ziel dieser Präsentation ist es, meine "Narben" zu zeigen, die nach diesem Wechsel zu Beginn des Jahres geblieben sind. Ich möchte teilen, was ich aus diesem Prozess gelernt habe. Wenn Sie also Ähnliches in Angriff nehmen, können Sie von meinen Erfahrungen profitieren und den Übergang mühelos gestalten.
Sie sehen Folien wie diese zu Beginn jeder Präsentation auf dem Ansible Fest. Diese Folie erzählt die Geschichte der Automatisierung in meinem Unternehmen. Ich bin kein Neuling in diesem Bereich, da ich seit 2007 mit Puppet/Puppet Enterprise arbeite. 2016 habe ich begonnen, mit Ansible zu arbeiten, und wie viele andere Nutzer dieses Produkts hat mich die Möglichkeit, 'Tricks' über die Kommandozeile auszuführen und einfache Skripte (Playbooks) zu erstellen, angezogen. Ende 2017 habe ich mein Management aus ernsthaften Gründen um die Genehmigung für den Umstieg auf Ansible Tower gebeten. In einer Minute werde ich Ihnen die Gründe darlegen, die mich zu diesem Schritt bewegt haben. Nachdem die Genehmigung erteilt wurde, dauerte es noch einige Monate, bis die Umsetzung abgeschlossen war, und ich habe den Wechsel im Januar/Februar dieses Jahres vollzogen. So haben wir vollständig auf Ansible umgestellt und uns von Puppet verabschiedet – und das ist eine großartige Sache.
Was mich an Ansible am meisten fasziniert, ist die Möglichkeit, Rollen und Playbooks zu erstellen und zu nutzen. Rollen eignen sich hervorragend zur Erstellung verschiedener, aber zusammenhängender Aufgaben und zur Bündelung aller relevanten Daten an einem Ort. Ein Playbook ist ein YAML-Syntax-Dokument, das die Aktionen für einen oder mehrere Hosts beschreibt. Ich erläutere diese Möglichkeiten in erster Linie Softwareentwicklern. Ansible Tower ermöglicht es, zu sagen: „Nein, Sie haben keinen Zugriff auf die Shell, aber ich gebe Ihnen die Möglichkeit, alle Tower-Prozesse zu starten und den Dienst nach Bedarf neu zu starten.“ Ich werde Ihnen von der Arbeitsumgebung und der von uns verwendeten Hardware erzählen.
Dies ist ein föderiertes LAN, das aus 7 physischen Standorten besteht, die über ein cloudbasiertes MPLS verbunden sind, 140 RHEL-Server, von denen 99 % virtualisiert sind (vSphere), SuperMicro-Hardware, NexentaStore-Netzwerkspeicher, ein Set von Cisco-, Arista- und Cumulus-Switches sowie Fortinet UTM zur einheitlichen Bedrohungsverwaltung an jedem Standort.
Das föderale Netzwerk bedeutet, dass ich alle Informationsschutzmaßnahmen, die durch Gesetze vorgegeben sind, einhalten muss. Es ist wichtig zu beachten, dass Puppet Enterprise die meisten der von uns verwendeten Geräte nicht unterstützt. Wir sind gezwungen, kostengünstige Hardware zu verwenden, da staatliche Stellen mit finanziellen Schwierigkeiten konfrontiert sind. Daher kaufen wir Hardware der Marke SuperMicro und stellen unsere Geräte aus einzelnen Komponenten zusammen, deren Wartung durch Regierungsverträge garantiert ist. Wir nutzen Linux, und das ist einer der wichtigen Gründe für unseren Umstieg auf Ansible.
Unsere Geschichte mit Puppet sieht so aus.
Im Jahr 2007 verfügten wir über ein kleines Netzwerk von 20-25 Knoten, in dem wir Puppet implementierten. Diese Knoten waren hauptsächlich einfach RedHat-„Boxen“. 2010 begannen wir, die Web-Oberfläche Puppet Dashboard für 45 Knoten zu verwenden. Als das Netzwerk weiter wuchs, wechselten wir 2014 zu PE 3.3 und führten einen vollständigen Übergang durch, indem wir das Manifest für 75 Knoten neu schrieben. Dies war notwendig, da Puppet bekannt dafür ist, die Spielregeln zu ändern, und in diesem Fall hatten sie die Sprache komplett umgestellt. 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. Auch hier mussten wir das Manifest für die neuen Server erneut anpassen und eine Lizenz für 100 Knoten erwerben, obwohl wir zu diesem Zeitpunkt nur 85 Knoten hatten.
Es sind nur 2 Jahre vergangen, und wir mussten erneut umfangreiche Arbeiten durchführen, um auf die neue Version PE 2016.4 umzusteigen. Wir kauften eine Lizenz für 300 Knoten, obwohl wir nur 130 hatten. Erneut mussten wir erhebliche Änderungen am Manifest vornehmen, da die neue Version der Sprache eine andere Syntax hatte als die Version von 2015. Schließlich wechselte unser SCM-System von SVN auf Bitbucket (Git). So gestalteten sich unsere „Beziehungen“ zu Puppet.
Ich musste dem Management erklären, warum wir auf ein anderes SCM umsteigen sollten, und habe dabei folgende Argumente verwendet. Erstens – der hohe Preis des Services. Ich habe mit den Leuten von RedHat gesprochen, und sie haben gesagt, dass die Kosten für die Verwaltung eines Netzwerks mit 300 Knoten über Ansible Tower nur die Hälfte der Kosten von Puppet Enterprise betragen. Wenn man noch Ansible Engine hinzukauft, werden die Kosten ungefähr gleich sein, aber man erhält dabei deutlich mehr Funktionen als bei PE. Da wir ein staatliches Unternehmen sind, das aus Bundesmitteln finanziert wird, ist das ein gewichtiges Argument.
Das zweite Argument ist die Vielseitigkeit. Puppet unterstützt nur die Hardware, auf der ein Puppet-Agent vorhanden ist. Das bedeutet, dass auf allen Switches ein Agent installiert werden muss, und zwar in der neuesten Version. Wenn einige Ihrer Switches eine Version unterstützen und andere eine andere, müssen Sie die neue Version des PE-Agenten auf denen installieren, damit sie alle in einem SCM-System arbeiten können.
Das Ansible Tower-System funktioniert anders, da es keine Agenten benötigt, sondern Module hat, die Cisco-Switches und andere Switches unterstützen. Diese SCM unterstützt Qubes OS, Linux und 4.NET UTM. Ansible Tower unterstützt ebenfalls NexentaStore-Netzwerkspeicher-Controller, die auf dem Illumos-Kernel basieren – einem Open-Source-Betriebssystem auf Unix-Basis. Dies ist zwar eine sehr begrenzte Unterstützung, aber Ansible Tower bietet sie dennoch an.
Das dritte Argument, das sowohl für mich als auch für unsere Verwaltung von großer Bedeutung ist, ist die einfache Einarbeitung. Ich habe 10 Jahre lang mit Puppet-Modulen und Manifest-Code gearbeitet, aber Ansible habe ich in einer Woche gelernt, da mit dieser SCM viel einfacher zu arbeiten ist. Wenn Sie ausführbare Dateien ausführen, natürlich, wenn Sie dies nicht unbedingt vermeiden, arbeiten vernünftige und reaktionsschnelle Handler mit ihnen. Die auf YAML basierenden Playbooks zeichnen sich durch einfache Erlernbarkeit und schnelle Nutzung aus. Selbst wenn man noch nie von YAML gehört hat, kann man einfach die Skripte lesen und leicht verstehen, wie sie funktionieren.
Ehrlich gesagt macht Puppet Ihre Arbeit als Entwickler viel komplizierter, da es auf der Verwendung von Puppet Master basiert. Das ist die einzige Maschine, die das Recht hat, mit Puppet-Agenten zu kommunizieren. Wenn Sie Änderungen am Manifest vorgenommen haben und Ihren Code testen möchten, müssen Sie den Code für den Puppet Master umschreiben, d.h. die Datei des Puppet Masters /etc/hosts so einrichten, dass alle Clients verbunden werden können, und den Puppet-Server starten. Erst danach können Sie die Funktionalität der 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 die Maschine zu entwickeln, die über SSH mit dem zu testenden Host kommunizieren kann. Damit lässt sich viel einfacher arbeiten.
Ein weiterer großer Vorteil von Ansible Tower ist die Möglichkeit, Ihr bestehendes Support-System zu nutzen und die vorhandene Hardware-Konfiguration beizubehalten. Dieses SCM verwendet ohne zusätzliche Maßnahmen alle verfügbaren Informationen über Ihre Infrastruktur und Ausrüstung, einschließlich virtueller Maschinen, Server usw. Es kann mit Ihren RH Satellite-Servern kommunizieren, falls vorhanden, und bietet Ihnen eine Integration, die Sie mit Puppet niemals erreichen würden.
Ein weiterer wichtiger Punkt ist die detaillierte Kontrolle. Sie wissen, dass Puppet ein modulares System ist, eine Client-Server-Anwendung, weshalb Sie alle Aspekte der Funktionalität Ihrer Maschinen in einem langen Manifest definieren müssen. Dabei muss der Zustand jedes einzelnen Systemelements alle 30 Minuten getestet werden – dies ist der Standardzeitraum. So funktioniert Puppet.
Tower befreit Sie von diesem Problem. Sie können uneingeschränkt verschiedene Prozesse auf unterschiedlichsten Geräten durchführen, die Hauptarbeit erledigen, andere wichtige Prozesse starten, das Sicherheitssystem konfigurieren und mit Datenbanken arbeiten. Alles, was in Puppet Enterprise mit bestimmten Schwierigkeiten verbunden ist, können Sie nun einfach erledigen. Wenn Sie beispielsweise eine Konfiguration auf einem Host durchgeführt haben, benötigt es Zeit, bis die Änderungen auf den anderen Hosts wirksam werden. Mit Ansible treten alle Änderungen gleichzeitig in Kraft.
Schließlich betrachten wir das Sicherheitsmodul. In Ansible Tower ist es einfach hervorragend umgesetzt, mit großer Präzision und Sorgfalt. Sie können Benutzern den Zugang zu bestimmten Diensten oder Hosts gewähren. Ich handhabe das so mit meinen Mitarbeitern, die an Windows gewöhnt sind, indem ich ihren Zugang zur Linux-Shell einschränke. Ich gewährleiste ihnen Zugang zu Tower, sodass sie nur die Aufgaben durchführen und nur die Dienste starten können, die in ihren Kompetenzbereich fallen.
Lassen Sie uns die Dinge betrachten, die Sie im Voraus erledigen sollten, um den Übergang zu Ansible Tower zu erleichtern. Zunächst müssen Sie Ihre Hardware vorbereiten. Wenn einige Elemente Ihrer Infrastruktur noch nicht in der Datenbank vorhanden sind, müssen Sie diese dort hinzufügen. Es gibt Systeme, die ihre Eigenschaften nicht ändern und daher in der Puppet-Datenbank fehlen. Wenn Sie diese jedoch nicht vor dem Übergang zu Tower einfügen, verlieren Sie eine Reihe von Vorteilen. Es mag sich um eine "schmutzige" Vorab-Datenbank handeln, aber sie sollte Informationen über all Ihre vorhandene Hardware enthalten. Daher sollten Sie ein dynamisches Hardware-Skript schreiben, das automatisch alle Änderungen in Ihrer Infrastruktur in die Datenbank einpflegt, sodass Ansible weiß, welche Hosts im neuen System vorhanden sein sollen. Sie müssen dieser SCM nicht mitteilen, welche Hosts Sie hinzugefügt haben und welche nicht mehr existieren, da es dies alles automatisch erfährt. Je mehr Daten in der Datenbank vorhanden sind, desto nützlicher und flexibler wird Ansible. Es funktioniert so, als würde es einfach den Barcode des Hardwarezustands aus der Datenbank ablesen.
Nehmen Sie sich etwas Zeit, um die Arbeitsweise der Kommandozeile in Ansible kennenzulernen. Führen Sie einige spezifische Befehle aus, um das Funktionieren des Hardware-Skripts zu testen, schreiben und führen Sie einfache, aber nützliche Playbook-Skripte aus, und verwenden Sie Jinja2-Vorlagen, wo es sinnvoll ist. Versuchen Sie, eine Rolle und ein Skript für einen komplexen mehrstufigen Prozess zu erstellen, indem Sie eine gängige Standardhardwarekonfiguration nutzen. Experimentieren Sie mit diesen Elementen und testen Sie deren Funktionsweise. So lernen Sie den Umgang mit den Werkzeugen zur Erstellung von Bibliotheken, die in Tower verwendet werden. Ich hatte bereits erwähnt, dass meine Vorbereitung auf den Umstieg etwa 3 Monate in Anspruch nahm. Ich denke, basierend auf meiner Erfahrung werden Sie in der Lage sein, dies schneller zu erreichen. Betrachten Sie diese Zeit nicht als verloren, da Sie später alle Vorteile Ihrer Arbeit spüren werden.
Als Nächstes müssen Sie entscheiden, was Sie von Ansible Tower erwarten und was genau dieses System für Sie leisten soll.
Benötigen Sie die Bereitstellung eines Systems auf leerer Hardware oder auf leeren virtuellen Maschinen? Oder möchten Sie die vorhandenen Betriebsbedingungen und die Konfiguration der aktuellen Hardware beibehalten? Dies ist ein sehr wichtiger Aspekt für die Arbeit von öffentlichen Unternehmen, daher sollten Sie sicherstellen, dass die Migration gelingt und Ansible auf der vorhandenen Konfiguration bereitgestellt werden kann. Bestimmen Sie die routinemäßigen Administrationsprozesse, 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 gewünschten Aufgaben und setzen Sie Prioritäten.
Beginnen Sie dann mit dem Schreiben von Skripten und Rollen, die die von Ihnen geplanten Aufgaben ausführen. Fassen Sie sie in Projekten zusammen, einer logischen Sammlung entsprechender Playbook-Skripte. Jedes Projekt wird sich auf ein separates Git-Repository oder ein anderes Repository beziehen, je nachdem, welchen Code-Manager Sie verwenden. Sie können Playbook-Skripte und -Verzeichnisse verwalten, indem Sie sie manuell im Project Base Path auf dem Tower-Server platzieren oder das Playbook in ein unterstütztes Quellcodeverwaltungssystem (SCM) einfügen, einschließlich Git, Subversion, Mercurial und Red Hat Insights. Innerhalb eines Projekts können Sie beliebig viele Skripte unterbringen. Zum Beispiel habe ich ein grundlegendes Projekt erstellt, in dem ich ein Skript für die grundlegenden RedHat-Elemente, ein Skript für die Linux-Grundlage und Skripte für die anderen Basismetriken untergebracht habe. So enthielt ein Projekt verschiedene Rollen und Skripte, die aus einem einzigen Git-Repository verwaltet wurden.
Führen Sie all diese Dinge über die Befehlszeile aus, das ist eine gute Möglichkeit, 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, bevor ich wirklich verstanden habe, was notwendig ist.
Wie ich bereits erwähnt habe, speichert Puppet alle Konfigurationen und Hardwareparameter in einem langen Manifest, das alles umfasst, was dieses SCM tun soll. Beim Wechsel müssen Sie Ihre Aufgaben nicht in eine Liste quetschen; stattdessen sollten Sie an die Struktur des neuen Systems denken: Rollen, Skripte, Tags, Gruppen und was darin enthalten sein sollte. Einige der autonomen Elemente des Netzwerks sollten in Gruppen zusammengefasst werden, für die Skripte erstellt werden können. Komplexere Infrastruktur-Elemente, die umfangreiche Ressourcen beanspruchen, einschließlich autonomer Klassen, können in Rollen gebündelt werden. Vor der Migration sollten Sie sich darüber im Klaren sein. Wenn Sie umfangreiche Rollen oder Skripte erstellen, die nicht auf einen Bildschirm passen, sollten Sie Tags verwenden, um bestimmte 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 Ihren Freunden empfehlen. , eine einzigartige Alternative zu Einsteiger-Servern, die wir für Sie entwickelt haben: (Verfügbar sind Optionen mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40GB DDR4).
Dell R730xd im Equinix Tier IV Rechenzentrum in Amsterdam zum halben Preis? Nur bei uns in den Niederlanden! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ab 99 $! Lesen Sie darüber
Quelle: habr.com
