Chapitre 4. GitOps

Avant cette mise à jour, lorsque vous configuriez Dex en utilisant le paramètre .spec.dex et que vous essayiez de vous connecter à l'interface utilisateur d'Argo CD en utilisant l'option LOG IN VIA OPENSHIFT, vous ne pouviez pas vous connecter. Cette mise à jour corrige le problème.

Avec cette mise à jour, vous pouvez ajouter la prise en charge de la fonctionnalité ApplicationSet Progressive Rollout Strategy. Grâce à cette fonctionnalité, vous pouvez améliorer la ressource ApplicationSet d'ArgoCD pour intégrer une stratégie de déploiement pour une mise à jour progressive des ressources d'application après avoir modifié la spécification de l'ApplicationSet ou les modèles d'application. Lorsque vous activez cette fonctionnalité, les applications sont mises à jour dans un ordre déclaratif au lieu d'être mises à jour simultanément. GITOPS-956

Avec cette mise à jour, Red Hat OpenShift GitOps Operator et kam CLI sont maintenant disponibles pour l'architecture ARM sur OpenShift Container Platform. GITOPS-1688

Avec cette mise à jour, vous pouvez passer des arguments de commande au déploiement du serveur repo en utilisant le CD CR d'Argo. GITOPS-2445

Par exemple :

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  repo:
    extraRepoCommandArgs:
      - --max.combined.directory.manifests.size
      - 10M

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  repo:
    extraRepoCommandArgs:
      - --max.combined.directory.manifests.size
      - 10M

Avant cette mise à jour, la variable d'environnement ARGOCD_GIT_MODULES_ENABLED ne pouvait être définie que sur le pod openshift-gitops-repo-server et non sur le pod ApplicationSet Controller. Par conséquent, lors de l'utilisation du générateur Git, les sous-modules Git étaient clonés lors de la génération des applications enfants car la variable était absente de l'environnement ApplicationSet Controller. De plus, si les informations d'identification requises pour cloner ces sous-modules n'étaient pas configurées dans ArgoCD, la génération de l'application échouait. Cette mise à jour corrige le problème ; vous pouvez maintenant ajouter des variables d'environnement telles que ArgoCD_GIT_MODULES_ENABLED au pod ApplicationSet Controller en utilisant le CD CR d'Argo. Le pod ApplicationSet Controller génère alors avec succès des applications enfants à partir du référentiel cloné et aucun sous-module n'est cloné dans le processus. GITOPS-2399

Par exemple :

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  applicationSet:
    env:
     - name: ARGOCD_GIT_MODULES_ENABLED
       value: "true"

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  applicationSet:
    env:
     - name: ARGOCD_GIT_MODULES_ENABLED
       value: "true"

Avec cette mise à jour, vous pouvez personnaliser le comportement des ressources en utilisant les sous-clés supplémentaires suivantes :

GITOPS-1561

Avec cette mise à jour, vous pouvez créer des applications, qui sont gérées par la même instance de plan de contrôle Argo CD, dans n'importe quel espace de noms dans le même cluster. En tant qu'administrateur, effectuez les actions suivantes pour activer cette mise à jour :

Avec cette mise à jour, Argo CD prend en charge la fonctionnalité Server-Side Apply, qui aide les utilisateurs à effectuer les tâches suivantes :

Avant cette mise à jour, le certificat RHSSO ne pouvait pas être validé lorsqu'il était configuré avec un certificat qui n'était pas signé par les autorités de certification. Cette mise à jour corrige le problème et vous pouvez désormais fournir un certificat personnalisé qui sera utilisé pour vérifier le certificat TLS du Keycloak lors de la communication avec celui-ci. Vous pouvez ajouter le site rootCA au champ de la ressource personnalisée Argo CD .spec.keycloak.rootCA. L'opérateur réconcilie ce changement et met à jour le champ oidc.config dans le champ argocd-cm ConfigMap avec le certificat racine codé en PEM. GITOPS-2214

