Comme le relate Rancher dans son blog, Rancher 2.5 simplifie le déploiement continu avec Rancher Continuous Delivery. Une nouvelle fonctionnalité qui adopte une approche GitOps pour rationaliser le processus dans toute infrastructure (environnements privés, publics, hybrides ou multi-cloud).
Continuous Delivery With GitOps
Un référentiel Git est ici la seule source d’autorité pour la configuration. Toutes les définitions sont conservées à la source, qu’il s’agisse de définitions de configuration de cluster Kubernetes, de définitions de déploiement d’application ou bientôt de définitions de politique de sécurité. Lorsque les développeurs apportent des modifications à une application, Git peut la transmettre à Kubernetes pour le déploiement. Si les changements s’écartent de l’état souhaité, Git peut les remettre en ligne.
Le projet Fleet, lancé plus tôt cette année, est le moteur de la livraison continue dans cette nouvelle version de Rancher. Fleet est un contrôleur de cluster Kubernetes conçu pour relever les défis de l’exécution de milliers à des millions de clusters dans le monde …
Rancher 2.5 Embraces GitOps at Scale with Rancher Continuous Delivery
Une démonstration simple avec le lancement dans Hetzner Cloud d’une première instance Ubuntu 20.04 LTS avec Rancher Server 2.5 :
via son image Docker …
Le serveur Rancher est accessible avec un petit cluster k3s installé par défaut :
Lancement d’une deuxième instance dans Hetzner Cloud destinée à exécuter un cluster K3s standalone :
Ce cluster K3s actif, je peux l’importer dans le serveur Rancher :
via ces manifests YAML …
Le cluster est importé et prêt à être utilisé dans le module Rancher Continuous Delivery comme on le verra plus loin …
Création d’une troisième instance Ubuntu 20.04 LTS destinée à exécuter un serveur Gitea dans Hetzner Cloud :
Récupération du binaire Gitea et lancement du serveur destiné à héberger un dépôt Git :
Le serveur expose localement par défaut sur port TCP 3000. Je vais l’exposer publiquement via Caddy 2, le fameux serveur web Open Source, avec le mode HTTPS automatique et écrit en Go :
Caddy 2 - The Ultimate Server with Automatic HTTPS
Exposition publique de Gitea avec ce domaine Wildcard et Caddy …
J’importe mon dépôt Git existant du sempiternel démonstrateur FC :
Je retourne sur le dashboard du serveur Rancher 2.5 et le cluster K3s précédemennt crée est déclaré dans le module Rancher Continuous Delivery :
Je crée un groupe de cluster qui contiendra ce cluster K3s ou d’autres clusters Kubernetes à importer (c’est donc Fleet qui pilotera un éventuel déploiement dans une flotte de clusters Kubernetes) :
Je déclare mon dépôt Git via Gitea dans Rancher Continuous Delivery :
Je déclare le chemin vers le ou les manifests de déploiement au sein de ce dépôt Git :
Cela génère ce fichier de configuration YAML :
Dès lors s’opère un déploiement automatique du démonstrateur FC vers le cluster K3s :
Avec ce manifest YAML présent dans le dépôt Git :
Je peux le vérifier localement au sein du cluster K3s :
Le démonstrateur FC est accessible publiquement via Traefik comme Ingress Controller dans le cluster K3s :
Rapide test de l’action de Rancher Continuous Delivery avec la modification du manifest de déploiement du démonstrateur FC directement dans Gitea :
Le nombre de Pod passe de 4 à 2 ici. Automatiquement ce changement est appliqué au sein du cluster K3s …
Je peux aussi le vérifier via l’installation de Weave Scope :
Avec assez peu de ressource consommée dans ce cluster Kubernetes minimal …
L’approche GitOps sous-jacente dans cet exemple s’appuie sur des processus de flux de travail matures et bien connus, compris par le développeur et le personnel d’exploitation. Rancher Continuous Delivery tire donc parti des ensembles d’outils de développement Git existants pour gérer les applications cloud natives, garantissant ainsi que les applications s’exécutent comme prévu (déjà réalisable avec le projet Fluxctl) …
Rancher Continuous Delivery s’appuie ici sur Fleet, conçu pour gérer jusqu’à un million de clusters. Il est également suffisamment léger pour fonctionner parfaitement pour un seul cluster, mais il brille vraiment lorsque vous arriverez à grande échelle, c’est à dire un grand nombre de clusters, un grand nombre de déploiements, soit un grand nombre d’équipes dans une seule organisation …
Fleet Management of Kubernetes Clusters at Scale — Rancher’s Fleet
Pour cela, Fleet peut gérer les déploiements à partir de Charts avec Helm, de manifest YAML ou via Kustomize voire une combinaison des trois …
Fleet est un projet distinct de Rancher et peut être installé sur n’importe quel cluster Kubernetes avec Helm.
À suivre !
Top comments (0)