Installer et configurer l'outil GitOps

Installez et configurez l'outil GitOps pour gérer les déploiements d'Automation Suite sur OpenShift.

Remarque :

Avant de procéder à l'installation et à la configuration de l'opérateur OpenShift GitOps, vous devez installer OpenShift Service Mesh et fournir toutes les autorisations requises au compte de service uipathadmin .

Pour obtenir les instructions d’installation et de configuration de Service Mesh, reportez-vous à Installation et configuration du service Mesh.

Pour les autorisations d'installation, reportez-vous à la section Accorder des autorisations d'installation.

Vous pouvez déployer Automation Suite à l’aide d’une instance OpenShift GitOps Operator dédiée aux applications UiPath® ou d’une instance OpenShift GitOps Operator partagée, si elle est déjà installée et disponible sur votre cluster.

Nous vous recommandons d’utiliser une instance OpenShift GitOps Operator dédiée pour installer les applications Automation Suite. Cette méthode nécessite des autorisations minimales pour les autres espaces de noms et ressources de cluster.

Pour obtenir des informations d’installation et d’accès, consultez les sections suivantes:

• Enregistrer une instance GitOps dédiée
• Configuration d'une instance GitOps partagée

Enregistrer une instance GitOps dédiée

Remarque :

Nous vous recommandons d'utiliser un espace de noms différent de <uipath> pour ArgoCD.

Si vous utilisez OpenShift GitOps version 1.15 ou supérieure et installez une instance dédiée d'ArgoCD dans l'espace de noms <uipath> , l'interface utilisateur d'ArgoCD ne sera pas accessible en raison des stratégies réseau dans l'espace de noms <uipath> ajoutées par le plan de contrôle de Service Mesh. Pour résoudre ce problème, vous devez ajouter une stratégie réseau, comme illustré dans l'exemple suivant, pour permettre aux pods d'entrée d'atteindre les pods de serveur ArgoCD dans l'espace de noms <uipath> .

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

Pour enregistrer une instance OpenShift GitOps Operator dédiée, procédez comme suit :

1. Si l'espace de noms <argocd> n'existe pas déjà, exécutez les commandes suivantes pour le créer :

   oc get namespace <argocd> || oc new-project <argocd>
   oc project <argocd>
   

2. Installez l’opérateur OpenShift GitOps en suivant les instructions dans Installation d’OpenShift GitOps.

3. Créez une nouvelle instance ArgoCD en suivant les instructions de la section Configuration d'une nouvelle instance ArgoCD.

   Remarque :

   Dans la section spec décrite dans Activation des répliques pour le serveur Argo CD et le serveur de référentiel, vous devez ajouter la ligne suivante :

   server.route.enabled: true
   

4. Si vous utilisez OpenShift Service Mesh 2.x, corrigez le déploiement ArgoCD afin que le service Mesh l’expose via une route OpenShift. Ignorez cette étape sur OpenShift Service Mesh 3.x, où le libellé maistra.io/expose-route n'a aucun effet.

   oc -n <argocd> patch deployment argocd-server \
     -p '{"spec":{"template":{"metadata":{"labels":{"maistra.io/expose-route":"true"}}}}}'
   

5. Créez un rôle afin qu'ArgoCD puisse gérer les plages limites.

   Avant Automation Suite 2.2510.3, le graphique Helm de la plate-forme fournissait un objet LimitRange qui attribuait des limites de ressources par défaut dans l'espace de noms <uipath>, de sorte que le contrôleur d'application ArgoCD avait besoin d'autorisations pour le créer et le gérer. À partir de la version 2.2510.3, cet objet LimitRange a été supprimé du graphique et le contrôleur n’a besoin que du verbe delete pour supprimer le LimitRange créé par une version antérieure lors de la synchronisation.

   Pour créer le rôle, procédez comme suit:

   1. Enregistrez la configuration du rôle qui correspond à votre version d'Automation Suite sous forme de fichier YAML:
      • Automation Suite 2.2510.3 et versions ultérieures (seul le verbe delete est requis):

        kind: Role
        apiVersion: rbac.authorization.k8s.io/v1
        metadata:
          name: limit-range-manager
          namespace: <uipath>
        rules:
          - apiGroups: [""]
            resources: ["limitranges"]
            verbs: ["delete"]
        

      • Versions antérieures à 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"]
        

   2. Appliquez la configuration en exécutant la commande suivante. Assurez-vous de remplacer l'espace réservé <file_name.yaml> par le nom réel du fichier YAML :

      oc apply -f <file_name.yaml>
      

