Weave a mis au point Ignite sur la base de Firecracker qui a la possibilité comme Docker de gérer les containers runC. Ignite construit des images de machines virtuelles à partir d’images OCI et peut gérer efficacement plusieurs machines virtuelles.
L’idée est qu’Ignite fait ressembler les VM Firecracker à des containers Docker. Les images utilisées sont des images Docker, mais au lieu de les exécuter dans un container, le système de fichiers racine de l’image s’exécute comme une VM réelle avec un noyau dédié et /sbin/init comme PID 1.
La mise en réseau s’effectue automatiquement, la VM obtient la même adresse IP que n’importe quel container docker sur l’hôte. La construction et le démarrage des VMs ne prennent au plus que quelques secondes. Avec Ignite, on peut commencer à utiliser Firecracker en un rien de temps …
Pour cette expérience, je profite de l’annonce faite par Scaleway de mettre à disposition ses instances General Purpose à base d’AMD EPYC dans la région d’Amsterdam :
Ces instances permettent l’usage de la virtualisation imbriquée (même s’il n’y a rien d’officiel sur ce point) :
Cette instance lancée, je récupère le binaire Ignite depuis son dépôt sur Github :
Au préalable, il faut procéder à l’installation du moteur Docker :
Rapide avec le lancement d’une microVM Ubuntu 18.04 :
J’y ai lancé un serveur Nginx qui répond en utilisant ici un tunnel Cloudflare Argo :
Je peux supprimer ce déploiement via quelques commandes :
Je passe à un test plus compliqué avec le déploiement d’un cluster Kubernetes en mode HA via Kubeadm :
Je lance un script de préparation avant le lancement des VMs :
Lancement du premier noeud maître du cluster via une image contenant Kubeadm :
et initialisation de ce noeud avec Kubeadm :
Récupération du client kubectl et le premier noeud maître du cluster est opérationnel :
Lancement des deux autres noeuds maîtres :
et raccordement de ces derniers au premier noeud maître du cluster pour initier ce mode HA :
Le cluster est prêt à recevoir ses noeuds Worker :
Pour cela création de trois noeuds Worker :
et raccordement de ces derniers au cluster via Kubeadm :
Le cluster Kubernetes sur la base de ces microVMs Ignite est fonctionnel :
Via Cockpit je peux visualiser ces MicroVMs comme de simples containers :
Je peux importer ce cluster dans un serveur Rancher préalablement déployé pour la circonstance :
Le cluster est alors importé et visualisable dans le dashboard du serveur Rancher :
avec Grafana pour le monitoring :
Dans une logique ChatOps, installation de BotKube :
Un bot lié à Slack va permettre l’exécution de commandes ou la réception d’infos de monitoring selon ce principe :
Activation de l’application dans Slack :
puis déploiement dans le cluster Kubernetes installé précédemment :
Le bot répond et peut interagir ici dans un canal de Slack :
Déploiement encore une fois dans le cluster du démonstrateur FC :
vu par le Bot :
Et lancement d’un container Docker avec HAProxy via ce fichier de configuration (le serveur pointe sur les noeuds Ignite et le NodePort du service associé au démonstrateur FC au sein du cluster) :
Cloudflare Argo et son tunnel permet d’exposer publiquement le démonstrateur :
Il est possible également d’utiliser le service de Load Balancer offert par Scaleway :
On a vu les VMs qui se prennent pour des containers avec Weave Ignite et bien passons aux Containers qui se prennent pour des VMs avec l’utilisation cette fois-çi de Weave Footloose :
Weave Footloose crée des containers qui ressemblent à des machines virtuelles. Ces containers s’exécutent en tant que PID 1 et un démon ssh peut être utilisé pour se connecter à ces derniers. Ils se comportent quasiment comme une VM, il est même possible d’y faire tourner un moteur Docker. Pour cela utilisation d’une autre instance AMD EPYC de Scaleway avec ubuntu 18.04 LTS dans la région d’Amsterdam :
Récupération du binaire Footloose depuis son dépôt sur Github :
Tout commence par la création d’un fichier de configuration YAML nommé footloose.yaml . Footloose lit une description du cluster de Machines à créer à partir de ce fichier. Un autre nom peut lui être spécifié en ligne de commande avec l’option — config ou via la variable d’environnement FOOTLOOSE_CONFIG . Lancement ici d’une instance CentOS 7 avec Footloose autorisant l’exécution d’un moteur Docker en mode privilégié :
Je lance cette instance Footloose (qui est en réalité un container Docker) mais qui se gère donc ici comme une machine virtuelle.
Même test que précemment avec l’installation d’un serveur Nginx via son image Docker (j’ai donc un container qui tourne dans un container) :
Je peux exposer ce serveur Nginx encore une fois via Cloudflare Argo :
Test cette fois avec l’initialisation d’un cluster Kubernetes via Rancher k3s dans trois instances Footloose :
via ce fichier YAML :
dans la première instance, lancement du noeud maîre du cluster avec l’installation au préalable d’un moteur Docker :
puis lancement de k3s :
Je raccorde les deux autres instances comme noeuds Worker du cluster encore une fois via k3s et l’installation au préalable d’un moteur Docker :
Le cluster est alors opérationnel :
et donc importable dans le serveur Rancher :
Je relance le déploiement du démonstrateur FC dans ce cluster :
Il est accessible sur le port TCP 11111 sur chaque noeud du cluster :
lancement comme précédemment d’un container Docker HAProxy en load balancer pointant sur ce port spécifique sur les trois noeuds :
Il répond sur le port TCP 80 de l’instance dans Scaleway :
Je peux l’ajouter en nouveau back-end dans le load balancer précédent dans Scaleway pour arriver à ce résultat :
Je complète donc la configuration du load balancer créé dans Scaleway :
Je n’ai plus qu’un seul endpoint qui pointe sur les deux démonstrateurs (l’un dans un cluster k8s avec Weave Ignite, l’autre avec le cluster k8s s’appuyant sur Weave Footloose) …
A suivre !
