Planen Sie Ihr Upgrade auf Ansible Automation Platform 2.6

Das Release von Red Hat Ansible Automation Platform 2.6 markiert einen entscheidenden Meilenstein. Bevor Sie mit dem Upgrade beginnen, sollten Sie 3 wichtige Punkte beachten, die Ihren Übergang reibungsloser gestalten:

• Dies ist die letzte Version mit einem RPM-basierten Installationsprogramm. Red Hat Ansible Automation Platform 2.6 mit der RPM-Methode ist nur für Red Hat Enterprise Linux (RHEL) 9 verfügbar. Das RPM-Installationsprogramm wird nach dieser Version eingestellt. Ansible Automation Platform 2.7 unterstützt nur eine containerisierte Installationsmethode, den Red Hat OpenShift Operator oder unsere Cloud Services. Daher ist es jetzt an der Zeit, mit dem Übergang zu beginnen.
• Ansible Automation Platform 2.6 ist ein Meilenstein für dieses Release. Die Upgrade-Pfade zu zukünftigen Versionen der Plattform müssen über die Version 2.6 erfolgen. Daran führt kein Weg vorbei.
• RHEL 8 wird nicht mehr unterstützt. Wenn Sie noch mit RHEL 8 arbeiten, müssen Sie zu RHEL 9 (oder RHEL 10) migrieren, bevor Sie ein Upgrade auf Ansible Automation Platform 2.6 durchführen.

Planung Ihres Upgrades

Bei der Planung Ihres Umstiegs auf Ansible Automation Platform 2.6 sollten zwei wichtige Überlegungen in Ihren Upgrade-Plan einfließen:

Es kann sich immer nur eine Komponente gleichzeitig ändern. Unabhängig davon, ob es sich um das zugrunde liegende Betriebssystem (OS), die Installationsmethode oder die Produktversion handelt: Das Installationsprogramm führt nur eine Änderung pro Durchlauf aus. Das bedeutet, dass Sie das Programm möglicherweise mehrmals ausführen müssen. Details dazu finden Sie in der offiziellen Dokumentation.

In den meisten Fällen benötigen Sie eine Neuinstallation. Abgesehen von einigen spezifischen Szenarien, wie dem Upgrade von 2.5 auf 2.6 auf derselben Architektur oder bestimmten Red Hat OpenShift Operator Deployments, müssen Sie eine neue Instanz von Ansible Automation Platform 2.6 bereitstellen und dann Ihre Konfiguration zu dieser Instanz migrieren.

Damit stellt sich die zentrale Frage: Wie übertragen Sie Ihre vorhandene Konfiguration in die neue Instanz? Die Antwort liegt in der Erkenntnis, dass Ihre Konfiguration von Ansible Automation Platform in einer PostgreSQL-Datenbank gespeichert wird. Ihre Upgrade-Strategie richtet sich danach, wie Sie diese Daten verschieben.

Ansätze für Upgrades

Zu Ansible Automation Platform 2.6 führen 2 Pfade: eine datenbankzentrierte Migration oder eine API-zentrierte Migration. Die richtige Wahl hängt von Ihrer Umgebung, Ihren Anforderungen und Ihrer Kompromissbereitschaft ab.

Bei einem datenbankzentrierten Ansatz wird Ansible Automation Platform wie ein zustandsbehaftetes System behandelt, bei dem die Daten die Source of Truth sind. Ein API-zentrierter Ansatz behandelt die Plattform als Configuration as Code (CaC), bei dem die Source of Truth in den Konfigurationsdateien liegt. In der folgenden Tabelle finden Sie die technischen Überlegungen für die einzelnen Ansätze:

Datenbankzentrierte Migrationen

Datenbankzentrierte Migrationen sind der dokumentierte, vollständig unterstützte Pfad, der die gesamte Datenbank während des Upgrade-Prozesses beibehält und migriert. Die Herausforderung? Der „Upgrade-Tanz“. Sie migrieren möglicherweise von RHEL 8 zu RHEL 9, von RPM zur containerisierten Version und von Ansible Automation Platform 2.4/2.5 zu 2.6. Jeder dieser Schritte ist ein separater Schritt, der eine eigene Infrastruktur erfordert. 

Dabei müssen potenziell viele Zwischenumgebungen bereitgestellt und verwaltet werden. Je nach Ausgangspunkt und Ziel der Migration sowie dem Umfang der Umgebung (und damit der Größe der Datenbank) kann dies eine zeitaufwendige Aufgabe sein.

