UiPath Documentation
automation-suite
2.2510
true
Automation Suite in OpenShift – Installationsanleitung
Wichtig :
Bitte beachten Sie, dass dieser Inhalt teilweise mithilfe von maschineller Übersetzung lokalisiert wurde. Es kann 1–2 Wochen dauern, bis die Lokalisierung neu veröffentlichter Inhalte verfügbar ist.

Installieren und Konfigurieren des GitOps-Tools

Installieren und konfigurieren Sie das GitOps-Tool zum Verwalten von Automation Suite-Bereitstellungen auf OpenShift.

Hinweis:

Bevor Sie mit der Installation und Konfiguration von OpenShift GitOps Operator fortfahren, müssen Sie OpenShift Service Mesh installieren und alle erforderlichen Berechtigungen für das uipathadmin -Dienstkonto bereitstellen.

Anweisungen zur Installation und Konfiguration des Service Mesh finden Sie unter Installieren und Konfigurieren des Service Meshs.

Die Installationsberechtigungen finden Sie unter Gewährung von Installationsberechtigungen.

Sie können die Automation Suite entweder mit einer OpenShift GitOps Operator-Instanz bereitstellen, die für die UiPath®-Anwendungen dediziert ist, oder mit einer gemeinsam genutzten OpenShift GitOps Operator-Instanz, wenn sie bereits in Ihrem Cluster installiert und verfügbar ist.

Es wird empfohlen, eine dedizierte OpenShift GitOps Operator-Instanz zu verwenden, um die Automation Suite-Anwendungen zu installieren. Diese Methode erfordert Mindestberechtigungen für die anderen Namespaces und Clusterressourcen.

Weitere Informationen zu Installation und Zugriff finden Sie in den folgenden Abschnitten:

Bereitstellen einer dedizierten GitOps-Instanz​

Hinweis:

Es wird empfohlen, einen anderen Namespace als <uipath> für ArgoCD zu verwenden.

Wenn Sie OpenShift GitOps Version 1.15 oder höher verwenden und eine dedizierte Instanz von ArgoCD im Namespace <uipath> installieren, ist die ArgoCD-Benutzeroberfläche aufgrund der Netzwerkrichtlinien im Namespace <uipath> , der von der Service Mesh-Steuerungsebene hinzugefügt wurde, nicht zugänglich. Um dies zu beheben, müssen Sie eine Netzwerkrichtlinie hinzufügen, wie im folgenden Beispiel gezeigt, damit die Ingress-Pods die ArgoCD-Server-Pods im <uipath> -Namespace erreichen können.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-argocd
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: argocd-server
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              network.openshift.io/policy-group: ingress
  policyTypes:
    - Ingress
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-argocd
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: argocd-server
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              network.openshift.io/policy-group: ingress
  policyTypes:
    - Ingress

