Migrieren von der Automation Suite unter Linux zur Automation Suite unter EKS/AKS

Sie können von der Automation Suite, die auf einer Linux-Maschine bereitgestellt wird, zur Automation Suite auf EKS/AKS migrieren. Dazu müssen Sie Ihre Daten mithilfe von uipathctl von einer Automation Suite-Variante in eine andere verschieben.

Einer der Vorteile dieses Migrationsprozesses besteht darin, dass Sie versuchen können, ihn mehrmals durchzuführen, ohne dass sich dies auf Ihren vorhandenen Cluster auswirkt.

Wichtig:

Sie können nur zu einer neuen Installation der Automatisierung auf EKS/AKS migrieren. Die Migration zu einer vorhandenen Installation der Automatisierung auf EKS/AKS wird derzeit nicht unterstützt.

Anforderungen

Um von der Automation Suite unter Linux zur Automation Suite unter EKS/AKS zu migrieren, müssen die folgenden Anforderungen erfüllt sein:

• Sie müssen eine Konnektivität zwischen den beiden Umgebungen herstellen.

• In Ihrem Quellcluster muss ein externer Objektspeicher konfiguriert sein. Wenn Sie clusterinternen Speicher verwenden, finden Sie weitere Informationen unter Migrieren des clusterinternen Objectstores zum externen Objectstore.

• Die Version Ihrer Automation Suite unter Linux muss 2022.10 oder höher sein.

• Nur-offline-Anforderungen: Sie müssen den Quellcluster hydratisieren.

Prozessübersicht

Nr.	Migrationsschritt
1.	Obligatorisch. Laden Sie uipathctl herunter. Anweisungen zum Herunterladen finden Sie unter uipathctl.
2.	Obligatorisch. Laden Sie versions.json herunter. Anweisungen zum Herunterladen finden Sie unter versions.json.
3.	Bereiten Sie die Docker-Images für den Quell- sowie den Zielcluster vor. Optional. Wenn Ihre Bereitstellung offline ist oder wenn Sie eine private OCI-Registrierung verwenden, stellen Sie sicher, dass die erforderlichen Images verfügbar sind.
4.	Bereiten Sie den Zielcluster vor: Erstellen Sie die Datei input.json. Führen Sie die Voraussetzungsprüfung durch.
5.	Führen Sie die Migration durch und verschieben Sie die Daten. Die Migration führt Pods sowohl auf dem Quell- als auch auf dem Zielcluster aus. Der für den Quellcluster konfigurierte externe Objektspeicher, insbesondere der Plattform-Bucket, wird als Zwischenspeicherort für die Migration verwendet. Quellcluster: general-migration-*-Pods sind für den Export von Kubernetes-Objekten aus dem Quellcluster in den Zielcluster verantwortlich. volume-migration-*-Pods sind für das Kopieren von PVC-Daten in den externen Zwischenspeicher verantwortlich. Zielcluster: inbound-pvc-migration-*-Pods sind für die Erstellung von PVCs im Zielcluster und das Kopieren der Quelldaten in diese verantwortlich.
6.	Führen Sie die Installation der Automation Suite auf AKS oder EKS aus.

Datenmigration und Zuständigkeiten

Daten	Migrationsmechanismus
	Status	Verantwortung
SQL	Beibehalten Sie haben zwei Optionen: Verwenden Sie dieselben Datenbanken für die neue Installation wieder. Verweisen Sie die SQL-Verbindungszeichenfolgen der Clusterkonfiguration auf den vorhandenen Datenbankserver. Klonen Sie Ihre Datenbanken und verwenden Sie stattdessen die Klone.	Kunde
Docker-Registrierung	Nicht migriert Wenn Sie eine private Registrierung verwenden, müssen Sie die Zielregistrierung hydratisieren. Wenn Sie registry.uipath.com für den Zielcluster verwenden, sind keine weiteren Schritte erforderlich.)	Kunde
FQDN	Optional Sie müssen einen neuen FQDN für den neuen Cluster auswählen. Optional können Sie bei Bedarf zum vorherigen FQDN zurückkehren.	Kunde
Zertifikat	Nicht migriert Sie müssen Zertifikate als Teil der neuen Clusterinstallation mitbringen.	Kunde
Clusterkonfiguration	Nicht migriert Sie müssen das neue input.json für den Zielclustertyp (AKS oder EKS) generieren.	Kunde
Benutzerdefinierte Warnungen und Dashboards, die von Benutzern erstellt wurden	Nicht migriert Sie müssen die benutzerdefinierten Warnungen und Dashboards nach der Migration neu konfigurieren.	Kunde
Von Benutzern erstellte Anwendungsprotokolle / Prometheus-Streaming-Konfiguration	Nicht migriert Sie müssen das Anwendungsprotokoll und das Prometheus-Streaming neu konfigurieren.	Kunde
Dynamische Workloads	Abhängig von der Anwendung AI Center-Trainingsaufträge gehen verloren; Fähigkeiten werden beibehalten.	Fähigkeiten (Skript, das nach dem Upgrade ausgeführt werden muss): UiPath® Trainingsaufträge: Kunde
Objektspeicher	Externer Objektspeicher: Beibehalten Für den externen Objektspeicher haben Sie zwei Optionen: Verwenden Sie den vorhandenen externen Objektspeicher wieder und verbinden Sie ihn mit der neuen Umgebung. Erstellen Sie ein Replikat Ihres aktuellen Objektspeichers und verwenden Sie es für das neue Setup. Wichtig: Wenn Sie einen clusterinternen Objektspeicher verwenden, müssen Sie vor dem Upgrade eine Migration von Ceph nach extern durchführen.	Migration vom clusterinternen zum externen Objektspeicher: Kunde Externer Objektspeicher: UiPath®
Insights	Beibehalten	UiPath®
MongoDB-Daten	Beibehalten MongoDB-Daten werden in die Ziel-SQL verschoben.	UiPath®
RabbitMQ	Nicht benötigt	UiPath®
Überwachen (Daten)	Nicht benötigt Überwachungsdaten gelten nicht für den neuen Cluster.	Keine Angabe

