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) :
et ces paramètres :
dans ce resource group :
Je connecte comme précédemment toutes ces instances au réseau que j’ai provisionné dans ZeroTier :
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
J’obtiens un cluster Kubernetes en mode HA :
visualisable via la console du serveur Rancher :
Je récupère le fichier kubeconfig (que je place dans ~.kube/config) depuis la console pour exécuter mes commandes dans le cluster :
Avec ZeroTier, j’installe MetalLB pour bénéficier d’adresses IP automatiquement lors du déploiement de services en load balancing au sein du cluster Kubernetes :
Un petit test pour vérifier le bon fonctionnement de MetalLB via le déploiement du démonstrateur FC :
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 :
J’obtiens donc ici ce type d’architecture :
J’en profite donc pour utiliser le service de configuration de pipeline CI/CD intégré au sein de la console du serveur Rancher :
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
Je peux configurer graphiquement mon pipeline dans la console (après avoir effectuer la liaison avec le serveur GitLab) :
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) :
Exécution du pipeline simple réussi :
Le démonstrateur FC Agent est déployé :
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 :
Le tout est visualisable via l’utilisation de Rancher CLI :
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) :
et une mise à jour du fichier .rancher-pipeline.yml :
L’exécution de ce pipeline mis à jour se termine alors correctement :
On peut aussi bénéficier de la fonction Auto-DevOps dans le serveur GitLab moyennant certaines conditions comme l’explique cet article :
A suivre !