Ein wichtiger Vorbehalt: Wenn Sie aufgrund dieser Komplexität zu gemanagten Cloud Service-Angeboten von Ansible Automation Platform tendieren, sollten Sie wissen, dass für das Hochladen einer Datenbank in gemanagte Services ein Support-Ticket erforderlich ist. Sie finden diesen Prozess hier dokumentiert. Um dies selbst zu tun, müssen Sie den API-zentrierten Ansatz verwenden.

API-zentrierte Migration

Red Hat unterstützt diesen Ansatz offiziell nicht (die einzelnen Komponenten, die diese Migrationstechnik ermöglichen, werden jedoch unterstützt). Dieser Ansatz kann jedoch deutlich schneller sein, vor allem für große Umgebungen. Da dies mit einer einzigen Verschiebung zur Zielplattform erfolgt, sind keine Zwischeninstallationen erforderlich.

Bei dieser Methode exportieren Sie die Konfiguration von Ansible Automation Platform mithilfe von API-Aufrufen, um sie lokal zu speichern, etwa in Konfigurationsdateien oder einer temporären Datenbank. Diese Dateien können Sie dann nach Bedarf ändern und anschließend über die API auch auf einer anderen Plattform wiederherstellen. Diese Methode bietet zudem einen vorteilhaften Nebeneffekt: Sie führt Configuration as Code (CaC) in Ihren Workflow ein. Dies bietet Ihnen eine Basis, um die Plattform zukünftig mit CaC-Methoden zu verwalten.

Die Kompromisse? Sie verlieren den Jobverlauf (gemindert durch einen externen Log-Aggregator) und müssen sorgfältig mit Secrets umgehen (gemindert durch einen externen Secrets Manager). Möglicherweise müssen Sie auch die exportierten Konfigurationsdateien bearbeiten, damit sie für den Import richtig formatiert sind. Dies gilt insbesondere für Objekte von Private Automation Hub und Event-Driven Ansible.

Hinweis zu Secrets

Secrets für Anmeldedaten und Benachrichtigungen werden in der Konfigurationsdatenbank gespeichert und durch den SECRET_KEY der Datenbank verschlüsselt. Da diese verschlüsselt sind, werden ihre Werte nicht über die API exportiert. Um Zugriff auf die Secrets für Ihre Konfiguration zu erhalten, ist daher Root-Zugriff auf den Datenbankserver erforderlich. Da dies Ihre Secrets im Klartext offenlegen würde, müssen Sie diese mit äußerster Sorgfalt behandeln, beispielsweise indem Sie die Secrets in einem Ansible Vault erneut verschlüsseln. 

Wenn Sie jedoch einen externen Secrets Manager wie HashiCorp Vault verwenden, stellt dies kein Problem dar, da diese Secrets nicht in Ansible Automation Platform gespeichert sind. Wenn nur wenige Secrets zu verwalten sind, kann es alternativ genauso einfach sein, die Secrets in der neuen Plattform einzufügen.

Überlegungen zu beiden Methoden

Unabhängig davon, für welchen Pfad Sie sich entscheiden, sollten Sie Folgendes berücksichtigen: Externe Integrationen und API-Token werden wahrscheinlich Aufmerksamkeit erfordern. 

Ansible Automation Platform 2.5 führte das Automation Gateway ein. Dieses einheitliche Frontend verbindet Automation Controller, Ansible Automation Hub und Event-Driven Ansible Controller in einer einzigen Oberfläche. Dadurch wurden viele API-Endpunkte auf neue Pfade verschoben. Obwohl wir die Abwärtskompatibilität dieser Integrationsendpunkte für Version 2.6 beibehalten haben, müssen Sie diese für zukünftige Releases aktualisieren. Außerdem müssen Sie die meisten von der Plattform ausgegebenen Token neu generieren und neu verteilen. Möglicherweise müssen Sie zusätzliche Server bereitstellen und Load Balancer auf den neuen Gateway-Service aktualisieren.

Extern gemanagte Datenbanken