Vorbereitung

Vorbereiten der cluster_config.json-Datei

Hinweis:

Ändern Sie nicht den Quellcluster, nachdem Sie den Migrationsprozess gestartet haben.

Führen Sie die folgenden Schritte aus, um die cluster_config.json-Datei vorzubereiten:

1. Laden Sie die Zielversion von uipathctl auf den Quellcluster herunter und generieren Sie die input.json-Datei, indem Sie uipathctl manifest get-revision ausführen. Weitere Informationen finden Sie im folgenden Diagramm:
   
2. Ändern Sie basierend auf der zuvor generierten input.json-Datei die input.json-Datei des Zielclusters. Anweisungen finden Sie unter Konfigurieren von input.json.

   Sie müssen die Orchestrator-spezifische Konfiguration übertragen, die den Verschlüsselungsschlüssel pro Mandant und die Einstellungen für Azure/Amazon S3-Speicher-Buckets enthält.

3. Überprüfen Sie die Voraussetzungen im Zielcluster, indem Sie den folgenden Befehl ausführen:

   uipathctl prereq run input-target.json --kubeconfig kubeconfig.target --versions versions.json

4. Klonen Sie die SQL-Datenbanken von der Quellbereitstellung auf die Zielbereitstellung.

Private Registrierung ohne Internetzugangsanforderungen

Für den Migrationsprozess muss das neueste Docker-Image-Tag uipathcore sowohl für den Quell- als auch für den Zielcluster verfügbar sein. Wenn Ihr Quellcluster offline ist, stellen Sie das Image mit den folgenden Schritten zur Verfügung:

1. Führen Sie die Schritte aus, um die vom Zielcluster verwendete Registrierung mit dem Offlinepaket in Option B: Hydratisieren der Registrierung mit dem Offlinepaket zu hydratisieren.
2. Kopieren Sie die Binärdatei uipathctl und die Datei versions.json auf eine VM mit Zugriff auf den Quellcluster.
3. Führen Sie den folgenden Befehl aus:

   jq -r '.[][] | select(.name=="uipath/uipathcore") | .ref + ":" + .version' "/path/to/versions.json" > images.txt

4. Fügen Sie das Image uipathcore mithilfe der Binärdatei uipathctl zu Ihrer privaten Registrierung hinzu:

   ./uipathctl registry seed --tag-file ./images.txt \
               --source-registry "target.registry.fqdn.com" \
               --source-password "target-registry-username" \
               --source-username "target-registry-password" \
               --dest-registry "<source.registry.fqdn.com>" \
               --dest-username "<source-registry-username>" \
               --dest-password "<source-registry-password>"

   Hinweis: Stellen Sie sicher, dass Sie registry.fqdn, registry-username und registry-password durch die richtigen Werte für die private Registrierung ersetzen, die von Ihrer Quell-Offlineinstallation verwendet wird.

Private Registrierung mit Internetzugangsanforderungen

Bei Verwendung eines privaten Registers müssen Sie dieses seeden. Anweisungen finden Sie unter Konfigurieren der OCI-konformen Registrierung.

Offline mit Registrierungsanforderungen innerhalb des Clusters

Wenn Sie eine Registrierung im Cluster in Ihrer Offlineumgebung verwenden, führen Sie die folgenden Schritte aus:

1. Laden Sie as.tar.gz auf den Quellcluster herunter.
2. Hydratisieren Sie Ihre Registrierung, indem Sie das Skript configureUiPathAS.sh ausführen:

   cd /opt/UiPathAutomationSuite/{version}/installer
   
   ./configureUiPathAS.sh registry upload --offline-bundle /uipath/{version}/as.tar.gz --offline-tmp-folder /uipath/tmp

Ausführung

Führen Sie die folgenden Schritte aus, um zur Automation Suite auf EKS/AKS zu migrieren:

1. Führen Sie die Migration aus, indem Sie den folgenden Befehl ausführen:

   uipathctl cluster migration run input-target.json --kubeconfig kubeconfig.source --target-kubeconfig kubeconfig.target --versions versions-target.json

