Introduction à GitOps pour OpenShift

Aujourd'hui, nous parlerons des principes et des modèles de GitOps, ainsi que de la façon dont ces modèles sont mis en œuvre sur la plate-forme OpenShift. Un guide en ligne sur ce sujet est disponible ici .



En bref, GitOps est un ensemble de méthodes pratiques d'utilisation des requêtes pull Git pour gérer les configurations d'infrastructure et d'application. Le référentiel Git dans GitOps est considéré comme une source unique d'informations sur l'état du système, et tout changement de cet état est entièrement surveillé et audité.

L'idée du suivi des modifications dans GitOps n'est pas nouvelle; cette approche a longtemps été utilisée presque partout lorsque vous travaillez avec du code source d'application. GitOps implémente simplement des fonctions similaires (vérifications de vérification, demandes d'extraction, balises, etc.) lors de la gestion de l'infrastructure et des configurations d'application et offre des avantages similaires à ceux de la gestion du code source.

Pour GitOps, il n'y a pas de définition académique ni d'ensemble de règles approuvé, seulement un ensemble de principes sur lesquels cette pratique est basée:

• La description déclarative du système est stockée dans le référentiel Git (configs, monitoring, etc.).
• Les changements d'état sont effectués par le biais de demandes d'extraction.
• L'état des systèmes en cours d'exécution est aligné sur les données du référentiel à l'aide des requêtes push Git.

Principes GitOps

• Les définitions de système sont décrites comme du code source.

La configuration du système est considérée comme du code, elle peut donc être stockée et versionnée automatiquement dans le référentiel Git, qui est la seule source de vérité. Cette approche facilite le déploiement et la restauration des modifications apportées aux systèmes.

• L'état souhaité et la configuration du système sont définis et versionnés dans Git

En stockant et en versionnant dans Git l'état souhaité des systèmes, nous obtenons la possibilité d'annuler et d'annuler facilement les modifications apportées aux systèmes et aux applications. Nous pouvons également utiliser les mécanismes de sécurité de Git pour contrôler la propriété du code et vérifier son authenticité.

• Les modifications de configuration peuvent être appliquées automatiquement à l'aide de demandes d'extraction.

À l'aide des demandes d'extraction Git, nous pouvons facilement contrôler la façon dont les modifications sont appliquées aux configurations dans le référentiel. Par exemple, ils peuvent être envoyés pour vérification à d'autres membres de l'équipe ou exécuter des tests CI, etc.

Et en même temps, vous n'avez pas besoin de donner des droits d'administrateur à droite et à gauche. Pour valider les modifications de configuration, les utilisateurs disposent d'autorisations suffisantes dans le référentiel Git où ces configurations sont stockées.

• Correction des configurations de dérive non contrôlées

Lorsque l'état souhaité du système est stocké dans le référentiel Git, nous ne pouvons trouver que des logiciels qui contrôleraient que l'état actuel du système correspond à son état souhaité. Si ce n'est pas le cas, ce logiciel devrait - selon les paramètres - soit corriger lui-même la différence, soit nous informer de la dérive de la configuration.

Modèles GitOps pour OpenShift

Réconciliateur de ressources sur cluster

Selon ce modèle, le cluster dispose d'un contrôleur chargé de comparer les ressources Kubernetes (fichiers YAML) du référentiel Git avec les ressources réelles du cluster. En cas de divergences, le contrôleur envoie des notifications et, éventuellement, prend des mesures pour éliminer les incohérences. Ce modèle GitOps est utilisé par Anthos Config Management et Weaveworks Flux.

Réconciliateur de ressources externes (push)

Ce modèle peut être considéré comme une variation du précédent, lorsque nous avons un ou plusieurs contrôleurs chargés de synchroniser les ressources par paires «Git repository - Kubernetes cluster». La différence ici est que chaque cluster géré n'a pas besoin d'avoir son propre contrôleur séparé. Les paires de clusters Git-k8s sont souvent définies comme CRD de définition de ressources personnalisées, qui décrivent comment le contrôleur doit effectuer la synchronisation. Dans ce modèle, les contrôleurs comparent le référentiel Git spécifié dans CRD avec les ressources du cluster Kubernetes, également définies dans CRD, et effectuent les actions correspondantes en fonction des résultats de la comparaison. En particulier, un tel modèle GitOps est utilisé dans ArgoCD.

GitOps sur la plate-forme OpenShift

Administration de l'infrastructure multicubuster Kubernetes

