- Überblick
- Anforderungen
- Installation
- Fragen und Antworten: Bereitstellungsvorlagen
- Herunterladen von Installationspaketen
- install-uipath.sh-Parameter
- Aktivieren eines High Availability Add-ons für den Cluster
- Document Understanding-Konfigurationsdatei
- Hinzufügen eines dedizierten Agent-Knotens mit GPU-Unterstützung
- Verbinden einer Task Mining-Anwendung
- Hinzufügen eines dedizierten Agent-Knotens für Task Mining
- Nach der Installation
- Clusterverwaltung
- Überwachung und Warnungen
- Migration und Upgrade
- Online-Auswertungsmodus mit einem einzelnen Knoten
- Offline-Auswertungsmodus mit einem einzelnen Knoten
- HA-fähiger Online-Produktionsmodus mit mehreren Knoten
- HA-fähiger Offline-Produktionsmodus mit mehreren Knoten
- Migrieren einer physischen Longhorn-Festplatte zum LVM
- Herabstufen von Ceph von 16.2.6 auf 15.2.9
- Migrationsoptionen
- B) Migration von einzelnen Mandanten
- Produktspezifische Konfiguration
- Best Practices und Wartung
- Fehlersuche und ‑behebung
- Fehlerbehebung bei Diensten während der Installation
- Deinstallieren des Clusters
- Löschen von Offline-Artefakten für mehr Speicherplatz
- So deaktivieren Sie TLS 1.0 und 1.1
- So können Sie die Istio-Protokollierung aktivieren
- So werden Protokolle manuell bereinigt
- So löschen Sie alte Protokolle, die im sf-logs-Paket gespeichert sind
- Fehlerbehebung bei fehlgeschlagenen Automation Suite-Installationen
- Deaktivieren von NIC-Prüfsummen-Offloading
- Es kann keine Offlineinstallation auf RHEL 8.4 OS ausgeführt werden.
- Fehler beim Herunterladen des Pakets
- Die Offlineinstallation schlägt aufgrund fehlender binärer Dateien fehl
- Zertifikatproblem bei der Offlineinstallation
- Validierungsfehler bei der SQL-Verbindungszeichenfolge
- Fehler nach der Zertifikatsaktualisierung
- Für die Automation Suite muss Backlog_wait_time festgelegt werden 1
- Anmeldung nach der Migration nicht mehr möglich
- Festlegen eines Timeout-Intervalls für die Verwaltungsportale
- Aktualisieren Sie die zugrunde liegenden Verzeichnisverbindungen
- Kinit: KDC für Bereich <AD-Domäne> kann beim Abrufen der ursprünglichen Anmeldeinformationen nicht gefunden werden
- Kinit: Keytab enthält keine geeigneten Schlüssel für *** beim Abrufen der ersten Anmeldeinformationen
- Der GSSAPI-Vorgang ist mit Fehler fehlgeschlagen: Es wurde ein ungültiger Statuscode übermittelt (Die Anmeldeinformationen des Clients wurden widerrufen).
- Anmeldung für Benutzer <ADDOMAIN><aduser> fehlgeschlagen. Grund: Das Konto ist deaktiviert.
- Alarm für fehlgeschlagenen Kerberos-tgt-update-Auftrag empfangen
- SSPI-Anbieter: Server nicht in Kerberos-Datenbank gefunden
- Fehler beim Abrufen des Sandbox-Abbilds
- Pods werden nicht in der ArgoCD-Benutzeroberfläche angezeigt
- Redis-Testfehler
- RKE2-Server kann nicht gestartet werden
- Secret nicht im UiPath-Namespace gefunden
- ArgoCD wechselt nach der ersten Installation in den Status „In Bearbeitung“.
- UNERWARTETE INKONSISTENZ; fsck MANUELL AUSFÜHREN
- Self-heal-operator und Sf-k8-utils-Repository fehlen
- Herabgestufte MongoDB- oder Geschäftsanwendungen nach der Clusterwiederherstellung
- Fehlerhafte Dienste nach Clusterwiederherstellung oder Rollback
- Document Understanding erscheint nicht auf der linken Leiste der Automation Suite
- Fehlerstatus beim Erstellen einer Datenbeschriftungssitzung
- Fehlerstatus beim Versuch, eine ML-Fähigkeit bereitzustellen
- Migrationsauftrag schlägt in ArgoCD fehl
- Die Handschrifterkennung mit dem Intelligent Form Extractor funktioniert nicht oder arbeitet zu langsam
- Verwenden des Automation Suite-Diagnosetools
- Verwenden des Automation Suite Support Bundle-Tools
- Erkunden von Protokollen
Übersicht über Zertifikate
https://automationsuite.mycompany.com/identity
.
Während zwei verschiedene Automation Suite-Produkte den FQDN des Clusters verwenden müssen, können sie auch mehrere Microservices enthalten. Diese Microservices können interne URLs verwenden, um miteinander zu kommunizieren.
Im folgenden Diagramm und Flow wird erläutert, wie der Client eine Verbindung mit einem Dienst herstellt und wie die Authentifizierung über den Identitätsdienst erfolgt.
- Der Client stellt eine Verbindung mit dem Dienst mithilfe der URL her, z. B. Orchestrator, Apps, Insights usw. mithilfe der folgenden URL:
https://automationsuite.mycompany.com/myorg/mytenant/service_
. - Istio fängt den Aufruf ab und leitet den Aufruf basierend auf dem Pfad von
service_
an den jeweiligen Dienst weiter. - Der Dienst ruft Identity Service auf, um die eingehende Anforderung vom Roboter über
https://automationsuite.mycompany.com/myorg/mytenant/identity_
zu authentifizieren. - Istio fängt den Aufruf ab und leitet die Anforderung basierend auf dem Pfad
identity_
an Identity Service weiter. - Identity Service gibt die Antwort mit dem Ergebnis an Istio zurück.
- Istio gibt die Antwort an den Dienst zurück. Da der Aufruf über das HTTPS-Protokoll erfolgt, gibt Istio die Antwort mit dem TLS-Zertifikat zurück, damit die Verbindung sicher ist. Wenn der Dienst dem von Istio zurückgegebenen Serverzertifikat vertraut, genehmigt er die Antwort. Andernfalls lehnt der Dienst die Antwort ab.
- Der Dienst bereitet die Antwort vor und sendet sie zurück an Istio.
-
Istio leitet die Anforderung zurück an den Client. Wenn die Clientmaschine dem Zertifikat vertraut, ist die gesamte Anforderung erfolgreich. Andernfalls schlägt die Anforderung fehl.
In diesem Abschnitt wird ein Szenario beschrieben, in dem ein Roboter versucht, eine Verbindung mit dem Orchestrator in der Automation Suite herzustellen. Im folgenden Diagramm und Flow wird erläutert, wie der Roboter eine Verbindung mit dem Orchestrator herstellt und wie die Authentifizierung über Identity Server erfolgt.
- Der Roboter stellt über die folgende URL eine Verbindung mit dem Orchestrator her:
https://automationsuite.mycompany.com/myorg/mytenant/orchestrator_
- Istio fängt den Aufruf ab und leitet ihn basierend auf dem
orchestrator_
-Pfad an den Orchestrator-Dienst weiter. - Der Orchestrator-Dienst ruft Identity Server auf, um die eingehende Anforderung vom Roboter über
https://automationsuite.mycompany.com/myorg/mytenant/identity_
zu authentifizieren. - Istio fängt den Aufruf ab und leitet die Anforderung basierend auf dem
identity_
-Pfad an Identity Server weiter. - Identity Server gibt die Antwort mit den Ergebnissen an Istio zurück.
- Istio gibt die Antwort an den Orchestrator zurück. Da der Aufruf über das HTTPS-Protokoll erfolgt, gibt Istio die Antwort mit dem TLS-Zertifikat zurück, sodass die Verbindung sicher ist. Wenn der Orchestrator dem von Istio zurückgegebenen Serverzertifikat vertraut, genehmigt er auch die Antwort. Andernfalls lehnt der Orchestrator die Antwort ab.
- Der Orchestrator bereitet die Antwort vor und sendet sie zurück an Istio.
-
Istio leitet die Anforderung zurück an den Roboter. Wenn die Robotermaschine dem Zertifikat vertraut, ist die gesamte Anforderung erfolgreich. Andernfalls schlägt die Anforderung fehl.
In diesem Beispiel verfügt der Container über ein eigenes Betriebssystem (RHEL OS), und der Dienst kann einen Orchestrator darstellen, der auf RHEL OS ausgeführt wird.
/etc/pki/ca-trust/ca/
.
In diesem Pfad speichert RHEL OS alle Zertifikate. Jeder Container verfügt über einen eigenen Trust Store für Zertifikate. Als Teil der Automation Suite-Konfiguration fügen wir das gesamte Kettenzertifikat ein, das das Stammzertifikat, alle Zwischenzertifikate sowie das Blattzertifikat enthält, und speichern sie in diesem Pfad. Da Dienste den Stamm- und Zwischenzertifikaten vertrauen, vertrauen sie automatisch allen anderen Zertifikaten, die von den Stamm- und Zwischenzertifikaten erstellt werden.
In der Automation Suite werden Hunderte von Containern ausgeführt. Das manuelle Hinzufügen von Zertifikaten für jeden dieser Container für alle Dienste wäre eine anspruchsvolle Aufgabe. Die Automation Suite enthält jedoch ein freigegebenes Volume und einen Init-Container -Cert-Trustor , um diese Aufgabe zu unterstützen. Init ist ein spezialisierter Container, der vor App-Containern in einem Pod ausgeführt wird, und sein Lebenszyklus endet, sobald er seinen Auftrag abgeschlossen hat.
Im folgenden Beispiel wird der Orchestrator-Dienst in einem Pod ausgeführt. Zur Erinnerung: Ein Pod kann mehr als einen Container enthalten. In diesem Pod fügen wir einen weiteren Init-Container namens Cert-trustorein. Dieser Container enthält das Stammzertifikat, die Zwischenzertifikate und das Blattzertifikat.
/etc/pki/ca-trust/ca/source/anchors
.
/etc/pki/ca-trust/ca/source/anchors
hinzufügt und beendet.
Zertifikate sind für den Orchestrator-Dienst über das freigegebene Volume verfügbar.
Als Teil der Installation der Automation Suite werden die folgenden Zertifikate generiert:
- Selbstsigniertes Zertifikat, das zum Zeitpunkt der Installation erstellt wird und drei Monate lang gültig ist. Nach der Installation müssen Sie das selbstsignierte Zertifikat durch ein Domänenzertifikat ersetzen. Siehe Verwalten von Zertifikaten.
- Identity Server-Zertifikat zum Signieren von JWT-Tokens, die bei der Authentifizierung verwendet werden. Wird das Zertifikat zum Signieren des JWT-Tokens nicht bereitgestellt, so verwendet die Automation Suite das aktuell konfigurierte TLS-Zertifikat (kann ein selbst signiertes oder ein vom Kunden bereitgestelltes sein), das nach 90 Tagen abläuft. Möchten Sie Ihr eigenes Zertifikat zum Signieren des Identitätstokens verwenden, können Sie es mithilfe der Anweisungen in Verwaltung von Zertifikaten konfigurieren.
-
Internes Zertifikat für MongoDB , das über den Zertifikatsmanager generiert wurde. Die Automation Suite-Version 2021.10.3 und älter stellt ein internes Zertifikat für MongoDB bereit, das 90 Tage gültig ist. Ab Version 2021.10.4 Zertifikate sind 3 Jahre gültig und werden automatisch aktualisiert.
Weitere Informationen finden Sie unter MongoDB – Manuelle Zertifikatsaktualisierung für Apps-Benutzer.
- RKE2-Zertifikate werden generiert und laufen standardmäßig in 12 Monaten ab. Wenn die Zertifikate bereits abgelaufen sind oder in weniger als 90 Tagen ablaufen, werden sie beim Neustart von RKE2 rotiert.
- Wenn aktiviert, kann das SAML2-Authentifizierungsprotokoll ein Dienstzertifikat verwenden.
- Wenn Sie Active Directory mit einem Benutzernamen und Kennwort konfigurieren, ist LDAPS (LDAP über SSL) optional. Wenn Sie sich für LDAPS entscheiden, müssen Sie ein Zertifikat bereitstellen. Dieses Zertifikat wird den vertrauenswürdigen Stammzertifizierungsstellen der Automation Suite hinzugefügt. Weitere Informationen finden Sie in der Microsoft-Dokumentation.
Dieses Zertifikat wird den vertrauenswürdigen Stammzertifizierungsstellen der Automation Suite hinzugefügt.
Die Zertifikate werden an zwei Orten gespeichert:
istio-ingressgateway-certs
inistio-system
uipath
-Namespace
istio-system
und uipath
zu aktualisieren, müssen Sie den Befehl sudo ./configureUiPathAS.sh tls-cert update
ausführen.
uipath
ausgeführt werden, nicht auf die Geheimnisse zugreifen, die im Namespace istio-system
gespeichert sind. Daher werden Zertifikate in beide Namespaces kopiert.
uipath
stellen wir die Zertifikate in den Pods bereit, die Zertifikate benötigen, und starten die Pods neu, damit sie die neuen Zertifikate verwenden können.
Bei Evaluierungsinstallationen mit einem Knoten werden die Pods durch das Update verkleinert. Alle Pods werden heruntergefahren und neu gestartet. Dieser Vorgang führt zu Ausfallzeiten.
Bei HA-fähigen Produktionsinstallationen mit mehreren Knoten erfolgt die Aktualisierung mit der fortlaufenden Bereitstellungsmethode. Wenn Microservices zwei Pods für Hochverfügbarkeitszwecke haben, löscht das Update einen der Pods und eine neue Version des Pods wird angezeigt. Sobald der neue erfolgreich gestartet wurde, wird der alte entfernt. Es wird eine kurze Ausfallzeit geben, während der alte Pod noch nicht beendet ist.
rootCA.crt
und tls.crt
verwendet werden. Zertifikate werden in der ArgoCD- und Docker-Registrierung verwendet und dann sowohl im Docker- als auch im ArgoCD-Namespace gespeichert.
Sie können die Geheimnisse mit dem folgenden Befehl überprüfen:
# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd cert list --cert-type https
# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd cert list --cert-type https
- Funktionsweise von Vertrauenszertifikaten
- Verstehen, wie Kommunikation funktioniert
- Verstehen, wie Roboter und Orchestrator kommunizieren
- Grundlegendes zur Containerarchitektur im Zusammenhang mit Zertifikaten
- Containerebene
- Pod-Ebene
- Bestandsaufnahme aller Zertifikate in der Automation Suite
- Während der Installation generierte Zertifikate
- Zusätzliche Zertifikate
- Funktionsweise der Zertifikatsaktualisierung/-rotation
- Onlineinstallation
- Offline-Installation