♻️ Gestion des environnements
Dans cette dernière étape, nous allons voir les liens possibles entre GitLab & Kubernetes.
Pour celle-ci, il vous faut installer (si ce n'est déjà fait):
Si vous n'avez pas de cluster en local, on vous en a préparé quelques-uns. Dites nous et on vous donnera le kubeconfig qui va bien.
Vérifier la connexion avec le cluster depuis un terminal:
Success
La liste de tous les pods du cluster s'affiche correctement
👮♀️ Installation du Kubernetes-agent
Afin d'intéragir simple avec un cluster, GitLab fournit un kubernetes-agent.
Dans un nouveau Blank project
intitulé demo-kub
,
-
En suivant la doc, installer l'agent sur votre cluster depuis le menu Infrastructure > Kubernetes et le bouton Connect a cluster.
Success
L'agent apparaît dans
Operate > Kubernetes clusters
à l'état Connecté -
Vérifier si le gitlab-agent est bien installé dans votre cluster
Success
2️⃣ pods apparaissent avec un nom
-gitlab-agent-xxx-xxx
☸️ Intéraction avec le cluster
Le kub-agent permet de facilement intéragir avec un cluster Kubernetes sans à avoir à fournir de KUBECONFIG en variable ou via un fichier dans la CI. Cela limite donc les risques de fuite de configuration pour accéder à votre cluster.
Depuis l'éditeur de pipelines (Buid > Pipeline editor
):
- Dans un fichier
gitlab-ci.yml
, ajouter le snippet pour vérifier que l'on arrive bien à intéragir avec le cluster depuis la CI- Il y a 3 variables à renseigner dans ce snippet :
GITLAB_GROUP
: le chemin vers votre projet (en grosgroup/sous-groupe/
)GITLAB_PROJECT
: le nom de votre projet dans GitLabGITLAB_AGENT
: le nom de l'agent que vous venez de créer
- Il y a 3 variables à renseigner dans ce snippet :
- Commiter le fichier sur la branche
main
Success
- Le pipeline s'exécute correctement ✅
- Dans les logs du job, la commande
kubectl
affiche des informations ✅
Vous pouvez désormais facilement intéragir avec votre cluster pour installer/mettre à jour des applications via kubectl
ou helm
par exemple.
🚀 Allons plus loin
Déployons maintenant une application de démo via notre GitLab-CI.
- Créer un fichier
demo.yml
à la racine du projet et utiliser le snippet pour déployer une application de demo - Modifier le
.gitlab-ci.yml
pour déployer l'application- On crée un
namespace
dédié pour l'application en ce basant sur le nom du projet et la branche en cours - On lie cela à un environment GitLab pour avoir la visibilité du déploiement des différentes branches de notre projet
- 🛟 aide
- On crée un
- Commiter
Success
- Le pipeline s'exécute correctement ✅
kubectl get ns
affiche un nouveau namespace<nom_projet>-main
✅
Dans le menu Operate > Environements
, on voit un nouvel environment crée avec les informations sur depuis quelle branche, quand et avec quel commit.
Ceci est pratique pour avoir une vision globale des environments liés au projet.
Un bouton "Stop" est disponible, et permet de supprimer un enivronment. On peut lier cette action dans notre .gitlab-ci.yml
pour déclencher des actions particulères.
- Via le pipeline editor:
- Retourner dans le menu
Operate > Environments
et déclencher le stop de l'environment.
Success
- Le pipeline s'exécute correctement ✅
- le job de nettoyage est déclenché ✅
kubectl get ns
n'affiche plus le namespace<nom_projet>-main
✅
Maintenant, on peut avoir besoin de plusieurs environnements en parallèle.
- Créer une branche
demo
à partir demain
- Forcer un pipeline manuellement sur la branche
demo
et sur la branchemain
Success
- 2 environments sont listés dans le menu
Operate > Environments
✅ kubectl get ns
affiche 2 nouveaux namespace<nom_projet>-main
&<nom_projet>-demo
✅
Pour aller encore plus loin, il y a : - la feature de Feature Flags. - pimper son cluster k8s pour avoir des environements encore plus simples à utiliser