Par exemple :

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
    keycloak:
     rootCA: |
       ---- BEGIN CERTIFICATE ----
       This is a dummy certificate
       Please place this section with appropriate rootCA
       ---- END CERTIFICATE ----
  server:
    route:
      enabled: true

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
    keycloak:
     rootCA: |
       ---- BEGIN CERTIFICATE ----
       This is a dummy certificate
       Please place this section with appropriate rootCA
       ---- END CERTIFICATE ----
  server:
    route:
      enabled: true

Red Hat OpenShift GitOps Operator peut utiliser RHSSO (KeyCloak) via OIDC en plus de Dex. Cependant, avec l'application d'un correctif de sécurité récent, le certificat de RHSSO ne peut pas être validé dans certains scénarios. GITOPS-2214

En guise de solution de contournement, désactivez la validation TLS pour le point de terminaison OIDC (Keycloak/RHSSO) dans la spécification ArgoCD.

Avant cette mise à jour, le certificat RHSSO ne pouvait pas être validé lorsqu'il était configuré avec un certificat qui n'était pas signé par les autorités de certification. Cette mise à jour corrige le problème et vous pouvez désormais fournir un certificat personnalisé qui sera utilisé pour vérifier le certificat TLS du Keycloak lors de la communication avec celui-ci. Vous pouvez ajouter le site rootCA au champ de la ressource personnalisée Argo CD .spec.keycloak.rootCA. L'opérateur réconcilie ce changement et met à jour le champ oidc.config dans le champ argocd-cm ConfigMap avec le certificat racine codé en PEM. GITOPS-2214

Par exemple :

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
    keycloak:
     rootCA: |
       ---- BEGIN CERTIFICATE ----
       This is a dummy certificate
       Please place this section with appropriate rootCA
       ---- END CERTIFICATE ----
  server:
    route:
      enabled: true

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
    keycloak:
     rootCA: |
       ---- BEGIN CERTIFICATE ----
       This is a dummy certificate
       Please place this section with appropriate rootCA
       ---- END CERTIFICATE ----
  server:
    route:
      enabled: true

Red Hat OpenShift GitOps Operator peut utiliser RHSSO (KeyCloak) avec OIDC et Dex. Cependant, avec l'application d'un correctif de sécurité récent, l'opérateur ne peut pas valider le certificat RHSSO dans certains scénarios. GITOPS-2214

En guise de solution de contournement, désactivez la validation TLS pour le point de terminaison OIDC (Keycloak/RHSSO) dans la spécification ArgoCD.

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  extraConfig:
    "admin.enabled": "true"
...

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  extraConfig:
    "admin.enabled": "true"
...

Avec cette mise à jour, l'opérateur met à jour Red Hat Single Sign-On (RH-SSO) vers la version v7.5.1 incluant les améliorations suivantes :

Avec cette mise à jour, un nouveau champ URL .host est ajouté au champ .status de l'opérande Argo CD. Lorsqu'une route ou une entrée est activée avec la priorité donnée à la route, le nouveau champ URL affiche la route. Si aucune URL n'est fournie par la route ou l'entrée, le champ .host n'est pas affiché.

Lorsque la route ou l'entrée est configurée, mais que le contrôleur correspondant n'est pas configuré correctement et n'est pas dans l'état Ready ou ne propage pas son URL, la valeur du champ .status.host dans l'opérande indique Pending au lieu d'afficher l'URL. Cela affecte l'état général de l'opérande en le rendant Pending au lieu de Available. GITOPS-654

Avant cette mise à jour, le certificat RHSSO ne pouvait pas être validé lorsqu'il était configuré avec un certificat qui n'était pas signé par les autorités de certification. Cette mise à jour corrige le problème et vous pouvez désormais fournir un certificat personnalisé qui sera utilisé pour vérifier le certificat TLS du Keycloak lors de la communication avec celui-ci. Vous pouvez ajouter le site rootCA au champ de la ressource personnalisée Argo CD .spec.keycloak.rootCA. L'opérateur réconcilie ce changement et met à jour le champ oidc.config dans le champ argocd-cm ConfigMap avec le certificat racine codé en PEM. GITOPS-2214

