21.11. Mise à jour de GitOps ZTP


Vous pouvez mettre à jour l'infrastructure Gitops zero touch provisioning (ZTP) indépendamment du cluster hub, de Red Hat Advanced Cluster Management (RHACM) et des clusters OpenShift Container Platform gérés.

Note

Vous pouvez mettre à jour l'opérateur Red Hat OpenShift GitOps lorsque de nouvelles versions sont disponibles. Lorsque vous mettez à jour le plugin GitOps ZTP, examinez les fichiers mis à jour dans la configuration de référence et assurez-vous que les changements répondent à vos besoins.

21.11.1. Vue d'ensemble du processus de mise à jour ZTP de GitOps

Vous pouvez mettre à jour GitOps zero touch provisioning (ZTP) pour un hub cluster pleinement opérationnel utilisant une version antérieure de l'infrastructure GitOps ZTP. Le processus de mise à jour évite l'impact sur les clusters gérés.

Note

Toute modification des paramètres de politique, y compris l'ajout de contenu recommandé, entraîne une mise à jour des politiques qui doit être déployée sur les clusters gérés et réconciliée.

À un niveau élevé, la stratégie de mise à jour de l'infrastructure ZTP de GitOps est la suivante :

  1. Étiqueter tous les groupes existants avec l'étiquette ztp-done.
  2. Arrêter les applications ArgoCD.
  3. Installer les nouveaux outils ZTP de GitOps.
  4. Mettre à jour le contenu requis et les changements optionnels dans le dépôt Git.
  5. Mettre à jour et redémarrer la configuration de l'application.

21.11.2. Préparation de la mise à niveau

Utilisez la procédure suivante pour préparer votre site à la mise à niveau GitOps zero touch provisioning (ZTP).

Procédure

  1. Obtenir la dernière version du conteneur GitOps ZTP qui contient les ressources personnalisées (CR) utilisées pour configurer Red Hat OpenShift GitOps pour une utilisation avec GitOps ZTP.
  2. Extrayez le répertoire argocd/deployment à l'aide des commandes suivantes :

    $ mkdir -p ./update
    $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12 extract /home/ztp --tar | tar x -C ./update

    Le répertoire /update contient les sous-répertoires suivants :

    • update/extra-manifestcontient les fichiers CR source que le CR SiteConfig utilise pour générer le manifeste supplémentaire configMap.
    • update/source-crscontient les fichiers CR source que le CR PolicyGenTemplate utilise pour générer les stratégies de Red Hat Advanced Cluster Management (RHACM).
    • update/argocd/deploymentcontient des correctifs et des fichiers YAML à appliquer sur le cluster hub pour l'étape suivante de cette procédure.
    • update/argocd/example: contient des exemples de fichiers SiteConfig et PolicyGenTemplate qui représentent la configuration recommandée.
  3. Mettez à jour les fichiers clusters-app.yaml et policies-app.yaml pour refléter le nom de vos applications et l'URL, la branche et le chemin de votre dépôt Git.

    Si la mise à niveau inclut des changements qui entraînent des politiques obsolètes, ces dernières doivent être supprimées avant d'effectuer la mise à niveau.

  4. Diffuser les changements entre les CR de configuration et de déploiement dans le dossier /update et le repo Git où vous gérez les CR de votre flotte de sites. Appliquez et poussez les changements requis dans le référentiel de votre site.

    Important

    Lorsque vous mettez à jour GitOps ZTP vers la dernière version, vous devez appliquer les changements du répertoire update/argocd/deployment au dépôt de votre site. N'utilisez pas d'anciennes versions des fichiers argocd/deployment/.

21.11.3. Labellisation des clusters existants

Pour s'assurer que les clusters existants ne sont pas touchés par les mises à jour de l'outil, apposez l'étiquette ztp-done sur tous les clusters gérés existants.

Note

Cette procédure s'applique uniquement à la mise à jour des clusters qui n'ont pas été provisionnés avec Topology Aware Lifecycle Manager (TALM). Les clusters provisionnés avec TALM sont automatiquement étiquetés avec ztp-done.

Procédure

  1. Trouvez un sélecteur d'étiquettes qui répertorie les clusters gérés qui ont été déployés avec le zero touch provisioning (ZTP), comme local-cluster!=true:

    $ oc get managedcluster -l 'local-cluster!=true'
  2. Assurez-vous que la liste obtenue contient tous les clusters gérés qui ont été déployés avec ZTP, puis utilisez ce sélecteur pour ajouter l'étiquette ztp-done:

    $ oc label managedcluster -l 'local-cluster!=true' ztp-done=

21.11.4. Arrêt des applications ZTP existantes de GitOps

La suppression des applications existantes permet de s'assurer que les modifications apportées au contenu existant dans le dépôt Git ne sont pas déployées tant que la nouvelle version des outils n'est pas disponible.

Utilisez les fichiers d'application du répertoire deployment. Si vous avez utilisé des noms personnalisés pour les applications, mettez d'abord à jour les noms dans ces fichiers.

Procédure

  1. Effectuer une suppression non cascadée sur l'application clusters pour laisser toutes les ressources générées en place :

    $ oc delete -f update/argocd/deployment/clusters-app.yaml
  2. Effectuez une suppression en cascade sur l'application policies pour supprimer toutes les politiques précédentes :

    $ oc patch -f policies-app.yaml -p '{"metadata": {"finalizers": ["resources-finalizer.argocd.argoproj.io"]}}' --type merge
    $ oc delete -f update/argocd/deployment/policies-app.yaml

21.11.5. Changements requis dans le dépôt Git

