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.
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.
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 :
-
Étiqueter tous les groupes existants avec l'étiquette
ztp-done
. - Arrêter les applications ArgoCD.
- Installer les nouveaux outils ZTP de GitOps.
- Mettre à jour le contenu requis et les changements optionnels dans le dépôt Git.
- 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
- 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.
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-manifest
contient les fichiers CR source que le CRSiteConfig
utilise pour générer le manifeste supplémentaireconfigMap
. -
update/source-crs
contient les fichiers CR source que le CRPolicyGenTemplate
utilise pour générer les stratégies de Red Hat Advanced Cluster Management (RHACM). -
update/argocd/deployment
contient 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 fichiersSiteConfig
etPolicyGenTemplate
qui représentent la configuration recommandée.
-
Mettez à jour les fichiers
clusters-app.yaml
etpolicies-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.
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.ImportantLorsque 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 fichiersargocd/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.
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
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'
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
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
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 unNamespace
préfixé parztp
. 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
etPolicyGenTemplate
doivent être inclus dans un fichierkustomization.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
NoteLes fichiers énumérés dans les sections
generator
doivent contenir uniquement les CRSiteConfig
ouPolicyGenTemplate
. Si vos fichiers YAML existants contiennent d'autres CR, par exempleNamespace
, ces autres CR doivent être extraits dans des fichiers séparés et répertoriés dans la sectionresources
.Le fichier de personnalisation
PolicyGenTemplate
doit contenir tous les fichiers YAMLPolicyGenTemplate
dans la sectiongenerator
et les CRNamespace
dans la sectionresources
. 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 YAMLSiteConfig
dans la sectiongenerator
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
etpost-sync.yaml
.Dans OpenShift Container Platform 4.10 et plus, les fichiers
pre-sync.yaml
etpost-sync.yaml
ne sont plus nécessaires. Le CRupdate/deployment/kustomization.yaml
gère le déploiement des politiques sur le cluster hub.NoteIl existe un ensemble de fichiers
pre-sync.yaml
etpost-sync.yaml
sous les arbresSiteConfig
etPolicyGenTemplate
.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
etPolicyGenTemplate
applicables aux types de clusters de votre réseau. Ces exemples se trouvent dans le répertoireargocd/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
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
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
- Pour plus d'informations sur le Topology Aware Lifecycle Manager (TALM), voir À propos de la configuration du Topology Aware Lifecycle Manager.
-
Pour plus d'informations sur la création des CR
ClusterGroupUpgrade
, voir À propos du CR ClusterGroupUpgrade auto-créé pour ZTP.