Um eine dedizierte OpenShift GitOps Operator-Instanz bereitzustellen, führen Sie die folgenden Schritte aus:

  1. Wenn der Namespace <argocd> noch nicht vorhanden ist, führen Sie die folgenden Befehle aus, um ihn zu erstellen:

    oc get namespace <argocd> || oc new-project <argocd>
    oc project <argocd>
    oc get namespace <argocd> || oc new-project <argocd>
    oc project <argocd>
    
  2. Installieren Sie den OpenShift-GitOps-Operator, indem Sie die Anweisungen unter Installieren von OpenShift-GitOps befolgen.

  3. Erstellen Sie eine neue ArgoCD-Instanz, indem Sie die Anweisungen unter Einrichten einer neuen ArgoCD-Instanz befolgen .

    Hinweis:

    Im Abschnitt spec , der unter Aktivieren von Replikaten für den Argo-CD-Server und den Repository-Server beschrieben ist, müssen Sie die folgende Zeile hinzufügen:

    server.route.enabled: true
    server.route.enabled: true
    
  4. Wenn Sie OpenShift Service Mesh 2.x verwenden, maskieren Sie die ArgoCD-Bereitstellung, sodass das Service Mesh sie über eine OpenShift-Route verfügbar macht. Überspringen Sie diesen Schritt bei OpenShift Service Mesh 3.x, bei dem die Beschriftung maistra.io/expose-route keine Auswirkungen hat.

    oc -n <argocd> patch deployment argocd-server \
      -p '{"spec":{"template":{"metadata":{"labels":{"maistra.io/expose-route":"true"}}}}}'
    oc -n <argocd> patch deployment argocd-server \
      -p '{"spec":{"template":{"metadata":{"labels":{"maistra.io/expose-route":"true"}}}}}'
    
  5. Erstellen Sie eine Rolle, damit ArgoCD Grenzwertbereiche verwalten kann.

    Vor Automation Suite 2.2510.3 lieferte das Helm-Chart der Plattform ein LimitRange -Objekt, das Standardressourcenlimits im <uipath> -Namespace zuwies. Daher benötigte der ArgoCD-Anwendungscontroller Berechtigungen zum Erstellen und Verwalten. Ab 2.2510.3 Dieses LimitRange -Objekt wurde aus dem Diagramm entfernt und der Controller benötigt nur das delete -Verb, um das LimitRange -Objekt zu bereinigen, das von einer früheren Version während der Synchronisierung erstellt wurde.

    Um die Rolle zu erstellen, führen Sie folgende Schritte aus:

    1. Speichern Sie die Rollenkonfiguration, die Ihrer Automation Suite-Version entspricht, als YAML-Datei:
      • Automation Suite 2.2510.3 und höher (nur das Verb delete ist erforderlich):
        kind: Role
        apiVersion: rbac.authorization.k8s.io/v1
        metadata:
          name: limit-range-manager
          namespace: <uipath>
        rules:
          - apiGroups: [""]
            resources: ["limitranges"]
            verbs: ["delete"]
        kind: Role
        apiVersion: rbac.authorization.k8s.io/v1
        metadata:
          name: limit-range-manager
          namespace: <uipath>
        rules:
          - apiGroups: [""]
            resources: ["limitranges"]
            verbs: ["delete"]
        
      • Versionen vor 2.2510.3:
        kind: Role
        apiVersion: rbac.authorization.k8s.io/v1
        metadata:
          name: limit-range-manager
          namespace: <uipath>
        rules:
          - apiGroups: [""]
            resources: ["limitranges"]
            verbs: ["get", "watch", "list", "patch", "update", "create"]
        kind: Role
        apiVersion: rbac.authorization.k8s.io/v1
        metadata:
          name: limit-range-manager
          namespace: <uipath>
        rules:
          - apiGroups: [""]
            resources: ["limitranges"]
            verbs: ["get", "watch", "list", "patch", "update", "create"]
        
    2. Wenden Sie die Konfiguration an, indem Sie den folgenden Befehl ausführen. Ersetzen Sie den Platzhalter <file_name.yaml> durch den tatsächlichen Namen der YAML-Datei:
      oc apply -f <file_name.yaml>
      oc apply -f <file_name.yaml>
      
  6. Binden Sie die Rolle limit-range-manager an das Dienstkonto argocd :

    oc -n <uipath> create rolebinding limit-range-manager-binding --role=limit-range-manager --serviceaccount=<argocd>:argocd-argocd-application-controller
    oc -n <uipath> create rolebinding limit-range-manager-binding --role=limit-range-manager --serviceaccount=<argocd>:argocd-argocd-application-controller
    
  7. Wenn Sie TaaS aktiviert haben, erstellen Sie eine Rolle, die dem ArgoCD-Anwendungscontroller Verben auf die Unterressource pods/log schreiben gewährt. Der Vorinstallationshook von TaaS erstellt eine Rolle, die diese Verben enthält, und die Kubernetes-RBAC-Eskalationsverhinderung erfordert, dass der Controller sie selbst hält, bevor er sie gewähren kann. Um die Rolle zu erstellen, führen Sie folgende Schritte aus:

    1. Speichern Sie die folgende Rollenkonfiguration als YAML-Datei:
      kind: Role
      apiVersion: rbac.authorization.k8s.io/v1
      metadata:
        name: argocd-pod-log-writer
        namespace: <uipath>
      rules:
        - apiGroups: [""]
          resources: ["pods/log"]
          verbs: ["create", "update", "patch", "delete"]
      kind: Role
      apiVersion: rbac.authorization.k8s.io/v1
      metadata:
        name: argocd-pod-log-writer
        namespace: <uipath>
      rules:
        - apiGroups: [""]
          resources: ["pods/log"]
          verbs: ["create", "update", "patch", "delete"]
      
    2. Wenden Sie die Konfiguration an, indem Sie den folgenden Befehl ausführen. Ersetzen Sie den Platzhalter <file_name.yaml> durch den tatsächlichen Namen der YAML-Datei:
      oc apply -f <file_name.yaml>
      oc apply -f <file_name.yaml>
      
    3. Binden Sie die Rolle argocd-pod-log-writer an das Dienstkonto argocd :
      oc -n <uipath> create rolebinding argocd-pod-log-writer-binding --role=argocd-pod-log-writer --serviceaccount=<argocd>:argocd-argocd-application-controller
      oc -n <uipath> create rolebinding argocd-pod-log-writer-binding --role=argocd-pod-log-writer --serviceaccount=<argocd>:argocd-argocd-application-controller
      
  8. Wenn Sie Automation Suite Robots aktiviert haben, müssen Sie den clusterweiten Modus für ArgoCD aktivieren, indem Sie die folgenden Schritte ausführen:

    Wichtig:

    Der clusterweite Modus ist erforderlich, da das Diagramm der Automation Suite-Roboter standardmäßig ein ClusterRole und ein ClusterRoleBinding bereitstellt, die eine ArgoCD-Instanz mit Namespace nicht verwalten kann. Wenn Sie nur mit Namespace-Scope-Berechtigungen installieren, können Sie diesen Schritt überspringen, indem Sie einen expliziten asrobots.concurrency_limit in input.json festlegen; stellt das Diagramm dann keine clusterbezogenen Ressourcen bereit. Weitere Informationen finden Sie unter Gewährung von Installationsberechtigungen ohne Clusterrollen.

    1. Bearbeiten Sie in <openshift-gitops> die Abonnementressource openshift-gitops-operator , um die folgende Umgebungsvariable einzuschließen:
      ARGOCD_CLUSTER_CONFIG_NAMESPACES: <argocd>
      ARGOCD_CLUSTER_CONFIG_NAMESPACES: <argocd>
      
    2. Befolgen Sie die Anweisungen unter Verwenden einer Argo-CD-Instanz zum Verwalten von Cluster-Scope-Ressourcen.
  9. Sie müssen sicherstellen, dass die ArgoCD-Instanz den <uipath> -Namespace verwalten kann, wenn der <uipath> -Namespace nicht mit dem <argocd> -Namespace identisch ist:

    oc label namespace <uipath> argocd.argoproj.io/managed-by=<argocd>
    oc label namespace <uipath> argocd.argoproj.io/managed-by=<argocd>
    

    In diesem Befehl ist <argocd> der Name des Namespace, in dem Sie die dedizierte ArgoCD-Instanz bereitgestellt haben.

    Nachdem Sie die Konfiguration angewendet haben, starten Sie ArgoCD application-controler (StatefulSet) und server (Bereitstellung) neu.

  10. Sie müssen die folgenden Schritte nur ausführen, wenn der <uipath> -Namespace nicht mit dem <argocd> -Namespace identisch ist. Erstellen Sie eine Rolle, um die Anwendungen im <argocd> -Namespace zu verwalten. Führen Sie zum Erstellen der Rolle die folgenden Schritte aus:

    1. Speichern Sie die folgende Rollenkonfiguration als YAML-Datei:
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: uipath-application-manager
        namespace: <argocd>
      rules:
      - apiGroups:
        - argoproj.io
        resources:
        - applications
        verbs: ["get", "watch", "list", "patch", "update", "create", "delete"]
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: uipath-application-manager
        namespace: <argocd>
      rules:
      - apiGroups:
        - argoproj.io
        resources:
        - applications
        verbs: ["get", "watch", "list", "patch", "update", "create", "delete"]
      
    2. Wenden Sie die Konfiguration an, indem Sie den folgenden Befehl ausführen. Ersetzen Sie den Platzhalter <file_name.yaml> durch den tatsächlichen Namen der YAML-Datei:
      oc apply -f <file_name.yaml>
      oc apply -f <file_name.yaml>
      
  11. Binden Sie die Rolle uipath-application-manager an das Dienstkonto uipathadmin :

    oc project <argocd>
    oc create rolebinding uipath-application-manager \
      --role=uipath-application-manager --serviceaccount=<uipath>:uipathadmin
    oc project <argocd>
    oc create rolebinding uipath-application-manager \
      --role=uipath-application-manager --serviceaccount=<uipath>:uipathadmin
    
  12. Erstellen Sie als Clusteradministrator das Repository-Geheimnis helm-credentials im Namespace <argocd>. Dies ist ein ArgoCD-Repository-Geheimnis, das die Details zur Verbindung mit der Helm-Registrierung enthält, und ArgoCD liest es, um die Automation Suite-Charts abzurufen.

    Wichtig:

    Wie dieses Geheimnis verwaltet wird, hängt von Ihrer Automation Suite-Version ab:

    • Automation Suite 2.2510.4 und höher: Das Geheimnis befindet sich in Ihrem Besitz. uipathctl verwaltet diese nicht und erfordert keinen Zugriff darauf oder auf den <argocd> -Namespace – das uipathadmin -Dienstkonto benötigt dort keine Berechtigungen außer der Verwaltung von ArgoCD, die Sie im vorherigen Schritt gewährt haben. Überspringen Sie den nächsten Schritt.
    • Automation Suite 2.2510.3: Sie erstellen das Geheimnis, aber uipathctl aktualisiert es bei jeder Ausführung, sodass uipathadmin get, update und patch benötigt. Schließen Sie den nächsten Schritt mit 2.2510.3 ab Rolle.
    • Versionen vor 2.2510.3: uipathctl erstellt und verwaltet das Geheimnis selbst, sodass Sie die Erstellung überspringen können. Führen Sie den nächsten Schritt mit der Rolle für Versionen vor 2.2510.3 aus.

    Immer wenn Sie das Geheimnis erstellt haben, müssen Sie es auch auf dem neuesten Stand halten: Wenn sich die Helm-Registrierungsanmeldeinformationen ändern, aktualisieren Sie das Geheimnis selbst, andernfalls kann ArgoCD die Diagramme nicht mehr abrufen.

    apiVersion: v1
    kind: Secret
    metadata:
      name: helm-credentials
      namespace: <argocd>
      labels:
        argocd.argoproj.io/secret-type: repository
    type: Opaque
    stringData:
      name: uipath-helm
      url: <helm-registry-url>
      type: helm
      enableOCI: "true"
      username: <registry-username>
      password: <registry-password>
    apiVersion: v1
    kind: Secret
    metadata:
      name: helm-credentials
      namespace: <argocd>
      labels:
        argocd.argoproj.io/secret-type: repository
    type: Opaque
    stringData:
      name: uipath-helm
      url: <helm-registry-url>
      type: helm
      enableOCI: "true"
      username: <registry-username>
      password: <registry-password>
    

    Die stringData Werte werden als Nur-Text bereitgestellt. Lassen Sie bei einer offenen Registrierung wie registry.uipath.com die Schlüssel username und password weg, damit ArgoCD eine anonyme Verbindung herstellt. Wenn Sie sie leer lassen, versucht ArgoCD einen Anmeldeversuch mit einem Fehler 401. Alternativ können Sie dasselbe Geheimnis mit der CLI erstellen:

    oc -n <argocd> create secret generic helm-credentials \
      --from-literal=name=uipath-helm \
      --from-literal=url=<helm-registry-url> \
      --from-literal=type=helm \
      --from-literal=enableOCI=true \
      --from-literal=username=<registry-username> \
      --from-literal=password=<registry-password>
    oc -n <argocd> label --overwrite secret helm-credentials argocd.argoproj.io/secret-type=repository
    oc -n <argocd> create secret generic helm-credentials \
      --from-literal=name=uipath-helm \
      --from-literal=url=<helm-registry-url> \
      --from-literal=type=helm \
      --from-literal=enableOCI=true \
      --from-literal=username=<registry-username> \
      --from-literal=password=<registry-password>
    oc -n <argocd> label --overwrite secret helm-credentials argocd.argoproj.io/secret-type=repository
    
  13. Nur Automation Suite 2.2510.3 und früher. Diese Versionen schreiben in das Geheimnis helm-credentials und suchen den Namespace <argocd>, daher benötigt uipathadmin Zugriff auf beide. Überspringen Sie diesen Schritt für 2.2510.4 und höher.

    1. Speichern Sie die Rollenkonfiguration, die Ihrer Automation Suite-Version entspricht, als YAML-Datei:
      • Automation Suite 2.2510.3, auf das Geheimnis, das Sie im vorherigen Schritt erstellt haben:
        apiVersion: rbac.authorization.k8s.io/v1
        kind: Role
        metadata:
          name: argo-secret-role
          namespace: <argocd>
        rules:
          - apiGroups: [""]
            resources: ["secrets"]
            resourceNames: ["helm-credentials"]
            verbs: ["get", "update", "patch"]
        apiVersion: rbac.authorization.k8s.io/v1
        kind: Role
        metadata:
          name: argo-secret-role
          namespace: <argocd>
        rules:
          - apiGroups: [""]
            resources: ["secrets"]
            resourceNames: ["helm-credentials"]
            verbs: ["get", "update", "patch"]
        
      • Versionen vor 2.2510.3:
        apiVersion: rbac.authorization.k8s.io/v1
        kind: Role
        metadata:
          name: argo-secret-role
          namespace: <argocd>
        rules:
          - apiGroups: ["rbac.authorization.k8s.io"]
            resources: ["roles", "rolebindings"]
            verbs: ["get", "watch", "list", "patch", "update", "create"]
          - apiGroups: [""]
            resources: ["secrets"]
            verbs: ["get", "watch", "list", "patch", "update", "create"]
        apiVersion: rbac.authorization.k8s.io/v1
        kind: Role
        metadata:
          name: argo-secret-role
          namespace: <argocd>
        rules:
          - apiGroups: ["rbac.authorization.k8s.io"]
            resources: ["roles", "rolebindings"]
            verbs: ["get", "watch", "list", "patch", "update", "create"]
          - apiGroups: [""]
            resources: ["secrets"]
            verbs: ["get", "watch", "list", "patch", "update", "create"]
        
    2. Wenden Sie die Konfiguration an, indem Sie den folgenden Befehl ausführen. Ersetzen Sie den Platzhalter <file_name.yaml> durch den tatsächlichen Namen der YAML-Datei:
      oc apply -f <file_name.yaml>
      oc apply -f <file_name.yaml>
      
    3. Binden Sie die Rolle argo-secret-role und die Rolle namespace-reader an das Dienstkonto uipathadmin:
      oc project <argocd>
      oc create rolebinding secret-binding \
        --role=argo-secret-role --serviceaccount=<uipath>:uipathadmin
      oc create rolebinding namespace-reader-rolebinding \
        --clusterrole=namespace-reader-clusterrole --serviceaccount=<uipath>:uipathadmin
      oc project <argocd>
      oc create rolebinding secret-binding \
        --role=argo-secret-role --serviceaccount=<uipath>:uipathadmin
      oc create rolebinding namespace-reader-rolebinding \
        --clusterrole=namespace-reader-clusterrole --serviceaccount=<uipath>:uipathadmin
      