Par exemple :

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
    keycloak:
     rootCA: |
       ---- BEGIN CERTIFICATE ----
       This is a dummy certificate
       Please place this section with appropriate rootCA
       ---- END CERTIFICATE ----
  server:
    route:
      enabled: true

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
    keycloak:
     rootCA: |
       ---- BEGIN CERTIFICATE ----
       This is a dummy certificate
       Please place this section with appropriate rootCA
       ---- END CERTIFICATE ----
  server:
    route:
      enabled: true

Red Hat OpenShift GitOps Operator peut utiliser RHSSO (KeyCloak) avec OIDC et Dex. Cependant, avec l'application d'un correctif de sécurité récent, l'opérateur ne peut pas valider le certificat RHSSO dans certains scénarios. GITOPS-2214

En guise de solution de contournement, désactivez la validation TLS pour le point de terminaison OIDC (Keycloak/RHSSO) dans la spécification ArgoCD.

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  extraConfig:
    "admin.enabled": "true"
...

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  extraConfig:
    "admin.enabled": "true"
...

Red Hat OpenShift GitOps Operator v1.4.0 a introduit une régression qui supprime les champs de description de spec pour les CRD suivants :

En tant qu'utilisateur administratif, lorsque vous donnez à Argo CD l'accès à un espace de noms en utilisant l'étiquette argocd.argoproj.io/managed-by, il assume les privilèges d'administrateur d'espace de noms. Ces privilèges posent un problème aux administrateurs qui fournissent des espaces de noms à des non-administrateurs, tels que des équipes de développement, car ils permettent à ces derniers de modifier des objets tels que les stratégies de réseau.

Avec cette mise à jour, les administrateurs peuvent configurer un rôle de cluster commun pour tous les espaces de noms gérés. Dans les liaisons de rôles pour le contrôleur d'application Argo CD, l'opérateur fait référence à la variable d'environnement CONTROLLER_CLUSTER_ROLE. Dans les liaisons de rôles pour le serveur Argo CD, l'opérateur se réfère à la variable d'environnement SERVER_CLUSTER_ROLE. Si ces variables d'environnement contiennent des rôles personnalisés, l'opérateur ne crée pas le rôle d'administrateur par défaut. Au lieu de cela, il utilise le rôle personnalisé existant pour tous les espaces de noms gérés. GITOPS-1290

Si vous migrez du fournisseur d'authentification Dex vers le fournisseur Keycloak, il se peut que vous rencontriez des problèmes de connexion avec Keycloak.

Pour éviter ce problème, lors de la migration, désinstallez Dex en supprimant la section .spec.dex de la ressource personnalisée du CD Argo. Laissez quelques minutes à Dex pour se désinstaller complètement. Ensuite, installez Keycloak en ajoutant .spec.sso.provider: keycloak à la ressource personnalisée du CD Argo.

En guise de solution, désinstallez Keycloak en supprimant .spec.sso.provider: keycloak. Réinstallez-le ensuite. GITOPS-1450, GITOPS-1331

Lors de l'utilisation d'une instance Argo CD Namespace-scoped, par exemple, une instance Argo CD qui n'est pas cadrée sur All Namepsaces dans un cluster, Red Hat OpenShift GitOps maintient dynamiquement une liste d'espaces de noms gérés. Ces espaces de noms incluent l'étiquette argocd.argoproj.io/managed-by. Cette liste d'espaces de noms est stockée dans un cache à Argo CD Settings Clusters "in-cluster" NAMESPACES. Avant cette mise à jour, si vous supprimiez l'un de ces espaces de noms, l'opérateur l'ignorait et l'espace de noms restait dans la liste. Ce comportement brisait CONNECTION STATE dans cette configuration de cluster, et toutes les tentatives de synchronisation aboutissaient à des erreurs. Par exemple :