Avec la diffusion de Kubernetes et la popularité croissante des stratégies multi-cloud et de l'informatique de pointe, le nombre moyen de clusters OpenShift par client a également augmenté.

Par exemple, lors de l'utilisation de l'informatique périphérique, les clusters d'un seul client peuvent être déployés par centaines, voire par milliers. En conséquence, il est obligé de gérer plusieurs clusters OpenShift indépendants ou coordonnés dans le cloud public et sur site.

Dans le même temps, de nombreux problèmes doivent être résolus, en particulier:

• Pour contrôler que les clusters sont dans un état identique (configurations, surveillance, stockage, etc.)
• Recréez (ou restaurez) des clusters selon un état connu.
• Créez de nouveaux clusters selon un état connu.
• Tirez les modifications sur plusieurs clusters OpenShift.
• Annulez les modifications apportées à plusieurs clusters OpenShift.
• Liez des configurations à motifs à différents environnements.

Configurations d'application

Au cours de leur cycle de vie, les applications passent souvent par une chaîne de clusters (dev, stage, etc.) avant d'entrer dans un cluster de production. De plus, en raison des exigences de disponibilité et d'évolutivité, les clients déploient souvent des applications sur plusieurs clusters sur site ou dans plusieurs régions d'une plateforme de cloud public.

Dans ce cas, il est nécessaire de résoudre les problèmes suivants:

• Assurer le mouvement des applications (binaires, configs, etc.) entre les clusters (dev, stage, etc.).
• Reportez les modifications apportées aux applications (binaires, configurations, etc.) dans plusieurs clusters OpenShift.
• Annulez les modifications des applications au niveau de l'état connu précédent.

Scénarios d'utilisation d'OpenShift GitOps

1. Appliquer les modifications du référentiel Git

L'administrateur de cluster peut stocker les configurations de cluster OpenShift dans le référentiel Git et les appliquer automatiquement pour créer de nouveaux clusters sans effort supplémentaire et les amener à un état identique à l'état connu stocké dans le référentiel Git.

2. Synchronisation avec Secret Manager

L'administrateur trouvera également utile de synchroniser les objets secrets OpenShift avec des logiciels appropriés comme Vault pour les gérer à l'aide d'outils spécialement créés à cet effet.

3. Contrôle des configurations de dérive

L'administrateur ne sera en faveur que si OpenShift GitOps détectera et avertira des écarts entre les configurations réelles et celles spécifiées dans le référentiel, afin que vous puissiez répondre rapidement à la dérive.

4. Notifications de dérive de configuration

Cela sera utile lorsque l'administrateur souhaite s'informer rapidement des configurations de dérive afin de prendre rapidement les mesures appropriées par lui-même.

5. Synchronisation manuelle des configurations lors de la dérive

Permet à l'administrateur de synchroniser le cluster OpenShift avec le référentiel Git en cas de configurations de dérive afin de ramener rapidement le cluster à un état connu antérieur.

6. Auto-synchronisation des configurations de dérive

L'administrateur peut également configurer le cluster OpenShift pour qu'il se synchronise automatiquement avec le référentiel lorsqu'une dérive est détectée, afin que la configuration du cluster corresponde toujours aux configurations de Git.

7. Clusters multiples - un référentiel

L'administrateur peut stocker les configurations de plusieurs clusters OpenShift différents dans un référentiel Git et les appliquer de manière sélective selon les besoins.

8. Hiérarchie des configurations de cluster (héritage)

L'administrateur peut définir la hiérarchie des configurations de cluster dans le référentiel (étape, prod, portefeuille d'applications, etc. avec héritage). En d'autres termes, il peut déterminer comment les configurations doivent être appliquées - à un ou plusieurs clusters.

Par exemple, si l'administrateur définit la hiérarchie «Clusters de production (prod) → Clusters du système X → Clusters de production du système X» dans le référentiel Git, les configurations suivantes sont appliquées aux clusters de production du système X:

• Configurations communes à tous les clusters de production.
• Configure le système de cluster X.
• Configurer le cluster de production du système X.

9. Modèles et remplacements de configuration

L'administrateur peut remplacer l'ensemble des configurations héritées et leurs valeurs, par exemple, pour affiner la configuration des clusters spécifiques auxquels ils seront appliqués.

10. Inclusion et exclusion sélectives pour les configurations, la configuration des applications

L'administrateur peut définir les conditions d'application ou de non-application de certaines configurations aux clusters ayant certaines caractéristiques.