Zugreifen auf die dedizierte ArgoCD-Instanz​

Führen Sie die folgenden Schritte aus, um auf ArgoCD zuzugreifen:

  1. Rufen Sie die Host-URL ab:
    oc get routes argocd-server -n <argocd> -o jsonpath={.spec.host}; echo
    oc get routes argocd-server -n <argocd> -o jsonpath={.spec.host}; echo
    
  2. Um sich anzumelden, verwenden Sie admin als Benutzernamen und führen Sie den folgenden Befehl aus, um das Kennwort zu erhalten:
    oc -n <argocd> get secrets argocd-cluster \
      -o "jsonpath={.data['admin\.password']}" | base64 -d; echo
    oc -n <argocd> get secrets argocd-cluster \
      -o "jsonpath={.data['admin\.password']}" | base64 -d; echo
    

Konfigurieren des privaten Helm-Repositorys und der Zertifikate in ArgoCD​

Führen Sie die folgenden Schritte aus, um das Helm-Repository in ArgoCD zu konfigurieren:

  1. Melden Sie sich bei ArgoCD an.
  2. Navigieren Sie zu Einstellungen > Repositorys > +CONNECT REPO.
  3. Verwenden Sie VIA HTTPS als Verbindungsmethode.
  4. Wählen Sie Helm als Typ aus.
  5. Geben Sie einen Namen an.
  6. Wählen Sie Standard als Projekt aus.
  7. Geben Sie die Repository-URL, den Benutzernamen, das Kennwort und das Zertifikat an.
    Wichtig:

    Beim Hinzufügen des TLS-Clientzertifikats auf der Seite +CONNECT REPO wird der TLS-Clientzertifikatschlüssel zu einem Pflichtfeld. Um das Registrierungszertifikat ohne den TLS-Clientzertifikatschlüssel zu konfigurieren, führen Sie die folgenden Schritte aus:

    1. Navigieren Sie zu Einstellungen > Repository-Zertifikate und bekannte Hosts > +TLS-ZERTIFIKATE.
    2. Fügen Sie den Repository-Namen und das TLS-Zertifikat im PEM-Format hinzu.
  8. Aktivieren Sie das Kontrollkästchen OCI .
  9. Select Connect.
  10. Stellen Sie sicher, dass der Verbindungsstatus Erfolgreich ist.

