Get best of the week

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

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.



Grüße an alle, mein Name ist Michael Rau, ich bin ein leitender Systemingenieur bei ActioNet, der für die National Oceanic and Atmospheric Administration (NOAA) von NESDIS arbeitet. Heute werden wir über das Trimmen von Linien sprechen - meine eigene Erfahrung bei der Migration von Puppet Enterprise zu Ansible Tower. Das Thema dieser Präsentation ist, „meine Narben zu betrachten“, die ich nach diesem Übergang zu Beginn des Jahres hinterlassen habe. Ich möchte erzählen, was ich während dieses Prozesses gelernt habe. Wenn Sie dies tun, können Sie nach meiner Erfahrung den Übergang ohne allzu große Schwierigkeiten durchführen.

Sie sehen ähnliche Folien zu Beginn jeder Präsentation auf dem Ansible Fest. Diese Folie zeigt den Verlauf der Automatisierung meines Unternehmens. Ich bin nicht neu in diesem Geschäft, da ich Puppet / Puppet Enterprise seit 2007 verwende. Ich habe 2016 angefangen, mit Ansible zu arbeiten, und wie viele andere Benutzer dieses Produkts hat mich die Möglichkeit von „Tricks“ über die Befehlszeile und einfache Skripte (Playbooks) angezogen. Ende 2017 wandte ich mich an meine Führung, um die guten Gründe für den Umzug in den Ansible Tower zu erfahren. In einer Minute werde ich über die Gründe sprechen, die mich zu diesem Schritt veranlasst haben. Nachdem ich die Zustimmung des Managements erhalten hatte, dauerte es noch einige Monate, bis der Plan erfüllt war, und ich machte den Übergang von Januar bis Februar dieses Jahres. Also haben wir Puppet komplett zugunsten von Ansible aufgegeben, und das ist eine großartige Sache.



Was mich an Ansible am meisten interessiert, ist die Fähigkeit, Rollen und Skripte (Playbooks) zu schreiben und zu verwenden. Rollen eignen sich hervorragend zum Erstellen verschiedener, aber miteinander verbundener Aufgaben (Aufgaben) und zum Platzieren aller Daten zu diesen Aufgaben an einem Ort. Playbook ist die YAML-Syntax, eine Skriptdatei, die Aktionen für einen oder mehrere Hosts beschreibt. Ich spreche mit Benutzern, hauptsächlich Softwareentwicklern, über diese Funktionen. Mit Ansible Tower können Sie sagen: "Nein, Sie haben keinen Zugriff auf den 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 über das Arbeitsumfeld und die von uns verwendeten Geräte berichten.



Dies ist ein Bundes-LAN, 7 physische Standorte, die über Cloud-basiertes MPLS verbunden sind, 140 RHEL-Server, von denen 99% virtuell (vSphere) sind, SuperMicro-Hardware, NexentaStore NAS, eine Reihe von Cisco-, Arista- und Cumulus-Switches und Fortinet UTM-Tools für das einheitliche Bedrohungsmanagement an jedem Standort .

Das föderale Netzwerk bedeutet, dass ich alle Mittel des Informationsschutzes nutzen muss, die in Gesetzgebungsakten vorgesehen sind. Sie sollten bedenken, dass Puppet Enterprise die meisten von uns verwendeten Geräte nicht unterstützt. Wir sind gezwungen, Budget-Hardware zu verwenden, weil Regierungsbehörden Probleme haben, diesen Ausgabenposten zu finanzieren. Aus diesem Grund kaufen wir Hardware der SuperMicro-Klasse und bauen unsere Geräte aus einzelnen Teilen zusammen, deren Wartung durch Regierungsaufträge garantiert wird. Wir verwenden Linux und dies ist einer der wichtigsten Gründe für den Wechsel zu Ansible.

Unsere Geschichte mit Puppet ist dies.