2. Schließen Sie die Installation der Automation Suite auf AKS/EKS auf dem Zielcluster ab, indem Sie den folgenden Befehl ausführen:

   uipathctl manifest apply input-target.json --kubeconfig kubeconfig.target --versions versions-target.json

Migration von AI Center-Fähigkeiten

Die Schritte in diesem Abschnitt gelten nur, wenn Sie das AI Center im Quell- sowie im Zielcluster aktiviert haben. Beachten Sie, dass die Anweisungen davon ausgehen, dass AI Center im Zielcluster auf die Datenbank verweist, welche die Fähigkeitsdaten zum Ausführen der Fähigkeiten enthält.

Nach Abschluss der Migration müssen Sie die AI Center-Fähigkeiten synchronisieren, damit Sie sie erneut verwenden können.

Überprüfen des Status der Fähigkeitsmigration

Um den Status der Fähigkeiten in der entsprechenden Automation Suite im EKS/AKS-Cluster abzurufen, führen Sie die folgenden Schritte aus:

1. Richten Sie die Variablen für die Ausführung der nächsten Befehle ein.

   aicJobsImage=$(kubectl -n uipath get configmap aic-jobs-config -o "jsonpath={.data['AIC_JOBS_IMAGE']}")
   podName="skillstatuspod"

2. Bereinigen Sie skillstatuspod, der eventuell ausgeführt wird, bevor Sie den Fähigkeitsstatus erneut abrufen. Der folgende Befehl löscht den Pod aus der vorherigen Iteration, also verwenden Sie ihn mit Vorsicht.

   kubectl -n uipath delete pod "$podName" --force.

3. Erstellen Sie den skillstatuspod, um den Fähigkeitsstatus abzurufen. Der Pod kann einige Zeit zum Abrufen des Image und zur Ausführung benötigen, normalerweise weniger als 30 Sekunden.

   kubectl -n uipath run "$podName" --image="$aicJobsImage" --restart=Never --labels="app.kubernetes.io/component=aicenter" --overrides='{ "metadata": { "annotations": {"sidecar.istio.io/inject": "false"}}}' -- /bin/bash -c "curl -sSL -XPOST -H 'Content-Type: application/json' 'ai-deployer-svc.uipath.svc.cluster.local/ai-deployer/v1/system/mlskills:restore-status' | jq -r '([\"SKILL_ID\",\"SKILL_NAME\", \"STATUS\"] | (., map(length*\"-\"))), (.data[] | [.skillId, .skillName, .syncStatus]) | @tsv' | column -ts $'\t'; exit"

4. Überprüfen Sie die Ausgabe des Fähigkeitsstatus.

   kubectl -n uipath logs -f "$podName" -c "$podName"

Ausführen der Fähigkeitsmigration

Um die Fähigkeitsmigration auszuführen, führen Sie die folgenden Schritte aus:

1. Richten Sie die Variablen für die Ausführung der nächsten Befehle ein.

   aicJobsImage=$(kubectl -n uipath get configmap aic-jobs-config -o "jsonpath={.data['AIC_JOBS_IMAGE']}")
   podName="skillsyncpod"

2. Bereinigen Sie skillsyncpod, der eventuell ausgeführt wird, bevor Sie den Fähigkeitsstatus erneut abrufen. Der folgende Befehl löscht den Pod aus der vorherigen Iteration, also verwenden Sie ihn mit Vorsicht.

   kubectl -n uipath delete pod "$podName" --force

3. Starten Sie die Synchronisierung der Fähigkeiten. Der Pod kann einige Zeit zum Abrufen des Image und zur Ausführung benötigen, normalerweise weniger als 30 Sekunden.

   kubectl -n uipath run "$podName" --image="$aicJobsImage" --restart=Never --labels="app.kubernetes.io/component=aicenter" --overrides='{ "metadata": { "annotations": {"sidecar.istio.io/inject": "false"}}}' -- /bin/bash -c "curl -sSL -XPOST -H 'Content-Type: application/json' 'ai-deployer-svc.uipath.svc.cluster.local/ai-deployer/v1/system/mlskills:restore-all' -d "[skill_id1, skill_id2, .... ]; exit"

4. Überprüfen Sie die Ausgabe des Synchronisierungsstatus der Fähigkeiten.

   kubectl -n uipath logs -f "$podName" -c "$podName"

5. Der Vorgang kann je nach Anzahl der zu synchronisierenden Fähigkeiten viel Zeit in Anspruch nehmen und Sie können den Status der Fähigkeitsmigration regelmäßig überprüfen, bis keine Fähigkeit mehr im Status IN_PROGRESS vorhanden ist.

Hinweis:

Wenn Sie den Status der Fähigkeitsmigration überprüfen oder die Fähigkeitsmigration ausführen, gilt dies für alle Fähigkeiten gleichzeitig. Alternativ können Sie diese Vorgänge nur für ausgewählte Fähigkeiten ausführen, indem Sie -d "[skill_id1, skill_id2, .... ]" als zusätzliches Argument an curl in Schritt 3 übergeben.