Konfigurieren einer gemeinsam genutzten GitOps-Instanz​

Wenn Ihr Plattformteam die freigegebene OpenShift GitOps Operator-Instanz noch nicht bereitgestellt hat, führen Sie die folgenden Installations- und Konfigurationsschritte aus:

  1. Erstellen Sie den Namespace <uipath>:

    oc get namespace <uipath> || oc new-project <uipath>
    oc project <uipath>
    oc get namespace <uipath> || oc new-project <uipath>
    oc project <uipath>
    
  2. Installieren Sie den OpenShift-GitOps-Operator, indem Sie die Anweisungen unter Installieren von OpenShift-GitOps befolgen. Diese Installation enthält die standardmäßige ArgoCD-Instanz namens openshift-gitops im <openshift-gitops> - Namespace.

  3. Aktivieren Sie den clusterweiten Modus für ArgoCD, indem Sie die folgenden Schritte ausführen:

    1. Bearbeiten Sie in <openshift-gitops> die Abonnementressource openshift-gitops-operator , um die folgende Umgebungsvariable einzuschließen:
      ARGOCD_CLUSTER_CONFIG_NAMESPACES: <openshift-gitops>
      ARGOCD_CLUSTER_CONFIG_NAMESPACES: <openshift-gitops>
      
    2. Befolgen Sie die Anweisungen unter Verwenden einer ArgoCD-Instanz zum Verwalten von Cluster-Scope-Ressourcen.
  4. Stellen Sie sicher, dass die ArgoCD-Instanz openshift-gitops den Namespace <uipath> verwalten kann:

    oc label namespace <uipath> argocd.argoproj.io/managed-by=openshift-gitops
    oc label namespace <uipath> argocd.argoproj.io/managed-by=openshift-gitops
    

    Nachdem Sie die Konfiguration angewendet haben, starten Sie ArgoCD openshift-gitops-application-controller (StatefulSet) und openshift-gitops-server (Bereitstellung) neu.

  5. Wenn Sie OpenShift Service Mesh 2.x verwenden, maskieren Sie die ArgoCD-Bereitstellung, sodass das Service Mesh sie über eine OpenShift-Route verfügbar macht. Überspringen Sie diesen Schritt bei OpenShift Service Mesh 3.x, bei dem die Beschriftung maistra.io/expose-route keine Auswirkungen hat.

    oc -n <uipath> patch deployment argocd-server \
      -p '{"spec":{"template":{"metadata":{"labels":{"maistra.io/expose-route":"true"}}}}}'
    oc -n <uipath> patch deployment argocd-server \
      -p '{"spec":{"template":{"metadata":{"labels":{"maistra.io/expose-route":"true"}}}}}'
    
  6. Erstellen Sie ein ArgoCD-Projekt für die UiPath®-Anwendung:

    apiVersion: argoproj.io/v1alpha1
    kind: AppProject
    metadata:
      name: uipath
      namespace: <openshift-gitops>
    spec:
      description: Appproject to managed and deploy uipath applications
      clusterResourceWhitelist:
        - group: '*'
          kind: '*'
      destinations:
        - namespace: <uipath>
          server: https://kubernetes.default.svc
        - namespace: <istio-system>
          server: https://kubernetes.default.svc
      sourceNamespaces:
        - <openshift-gitops>
      sourceRepos:
        - '*'
    apiVersion: argoproj.io/v1alpha1
    kind: AppProject
    metadata:
      name: uipath
      namespace: <openshift-gitops>
    spec:
      description: Appproject to managed and deploy uipath applications
      clusterResourceWhitelist:
        - group: '*'
          kind: '*'
      destinations:
        - namespace: <uipath>
          server: https://kubernetes.default.svc
        - namespace: <istio-system>
          server: https://kubernetes.default.svc
      sourceNamespaces:
        - <openshift-gitops>
      sourceRepos:
        - '*'
    
  7. Erstellen Sie eine Rolle, damit ArgoCD Grenzwertbereiche verwalten kann.

    Vor Automation Suite 2.2510.3 lieferte das Helm-Chart der Plattform ein LimitRange -Objekt, das Standardressourcenlimits im <uipath> -Namespace zuwies. Daher benötigte der ArgoCD-Anwendungscontroller Berechtigungen zum Erstellen und Verwalten. Ab 2.2510.3 Dieses LimitRange -Objekt wurde aus dem Diagramm entfernt und der Controller benötigt nur das delete -Verb, um das LimitRange -Objekt zu bereinigen, das von einer früheren Version während der Synchronisierung erstellt wurde.

    Um die Rolle zu erstellen, führen Sie folgende Schritte aus:

    1. Speichern Sie die Rollenkonfiguration, die Ihrer Automation Suite-Version entspricht, als YAML-Datei:
      • Automation Suite 2.2510.3 und höher (nur das Verb delete ist erforderlich):
        kind: Role
        apiVersion: rbac.authorization.k8s.io/v1
        metadata:
          name: limit-range-manager
          namespace: <uipath>
        rules:
          - apiGroups: [""]
            resources: ["limitranges"]
            verbs: ["delete"]
        kind: Role
        apiVersion: rbac.authorization.k8s.io/v1
        metadata:
          name: limit-range-manager
          namespace: <uipath>
        rules:
          - apiGroups: [""]
            resources: ["limitranges"]
            verbs: ["delete"]
        
      • Versionen vor 2.2510.3:
        kind: Role
        apiVersion: rbac.authorization.k8s.io/v1
        metadata:
          name: limit-range-manager
          namespace: <uipath>
        rules:
          - apiGroups: [""]
            resources: ["limitranges"]
            verbs: ["get", "watch", "list", "patch", "update", "create"]
        kind: Role
        apiVersion: rbac.authorization.k8s.io/v1
        metadata:
          name: limit-range-manager
          namespace: <uipath>
        rules:
          - apiGroups: [""]
            resources: ["limitranges"]
            verbs: ["get", "watch", "list", "patch", "update", "create"]
        
    2. Wenden Sie die Konfiguration an, indem Sie den folgenden Befehl ausführen. Ersetzen Sie den Platzhalter <file_name.yaml> durch den tatsächlichen Namen der YAML-Datei:
      oc apply -f <file_name.yaml>
      oc apply -f <file_name.yaml>
      
  8. Binden Sie die Rolle limit-range-manager an das Dienstkonto argocd :

    oc -n <uipath> create rolebinding limit-range-manager-binding --role=limit-range-manager --serviceaccount=<openshift-gitops>:openshift-gitops-argocd-application-controller
    oc -n <uipath> create rolebinding limit-range-manager-binding --role=limit-range-manager --serviceaccount=<openshift-gitops>:openshift-gitops-argocd-application-controller
    
  9. Erstellen Sie eine Rolle, um die Anwendungen im <openshift-gitops> -Namespace zu verwalten:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: uipath-application-manager
      namespace: <openshift-gitops>
    rules:
    - apiGroups:
      - argoproj.io
      resources:
      - applications
      verbs: ["get", "watch", "list", "patch", "update", "create"]
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: uipath-application-manager
      namespace: <openshift-gitops>
    rules:
    - apiGroups:
      - argoproj.io
      resources:
      - applications
      verbs: ["get", "watch", "list", "patch", "update", "create"]
    
  10. Binden Sie die Rolle uipath-application-manager an das Dienstkonto uipathadmin :

    oc project <openshift-gitops>
    oc create rolebinding uipath-application-manager \
      --role=uipath-application-manager --serviceaccount=<uipath>:uipathadmin
    oc project <openshift-gitops>
    oc create rolebinding uipath-application-manager \
      --role=uipath-application-manager --serviceaccount=<uipath>:uipathadmin
    
  11. Erstellen Sie als Clusteradministrator das Repository-Geheimnis helm-credentials im Namespace <openshift-gitops>. Dies ist ein ArgoCD-Repository-Geheimnis, das die Details zur Verbindung mit der Helm-Registrierung enthält, und ArgoCD liest es, um die Automation Suite-Charts abzurufen.

    Wichtig:

    Wie dieses Geheimnis verwaltet wird, hängt von Ihrer Automation Suite-Version ab:

    • Automation Suite 2.2510.4 und höher: Das Geheimnis befindet sich in Ihrem Besitz. uipathctl verwaltet diese nicht und erfordert keinen Zugriff darauf oder auf den <openshift-gitops> -Namespace – das uipathadmin -Dienstkonto benötigt dort keine Berechtigungen außer der Verwaltung von ArgoCD, die Sie im vorherigen Schritt gewährt haben. Überspringen Sie den nächsten Schritt.
    • Automation Suite 2.2510.3: Sie erstellen das Geheimnis, aber uipathctl aktualisiert es bei jeder Ausführung, sodass uipathadmin get, update und patch benötigt. Schließen Sie den nächsten Schritt mit 2.2510.3 ab Rolle.
    • Versionen vor 2.2510.3: uipathctl erstellt und verwaltet das Geheimnis selbst, sodass Sie die Erstellung überspringen können. Führen Sie den nächsten Schritt mit der Rolle für Versionen vor 2.2510.3 aus.

    Immer wenn Sie das Geheimnis erstellt haben, müssen Sie es auch auf dem neuesten Stand halten: Wenn sich die Helm-Registrierungsanmeldeinformationen ändern, aktualisieren Sie das Geheimnis selbst, andernfalls kann ArgoCD die Diagramme nicht mehr abrufen.

    apiVersion: v1
    kind: Secret
    metadata:
      name: helm-credentials
      namespace: <openshift-gitops>
      labels:
        argocd.argoproj.io/secret-type: repository
    type: Opaque
    stringData:
      name: uipath-helm
      url: <helm-registry-url>
      type: helm
      enableOCI: "true"
      username: <registry-username>
      password: <registry-password>
    apiVersion: v1
    kind: Secret
    metadata:
      name: helm-credentials
      namespace: <openshift-gitops>
      labels:
        argocd.argoproj.io/secret-type: repository
    type: Opaque
    stringData:
      name: uipath-helm
      url: <helm-registry-url>
      type: helm
      enableOCI: "true"
      username: <registry-username>
      password: <registry-password>
    

    Die stringData Werte werden als Nur-Text bereitgestellt. Lassen Sie bei einer offenen Registrierung wie registry.uipath.com die Schlüssel username und password weg, damit ArgoCD eine anonyme Verbindung herstellt. Wenn Sie sie leer lassen, versucht ArgoCD einen Anmeldeversuch mit einem Fehler 401. Alternativ können Sie dasselbe Geheimnis mit der CLI erstellen:

    oc -n <openshift-gitops> create secret generic helm-credentials \
      --from-literal=name=uipath-helm \
      --from-literal=url=<helm-registry-url> \
      --from-literal=type=helm \
      --from-literal=enableOCI=true \
      --from-literal=username=<registry-username> \
      --from-literal=password=<registry-password>
    oc -n <openshift-gitops> label --overwrite secret helm-credentials argocd.argoproj.io/secret-type=repository
    oc -n <openshift-gitops> create secret generic helm-credentials \
      --from-literal=name=uipath-helm \
      --from-literal=url=<helm-registry-url> \
      --from-literal=type=helm \
      --from-literal=enableOCI=true \
      --from-literal=username=<registry-username> \
      --from-literal=password=<registry-password>
    oc -n <openshift-gitops> label --overwrite secret helm-credentials argocd.argoproj.io/secret-type=repository
    
  12. Nur Automation Suite 2.2510.3 und früher. Diese Versionen schreiben in das Geheimnis helm-credentials und suchen den Namespace <openshift-gitops>, daher benötigt uipathadmin Zugriff auf beide. Überspringen Sie diesen Schritt für 2.2510.4 und höher.

    1. Speichern Sie die Rollenkonfiguration, die Ihrer Automation Suite-Version entspricht, als YAML-Datei:
      • Automation Suite 2.2510.3, auf das Geheimnis, das Sie im vorherigen Schritt erstellt haben:
        apiVersion: rbac.authorization.k8s.io/v1
        kind: Role
        metadata:
          name: argo-secret-role
          namespace: <openshift-gitops>
        rules:
          - apiGroups: [""]
            resources: ["secrets"]
            resourceNames: ["helm-credentials"]
            verbs: ["get", "update", "patch"]
        apiVersion: rbac.authorization.k8s.io/v1
        kind: Role
        metadata:
          name: argo-secret-role
          namespace: <openshift-gitops>
        rules:
          - apiGroups: [""]
            resources: ["secrets"]
            resourceNames: ["helm-credentials"]
            verbs: ["get", "update", "patch"]
        
      • Versionen vor 2.2510.3:
        apiVersion: rbac.authorization.k8s.io/v1
        kind: Role
        metadata:
          name: argo-secret-role
          namespace: <openshift-gitops>
        rules:
          - apiGroups: ["rbac.authorization.k8s.io"]
            resources: ["roles", "rolebindings"]
            verbs: ["get", "watch", "list", "patch", "update", "create"]
          - apiGroups: [""]
            resources: ["secrets"]
            verbs: ["get", "watch", "list", "patch", "update", "create"]
        apiVersion: rbac.authorization.k8s.io/v1
        kind: Role
        metadata:
          name: argo-secret-role
          namespace: <openshift-gitops>
        rules:
          - apiGroups: ["rbac.authorization.k8s.io"]
            resources: ["roles", "rolebindings"]
            verbs: ["get", "watch", "list", "patch", "update", "create"]
          - apiGroups: [""]
            resources: ["secrets"]
            verbs: ["get", "watch", "list", "patch", "update", "create"]
        
    2. Wenden Sie die Konfiguration an, indem Sie den folgenden Befehl ausführen. Ersetzen Sie den Platzhalter <file_name.yaml> durch den tatsächlichen Namen der YAML-Datei:
      oc apply -f <file_name.yaml>
      oc apply -f <file_name.yaml>
      
    3. Binden Sie die Rolle argo-secret-role und die Rolle namespace-reader an das Dienstkonto uipathadmin:
      oc project <openshift-gitops>
      oc create rolebinding secret-binding \
        --role=argo-secret-role --serviceaccount=<uipath>:uipathadmin
      oc create rolebinding namespace-reader-rolebinding \
        --clusterrole=namespace-reader-clusterrole --serviceaccount=<uipath>:uipathadmin
      oc project <openshift-gitops>
      oc create rolebinding secret-binding \
        --role=argo-secret-role --serviceaccount=<uipath>:uipathadmin
      oc create rolebinding namespace-reader-rolebinding \
        --clusterrole=namespace-reader-clusterrole --serviceaccount=<uipath>:uipathadmin
      

