- Überblick
- Anforderungen
- Vor der Installation
- Vorbereiten der Installation
- Installieren und Konfigurieren des Dienstgeflechts
- Herunterladen der Installationspakete
- Konfigurieren der OCI-konformen Registrierung
- Erteilen von Installationsberechtigungen
- Installieren und Konfigurieren des GitOps-Tools
- Anwenden verschiedener Konfigurationen
- Ausführen von uipathctl
- Installation
- Nach der Installation
- Migration und Upgrade
- Aktualisieren der Automation Suite
- Migrieren von eigenständigen Produkten zur Automation Suite
- Schritt 1: Wiederherstellen der eigenständigen Produktdatenbank
- Schritt 2: Aktualisieren des Schemas der wiederhergestellten Produktdatenbank
- Schritt 3: Verschieben der Identitätsorganisationsdaten von der eigenständigen Bereitstellung in die Automation Suite
- Schritt 4: Sichern der Plattformdatenbank in der Automation Suite
- Schritt 5: Zusammenführen von Organisationen in der Automation Suite
- Schritt 6: Aktualisieren der migrierten Produktverbindungszeichenfolgen
- Schritt 7: Migrieren des eigenständigen Orchestrator
- Schritt 8: Migrieren von eigenständigen Insights
- Schritt 9: Migrieren des eigenständigen Test Managers
- Schritt 10: Löschen des Standardmandanten
- Durchführen der Migration eines einzelnen Mandanten
- Migrieren zwischen Automation Suite-Clustern
- Migrieren von der Automation Suite auf EKS/AKS zur Automation Suite auf OpenShift
- Überwachung und Warnungen
- Clusterverwaltung
- Produktspezifische Konfiguration
- Erweiterte Orchestrator-Konfiguration
- Konfigurieren von Orchestrator-Parametern
- Konfigurieren von AppSettings
- Konfigurieren der maximalen Anforderungsgröße
- Überschreiben der Speicherkonfiguration auf Clusterebene
- Konfigurieren von NLog
- Speichern von Roboterprotokollen in Elasticsearch
- Konfigurieren von Anmeldeinformationsspeichern
- Konfigurieren der Verwendung von einem Verschlüsselungsschlüssel pro Mandant
- Bereinigen der Orchestrator-Datenbank
- Installation der Hostbibliothek überspringen
- Fehlersuche und ‑behebung
- Zugriff auf Automation Hub nach Upgrade auf Automation Suite 2024.10.0 nicht mehr möglich
- AI Center-Bereitstellungsfehler nach Upgrade auf 2023.10 oder höher
- Insights-Volumes, die nach der Migration in zwei verschiedenen Zonen erstellt wurden
- Upgrade schlägt aufgrund überschriebener Insights-PVC-Größen fehl
- 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
- Der Roboter kann keine Verbindung mit einer Automation Suite-Orchestrator-Instanz herstellen
- Protokollstreaming funktioniert nicht in Proxy-Setups
- Die Velero-Sicherung schlägt mit dem Fehler „FehlgeschlageneValidierung“ fehl
- Beim Zugriff auf den FQDN wird RBAC zurückgegeben: Zugriff verweigert
- Validierungsfehler beim TLS-Zertifikat
- Manual ArgoCD NetworkPolicy mitigation (GHSA-47m3-95c7-g2g8)
Konfigurieren Sie Azure- oder AWS-Netzwerkressourcen, um die Konnektivität und den Cloud-Infrastrukturzugriff für die Automation Suite auf EKS/AKS sicherzustellen.
Sie müssen Azure- oder AWS-Netzwerkressourcen bereitstellen und konfigurieren, um sicherzustellen, dass die Automation Suite in Ihrem Cluster über Konnektivität und Zugriff auf die Cloud-Infrastrukturvoraussetzungen verfügt (z. B. Speicher, Datenbank, Cache und DNS). Je nach Netzwerkarchitektur kann dies die Konfiguration von VNETs/VPC, DNS, Subnetzen, NSGs/Sicherheitsgruppen, NAT-Gateway, elastischen IP und Internetgateway umfassen. Weitere Informationen dazu finden Sie unter Bereitstellungsszenarien.
Beachten Sie, dass je nach Workload-Skalierung möglicherweise mehr Replikate benötigt werden. Standardmäßig erfordert der HA-Modus zwei Replikate und kann bis zu zehn oder mehr Replikate umfassen. Stellen Sie sicher, dass Ihr Netzwerk diese Skalierungsstufe unterstützt.
You can use any CNI as long as pods can communicate with one another. Additionally, to benefit from the network policies included with Automation Suite, your CNI must support and enforce Kubernetes network policies. Some CNIs, such as the Amazon VPC CNI, do not enable network policy enforcement by default. For details, refer to Networking policies.
There are special considerations for cloud CNIs such as Azure CNI and Amazon VPC CNI, which do not support internal or private pod networking subnets. The number of pods required for Automation Suite depends on your product selection and workload scaling. For instance, for a deployment with all the services enabled and at high utilization, you might need over 400 IPs to support the scaling requirements.
Because of this, we recommend allocating a CIDR range of at least /23.
Die Automation Suite unterstützt nicht das IPv6-Internetprotokoll.
Änderungen an IP-Tabellen werden nicht empfohlen oder unterstützt.
Benutzerdefinierter Ingress-Controller
Wenn Sie einen benutzerdefinierten Ingress-Controller (NGINX) haben, lesen Sie Konfigurieren des NGINX-Ingress und überspringen Sie den Rest der Seite.
Konfiguration des Lastausgleichs
Die Automation Suite stellt während der Installation einen Lastausgleich in Ihrem Namen bereit. Dem Lastausgleich müssen öffentliche oder private IP-Adressen zugewiesen werden, damit er die eingehenden FQDN-Anforderungen weiterleiten kann. Sie haben zwei Optionen, um den Lastausgleich zu konfigurieren:
- Vorab zugewiesene IPs: Weisen Sie öffentliche oder private IPs für den Lastausgleich zu, konfigurieren Sie die DNS-Datensätze, um die FQDNs diesen IPs zuzuordnen, und geben Sie diese IPs als Teil des Ingress-Abschnitts von
input.jsonan . - Dynamisch zugewiesene IPs: Wenn Sie keine IP-Adresse angeben, weist die Automation Suite dynamisch IPs aus dem Cluster-Subnetz dem Lastenausgleich zu.
Die Netzwerksicherheitsgruppen auf dem Lastenausgleich müssen HTTPS-Datenverkehr von Endclients über Port 443 zulassen. Standardmäßig konfigurieren wir den Lastausgleich so, dass er regelmäßige TCP-Zustandsprüfungen durchführt.
Wenn Sie Ihr eigenes Ingress wie NGINX verwenden, stellen Sie sicher, dass Sie die Netzwerkanforderungen erfüllen, die unter Konfigurieren der NGINX Ingress Controldokumentiert sind. Wenn Sie Istio verwenden, das einen NLB bereitstellt, beachten Sie, dass in der Regel drei Listener erstellt werden, darunter die Ports 80, 443 und 15021. Dies ist jedoch ein typisches Setup, und Ihre tatsächlichen Anforderungen können je nach Ihren genauen Gegebenheiten abweichen, also passen Sie sie nach Bedarf an.
Vorab zugewiesene IPs
Sie müssen die folgenden Dienstanmerkungen im Abschnitt ingress von input.json.
Eine Liste der Dienstanmerkungen in EKS finden Sie in der Dokumentation zum AWS Load Balancer.
Eine Liste der Dienstanmerkungen in AKS finden Sie in der Dokumentation zum Azure Load Balancer.
Beispiele für EKS-Anmerkungen
Die folgenden Beispiele zeigen, wie der Abschnitt ingress.service_annotations in input.json erstellt wird. Sie müssen vor der Installation einen AWS Load Balancer-Controller auf Ihrem EKS-Cluster bereitstellen, damit die Beispiele ordnungsgemäß funktionieren.
Das folgende Beispiel zeigt, wie elastische IPs von AWS zugewiesen und ein öffentlicher Lastausgleich bereitgestellt wird. Wenn Sie dieses Beispiel als Ausgangspunkt für Ihre Konfiguration verwenden, stellen Sie sicher, dass Sie die IPs durch tatsächliche Werte ersetzen.
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
"service.beta.kubernetes.io/aws-load-balancer-eip-allocations": "<elastic_ip_id_0>,<elastic_ip_id_1>",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internet-facing",
"service.beta.kubernetes.io/aws-load-balancer-type": "nlb"
}
}
...
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
"service.beta.kubernetes.io/aws-load-balancer-eip-allocations": "<elastic_ip_id_0>,<elastic_ip_id_1>",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internet-facing",
"service.beta.kubernetes.io/aws-load-balancer-type": "nlb"
}
}
...
Das folgende Beispiel zeigt, wie einem internen Lastenausgleich private IPs aus den EKS-Clustersubnetzen zugewiesen werden. Wenn Sie dieses Beispiel als Ausgangspunkt für Ihre Konfiguration verwenden, stellen Sie sicher, dass Sie die IPs und Subnetze mit tatsächlichen Werten aktualisieren.
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
"service.beta.kubernetes.io/aws-load-balancer-private-ipv4-addresses":""<IP_0>,<IP_1>"",
"service.beta.kubernetes.io/aws-load-balancer-subnets": "SUBNET_ID_0>,<SUBNET_ID_1>",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internal",
"service.beta.kubernetes.io/aws-load-balancer-type": "nlb"
"service.beta.kubernetes.io/aws-load-balancer-target-group-attributes": "preserve_client_ip.enabled=false"
}
}
...
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
"service.beta.kubernetes.io/aws-load-balancer-private-ipv4-addresses":""<IP_0>,<IP_1>"",
"service.beta.kubernetes.io/aws-load-balancer-subnets": "SUBNET_ID_0>,<SUBNET_ID_1>",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internal",
"service.beta.kubernetes.io/aws-load-balancer-type": "nlb"
"service.beta.kubernetes.io/aws-load-balancer-target-group-attributes": "preserve_client_ip.enabled=false"
}
}
...
IPs und Subnetze müssen übereinstimmen.
Im vorherigen Beispiel ist <IP_0> in <SUBNET_0> und <IP_1> in <SUBNET_1>.
Beispiel für AKS-Anmerkungen
Das folgende Beispiel zeigt, wie öffentliche IPs von Azure zugewiesen und ein öffentlicher Lastausgleich bereitgestellt wird. Wenn Sie dieses Beispiel als Ausgangspunkt für Ihre Konfiguration verwenden, stellen Sie sicher, dass Sie die IPs mit tatsächlichen Werten aktualisieren.
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/azure-load-balancer-internal": "false",
"service.beta.kubernetes.io/azure-load-balancer-ipv4": "<IP>"
}
}
...
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/azure-load-balancer-internal": "false",
"service.beta.kubernetes.io/azure-load-balancer-ipv4": "<IP>"
}
}
...
Das folgende Beispiel zeigt, wie private IPs einem internen Lastausgleich aus den AKS-Cluster-Subnetzen zugewiesen werden. Wenn Sie dieses Beispiel als Ausgangspunkt für Ihre Konfiguration verwenden, stellen Sie sicher, dass Sie die IPs und Subnetze mit den tatsächlichen Werten aktualisieren.
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/azure-load-balancer-internal": "true",
"service.beta.kubernetes.io/azure-load-balancer-ipv4": "<IP>",
"service.beta.kubernetes.io/azure-load-balancer-internal-subnet": "<SUBNET>",
}
}
...
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/azure-load-balancer-internal": "true",
"service.beta.kubernetes.io/azure-load-balancer-ipv4": "<IP>",
"service.beta.kubernetes.io/azure-load-balancer-internal-subnet": "<SUBNET>",
}
}
...
DNS-Konfiguration
Stellen Sie sicher, dass die DNS-Datensätze so konfiguriert sind, dass sie die folgenden UiPath®-FQDNs dem Lastausgleich zuordnen:
FQDNalm.FQDNmonitoring.FQDNinsights.FQDN(bei Installation von UiPath Insights)apps.FQDN(wenn UiPath Apps installiert wird)
Der FQDN ist eine der Voraussetzungsprüfungen vor der Installation. Wenn Sie keine IP-Adresse angeben oder die FQDN-Zuordnung noch nicht durchgeführt haben, schlägt die Prüfung fehl.
Wenn Sie Route 53 für DNS verwenden, ändern Sie die relevanten DNS-Datensätze in Alias-Datensätze, die direkt auf den Elastic Load Balancer (ELB) verweisen, der während der Installation erstellt wurde. Dies gewährleistet ein korrektes Routing und eine schnellere Lösung, insbesondere wenn mehrere öffentliche IPs bei Multi-AZ-Installationen in AWS-Umgebungen beteiligt sind.
Dynamisch zugewiesene IPs
Wenn Sie keine IPs in input.jsonangeben, weist die Automation Suite dynamisch die privaten IPs aus den Subnetzen der Arbeiterknoten zu. Führen Sie in diesem Szenario die Automation Suite Installation wie folgt aus.
EKS-Beispiel für input.json
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internal",
"service.beta.kubernetes.io/aws-load-balancer-type": "nlb",
"service.beta.kubernetes.io/aws-load-balancer-internal": true
}
}
...
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "ssl",
"service.beta.kubernetes.io/aws-load-balancer-nlb-target-type": "ip",
"service.beta.kubernetes.io/aws-load-balancer-scheme": "internal",
"service.beta.kubernetes.io/aws-load-balancer-type": "nlb",
"service.beta.kubernetes.io/aws-load-balancer-internal": true
}
}
...
AKS-Beispiel für input.json
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/azure-load-balancer-internal": "true"
}
}
...
...
"ingress": {
"service_annotations": {
"service.beta.kubernetes.io/azure-load-balancer-internal": "true"
}
}
...
Installationsschritte
Führen Sie in diesem Szenario das Installationsprogramm wie folgt aus:
- Führen Sie das Installationsprogramm nur bis zur Bereitstellung des Lastenausgleichs aus:
uipathctl manifest apply <INPUT_JSON> --versions <VERSIONS_JSON> --override=gatewayuipathctl manifest apply <INPUT_JSON> --versions <VERSIONS_JSON> --override=gateway - Rufen Sie den Hostnamen des Lastenausgleichs ab:
kubectl get svc -n <istio-system> istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'kubectl get svc -n <istio-system> istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}' - Konfigurieren Sie Ihr DNS mit FQDNs, die dem Lastausgleichsendpunkt oder den IPs zugeordnet sind.
- Führen Sie das Installationsprogramm erneut aus, um die Installation abzuschließen:
uipathctl manifest apply input.json --versions versions.jsonuipathctl manifest apply input.json --versions versions.json
Beachten Sie, dass die Überprüfung der FQDN-Voraussetzungen ohne DNS-Zuordnung fehlschlägt. Voraussetzungsprüfungen sollen Ihnen die Gewissheit geben, dass Sie alle Voraussetzungen korrekt bereitgestellt haben, bevor Sie die Automation Suite installieren. Die Überprüfung des FQDN hindert Sie nicht daran, die Automation Suite zu installieren.