6. Liez le rôle limit-range-manager au compte de service argocd :

   oc -n <uipath> create rolebinding limit-range-manager-binding --role=limit-range-manager --serviceaccount=<argocd>:argocd-argocd-application-controller
   

7. Si vous avez activé TaaS, créez un rôle qui autorise les verbes d'écriture du contrôleur d'application ArgoCD sur la sous-ressource pods/log. Le hook pré-installé de TaaS crée un rôle qui inclut ces verbes, et la prévention de l’escalade RBAC Kubernetes nécessite que le contrôleur les conserve avant de pouvoir les accorder. Pour créer le rôle, procédez comme suit:

   1. Enregistrez la configuration de rôle suivante sous forme de fichier YAML :

      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. Appliquez la configuration en exécutant la commande suivante. Assurez-vous de remplacer l'espace réservé <file_name.yaml> par le nom réel du fichier YAML :

      oc apply -f <file_name.yaml>
      

   3. Liez le rôle argocd-pod-log-writer au compte de service argocd :

      oc -n <uipath> create rolebinding argocd-pod-log-writer-binding --role=argocd-pod-log-writer --serviceaccount=<argocd>:argocd-argocd-application-controller
      

8. Si vous avez activé les Automation Suite Robots, vous devez activer le mode à l'échelle du cluster pour ArgoCD en procédant comme suit :

   Important :

   Le mode à l'échelle du cluster est requis car, par défaut, le graphique Automation Suite Robots déploie une ClusterRole et une ClusterRoleBinding qu'une instance ArgoCD avec espace de noms ne peut pas gérer. Si vous effectuez l'installation avec uniquement des autorisations liées à l'espace de noms, vous pouvez ignorer cette étape en définissant une variable asrobots.concurrency_limit explicite dans input.json; le graphique ne déploie alors aucune ressource à l'échelle du cluster. Pour plus de détails, consultez la section Octroi d’autorisations d’installation sans rôles de cluster.

   1. Dans <openshift-gitops>, modifiez la ressource d'abonnement openshift-gitops-operator pour y inclure la variable d'environnement suivante :

      ARGOCD_CLUSTER_CONFIG_NAMESPACES: <argocd>
      

   2. Suivez les instructions de la section Utilisation d'une instance Argo CD pour gérer les ressources à l'échelle du cluster.

