Pipeline de CI/CD simplifié dans un cluster Kubernetes avec GitLab et Rancher …

Image for post
Image for post

Pour cette expérience, je pars encore une fois d’un pool d’instances basse priorité dans Azure (mais sans adresses IP publiques) via ce template (on peut arriver jusqu’à 80% de réduction par rapport au prix normal d’une instance dans une région) :

Image for post
Image for post

et ces paramètres :

Image for post
Image for post

dans ce resource group :

Image for post
Image for post
Image for post
Image for post

Et j’initie un serveur Rancher dans l’une de ces instances (qui va me servir à provisionner un cluster Kubernetes dans les autres instances) :

$ sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher:master
Image for post
Image for post
Image for post
Image for post

J’obtiens un cluster Kubernetes en mode HA :

Image for post
Image for post
Image for post
Image for post

visualisable via la console du serveur Rancher :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Je récupère le fichier kubeconfig (que je place dans ~.kube/config) depuis la console pour exécuter mes commandes dans le cluster :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Un petit test pour vérifier le bon fonctionnement de MetalLB via le déploiement du démonstrateur FC :

Image for post
Image for post
Image for post
Image for post

Cela fonctionne (j’ai bien une adresse IP du pool configuré en DHCP dans ZeroTier fournie de manière automatique via MetalLB) avec les informations accessibles sur la console du serveur Rancher :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

J’obtiens donc ici ce type d’architecture :

Image for post
Image for post

J’en profite donc pour utiliser le service de configuration de pipeline CI/CD intégré au sein de la console du serveur Rancher :

Image for post
Image for post

Pour cela j’ai provisionné dans l’une des instances basse priorité un serveur GitLab (dans un container docker) avec le dépôt du démonstrateur FC Agent (également connecté à ZeroTier) :

$ sudo docker run --detach \
--hostname <HOSTNAME> \
--publish 443:443 --publish 80:80 --publish 2222:22 \
--name gitlab \
--restart always \
--volume /srv/gitlab/config:/etc/gitlab \
--volume /srv/gitlab/logs:/var/log/gitlab \
--volume /srv/gitlab/data:/var/opt/gitlab \
gitlab/gitlab-ee:latest
Image for post
Image for post

Je peux configurer graphiquement mon pipeline dans la console (après avoir effectuer la liaison avec le serveur GitLab) :

Image for post
Image for post

qui me génère un fichier .rancher-pipeline.yml au sein de mon dépôt dans GitLab (configuration assez simple avec un déploiement depuis un fichier de manifest YAML) :

Image for post
Image for post
Image for post
Image for post

Exécution du pipeline simple réussi :

Image for post
Image for post
Image for post
Image for post

Le démonstrateur FC Agent est déployé :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

On peut voir que la configuration de ce pipeline de CI/CD a engendré le déploiement dans un namespace dédié d’un ensemble de composants :

Image for post
Image for post
Image for post
Image for post

Il est possible de modifier le pipeline pour y ajouter des étapes (ici avant la phase Deploy je rajoute une phase Build qui va utiliser le fichier Dockerfile présent au sein du dépôt Git) :

Image for post
Image for post

et une mise à jour du fichier .rancher-pipeline.yml :

Image for post
Image for post

L’exécution de ce pipeline mis à jour se termine alors correctement :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

A suivre !

Image for post
Image for post

Above the clouds, the sky is always blue ...

Get the Medium app