Le compte de service Argo n'a pas <random_verb> sur <random_resource_type> dans l'espace de noms <the_namespace_you_deleted>.

Le compte de service Argo n'a pas <random_verb> sur <random_resource_type> dans l'espace de noms <the_namespace_you_deleted>.

Ce bogue est corrigé. GITOPS-1521

L'Opérateur GitOps est maintenant conforme aux conventions de nommage recommandées par la dernière version de l'Operator-SDK :

Lors de la migration du fournisseur d'authentification Dex vers le fournisseur Keycloak, il se peut que vous rencontriez des problèmes de connexion avec Keycloak. GITOPS-1450

Pour éviter ce problème, lors de la migration, désinstallez Dex en supprimant la section .spec.dex qui se trouve dans la ressource personnalisée du CD Argo. Laissez quelques minutes à Dex pour se désinstaller complètement, puis procédez à l'installation de Keycloak en ajoutant .spec.sso.provider: keycloak à la ressource personnalisée du CD Argo.

En guise de solution, désinstallez Keycloak en supprimant .spec.sso.provider: keycloak, puis réinstallez-le.

L'authentification Argo CD est maintenant intégrée avec Red Hat SSO et elle est automatiquement configurée avec OpenShift 4 Identity Provider sur le cluster. Cette fonctionnalité est désactivée par défaut. Pour activer Red Hat SSO, ajoutez la configuration SSO dans ArgoCD CR comme indiqué ci-dessous. Actuellement,keycloak est le seul fournisseur pris en charge.

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
  server:
    route:
     enabled: true

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
  server:
    route:
     enabled: true

Vous pouvez désormais définir des noms d'hôtes à l'aide d'étiquettes d'itinéraires afin de prendre en charge la répartition des routeurs. La prise en charge de la définition d'étiquettes sur les routes server (serveur argocd), grafana et prometheus est désormais disponible. Pour définir des étiquettes sur une route, ajoutez labels sous la configuration de la route pour un serveur dans le CR ArgoCD.

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  server:
    route:
     enabled: true
     labels:
       key1: value1
       key2: value2

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  server:
    route:
     enabled: true
     labels:
       key1: value1
       key2: value2

Le quota de ressources a été activé dans l'espace de noms openshift-gitops dans Red Hat OpenShift GitOps 1.2. Cela peut affecter les charges de travail hors bande déployées manuellement et les charges de travail déployées par l'instance Argo CD par défaut dans l'espace de noms openshift-gitops. Lorsque vous mettez à niveau Red Hat OpenShift GitOps v1.1.2 vers v1.2, ces charges de travail doivent être configurées avec des demandes et des limites de ressources. S'il y a des charges de travail supplémentaires, le quota de ressources dans l'espace de noms openshift-gitops doit être augmenté.

Quota de ressources actuel pour l'espace de noms openshift-gitops.

Vous pouvez utiliser la commande suivante pour mettre à jour les limites du processeur.

oc patch resourcequota openshift-gitops-compute-resources -n openshift-gitops --type='json' -p='[{"op": "replace", "path": "/spec/hard/limits.cpu", "value":"9000m"}]'

$ oc patch resourcequota openshift-gitops-compute-resources -n openshift-gitops --type='json' -p='[{"op": "replace", "path": "/spec/hard/limits.cpu", "value":"9000m"}]'

Vous pouvez utiliser la commande suivante pour mettre à jour les demandes de CPU.

oc patch resourcequota openshift-gitops-compute-resources -n openshift-gitops --type='json' -p='[{"op": "replace", "path": "/spec/hard/cpu", "value":"7000m"}]

$ oc patch resourcequota openshift-gitops-compute-resources -n openshift-gitops --type='json' -p='[{"op": "replace", "path": "/spec/hard/cpu", "value":"7000m"}]

Vous pouvez remplacer le chemin dans les commandes ci-dessus de cpu à memory pour mettre à jour la mémoire.