Zusätzlich zur Ausführung der Schritte zum Konfigurieren der freigegebenen ArgoCD-Instanz für die Automation Suite-Installation müssen Sie der Datei input.json die folgenden Parameter hinzufügen:

  "argocd": {
    "project": "<uipath>"
  },
  "argocd": {
    "project": "<uipath>"
  },

Zugriff auf die freigegebene ArgoCD-Instanz​

Führen Sie die folgenden Schritte aus, um auf ArgoCD zuzugreifen:

  1. Rufen Sie die Host-URL ab, indem Sie die folgenden Befehle ausführen:
    oc get routes openshift-gitops-server -n <openshift-gitops> -o jsonpath={.spec.host}; echo
    oc get routes openshift-gitops-server -n <openshift-gitops> -o jsonpath={.spec.host}; echo
    
  2. Um sich anzumelden, verwenden Sie admin als Benutzernamen und führen Sie den folgenden Befehl aus, um das Kennwort zu erhalten:
    oc -n <openshift-gitops> get secrets openshift-gitops-cluster \
      -o "jsonpath={.data['admin\.password']}" | base64 -d; echo
    oc -n <openshift-gitops> get secrets openshift-gitops-cluster \
      -o "jsonpath={.data['admin\.password']}" | base64 -d; echo
    

