- Überblick
- Anforderungen
- Installation
- Nach der Installation
- Migration und Upgrade
- Aktualisieren der Automation Suite auf EKS/AKS
- Schritt 1: Verschieben der Identitätsorganisationsdaten von einer eigenständigen in die Automation Suite
- Schritt 2: Wiederherstellen der eigenständigen Produktdatenbank
- Schritt 3: Sichern der Plattformdatenbank in der Automation Suite
- Schritt 4: Zusammenführen von Organisationen in der Automation Suite
- Schritt 5: Aktualisieren der migrierten Produktverbindungszeichenfolgen
- Schritt 6: Migrieren des eigenständigen Orchestrators
- Schritt 7: Migrieren von eigenständigen Insights
- Schritt 8: Migrieren des eigenständigen Test Managers
- Schritt 9: Löschen des Standardmandanten
- Durchführen der Migration eines einzelnen Mandanten
- Migrieren von der Automation Suite unter Linux zur Automation Suite unter EKS/AKS
- Überwachung und Warnungen
- Clusterverwaltung
- Produktspezifische Konfiguration
- Konfigurieren von Orchestrator-Parametern
- Orchestrator-appSettings
- Konfigurieren von AppSettings
- Konfigurieren der maximalen Anforderungsgröße
- Überschreiben der Speicherkonfiguration auf Clusterebene
- Konfigurieren von Anmeldeinformationsspeichern
- Konfigurieren der Verwendung von einem Verschlüsselungsschlüssel pro Mandant
- Bereinigen der Orchestrator-Datenbank
- Fehlersuche und ‑behebung
- Das Sicherungssetup funktioniert nicht, da die Verbindung mit Azure Government fehlgeschlagen ist
- Hängende Pods im uipath-Namespace bei Aktivierung von benutzerdefinierten Knoten-Markierungen
- Automation Hub und Apps können mit Proxy-Setup nicht gestartet werden
- Pods können nicht mit FQDN in einer Proxy-Umgebung kommunizieren
- SQL-Verbindungszeichenfolge der Testautomatisierung wird ignoriert
- EKS-Sicherung aufgrund der Velero-Version
- Die Velero-Sicherung schlägt mit dem Fehler „FehlgeschlageneValidierung“ fehl
- Beim Zugriff auf den FQDN wird der Fehler „RBAC-Zugriff verweigert“ zurückgegeben
- Manuelle Schadensbegrenzung bei ArgoCD NetworkPolicy (GHSA-47m3-95c7-g2g8)
Verwalten des Clusters in ArgoCD
Verwalten Sie den Automation Suite-Cluster mithilfe von ArgoCD für GitOps-basierte kontinuierliche Bereitstellung auf EKS/AKS.
Überblick
ArgoCD ist ein deklaratives Tool zur kontinuierlichen Bereitstellung von GitOps für Kubernetes. Es ist als Kubernetes-Controller konzipiert, der ausgeführte UiPath®-Anwendungen kontinuierlich überwacht und den aktuellen Status mit dem gewünschten Zielstatus abgleicht, wie in der Docker-Registrierung angegeben. Weitere Informationen finden Sie in der ArgoCD-Dokumentation.
Administratoren können sich über eine einfache UI oder CLI einen Überblick über den Cluster, die Konfigurationen, den Anwendungsstatus und die Integrität verschaffen. ArgoCD wird mit seinem eigenen Open-Source-Paket Redis geliefert, das sowohl HA- als auch Nicht-HA-Konfigurationen unterstützt.
Die Automation Suite verwendet ArgoCD in den folgenden Szenarien:
- Installieren und Upgraden der Fabric-Komponenten und der grundlegenden UiPath®-Dienste.
- Automatisieren der Bereitstellung der gewünschten Anwendungsstatus in den angegebenen Zielumgebungen. ArgoCD folgt dem GitOps-Muster, bei dem Git/Helm-Repositorys als Quelle der Wahrheit zum Definieren des gewünschten Anwendungsstatus verwendet werden.
- Verfolgen des Installationsstatus. Wenn die Installation an einem bestimmten Punkt fehlgeschlagen ist und Sie sie nach einer Weile fortsetzen, überspringt ArgoCD alle Schritte, die bereits synchronisiert sind, und fährt an der Stelle fort, an der sie fehlgeschlagen ist.
- Selbstreparatur der Anwendungen. Wenn Sie eines der Objekte versehentlich löschen, werden die Manifeste automatisch synchronisiert.
Schreibgeschützte ArgoCD-Szenarien
Sie können das ArgoCD-Konto in den folgenden schreibgeschützten Szenarien verwenden:
- Visualisieren Sie alle Ihre Apps, Pods und Dienste in einer einfachen Oberfläche
- Überwachen des Zustands aller Ihrer Apps, Pods und Dienste
- Schnelles Identifizieren von Problemen in Ihrer Bereitstellung
- Ihre Anwendung in Ihrem Cluster wird erneut synchronisiert
Erweiterte ArgoCD-Szenarien
Sie dürfen keine anderen Einstellungen oder Parameter ändern, außer den in diesem Abschnitt aufgeführten.
Sie können das ArgoCD-Administratorkonto in den folgenden erweiterten Szenarien verwenden :
- Ändern von Parametern nur zu Debugging-Zwecken; zum Beispiel das Deaktivieren der Selbstkorrektur;
- Löschen von Pods;
- Fehlerbehebung;
- Verwalten der benutzerdefinierten Orchestrator-Konfiguration; zum Beispiel: Einrichten des Verschlüsselungsschlüssels pro Mandant;
- Aktualisieren der Datenbankverbindungszeichenfolgen;
- Synchronisierung von Anwendungen.
Hinweis:
Lesen Sie die richtige UiPath®-Dokumentation, bevor Sie die erweiterte Konfiguration auf der Benutzeroberfläche löschen oder ändern.
Zugreifen auf ArgoCD
ArgoCD unterstützt zwei Authentifizierungsmethoden:
- Benutzername und Kennwort – Standardauthentifizierungsmethode;
- SSO – Empfohlene Authentifizierungsmethode. Sie können die SSO-Authentifizierung nach der Installation aktivieren. Weitere Informationen finden Sie unter Aktivieren von SSO für ArgoCD.
Benutzername und Kennwort-Authentifizierung
Zugriff auf das ArgoCD-Administratorkonto
Um mit Benutzername und Kennwort auf das ArgoCD-Administratorkonto zuzugreifen, führen Sie die folgenden Schritte aus:
- Greifen Sie auf die folgende URL zu:
https://alm.${CONFIG_CLUSTER_FQDN}. - Geben Sie den folgenden Benutzernamen ein: admin .
- Zugriff auf das Kennwort:
kubectl get secret -n argocd argocd-initial-admin-secret -o jsonpath='{.data.password}' | base64 -dkubectl get secret -n argocd argocd-initial-admin-secret -o jsonpath='{.data.password}' | base64 -d - Geben Sie Ihr Kennwort ein.
Wichtig:
Sie dürfen das ArgoCD-Administratorkonto nur für erweiterte Szenarien verwenden. Es kann zu Unterbrechungen im Cluster führen, wenn es nicht mit Vorsicht verwendet wird.
SSO-Authentifizierung
Um über SSO auf ArgoCD zuzugreifen, führen Sie die folgenden Schritte aus:
- Wählen Sie die Schaltfläche SSO auf der ArgoCD-Anmeldeseite aus.
- Geben Sie die Anmeldeinformationen für die Unternehmensdomäne ein.
Aktivieren von SSO für ArgoCD
Überblick
Um die SSO-Authentifizierung zu aktivieren, müssen Sie das uipathctl-Befehlszeilentool verwenden.
Vorbereiten der Konfigurationsdateien
Sie müssen die RBAC-Datei generieren, bevor Sie SSO für ArgoCD aktivieren.
Die RBAC-Datei
Die RBAC-Datei enthält Zugriffsregeln.
Weitere Informationen zu den integrierten Rollendefinitionen finden Sie in der ArgoCD-Dokumentation.
Weitere Informationen zu den ArgoCD-Kontotypen und deren Berechtigungen finden Sie unter Verwalten des Clusters in ArgoCD.
Wir empfehlen, diese Rollen beim Definieren Ihrer Gruppen zu verwenden, aber Sie können auch Ihre eigenen Berechtigungen erstellen.
Konfigurieren der RBAC-Datei
- Erstellen Sie eine Datei mit dem Namen
policy.csv, indem Sie den folgenden Befehl ausführen:uipathctl config argocd generate-rbacuipathctl config argocd generate-rbac - Fügen Sie der Datei
policy.csvden folgenden Inhalt hinzu und speichern Sie sie:p, role:uipath-sync, applications, get, */*, allow p, role:uipath-sync, applications, sync, */*, allow g, argocdro, role:uipath-syncp, role:uipath-sync, applications, get, */*, allow p, role:uipath-sync, applications, sync, */*, allow g, argocdro, role:uipath-sync - Verknüpfen Sie Ihre RBAC-Gruppen mit der integrierten Administratorrolle und der schreibgeschützten UiPath®-Rolle argocdro , indem Sie die folgenden Zeilen an die RBAC-Datei
policy.csvanfügen:g, <your_ldap_readonly_group_name>, role:uipath-sync g, <your_ldap_admin_group_name>, role:adming, <your_ldap_readonly_group_name>, role:uipath-sync g, <your_ldap_admin_group_name>, role:admin - Speichern Sie die aktualisierte
policy.csvRBAC-Datei. - Erstellen Sie einen neuen Abschnitt mit dem Namen
policy.defaultin derargo-cd-rbac-cm-Konfigurationsübersicht nach dempolicy.csv-Abschnitt, wie im folgenden Beispiel gezeigt:policy.csv: | p, role:org-admin, applications, *, /, allow p, role:org-admin, clusters, get, *, allow p, role:org-admin, repositories, get, *, allow p, role:org-admin, repositories, create, *, allow p, role:org-admin, repositories, update, *, allow p, role:org-admin, repositories, delete, *, allow g, "694afc07-6767-8998-bf84-ab80b53379df", role:org-admin # (azure group assigned to role) policy.default: role:readonlypolicy.csv: | p, role:org-admin, applications, *, /, allow p, role:org-admin, clusters, get, *, allow p, role:org-admin, repositories, get, *, allow p, role:org-admin, repositories, create, *, allow p, role:org-admin, repositories, update, *, allow p, role:org-admin, repositories, delete, *, allow g, "694afc07-6767-8998-bf84-ab80b53379df", role:org-admin # (azure group assigned to role) policy.default: role:readonly - Informationen zum Konfigurieren von SSO mit OIDC finden Sie in der ArgoCD-Dokumentation.
Beispiel
Wenn Ihre LDAP-Gruppe für ArgoCD-Administratoren Administratoren und die LDAP-Gruppe für schreibgeschützte ArgoCD-Benutzer Leser ist, sollte die RBAC-Datei der im folgenden Beispiel ähneln:
p, role:uipath-sync, applications, get, */*, allow
p, role:uipath-sync, applications, sync, */*, allow
g, argocdro, role:uipath-sync
g, Readers, role:uipath-sync
g, Administrators, role:admin
p, role:uipath-sync, applications, get, */*, allow
p, role:uipath-sync, applications, sync, */*, allow
g, argocdro, role:uipath-sync
g, Readers, role:uipath-sync
g, Administrators, role:admin
Für erweiterte Anwendungsfälle zeigt das folgende Beispiel die standardmäßige RBAC-Datei:
# Built-in policy which defines two roles: role:readonly and role:admin,
# and additionally assigns the admin user to the role:admin role.
# There are two policy formats:
# 1. Applications, logs, and exec (which belong to a project):
# p, <user/group>, <resource>, <action>, <project>/<object>
# 2. All other resources:
# p, <user/group>, <resource>, <action>, <object>
p, role:readonly, applications, get, */*, allow
p, role:readonly, certificates, get, *, allow
p, role:readonly, clusters, get, *, allow
p, role:readonly, repositories, get, *, allow
p, role:readonly, projects, get, *, allow
p, role:readonly, accounts, get, *, allow
p, role:readonly, gpgkeys, get, *, allow
p, role:readonly, logs, get, */*, allow
p, role:admin, applications, create, */*, allow
p, role:admin, applications, update, */*, allow
p, role:admin, applications, delete, */*, allow
p, role:admin, applications, sync, */*, allow
p, role:admin, applications, override, */*, allow
p, role:admin, applications, action/*, */*, allow
p, role:admin, applicationsets, get, */*, allow
p, role:admin, applicationsets, create, */*, allow
p, role:admin, applicationsets, update, */*, allow
p, role:admin, applicationsets, delete, */*, allow
p, role:admin, certificates, create, *, allow
p, role:admin, certificates, update, *, allow
p, role:admin, certificates, delete, *, allow
p, role:admin, clusters, create, *, allow
p, role:admin, clusters, update, *, allow
p, role:admin, clusters, delete, *, allow
p, role:admin, repositories, create, *, allow
p, role:admin, repositories, update, *, allow
p, role:admin, repositories, delete, *, allow
p, role:admin, projects, create, *, allow
p, role:admin, projects, update, *, allow
p, role:admin, projects, delete, *, allow
p, role:admin, accounts, update, *, allow
p, role:admin, gpgkeys, create, *, allow
p, role:admin, gpgkeys, delete, *, allow
p, role:admin, exec, create, */*, allow
g, role:admin, role:readonly
g, admin, role:admin
# Built-in policy which defines two roles: role:readonly and role:admin,
# and additionally assigns the admin user to the role:admin role.
# There are two policy formats:
# 1. Applications, logs, and exec (which belong to a project):
# p, <user/group>, <resource>, <action>, <project>/<object>
# 2. All other resources:
# p, <user/group>, <resource>, <action>, <object>
p, role:readonly, applications, get, */*, allow
p, role:readonly, certificates, get, *, allow
p, role:readonly, clusters, get, *, allow
p, role:readonly, repositories, get, *, allow
p, role:readonly, projects, get, *, allow
p, role:readonly, accounts, get, *, allow
p, role:readonly, gpgkeys, get, *, allow
p, role:readonly, logs, get, */*, allow
p, role:admin, applications, create, */*, allow
p, role:admin, applications, update, */*, allow
p, role:admin, applications, delete, */*, allow
p, role:admin, applications, sync, */*, allow
p, role:admin, applications, override, */*, allow
p, role:admin, applications, action/*, */*, allow
p, role:admin, applicationsets, get, */*, allow
p, role:admin, applicationsets, create, */*, allow
p, role:admin, applicationsets, update, */*, allow
p, role:admin, applicationsets, delete, */*, allow
p, role:admin, certificates, create, *, allow
p, role:admin, certificates, update, *, allow
p, role:admin, certificates, delete, *, allow
p, role:admin, clusters, create, *, allow
p, role:admin, clusters, update, *, allow
p, role:admin, clusters, delete, *, allow
p, role:admin, repositories, create, *, allow
p, role:admin, repositories, update, *, allow
p, role:admin, repositories, delete, *, allow
p, role:admin, projects, create, *, allow
p, role:admin, projects, update, *, allow
p, role:admin, projects, delete, *, allow
p, role:admin, accounts, update, *, allow
p, role:admin, gpgkeys, create, *, allow
p, role:admin, gpgkeys, delete, *, allow
p, role:admin, exec, create, */*, allow
g, role:admin, role:readonly
g, admin, role:admin
Aktivieren von SSO für ArgoCD
Nachdem Sie die RBAC-Datei vorbereitet haben, können Sie SSO für ArgoCD aktivieren:
- Fügen Sie die folgenden Zeilen zur Datei
input.jsonhinzu:{ "fabric": { "argocd_rbac_config_file": "/path/to/policy.csv" } }{ "fabric": { "argocd_rbac_config_file": "/path/to/policy.csv" } } - Übernehmen Sie die Konfiguration, indem Sie den folgenden Befehl ausführen:
uipathctl manifest apply input.json --versions versions.jsonuipathctl manifest apply input.json --versions versions.json