Lors de la mise à niveau du conteneur ztp-site-generate d'une version antérieure de GitOps ZTP vers la version 4.10 ou une version ultérieure, le contenu du référentiel Git doit répondre à des exigences supplémentaires. Le contenu existant du référentiel doit être mis à jour pour refléter ces changements.

  • Apportez les modifications nécessaires aux fichiers PolicyGenTemplate:

    Tous les fichiers PolicyGenTemplate doivent être créés dans un Namespace préfixé par ztp. Cela garantit que l'application GitOps zero touch provisioning (ZTP) est en mesure de gérer les CR de politique générés par GitOps ZTP sans entrer en conflit avec la façon dont Red Hat Advanced Cluster Management (RHACM) gère les politiques en interne.

  • Ajouter le fichier kustomization.yaml au référentiel :

    Tous les CR SiteConfig et PolicyGenTemplate doivent être inclus dans un fichier kustomization.yaml sous leurs arborescences respectives. Par exemple :

    ├── policygentemplates
    │   ├── site1-ns.yaml
    │   ├── site1.yaml
    │   ├── site2-ns.yaml
    │   ├── site2.yaml
    │   ├── common-ns.yaml
    │   ├── common-ranGen.yaml
    │   ├── group-du-sno-ranGen-ns.yaml
    │   ├── group-du-sno-ranGen.yaml
    │   └── kustomization.yaml
    └── siteconfig
        ├── site1.yaml
        ├── site2.yaml
        └── kustomization.yaml
    Note

    Les fichiers énumérés dans les sections generator doivent contenir uniquement les CR SiteConfig ou PolicyGenTemplate. Si vos fichiers YAML existants contiennent d'autres CR, par exemple Namespace, ces autres CR doivent être extraits dans des fichiers séparés et répertoriés dans la section resources.

    Le fichier de personnalisation PolicyGenTemplate doit contenir tous les fichiers YAML PolicyGenTemplate dans la section generator et les CR Namespace dans la section resources. Par exemple :

    apiVersion: kustomize.config.k8s.io/v1beta1
    kind: Kustomization
    
    generators:
    - common-ranGen.yaml
    - group-du-sno-ranGen.yaml
    - site1.yaml
    - site2.yaml
    
    resources:
    - common-ns.yaml
    - group-du-sno-ranGen-ns.yaml
    - site1-ns.yaml
    - site2-ns.yaml

    Le fichier de personnalisation SiteConfig doit contenir tous les fichiers YAML SiteConfig dans la section generator et tout autre CR dans les ressources :

    apiVersion: kustomize.config.k8s.io/v1beta1
    kind: Kustomization
    
    generators:
    - site1.yaml
    - site2.yaml
  • Supprimer les fichiers pre-sync.yaml et post-sync.yaml.

    Dans OpenShift Container Platform 4.10 et plus, les fichiers pre-sync.yaml et post-sync.yaml ne sont plus nécessaires. Le CR update/deployment/kustomization.yaml gère le déploiement des politiques sur le cluster hub.

    Note

    Il existe un ensemble de fichiers pre-sync.yaml et post-sync.yaml sous les arbres SiteConfig et PolicyGenTemplate.

  • Examiner et intégrer les modifications recommandées

    Chaque version peut inclure des changements supplémentaires recommandés pour la configuration appliquée aux clusters déployés. Généralement, ces changements permettent de réduire l'utilisation du processeur par la plateforme OpenShift, d'ajouter des fonctionnalités ou d'améliorer le réglage de la plateforme.

    Examinez les CR de référence SiteConfig et PolicyGenTemplate applicables aux types de clusters de votre réseau. Ces exemples se trouvent dans le répertoire argocd/example extrait du conteneur ZTP GitOps.

21.11.6. Installation des nouvelles applications ZTP de GitOps

En utilisant le répertoire argocd/deployment extrait, et après avoir vérifié que les applications pointent vers le dépôt Git de votre site, appliquez le contenu complet du répertoire de déploiement. L'application du contenu complet du répertoire garantit que toutes les ressources nécessaires aux applications sont correctement configurées.

Procédure

  1. Pour patcher l'instance ArgoCD dans le cluster hub en utilisant le fichier patch que vous avez précédemment extrait dans le répertoire update/argocd/deployment/, entrez la commande suivante :

    $ oc patch argocd openshift-gitops \
    -n openshift-gitops --type=merge \
    --patch-file update/argocd/deployment/argocd-openshift-gitops-patch.json
  2. Pour appliquer le contenu du répertoire argocd/deployment, entrez la commande suivante :

    $ oc apply -k update/argocd/deployment

21.11.7. Déploiement des changements de configuration de GitOps ZTP

Si des changements de configuration ont été inclus dans la mise à niveau en raison de la mise en œuvre des changements recommandés, le processus de mise à niveau entraîne un ensemble de CR de politiques sur le cluster concentrateur dans l'état Non-Compliant. Avec le conteneur ZTP GitOps v4.10 et les versions ultérieures ztp-site-generate, ces politiques sont définies en mode inform et ne sont pas poussées vers les clusters gérés sans une étape supplémentaire de la part de l'utilisateur. Cela permet de gérer les changements potentiellement perturbateurs apportés aux clusters en termes de moment où les changements sont effectués, par exemple, au cours d'une fenêtre de maintenance, et de nombre de clusters mis à jour simultanément.

Pour déployer les changements, créez un ou plusieurs CR ClusterGroupUpgrade comme indiqué dans la documentation TALM. Le CR doit contenir la liste des politiques Non-Compliant que vous souhaitez appliquer aux clusters gérés, ainsi qu'une liste ou un sélecteur des clusters à inclure dans la mise à jour.

Ressources supplémentaires

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.