Konfigurieren des privaten Helm-Repositorys und der Zertifikate in ArgoCD​

Führen Sie die folgenden Schritte aus, um das Helm-Repository in ArgoCD zu konfigurieren:

  1. Melden Sie sich bei ArgoCD an.
  2. Navigieren Sie zu Einstellungen > Repositorys > +CONNECT REPO.
  3. Verwenden Sie VIA HTTPS als Verbindungsmethode.
  4. Wählen Sie Helm als Typ aus.
  5. Geben Sie einen Namen an.
  6. Wählen Sie uipath als Projekt aus. uipath ist der Name des ArgoCD-Projekts, das Sie für die UiPath®-Anwendung erstellt haben.
  7. Geben Sie die Repository-URL, den Benutzernamen, das Kennwort und das Zertifikat an.
    Wichtig:

    Beim Hinzufügen des TLS-Clientzertifikats auf der Seite +CONNECT REPO wird der TLS-Clientzertifikatschlüssel zu einem Pflichtfeld. Um das Registrierungszertifikat ohne den TLS-Clientzertifikatschlüssel zu konfigurieren, führen Sie die folgenden Schritte aus:

    1. Navigieren Sie zu Einstellungen > Repository-Zertifikate und bekannte Hosts > +TLS-ZERTIFIKATE.
    2. Fügen Sie den Repository-Namen und das TLS-Zertifikat im PEM-Format hinzu.
  8. Aktivieren Sie das Kontrollkästchen OCI .
  9. Select Connect.
  10. Stellen Sie sicher, dass der Verbindungsstatus Erfolgreich ist.