11. Prise en charge des modèles

Les développeurs trouveront utile de choisir la manière dont les ressources de l'application seront déterminées (Helm Chart, pure Kubernetes yaml, etc.) afin d'utiliser le format le plus approprié pour chaque application spécifique.

Outils GitOps sur la plate-forme OpenShift

Argocd

ArgoCD implémente le modèle External Resource Reconcile et offre une interface utilisateur centralisée pour orchestrer les relations entre les clusters et les référentiels Git de manière un à plusieurs. Les inconvénients de ce programme incluent l'impossibilité de gérer les applications pendant qu'ArgoCD ne fonctionne pas.

Site officiel

Flux

Flux implémente le modèle On-Cluster Resource Reconcile et, par conséquent, il n'y a pas de gestion centralisée du référentiel de définitions, ce qui est un point faible. D'un autre côté, précisément en raison du manque de centralisation, la capacité de gérer les applications est préservée même en cas de défaillance d'un cluster.

Site officiel

Installer ArgoCD sur OpenShift

ArgoCD offre une excellente interface de ligne de commande et une console Web, nous ne considérerons donc pas Flux et d'autres alternatives ici.

Pour déployer ArgoCD sur la plate-forme OpenShift 4, procédez comme suit en tant qu'administrateur de cluster:

Déploiement de composants ArgoCD sur la plate-forme OpenShift

# Create a new namespace for ArgoCD components oc create namespace argocd # Apply the ArgoCD Install Manifest oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml # Get the ArgoCD Server password ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}') 

Le raffinement d'ArgoCD Server sera vu par OpenShift Route

 # Patch ArgoCD Server so no TLS is configured on the server (--insecure) PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}' oc -n argocd patch deployment argocd-server -p $PATCH # Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=Redirect 

Déployer l'outil ArgoCD Cli

 # Download the argocd binary, place it under /usr/local/bin and give it execution permissions curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd chmod +x /usr/local/bin/argocd 

Changer le mot de passe administrateur ArgoCD Server

 # Get ArgoCD Server Route Hostname ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}') # Login with the current admin password argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD} # Update admin's password argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password 

Une fois ces étapes terminées, vous pouvez travailler avec ArgoCD Server via la console Web ArgoCD WebUI ou l'outil de ligne de commande ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Il n'est jamais trop tard

«Le train est parti» - c'est ce qu'ils disent de la situation lorsque l'occasion de faire quelque chose est manquée. Dans le cas d'OpenShift, le désir de commencer immédiatement à utiliser cette nouvelle plate-forme cool crée souvent une telle situation avec la gestion et la maintenance des itinéraires, des déploiements et d'autres objets OpenShift. Mais la chance est-elle toujours complètement manquée?

Poursuivant une série d'articles sur GitOps , nous montrerons aujourd'hui comment transformer une application créée manuellement et ses ressources en un certain processus où la boîte à outils GitOps contrôle tout. Pour ce faire, nous déployons d'abord l'application httpd avec nos mains. La capture d'écran ci-dessous montre comment nous créons un espace de noms, un déploiement et un service, puis exposons ce service pour créer un itinéraire.

 oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml oc expose svc/httpd -n simple-app 

Nous avons donc une application créée manuellement. Maintenant, il doit être transféré sous le contrôle de GitOps sans perte de disponibilité. En bref, il fait ceci:

• Créez un référentiel Git pour le code.
• Nous exportons nos objets actuels et les chargeons dans le référentiel Git.
• Sélectionnez et déployez la boîte à outils GitOps.
• Ajoutez notre référentiel à cette boîte à outils.
• Nous définissons l'application dans notre boîte à outils GitOps.
• Effectuez une exécution d'essai de l'application à l'aide de la boîte à outils GitOps.
• Nous synchronisons les objets à l'aide de la boîte à outils GitOps.
• Nous activons l'élagage et la synchronisation automatique des objets.

Comme mentionné dans l' article précédent, GitOps a une et une seule source d'informations sur tous les objets dans le (s) cluster (s) Kubernetes - le référentiel Git. De plus, nous partons du principe que votre organisation utilise déjà un référentiel Git. Il peut être public ou privé, mais il doit être disponible pour les clusters Kubernetes. Il peut s'agir du même référentiel que pour le code d'application ou d'un référentiel distinct créé spécifiquement pour le déploiement. Il est recommandé de disposer d'autorisations strictes dans le référentiel, car les objets secrets, les itinéraires et autres éléments sensibles à la sécurité y seront stockés.