2007 hatten wir ein kleines Netzwerk von 20 bis 25 Knoten, in denen wir Puppet eingesetzt haben. Im Grunde waren diese Knoten nur "Boxen" von RedHat. Im Jahr 2010 haben wir begonnen, die Puppet Dashboard-Weboberfläche für 45 Knoten zu verwenden. Als das Netzwerk weiter ausgebaut wurde, wechselten wir 2014 zu PE 3.3 und machten einen vollständigen Übergang mit dem Umschreiben des Manifests für 75 Knoten. Dies musste getan werden, weil Puppet gerne die Spielregeln ändert und in diesem Fall die Sprache komplett geändert hat. Ein Jahr später, als die Unterstützung für Version 3 von Puppet Enterprise eingestellt wurde, mussten wir auf PE 2015.2 migrieren. Ich musste das Manifest für die neuen Server erneut umschreiben und eine Lizenz mit einer Reserve von 100 Knoten erwerben, obwohl wir zu diesem Zeitpunkt nur 85 Knoten hatten.

Es vergingen nur 2 Jahre und wir mussten erneut viel arbeiten, um auf die neue Version von PE 2016.4 umzusteigen. Wir haben eine Lizenz für 300 Knoten mit insgesamt 130 Knoten gekauft. Wir mussten erneut wesentliche Änderungen am Manifest vornehmen, da die neue Version der Sprache eine andere Syntax als die Sprache der Version 2015 hatte. Infolgedessen wechselte unser SCM von einem SVN-Versionskontrollsystem zu Bitbucket (Git). Das war unsere "Beziehung" zu Puppet.

Daher musste ich dem Management anhand der folgenden Argumente erklären, warum wir zu einem anderen SCM wechseln müssen. Der erste ist der hohe Preis des Dienstes. Ich habe mit den RedHat-Leuten gesprochen und sie sagten, dass die Kosten für die Wartung eines 300-Knoten-Netzwerks mit Ansible Tower die Hälfte der Kosten von Puppet Enterprise betragen. Wenn Sie eine andere Ansible Engine kaufen, sind die Kosten ungefähr gleich, aber Sie erhalten viel mehr Funktionen als PE. Da wir ein staatliches Unternehmen sind, das aus dem Bundeshaushalt finanziert wird, ist dies ein ziemlich gewichtiges Argument.



Das zweite Argument ist die Vielseitigkeit. Puppet unterstützt nur Hardware mit einem Puppet-Agenten. Dies bedeutet, dass Sie einen Agenten auf allen Switches installieren müssen und es sich um die neueste Version handeln muss. Wenn ein Teil Ihrer Switches eine Version und ein Teil eine andere unterstützt, müssen Sie eine neue Version des PE-Agenten auf ihnen installieren, damit alle auf demselben SCM-System arbeiten können.

Das Ansible Tower-System funktioniert anders, da es keine Agenten hat. Es gibt jedoch Module, 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-NASs, die auf dem Illumos-Kernel basieren, einem Open-Source-Unix-basierten Betriebssystem. Dies ist sehr wenig Unterstützung, aber Ansible Tower macht es trotzdem.

Das dritte Argument, das sowohl für mich als auch für unsere Verwaltung sehr wichtig ist, ist die einfache Entwicklung. Ich habe die Puppet-Manifest-Module und den Code 10 Jahre lang beherrscht, aber eine Woche lang Ansible studiert, weil es viel einfacher ist, mit diesem SCM zu arbeiten. Wenn Sie ausführbare Dateien ausführen, arbeiten Sie natürlich mit ihnen, wenn Sie dies nicht unnötig tun. YAML-basierte Playbooks-Skripte sind einfach zu erlernen und schnell zu verwenden. Diejenigen, die noch nie von YAML gehört haben, können einfach die Skripte lesen und leicht verstehen, wie es funktioniert.

Ehrlich gesagt erschwert Puppet Ihre Arbeit als Entwickler, da es auf der Verwendung von Puppet Master basiert. Dies ist die einzige Maschine, die zur Kommunikation mit Puppet-Agenten berechtigt ist. Wenn Sie Änderungen am Manifest vorgenommen haben und Ihren Code testen möchten, müssen Sie den Code für den Puppet Master neu schreiben, dh die Puppet Master-Datei / etc / hosts konfigurieren, um alle Clients zu verbinden und den Puppet Server-Dienst zu starten. Nur dann 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 einen Computer entwickeln, der über SSH mit dem zu testenden Host kommunizieren kann. Dies ist viel einfacher zu bearbeiten.

