Der National Environmental Satellite Data Information Service (NESDIS) hat seine Konfigurationsverwaltungskosten für Red Hat Enterprise Linux (RHEL) durch die Migration von Puppet Enterprise zu Ansible Tower um 35 % gesenkt. In diesem „Wie wir es gemacht haben“-Video erklärt Systemingenieur Michael Rau die Gründe für diese Migration und gibt nützliche Tipps und Erkenntnisse aus der Umstellung von einem SCM auf ein anderes.
In diesem Video erfahren Sie:
- Wie kann man gegenüber dem Management die Machbarkeit eines Wechsels von Puppet Enterprise zu Ansible Tower rechtfertigen?
- Welche Strategien sind anzuwenden, um den Übergang so reibungslos wie möglich zu gestalten?
- Tipps zum Transkodieren von PE-Manifesten in Ansible Playbook;
- Empfehlungen für die optimale Installation von Ansible Tower.
Hallo zusammen, mein Name ist Michael Rau, ich bin Senior Systems Engineer bei ActioNet, das für den NESDIS-Dienst der National Oceanic and Atmospheric Administration (NOAA) arbeitet. Heute werden wir über das Trimmen von Zeichenfolgen sprechen – meine eigene Erfahrung bei der Migration von Puppet Enterprise zu Ansible Tower. Das Thema dieser Präsentation ist es, „einen Blick auf meine Narben zu werfen“, die nach diesem Übergang zu Beginn des Jahres entstanden sind. Ich möchte teilen, was ich durch diesen Prozess gelernt habe. Wenn Sie also so etwas in Angriff nehmen, können Sie mit meiner Erfahrung den Übergang ohne zusätzliche Arbeit schaffen.
Ähnliche Folien sehen Sie zu Beginn jeder Präsentation beim Ansible Fest. Diese Folie beschreibt die Geschichte der Automatisierung meines Unternehmens. Ich bin kein Neuling in diesem Bereich, da ich Puppet/Puppet Enterprise seit 2007 verwende. Ich habe 2016 angefangen, mit Ansible zu arbeiten, und wie viele andere Benutzer dieses Produkts war ich von der Möglichkeit von „Tricks“ über die Befehlszeile und einfache Skripte (Playbooks) fasziniert. Ende 2017 wandte ich mich an mein Management, um mir die triftigen Gründe für den Umzug in den Ansible Tower mitzuteilen. Ich werde Ihnen gleich die Gründe erläutern, die mich zu diesem Schritt bewogen haben. Nachdem ich die Zustimmung des Managements erhalten hatte, dauerte es noch mehrere Monate, bis der Plan fertig war, und ich vollzog den Übergang im Januar/Februar dieses Jahres. Deshalb haben wir Puppet komplett zugunsten von Ansible aufgegeben, und das ist eine großartige Sache.
Was mich an Ansible am meisten fasziniert, ist die Fähigkeit, Rollen und Playbooks zu schreiben und zu verwenden. Rollen eignen sich hervorragend zum Erstellen unterschiedlicher, aber zusammenhängender Aufgaben und zum Speichern aller mit diesen Aufgaben verbundenen Daten an einem Ort. Ein Playbook ist eine YAML-Syntax-Skriptdatei, die Aktionen für einen oder mehrere Hosts beschreibt. Ich informiere Benutzer über diese Funktionen, vor allem Softwareentwickler. Ansible Tower gibt Ihnen die Möglichkeit zu sagen: „Nein, Sie haben keinen Shell-Zugriff, aber ich gebe Ihnen die Möglichkeit, alle Tower-Prozesse auszuführen und den Dienst neu zu starten, wenn Sie ihn brauchen.“ Ich erzähle Ihnen etwas über das Arbeitsumfeld und die von uns verwendete Ausrüstung.
Dabei handelt es sich um ein Bundes-LAN, 7 physische Standorte, die über Cloud-MPLS verbunden sind, 140 RHEL-Server, davon 99 % virtuell (vSphere), SuperMicro-Hardware, NexentaStore-Netzwerkspeicher, eine Reihe von Cisco-, Arista- und Cumulus-Switches und ein einheitliches Bedrohungsmanagement von Fortinet UTM Tools auf jeder Website.
Aufgrund des Bundesnetzes muss ich alle gesetzlich vorgesehenen Informationssicherheitsmaßnahmen anwenden. Bitte beachten Sie, dass Puppet Enterprise den Großteil der von uns verwendeten Hardware nicht unterstützt. Wir sind gezwungen, Budget-Hardware zu verwenden, weil staatliche Stellen Probleme haben, diesen Ausgabenposten zu finanzieren. Deshalb kaufen wir SuperMicro-Hardware und bauen unsere Geräte aus Einzelteilen zusammen, deren Wartung durch staatliche Verträge garantiert ist. Wir nutzen Linux und das ist einer der wichtigen Gründe für den Umstieg auf Ansible.
Unsere Geschichte mit Puppet ist wie folgt.
Im Jahr 2007 hatten wir ein kleines Netzwerk von 20 bis 25 Knoten, in dem wir Puppet einsetzten. Im Grunde waren diese Knoten nur RedHat-„Boxen“. Im Jahr 2010 begannen wir, die Puppet Dashboard-Weboberfläche 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 mit einer Manifest-Neufassung für 75 Knoten durch. Dies musste getan werden, da Puppet gerne die Spielregeln ändert, und in diesem Fall haben sie die Sprache komplett geändert. Ein Jahr später, als der Support für Version 3 von Puppet Enterprise endete, waren wir gezwungen, auf PE 2015.2 zu migrieren. Wir mussten das Manifest für die neuen Server noch einmal umschreiben und eine Lizenz mit einer Reserve von 100 Knoten erwerben, obwohl wir zu diesem Zeitpunkt nur 85 Knoten hatten.
Es sind erst 2 Jahre vergangen und wir mussten erneut viel Arbeit leisten, um auf die neue Version PE 2016.4 zu migrieren. Wir kauften eine Lizenz für 300 Knoten und hatten nur 130. Wir mussten erneut große Änderungen am Manifest vornehmen, da die neue Version der Sprache eine andere Syntax hatte als die Sprache der Version 2015. Infolgedessen wechselte unser SCM von der SVN-Versionskontrolle zu Bitbucket (Git). Das war unsere „Beziehung“ zu Puppet.
Daher musste ich dem Management mit den folgenden Argumenten erklären, warum wir zu einem anderen SCM wechseln mussten. Der erste ist der hohe Preis des Dienstes. Ich habe mit den Leuten von RedHat gesprochen und sie sagten, dass die Kosten für den Betrieb eines 300-Knoten-Netzwerks mit Ansible Tower halb so hoch sind wie die Kosten für Puppet Enterprise. Wenn Sie auch Ansible Engine kaufen, sind die Kosten ungefähr gleich, aber Sie erhalten viel mehr Funktionen als PE. Da wir ein aus dem Bundeshaushalt finanziertes Staatsunternehmen sind, ist das ein ziemlich schlagkräftiges Argument.
Das zweite Argument ist Vielseitigkeit. Puppet unterstützt nur Hardware, die über einen Puppet-Agenten verfügt. Das bedeutet, dass auf allen Switches ein Agent installiert sein muss, und zwar in der aktuellsten Version. Und wenn einige Ihrer Switches eine Version unterstützen und andere eine andere, müssen Sie eine neue Version des PE-Agenten auf ihnen installieren, damit sie alle im selben SCM-System arbeiten können.
Das Ansible Tower-System funktioniert anders, da es über keine Agenten verfügt, aber über Module verfügt, die Cisco-Switches und alle anderen Switches unterstützen. Dieser SCM unterstützt Qubes OS, Linux und 4.NET UTM. Ansible Tower unterstützt auch NexentaStore-Netzwerkspeichercontroller, die auf dem Illumos-Kernel basieren, einem Open-Source-Betriebssystem auf Unix-Basis. Das ist zwar sehr wenig Unterstützung, aber Ansible Tower leistet es trotzdem.
Das dritte Argument, das sowohl für mich als auch für unsere Verwaltung sehr wichtig ist, ist die Benutzerfreundlichkeit. Ich habe 10 Jahre damit verbracht, Puppet-Module und Manifest-Code zu beherrschen, aber Ansible habe ich innerhalb einer Woche gelernt, weil die Arbeit mit diesem SCM viel einfacher ist. Wenn Sie ausführbare Dateien ausführen, arbeiten intelligente und reaktionsfähige Handler natürlich mit ihnen, es sei denn, Sie tun dies unnötig. YAML-basierte Playbooks sind einfach zu erlernen und schnell zu verwenden. Wer noch nie von YAML gehört hat, kann einfach die Skripte lesen und leicht verstehen, wie es funktioniert.
Ehrlich gesagt erschwert Puppet die Arbeit als Entwickler erheblich, da es auf der Verwendung von Puppet Master basiert. Es ist die einzige Maschine, die mit Puppet-Agenten kommunizieren darf. Wenn Sie Änderungen am Manifest vorgenommen haben und Ihren Code testen möchten, müssen Sie den Code für Puppet Master neu schreiben, d. h. die Puppet Master-Datei /etc/hosts konfigurieren, um alle Clients zu verbinden und den Puppet Server-Dienst zu starten. Erst danach können Sie den Betrieb von Netzwerkgeräten auf einem Host testen. Dies ist eine ziemlich schmerzhafte Prozedur.
In Ansible ist alles viel einfacher. Sie müssen lediglich Code für eine Maschine entwickeln, die über SSH mit dem zu testenden Host kommunizieren kann. Damit lässt sich viel einfacher arbeiten.
Der nächste große Vorteil von Ansible Tower ist die Möglichkeit, Ihr bestehendes Supportsystem zu nutzen und Ihre bestehende Hardwarekonfiguration beizubehalten. Dieser SCM nutzt alle verfügbaren Informationen über Ihre Infrastruktur und Hardware, virtuelle Maschinen, Server usw. ohne zusätzliche Schritte. Es kann mit Ihren RH Satellite-Servern kommunizieren, sofern Sie einen haben, und bietet Ihnen Integrationen, die Sie mit Puppet nie erhalten würden.
Ein weiterer wichtiger Punkt ist die detaillierte Kontrolle. Sie wissen, dass Puppet ein modulares System ist, eine Client-Server-Anwendung, daher müssen Sie die vorhandenen Aspekte aller Ihrer Maschinen in einem langen Manifest definieren. In diesem Fall muss der Zustand jedes einzelnen Elements des Systems jede halbe Stunde getestet werden – dies ist der Standardzeitraum. So funktioniert Puppet.
Tower erspart Ihnen das. Sie können eine Vielzahl von Prozessen ohne Einschränkungen auf einer Vielzahl von Geräten ausführen; Sie können grundlegende Arbeiten ausführen, andere wichtige Prozesse ausführen, ein Sicherheitssystem einrichten und mit Datenbanken arbeiten. In Puppet Enterprise können Sie alles tun, was schwierig ist. Wenn Sie es also auf einem Host konfiguriert haben, dauert es einige Zeit, bis die Änderungen auf den verbleibenden Hosts wirksam werden. In Ansible werden alle Änderungen gleichzeitig wirksam.
Schauen wir uns abschließend noch das Sicherheitsmodul an. Ansible Tower setzt es einfach großartig um, mit großer Präzision und Sorgfalt. Sie können Benutzern Zugriff auf bestimmte Dienste oder bestimmte Hosts gewähren. Ich mache das bei meinen Mitarbeitern, die es gewohnt sind, unter Windows zu arbeiten, und beschränke ihren Zugriff auf die Linux-Shell. Ich stelle sicher, dass sie Zugriff auf Tower haben, sodass sie nur die Arbeit erledigen und nur die Dienste ausführen können, die für sie relevant sind.
Schauen wir uns die Dinge an, die Sie im Voraus tun müssen, um den Übergang zu Ansible Tower zu erleichtern. Zunächst müssen Sie Ihre Ausrüstung vorbereiten. Wenn einige Elemente Ihrer Infrastruktur noch nicht in der Datenbank vorhanden sind, müssen Sie sie dort hinzufügen. Es gibt Systeme, die ihre Eigenschaften nicht ändern und daher nicht in der Puppet-Datenbank enthalten sind. Wenn Sie sie jedoch nicht dort hinzufügen, bevor Sie zu Tower wechseln, verlieren Sie eine Reihe von Vorteilen. Dabei handelt es sich möglicherweise um eine „schmutzige“, vorläufige Datenbank, sie sollte jedoch Informationen über die gesamte Ausrüstung enthalten, über die Sie verfügen. Daher sollten Sie ein dynamisches Hardware-Skript schreiben, das alle Infrastrukturänderungen automatisch in die Datenbank überträgt, damit Ansible weiß, welche Hosts auf dem neuen System vorhanden sein sollten. Sie müssen diesem SCM nicht mitteilen, welche Hosts Sie hinzugefügt haben und welche nicht mehr vorhanden sind, da er dies alles automatisch weiß. Je mehr Daten in der Datenbank vorhanden sind, desto nützlicher und flexibler ist Ansible. Es funktioniert so, als würde es einfach den Hardwarestatus-Barcode aus einer Datenbank lesen.
Nehmen Sie sich etwas Zeit, um sich mit der Befehlszeile in Ansible vertraut zu machen. Führen Sie einige benutzerdefinierte Befehle aus, um das Hardware-Skript zu testen, schreiben und führen Sie einige einfache, aber nützliche Playbook-Skripte aus und verwenden Sie gegebenenfalls Jinja2-Vorlagen. Versuchen Sie, eine Rolle und ein Skript für einen komplexen, mehrstufigen Prozess zu schreiben, der eine häufig vorkommende Hardwarekonfiguration verwendet. Spielen Sie mit diesen Dingen und testen Sie, wie es funktioniert. Auf diese Weise lernen Sie, wie Sie die in Tower verwendeten Tools zur Bibliothekserstellung verwenden. Ich habe bereits gesagt, dass ich etwa drei Monate gebraucht habe, um mich auf den Übergang vorzubereiten. Ich denke, dass Sie dies meiner Erfahrung nach schneller erledigen können. Betrachten Sie diese Zeit nicht als verschwendete Zeit, denn später werden Sie alle Vorteile der geleisteten Arbeit erleben.
Als nächstes müssen Sie entscheiden, was Sie von Ansible Tower erwarten und was genau dieses System für Sie leisten soll.
Müssen Sie das System auf reiner Hardware oder auf reinen virtuellen Maschinen bereitstellen? Oder möchten Sie die ursprünglichen Betriebsbedingungen und Einstellungen vorhandener Geräte beibehalten? Dies ist ein sehr wichtiger Aspekt für öffentliche Unternehmen. Sie müssen daher sicher sein, dass Sie Ansible auf Ihrer vorhandenen Konfiguration migrieren und bereitstellen können. Identifizieren Sie routinemäßige Verwaltungsprozesse, die Sie automatisieren möchten. Finden Sie heraus, ob Sie bestimmte Anwendungen und Dienste auf dem neuen System bereitstellen müssen. Erstellen Sie eine Liste dessen, was Sie tun möchten, und priorisieren Sie diese.
Beginnen Sie dann mit dem Schreiben von Skriptcode und Rollen, die die Aufgaben ermöglichen, die Sie erledigen möchten. Kombinieren Sie sie zu Projekten, einer logischen Sammlung relevanter Playbooks. Jedes Projekt gehört zu einem separaten Git-Repository oder einem anderen Repository, je nachdem, welchen Code-Manager Sie verwenden. Sie können Playbook-Skripte und Playbook-Verzeichnisse verwalten, indem Sie sie manuell im Projektbasispfad auf dem Tower-Server platzieren oder indem Sie das Playbook in einem beliebigen von Tower unterstützten Quellcodeverwaltungssystem (SCM), einschließlich Git, Subversion, Mercurial und Red Hat, platzieren Einblicke. Innerhalb eines Projekts können Sie beliebig viele Skripte platzieren. Ich habe beispielsweise ein Basisprojekt erstellt, in dem ich ein Skript für die RedHat-Kernelemente, ein Skript für den Linux-Kern und Skripte für die restlichen Baselines platziert habe. So gab es in einem Projekt eine Vielzahl von Rollen und Szenarien, die von einem Git-Repository aus verwaltet wurden.
Das Ausführen all dieser Dinge über die Befehlszeile ist eine gute Möglichkeit, ihre Funktionalität zu testen. Dies bereitet Sie auf die Tower-Installation vor.
Lassen Sie uns ein wenig über die Transkodierung des Puppet-Manifests sprechen, da ich viel Zeit damit verbracht habe, bis ich herausgefunden habe, was tatsächlich getan werden muss.
Wie ich bereits sagte, speichert Puppet alle Einstellungen und Hardwareoptionen in einem langen Manifest, und dieses Manifest speichert alles, was dieser SCM tun soll. Bei der Umstellung müssen Sie nicht alle Ihre Aufgaben in einer Liste zusammenfassen; denken Sie stattdessen über die Struktur des neuen Systems nach: Rollen, Skripte, Tags, Gruppen und was dort hingehört. Einige der autonomen Netzwerkelemente sollten in Gruppen zusammengefasst werden, für die Skripte erstellt werden können. Komplexere Infrastrukturelemente, die eine große Anzahl von Ressourcen umfassen, einschließlich eigenständiger Klassen, können zu Rollen zusammengefasst werden. Vor der Migration müssen Sie sich darüber entscheiden. Wenn Sie große Rollen oder Szenarien erstellen, die nicht auf einen Bildschirm passen, sollten Sie Tags verwenden, um bestimmte Teile der Infrastruktur erfassen zu können.
18:00
Einige Anzeigen 🙂
Vielen Dank, dass Sie bei uns geblieben sind. Gefallen Ihnen unsere Artikel? Möchten Sie weitere interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder an Freunde weiterempfehlen. , ein einzigartiges Analogon von Einstiegsservern, das von uns für Sie erfunden wurde: (verfügbar mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40 GB DDR4).
Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur hier in den Niederlanden! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbit/s 100 TB – ab 99 $! Lesen über
Source: habr.com