Dans notre exemple, nous allons créer un nouveau référentiel public sur GitHub. Vous pouvez le nommer comme vous le souhaitez, nous utilisons le nom blogpost.

Si les fichiers YAML des objets n'étaient pas stockés localement ou dans Git, vous devrez utiliser les binaires oc ou kubectl. Dans la capture d'écran ci-dessous, nous demandons YAML pour notre espace de noms, déploiement, service et route. Avant cela, nous avons cloné le référentiel nouvellement créé et l'avons déplacé avec la commande cd.

 oc get namespace simple-app -o yaml --export > namespace.yaml oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml oc get service httpd -o yaml -n simple-app --export > service.yaml oc get route httpd -o yaml -n simple-app --export > route.yaml 

Corrigez maintenant le fichier deployment.yaml pour en supprimer un champ que le CD Argo ne peut pas synchroniser.

 sed -i '/\sgeneration: .*/d' deployment.yaml 

De plus, vous devez modifier l'itinéraire. Nous allons d'abord définir la variable multiligne, puis remplacer ingress: null par le contenu de cette variable.

 export ROUTE=" ingress:\\ - conditions:\\ - status: 'True'\\ type: Admitted" sed -i "s/ ingress: null/$ROUTE/g" route.yaml 

Donc, avec les fichiers triés, il reste à les enregistrer dans le référentiel Git. Après cela, ce référentiel devient la seule source d'informations et toute modification manuelle des objets doit être strictement interdite.

 git commit -am 'initial commit of objects' git push origin master 

De plus, nous partons du fait qu'ArgoCD est déjà déployé pour vous (comment faire, voir le post précédent). Par conséquent, nous ajoutons au CD Argo le référentiel que nous avons créé qui contient le code d'application de notre exemple. Assurez-vous simplement de spécifier le référentiel exact que vous avez créé précédemment.

 argocd repo add https://github.com/cooktheryan/blogpost 

Créez maintenant l'application. L'application définit les valeurs de sorte que la boîte à outils GitOps comprenne le référentiel et les chemins à utiliser, quel OpenShift est nécessaire pour gérer les objets, ainsi que la branche spécifique du référentiel nécessaire et si les ressources doivent être auto-synchronisées.

 argocd app create --project default \ --name simple-app --repo https://github.com/cooktheryan/blogpost.git \ --path . --dest-server https://kubernetes.default.svc \ --dest-namespace simple-app --revision master --sync-policy none 

Une fois l'application spécifiée dans le CD Argo, cette boîte à outils commence à vérifier la conformité des objets déjà déployés avec les définitions du référentiel. Dans notre exemple, la synchronisation automatique et le nettoyage sont désactivés, donc les éléments ne changent pas encore. Veuillez noter que dans l'interface Argo CD, notre application aura le statut «Hors synchronisation» (non synchronisée), car il n'y a aucune étiquette d'étiquette qu'ArgoCD appose.
C'est pourquoi, lorsque nous lancerons la synchronisation un peu plus tard, le redéploiement des objets ne sera pas effectué.

Exécutez maintenant un test pour vous assurer qu'il n'y a pas d'erreurs dans nos fichiers.

 argocd app sync simple-app --dry-run 

S'il n'y a aucune erreur, vous pouvez procéder à la synchronisation.

 argocd app sync simple-app 

Après avoir exécuté la commande argocd get sur notre application, nous devrions voir que le statut de l'application est passé à Healthy ou Synced. Cela signifie que toutes les ressources du référentiel Git correspondent désormais aux ressources déjà déployées.

 argocd app get simple-app Name: simple-app Project: default Server: https://kubernetes.default.svc Namespace: simple-app URL: https://argocd-server-route-argocd.apps.example.com/applications/simple-app Repo: https://github.com/cooktheryan/blogpost.git Target: master Path: . Sync Policy: <none> Sync Status: Synced to master (60e1678) Health Status: Healthy ... 

Mais maintenant, vous pouvez activer la synchronisation automatique et le nettoyage pour vous assurer que rien ne sera créé manuellement et que chaque fois que l'objet est créé ou mis à jour dans le référentiel, le déploiement sera effectué.

 argocd app set simple-app --sync-policy automated --auto-prune 

Ainsi, nous avons réussi à transférer au contrôle de GitOps une application qui au départ n'utilisait pas GitOps en aucune façon.