Für Kunden mit extern gemanagten Datenbanken gibt es zusätzliche Überlegungen.  Zunächst verwendet Ansible Automation Platform 2.4 Postgres 13. Dies wird auf Postgres 15 für 2.5 und PostgreSQL 15 für 2.6 aktualisiert. Ansible Automation Platform 2.6 unterstützt auch von Kunden bereitgestellte Datenbanken der Versionen PostgreSQL 16 und 17. Dieses Verfahren zum Datenbank-Upgrade ist ein wichtiger Aspekt bei der Migration und beim „Update-Tanz“. Es ist ein wesentlicher Grund, warum Kunden ihre bestehende Datenbank nicht ohne diesen Update-Prozess wiederverwenden können.  Insbesondere für Ansible Automation Platform 2.5+ müssen Sie International Components for Unicode (ICU) in vom Kunden bereitgestellten Datenbanken aktivieren. Diese Funktion ist bei den meisten großen Datenbankanbietern wie EDB, Amazon Web Services Relational Database Service (AWS RDS) und Azure SQL Database verfügbar, aber nicht standardmäßig aktiviert. Wegen dieser Datenbankkompatibilität können wir das Schema in einer bestehenden Datenbank nicht einfach aktualisieren.

Kompatibilität von Playbooks

Wenn Sie ein Upgrade für Ansible Automation Platform durchführen, wird auch die Version von ansible-core in der Standard-Ausführungsumgebung aktualisiert. Die gute Nachricht ist, dass Sie ältere Ausführungsumgebungen immer auf neueren Versionen der Plattform ausführen können, sodass die Abwärtskompatibilität erhalten bleibt. Wir empfehlen jedoch dringend ein Upgrade, damit Sie von neuen Funktionen und Sicherheitskorrekturen profitieren.

Wenn Sie Ihre Ausführungsumgebungen aktualisieren, führen Sie ein Upgrade auf eine neue Version von Ansible Core durch, was einige Änderungen mit sich bringen kann.  Das können Sie erwarten:

Ansible Automation Platform 2.4 migriert zu 2.6 (ansible-core 2.15 migriert zu 2.16)

Dies ist ein kleineres Upgrade. Die wichtigste Änderung besteht darin, dass das System einige Warnungen in bedingten Anweisungen jetzt als Fehler behandelt. Darüber hinaus sind die Auswirkungen minimal.

Migration zu ansible-core 2.18 (optionale Ausführungsumgebung in Ansible Automation Platform 2.6) Als optionale unterstützte Ausführungsumgebung für Ansible Automation Platform 2.6 bringt dieses Upgrade deutlich mehr Änderungen mit sich. Speziell:

• Python 2.7 und 3.6 auf Zielknoten sind keine unterstützten Versionen mehr. Dies bedeutet, dass Sie mit dieser Ausführungsumgebung keine RHEL 6-Hosts mehr ansteuern können. RHEL 7-Hosts benötigen Python 3.8 (verfügbar über Red Hat Software Collections), damit Sie diese mit Ansible Automation Platform automatisieren können.
• Python 3.11 ist jetzt die in Ihrer Ausführungsumgebung enthaltene Python-Version. Sie müssen benutzerdefinierte Python-Libraries und Libraries von Drittanbietern auf mit 3.11 kompatible Libraries aktualisieren.
• Die Bereinigung von veralteten Modulen („Dead Batteries“) in Python ist im Gange. PEP 594 entfernt im Laufe der nächsten Python-Releases nicht gewartete, unsichere und veraltete Libraries aus der Standard-Library. Warnungen vor veralteten Elementen beginnen mit Python 3.11. Einige Libraries werden in Version 3.12 entfernt, und die umfassende Entfernung erfolgt in Version 3.13.

Für die meisten Kunden stellt dies kein unmittelbares Problem dar. Es lohnt sich jedoch, jetzt auf Warnungen vor veralteten Elementen zu achten, damit Sie sich vorbereiten können.

Ausführliche Informationen zu unterstützten ansible-core-Versionen finden Sie in der offiziellen Support-Richtlinie von Red Hat.

Der Umstieg auf Ansible Automation Platform 2.6 ist mehr als nur ein Versionsupdate. Es handelt sich um einen strategischen Schritt, der die Grundlage für die nächste Generation der Automatisierung schafft. Indem Sie den Migrationspfad wählen, der heute am besten zu Ihrer Infrastruktur passt, halten Sie Ihre Automatisierung resilient, sicherheitsorientiert und bereit für zukünftige Anforderungen.

Zusätzliche Ressourcen

• Artikel: Automatisierung von Upgrades für Ansible Automation Platform 2.6 mit Python, AsyncIO und Bulk-Vorgängen
• Versionshinweise und Dokumentation zu Ansible Automation Platform.
• Neuerungen bei Ansible Automation Platform