Das nächste große Plus von Ansible Tower ist die Möglichkeit, Ihr vorhandenes Support-System zu nutzen und Ihre vorhandene Hardwarekonfiguration zu speichern. Dieser SCM verwendet ohne zusätzliche Aktionen alle verfügbaren Informationen zu Ihrer Infrastruktur und Ausrüstung, zu virtuellen Maschinen, Servern usw. Es kann mit Ihren RH Satellite-Servern kommunizieren, falls vorhanden, und bietet Ihnen eine Integration, die Sie bei der Arbeit mit Puppet niemals erhalten werden.

Ein weiterer wichtiger Punkt ist die detaillierte Kontrolle. Sie wissen, dass Puppet ein modulares System ist, es ist eine Client-Server-Anwendung, daher müssen Sie die vorhandenen Aspekte des Betriebs aller Ihrer Maschinen in einem langen Manifest bestimmen. In diesem Fall muss der Status jedes einzelnen Elements des Systems jede halbe Stunde getestet werden - dies ist die Standardperiode. So funktioniert Puppet.

Tower rettet dich davor. Sie können verschiedene Prozesse ohne Einschränkungen auf einer Vielzahl von Geräten ausführen, die Hauptarbeit erledigen, andere wichtige Prozesse starten, das Sicherheitssystem konfigurieren und mit Datenbanken arbeiten. Sie können in Puppet Enterprise alles tun, was mit bestimmten Schwierigkeiten verbunden ist. Wenn Sie also auf einem Host konfiguriert haben, dauert es einige Zeit, bis die Änderungen auf den anderen Hosts wirksam werden. In Ansible werden alle Änderungen gleichzeitig wirksam.

Betrachten Sie abschließend das Sicherheitsmodul. In Ansible Tower wird es einfach erstaunlich implementiert, mit großer Genauigkeit und Gründlichkeit. Sie können Benutzern Zugriff auf bestimmte Dienste oder auf bestimmte Hosts gewähren. Ich mache das mit meinen Mitarbeitern, die es gewohnt sind, unter Windows zu arbeiten, und schränke ihnen den Zugriff auf die Linux-Shell ein. Ich biete ihnen Zugang zum Turm, damit sie nur die Arbeit erledigen und nur die Dienste ausführen können, die in ihre Zuständigkeit fallen.



Schauen wir uns die Dinge an, die Sie im Voraus tun müssen, um den Übergang zum Ansible Tower zu erleichtern. Zunächst ist es notwendig, Ihre Ausrüstung vorzubereiten. Wenn sich noch keine Elemente Ihrer Infrastruktur in der Datenbank befinden, müssen Sie sie dort hinzufügen. Es gibt Systeme, die ihre Eigenschaften nicht ändern und daher in der Puppet-Datenbank nicht vorhanden sind. Wenn Sie sie jedoch vor dem Wechsel zu Tower nicht hinzufügen, verlieren Sie eine Reihe von Vorteilen. Dies kann eine "schmutzige" vorläufige Datenbank sein, sie sollte jedoch Informationen zu allen Geräten enthalten, über die Sie verfügen. Daher sollten Sie ein dynamisches Hardware-Skript schreiben, das automatisch alle Infrastrukturänderungen an der Datenbank vornimmt. Dann weiß Ansible, welche Hosts sich im neuen System befinden sollten. Sie müssen dieses SCM nicht informieren.Welche Hosts Sie hinzugefügt haben und welche Hosts nicht mehr existieren, weil sie das alles automatisch weiß. Je mehr Daten sich in der Datenbank befinden, desto nützlicher und flexibler wird Ansible. Es funktioniert so, als würde einfach ein Barcode des Gerätestatus aus der Datenbank gelesen.

