Gérer des environnements multicluster avec GIT dans Kubernetes

La gestion simultanée de plusieurs clusters Kubernetes est une opération cruciale pour les organisations disposant d’infrastructures cloud natives. La méthode GitOps et l’utilisation de GitLab ou de GitHub sont souvent les solutions de choix pour mener ces tâches à bien, car elles ont démontré leur efficacité. Dans cet article, nous allons voir les raisons de leur popularité et comment les utiliser au mieux.

Vous souhaitez devenir incollable dans la gestion de vos applications conteneurisées ? Nos formations Kubernetes vous donneront toutes les clés en main pour devenir autonome sur vos missions DevOps. Vous pouvez également suivre nos formations Git afin d’apprendre l’utilisation d’outils comme GitLab ou GitHub.
L’équipe Ambient IT

Qu’est-ce que Gitops ?

Le GitOps est un ensemble de pratiques qui permettent aux développeurs d’effectuer des tâches qui relèvent généralement du domaine des opérations informatiques. L’idée de base est d’utiliser Git comme source unique de vérité pour le code du système et de l’application.

La base du gitops repose sur le Contrôle de version. Cela veut dire que tout, y compris l’infrastructure, la configuration de l’application et le code de surveillance, est stocké dans un dépôt Git. Les modifications apportées au système ou à l’application sont effectuées par l’intermédiaire de Git commits.

Cette méthode permet tout d’abord de garantir une automatisation complète de votre déploiement ainsi qu’une facilité dans l’utilisation de l’historique et des retours en arrière, ce qui garantit la stabilité du système.

Le GitOps est donc par essence idéal pour entretenir des environnements DevOps multicluster.

Comment gérer des clusters multiples avec GitLab ?

Dans notre exemple, nous utiliserons GitLab. Si GitLab et GitHub offrent tous deux de nombreuses fonctionnalités spécifiques pour la gestion de plusieurs clusters Kubernetes, GitLab reste le meilleur choix. Vous pouvez gérer efficacement vos manifestes au sein d’un dépôt Git, en les organisant de manière structurée dans des environnements multicloud, ce qui est la manière de faire traditionnelle du GitOps.

Créer des groupes hiérarchiques GitLab

Gitlab vous permet de définir un groupe à l’intérieur d’un autre groupe et de lui faire hériter de toutes les variables d’environnement du groupe parent. Dans ce cas, vous pouvez définir le fichier KUBECONFIG dans le groupe parent et utiliser ces variables dans tous les projets qui en font partie.

Si, par exemple, vous disposez de trois clusters Kubernetes dans différents environnements tels que AWS, Google Cloud et Azure. Chaque groupe représente un cluster Kubernetes, et chaque projet contient un ensemble de fichiers manifestes liés à ce projet.

Placer KubeConfig dans les variables d’environnement au niveau du groupe

Les projets au sein d’un groupe GitLab peuvent accéder aux variables d’environnement partagées qui sont définies dans leur groupe parent ou à des niveaux supérieurs, et vice versa. Pour ce faire, vous devez configurer le fichier KubeConfig dans les paramètres du groupe :

Group Name -> CI/CD Settings -> Variables -> Add Variable Path :

Déployez votre application à l’aide de GitLab CI

Après avoir suivi les deux étapes précédentes, vous pouvez maintenant créer des fichiers manifestes dans chaque projet et les déployer en utilisant le pipeline GitLab CI. Voici un exemple

.
├── gitlab-ci.yml
└── manifests
    ├── configmap.yaml
    ├── deployment.yaml
    └── service.yaml

À l’intérieur du fichier gitlab-ci.yml, vous pouvez déployer vos manifestes de la manière suivante :

stages:
  - deploy

deploy:
  stage: deploy
  image: bitnami/kubectl
  script: |
    for f in manifests/*
    do
        kubectl apply -f $f 
    done

À noter que la variable d’environnement KUBECONFIG est définie dans le groupe parent, il n’est donc pas nécessaire de la définir pour chaque projet individuel.

Contrôle d’accès

Il est possible de déléguer la gestion de vos groupes et projets aux membres de votre équipe en suivant un ordre hiérarchique. En attribuant des accès au niveau du groupe, tous les projets de ce groupe hériteront du même modèle d’accès, éliminant ainsi le besoin de modifier les paramètres d’accès pour chaque projet individuellement.

Les rôles GitLab se décomposent de la manière suivante :

Guest : peut juste voir le projet
Reporter : peut créer des issues, voir le code et les commits
Developer : peut créer des branches et des demandes de fusion, pousser du code et gérer les problèmes
Maintainer : peut ajouter/supprimer des membres du projet et modifier les paramètres du projet et accéder aux branches protégées
Propriétaire : dispose de tous les accès en plus de pouvoir supprimer le projet ou de le transférer.

Une bonne assignation des rôles n’est pas seulement utile pour la fluidité de vos workflows, mais également pour la sécurité de vos clusters.

Encapsuler le code du pipeline CD

GitLab dispose d’une fonction de modélisation. Cela signifie que vous pouvez définir un modèle général pour votre pipeline et l’inclure partout où vous en avez besoin.

Cela vous permet d’encapsuler le code de votre pipeline de CD et d’effectuer des modifications à un seul endroit. Ainsi, lorsque vous modifiez le code du pipeline, vous n’avez pas besoin d’apporter des modifications à chaque projet individuellement.

Pour réaliser cette opération, vous devrez d’abord créer un projet afin de stocker le code de votre pipeline puis l’inclure dans les autres projets. En configurant un simple fichier install.ym, vous pourrez mettre à jour tous vos projets avec un nombre minimal de manipulations.