Konfigurieren von ArgoCD für mehrere Installationen in einem einzelnen Cluster​

Führen Sie die folgenden Schritte aus, um ArgoCD für mehrere Automation Suite-Installationen in einem einzelnen OpenShift-Cluster zu konfigurieren:

  1. Überprüfen Sie, ob alle Dienste von ArgoCD in Betrieb sind. Sie können den folgenden Befehl ausführen, um alle Pods zu überwachen:
    oc get pods -n <argocd>
    oc get pods -n <argocd>
    
  2. Sobald alle Dienste in Betrieb sind, können Sie den folgenden Befehl sequenziell verwenden, um die Berechtigungen von ArgoCD zu patchen. Dadurch kann ArgoCD verschiedene Anwendungsnamespaces verwalten, in denen die Automation Suite installiert ist:
    oc patch appprojects.argoproj.io default -n <argocd> --type='merge' -p '{"spec": {"sourceNamespaces": ["*"]}}'
    oc patch configmaps argocd-cmd-params-cm -n <argocd> --type='merge' -p '{"data": {"application.namespaces": "*"}}'
    oc rollout restart -n <argocd> deployment argocd-server
    oc rollout restart -n <argocd> statefulset argocd-application-controller
    oc patch appprojects.argoproj.io default -n <argocd> --type='merge' -p '{"spec": {"sourceNamespaces": ["*"]}}'
    oc patch configmaps argocd-cmd-params-cm -n <argocd> --type='merge' -p '{"data": {"application.namespaces": "*"}}'
    oc rollout restart -n <argocd> deployment argocd-server
    oc rollout restart -n <argocd> statefulset argocd-application-controller
    

War diese Seite hilfreich?

Verbinden

Benötigen Sie Hilfe? Support

Möchten Sie lernen? UiPath Academy

Haben Sie Fragen? UiPath-Forum

Auf dem neuesten Stand bleiben