Verbringen Sie einige Zeit damit, die Befehlszeile in Ansible kennenzulernen. Führen Sie einige spezielle Befehle aus, um das Hardware-Skript zu testen, schreiben Sie einige einfache, aber nützliche Playbook-Skripte und führen Sie gegebenenfalls Jinja2-Vorlagen aus. Versuchen Sie, eine Rolle und ein Skript für einen komplexen mehrstufigen Prozess mit einer häufig vorkommenden Standardhardwarekonfiguration zu schreiben. Spielen Sie mit diesen Dingen und testen Sie, wie es funktioniert. Auf diese Weise lernen Sie, wie Sie mit den Tools zum Erstellen von Bibliotheken arbeiten, die im Tower verwendet werden. Ich habe bereits gesagt, dass ich ungefähr 3 Monate gebraucht habe, um mich auf den Übergang vorzubereiten. Ich denke, dass Sie es aufgrund meiner Erfahrung schneller schaffen werden. Betrachten Sie diese Zeit nicht als verloren, da Sie später alle Vorteile der geleisteten 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 tun soll.



Müssen Sie das System auf leerer Hardware und auf leeren virtuellen Maschinen bereitstellen? Oder möchten Sie die ursprünglichen Arbeitsbedingungen und Einstellungen der vorhandenen Geräte beibehalten? Dies ist ein sehr wichtiger Aspekt für die Arbeit staatseigener Unternehmen. Sie müssen daher sicher sein, dass Sie Ansible in Ihrer vorhandenen Konfiguration migrieren und bereitstellen können. Identifizieren Sie die routinemäßigen 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 mit den gewünschten Aktionen und Prioritäten.

Schreiben Sie dann Code für Skripte und Rollen, mit denen Sie Ihre geplanten Aufgaben erledigen können. Kombinieren Sie sie in Projects, einer logischen Sammlung relevanter Playbook-Skripte. Jedes Projekt bezieht sich auf ein separates Git-Repository oder ein anderes Repository, je nachdem, welchen Code-Manager Sie verwenden. Sie können Playbook-Skripte und Playbook-Verzeichnisse verwalten, indem Sie sie manuell in Project Base Path auf dem Tower-Server oder in einem beliebigen SCM-System (Tower Source Code Management), einschließlich Git, Subversion, Mercurial und Red Hat Insights, ablegen. Innerhalb eines Projekts können Sie so viele Skripte platzieren, wie Sie möchten. Zum Beispiel habe ich ein Basisprojekt erstellt, in dem ich ein Skript für die Hauptelemente von RedHat platziert habe, ein Skript für die Grundlagen von Linux.Szenarien für die verbleibenden Baselines. Daher gab es in einem Projekt eine Vielzahl von Rollen und Skripten, die von einem Git-Repository aus verwaltet wurden.

Führen Sie all diese Dinge über die Befehlszeile aus. Dies ist eine gute Möglichkeit, ihre Leistung zu testen. Auf diese Weise bereiten Sie sich auf die Tower-Installation vor.

Lassen Sie uns ein wenig über das Transcodieren des Puppet-Manifests sprechen, da ich viel Zeit damit verbracht habe, bis ich herausgefunden habe, was wirklich getan werden muss.



Wie ich bereits sagte, speichert Puppet alle Einstellungen und Ausrüstungsparameter in einem langen Manifest, und dieses Manifest enthält alles, was dieses SCM tun sollte. Während des Übergangs müssen Sie nicht alle Ihre Aufgaben in einer Liste zusammenfassen, sondern müssen über die Struktur des neuen Systems nachdenken: Rollen, Skripte, Tags, Gruppen und was dort hingehen soll. Einige der eigenständigen Netzwerkelemente sollten in Gruppen gruppiert werden, für die Sie Skripts erstellen können. Komplexere Infrastrukturelemente, die eine große Anzahl von Ressourcen umfassen, einschließlich autonomer Klassen, können in Rollen kombiniert werden. Vor der Migration müssen Sie sich dafür entscheiden. Wenn Sie umfangreiche 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

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

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?

More articles:


All Articles