9. Vous devez vous assurer que l'instance ArgoCD peut gérer l'espace de noms <uipath> si l'espace de noms <uipath> n'est pas le même que l'espace de noms <argocd> :

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

   Dans cette commande, <argocd> est le nom de l'espace de noms dans lequel vous avez déployé l'instance ArgoCD dédiée.

   Après avoir appliqué la configuration, redémarrez ArgoCD application-controler (ensemble d'états) et server (déploiement).

10. Vous devez effectuer les étapes suivantes uniquement si l'espace de noms <uipath> n'est pas le même que l'espace de noms <argocd> . Créez un rôle pour gérer les applications de l'espace de noms <argocd> . Pour créer le rôle, procédez comme suit :

    1. Enregistrez la configuration de rôle suivante sous forme de fichier YAML :

       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. Appliquez la configuration en exécutant la commande suivante. Assurez-vous de remplacer l'espace réservé <file_name.yaml> par le nom réel du fichier YAML :

       oc apply -f <file_name.yaml>
       

11. Liez le rôle uipath-application-manager au compte de service uipathadmin :

    oc project <argocd>
    oc create rolebinding uipath-application-manager \
      --role=uipath-application-manager --serviceaccount=<uipath>:uipathadmin
    

12. En tant qu'administrateur de cluster, créez la clé secrète du référentiel helm-credentials dans l'espace de noms <argocd>. Il s'agit d'une clé secrète du référentiel ArgoCD qui contient les détails de la connexion au registre Helm, et ArgoCD le lit pour extraire les graphiques Automation Suite.

    Important :

    La façon dont cette clé secrète est gérée dépend de votre version d’Automation Suite:

    • Automation Suite 2.2510.4 et versions ultérieures: la clé secrète vous appartient. uipathctl ne le gère pas et ne nécessite aucun accès à celui-ci ou à l'espace de noms <argocd> - le compte de service uipathadmin n'a besoin d'aucune autorisation du tout, à l'exception de la gestion des applications ArgoCD, que vous avez accordée à l'étape précédente. Ignorez l'étape suivante.
    • Automation Suite 2.2510.3: vous créez la clé secrète, mais uipathctl la met toujours à jour à chaque exécution, de sorte que uipathadmin a besoin de get, update et patch sur cette clé. Terminez l'étape suivante avec le 2.2510.3 rôle.
    • Versions antérieures à 2.2510.3: uipathctl crée et gère la clé secrète elle-même, vous pouvez donc ignorer sa création. Terminez l'étape suivante avec le rôle pour les versions antérieures à 2.2510.3.

    Chaque fois que vous avez créé la clé secrète, vous devez également la maintenir à jour: si les informations d'identification du registre Helm changent, mettez à jour la clé secrète vous-même, sinon ArgoCD cessera d'être en mesure d'extraire les graphiques.

    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>
    

    Les valeurs stringData sont fournies en texte brut. Pour un registre ouvert tel que registry.uipath.com, omettez les clés username et password afin qu’ArgoCD se connecte de manière anonyme. Les laisser vides fait que ArgoCD tente de se connecter et échoue avec une erreur 401. Vous pouvez également créer la même clé secrète avec la CLI:

    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. Automation Suite 2.2510.3 et versions antérieures uniquement. Ces versions écrivent dans la clé secrète helm-credentials et recherchent l'espace de noms <argocd>; uipathadmin a donc besoin d'accéder aux deux. Ignorez cette étape sur la version 2.2510.4 et ultérieure.

    1. Enregistrez la configuration du rôle qui correspond à votre version d'Automation Suite sous forme de fichier YAML:
       • Automation Suite 2.2510.3, étendu au secret que vous avez créé à l'étape précédente:

         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"]
         

       • Versions antérieures à 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"]
         

    2. Appliquez la configuration en exécutant la commande suivante. Assurez-vous de remplacer l'espace réservé <file_name.yaml> par le nom réel du fichier YAML :

       oc apply -f <file_name.yaml>
       

    3. Liez le rôle argo-secret-role et le rôle namespace-reader au compte de service 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
       

Accéder à l'instance ArgoCD

Pour accéder à ArgoCD, procédez comme suit :

1. Obtenir l'URL de l'hôte :

   oc get routes argocd-server -n <argocd> -o jsonpath={.spec.host}; echo
   

2. Pour vous connecter, utilisez admin comme nom d'utilisateur et exécutez la commande suivante pour obtenir le mot de passe :

   oc -n <argocd> get secrets argocd-cluster \
     -o "jsonpath={.data['admin\.password']}" | base64 -d; echo
   

Configuration du référentiel Helm privé et des certificats dans ArgoCD

Pour configurer le référentiel Helm dans ArgoCD, procédez comme suit :

1. Connectez-vous à ArgoCD.
2. Accédez à Paramètres > Référentiels > +CONNECTERPO.
3. Utilisez VI HTTPS pour la méthode de connexion.
4. Sélectionnez Helm comme type.
5. Indiquez un nom.
6. Choisissez la valeur par défaut en tant que projet.
7. Indiquez l'URL du référentiel, le nom d'utilisateur, le mot de passe et les informations de certificat.
   Important :

   Lors de l'ajout du certificat client TLS sur la page +CONNECTUREPO , la clé de certificat client TLS devient un champ obligatoire. Pour configurer le certificat de registre sans la clé de certificat client TLS, procédez comme suit :

   1. Accédez à Paramètres > Certificats de référentiel et hôtes connus > +ADD TLS CERTIFICATE.
   2. Ajoutez le nom du référentiel et le certificat TLS au format PEM.
8. Cochez la case OCI .
9. Select Connect.
10. Assurez-vous que le statut de la connexion est Réussite.

Configuration d'une instance GitOps partagée

Si votre équipe de plate-forme n'a pas encore enregistré l'instance partagée OpenShift GitOps Operator, effectuez les étapes d'installation et de configuration suivantes :

1. Créez l'espace de noms <uipath> :

   oc get namespace <uipath> || oc new-project <uipath>
   oc project <uipath>
   

2. Installez l’opérateur OpenShift GitOps en suivant les instructions dans Installation d’OpenShift GitOps. Cette installation est livrée avec l'instance ArgoCD, nommée openshift-gitops, dans l'espace de noms <openshift-gitops> .

3. Activez le mode à l'échelle du cluster pour ArgoCD en procédant comme suit :

   1. Dans <openshift-gitops>, modifiez la ressource d'abonnement openshift-gitops-operator pour y inclure la variable d'environnement suivante :

      ARGOCD_CLUSTER_CONFIG_NAMESPACES: <openshift-gitops>
      

   2. Suivez les instructions de la section Utilisation d'une instance ArgoCD pour gérer les ressources à l'échelle du cluster.

4. Assurez-vous que l'instance ArgoCD openshift-gitops peut gérer l'espace de noms <uipath> :

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

   Après avoir appliqué la configuration, redémarrez ArgoCD openshift-gitops-application-controller (ensemble d'états) et openshift-gitops-server (déploiement).

5. Si vous utilisez OpenShift Service Mesh 2.x, corrigez le déploiement ArgoCD afin que le service Mesh l’expose via une route OpenShift. Ignorez cette étape sur OpenShift Service Mesh 3.x, où le libellé maistra.io/expose-route n'a aucun effet.

   oc -n <uipath> patch deployment argocd-server \
     -p '{"spec":{"template":{"metadata":{"labels":{"maistra.io/expose-route":"true"}}}}}'
   

6. Créez un projet ArgoCD pour l’application UiPath® :

   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. Créez un rôle afin qu'ArgoCD puisse gérer les plages limites.

   Avant Automation Suite 2.2510.3, le graphique Helm de la plate-forme fournissait un objet LimitRange qui attribuait des limites de ressources par défaut dans l'espace de noms <uipath>, de sorte que le contrôleur d'application ArgoCD avait besoin d'autorisations pour le créer et le gérer. À partir de la version 2.2510.3, cet objet LimitRange a été supprimé du graphique et le contrôleur n’a besoin que du verbe delete pour supprimer le LimitRange créé par une version antérieure lors de la synchronisation.

   Pour créer le rôle, procédez comme suit:

   1. Enregistrez la configuration du rôle qui correspond à votre version d'Automation Suite sous forme de fichier YAML:
      • Automation Suite 2.2510.3 et versions ultérieures (seul le verbe delete est requis):

        kind: Role
        apiVersion: rbac.authorization.k8s.io/v1
        metadata:
          name: limit-range-manager
          namespace: <uipath>
        rules:
          - apiGroups: [""]
            resources: ["limitranges"]
            verbs: ["delete"]
        

      • Versions antérieures à 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"]
        

   2. Appliquez la configuration en exécutant la commande suivante. Assurez-vous de remplacer l'espace réservé <file_name.yaml> par le nom réel du fichier YAML :

      oc apply -f <file_name.yaml>
      

8. Liez le rôle limit-range-manager au compte de service argocd :

   oc -n <uipath> create rolebinding limit-range-manager-binding --role=limit-range-manager --serviceaccount=<openshift-gitops>:openshift-gitops-argocd-application-controller
   

9. Créez un rôle pour gérer les applications dans l'espace de noms <openshift-gitops> :

   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. Liez le rôle uipath-application-manager au compte de service uipathadmin :

    oc project <openshift-gitops>
    oc create rolebinding uipath-application-manager \
      --role=uipath-application-manager --serviceaccount=<uipath>:uipathadmin
    

11. En tant qu'administrateur de cluster, créez la clé secrète du référentiel helm-credentials dans l'espace de noms <openshift-gitops>. Il s'agit d'une clé secrète du référentiel ArgoCD qui contient les détails de la connexion au registre Helm, et ArgoCD le lit pour extraire les graphiques Automation Suite.

    Important :

    La façon dont cette clé secrète est gérée dépend de votre version d’Automation Suite:

    • Automation Suite 2.2510.4 et versions ultérieures: la clé secrète vous appartient. uipathctl ne le gère pas et ne nécessite aucun accès à celui-ci ou à l'espace de noms <openshift-gitops> - le compte de service uipathadmin n'a besoin d'aucune autorisation du tout, à l'exception de la gestion des applications ArgoCD, que vous avez accordée à l'étape précédente. Ignorez l'étape suivante.
    • Automation Suite 2.2510.3: vous créez la clé secrète, mais uipathctl la met toujours à jour à chaque exécution, de sorte que uipathadmin a besoin de get, update et patch sur cette clé. Terminez l'étape suivante avec le 2.2510.3 rôle.
    • Versions antérieures à 2.2510.3: uipathctl crée et gère la clé secrète elle-même, vous pouvez donc ignorer sa création. Terminez l'étape suivante avec le rôle pour les versions antérieures à 2.2510.3.

    Chaque fois que vous avez créé la clé secrète, vous devez également la maintenir à jour: si les informations d'identification du registre Helm changent, mettez à jour la clé secrète vous-même, sinon ArgoCD cessera d'être en mesure d'extraire les graphiques.

    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>
    

    Les valeurs stringData sont fournies en texte brut. Pour un registre ouvert tel que registry.uipath.com, omettez les clés username et password afin qu’ArgoCD se connecte de manière anonyme. Les laisser vides fait que ArgoCD tente de se connecter et échoue avec une erreur 401. Vous pouvez également créer la même clé secrète avec la CLI:

    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. Automation Suite 2.2510.3 et versions antérieures uniquement. Ces versions écrivent dans la clé secrète helm-credentials et recherchent l'espace de noms <openshift-gitops>; uipathadmin a donc besoin d'accéder aux deux. Ignorez cette étape sur la version 2.2510.4 et ultérieure.

    1. Enregistrez la configuration du rôle qui correspond à votre version d'Automation Suite sous forme de fichier YAML:
       • Automation Suite 2.2510.3, étendu au secret que vous avez créé à l'étape précédente:

         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"]
         

       • Versions antérieures à 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"]
         

    2. Appliquez la configuration en exécutant la commande suivante. Assurez-vous de remplacer l'espace réservé <file_name.yaml> par le nom réel du fichier YAML :

       oc apply -f <file_name.yaml>
       

    3. Liez le rôle argo-secret-role et le rôle namespace-reader au compte de service 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
       

En plus de terminer les étapes de configuration de l’instance partagée ArgoCD pour l’installation d’Automation Suite, vous devez ajouter les paramètres suivants au fichier input.json :

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

Accéder à l'instance ArgoCD partagée

Pour accéder à ArgoCD, procédez comme suit :

1. Obtenez l'URL de l'hôte en exécutant les commandes suivantes :

   oc get routes openshift-gitops-server -n <openshift-gitops> -o jsonpath={.spec.host}; echo
   

2. Pour vous connecter, utilisez admin comme nom d'utilisateur et exécutez la commande suivante pour obtenir le mot de passe :

   oc -n <openshift-gitops> get secrets openshift-gitops-cluster \
     -o "jsonpath={.data['admin\.password']}" | base64 -d; echo
   

Configuration du référentiel Helm privé et des certificats dans ArgoCD

Pour configurer le référentiel Helm dans ArgoCD, procédez comme suit :

1. Connectez-vous à ArgoCD.
2. Accédez à Paramètres > Référentiels > +CONNECTERPO.
3. Utilisez VI HTTPS pour la méthode de connexion.
4. Sélectionnez Helm comme type.
5. Indiquez un nom.
6. Choisissez uipath comme projet. uipath est le nom du projet ArgoCD que vous avez créé pour l’application UiPath®.
7. Indiquez l'URL du référentiel, le nom d'utilisateur, le mot de passe et les informations de certificat.
   Important :

   Lors de l'ajout du certificat client TLS sur la page +CONNECTUREPO , la clé de certificat client TLS devient un champ obligatoire. Pour configurer le certificat de registre sans la clé de certificat client TLS, procédez comme suit :

   1. Accédez à Paramètres > Certificats de référentiel et hôtes connus > +ADD TLS CERTIFICATE.
   2. Ajoutez le nom du référentiel et le certificat TLS au format PEM.
8. Cochez la case OCI .
9. Select Connect.
10. Assurez-vous que le statut de la connexion est Réussite.

Configuration d'ArgoCD pour plusieurs installations dans un seul cluster

Pour configurer ArgoCD pour plusieurs installations Automation Suite dans un seul cluster OpenShift, suivez ces étapes :

1. Vérifiez si tous les services d'ArgoCD sont opérationnels. Vous pouvez exécuter la commande suivante pour surveiller tous les pods :

   oc get pods -n <argocd>
   

2. Une fois tous les services opérationnels, vous pouvez utiliser la commande suivante de manière séquentielle pour corriger les autorisations d'ArgoCD. Cela permet à ArgoCD de gérer différents espaces de noms d'application dans lesquels Automation Suite est installé :

   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