Test expérimental d'un pipeline CI/CD avec Canonical Distribution of Kubernetes ...

Comme il est possible de lancer un cluster Kubernetes entier dans un seul container, il est également possible de le faire pour un cluster Openstack (me s'il ne faut jamais faire ça en production). Je profite de la sortie de deux nouvelles saveurs chez Scaleway (filiale d'Iliad/Free) qui monte en puissance et qui copie un peu en France le modèle de Digital Ocean aux US => https://blog.online.net/2017/02/07/scaleway-new-cloud-servers-for-intensive-workloads/

Je prends la saveur X64-60GB qui est le deuxième plus gros VPS à base d'Intel Xeon à 18 centimes de l'heure :

Je lance le serveur qui est ici en Ubuntu Server 16.10 64 Bits =>

J'ai bien une série de disques accolés au serveur mais qu'il faut monter =>

et j'initie l'hyperviseur LXD avec son bridge local (et pas d'IPV6) :

Il n'y a comme la fois précédente plus qu'à lancer le gros container LXC qui fera office de réceptacle du cluster Openstack lui même constitué de containers LXC piloté par l'hyperviseur LXD du ... container :

Lancement d'un hyperviseur LXD à l'intérieur de ce gros container :

et à y installer conjure-up :

Il n'y a alors plus qu'à lancer conjure-up à l'intérieur de ce container pour installer un cluster Openstack sur une base Nova-LXD (et pas KVM pour des raisons évidentes de performance) :

Il y a alors bootstrap d'un Juju Controller qui lancera à son tour les containers LXC constitutifs du cluster Openstack :

Une fois terminée on peut apercevoir une vue d'ensemble de ce qui a été déployé pour ce cluster Openstack :

et en particulier des containers LXC qui tournent à l'intérieur de ce gros container ... LXC :

avec la topologie affiché du dashboard Juju GUI :

et via encore une fois une rêgle iptables, je peux par un port forwarding accéder au dashboard du cluster Openstack :

et sa mire de login :

Résultat : cette expérience de deux heures m'aura coûté le prix d'un café à la machine du rez de chaussée (trop de café c'est mauvais pour la santé) ...

Il est possible de reproduire cette expérience avec le Windows Subsystem for Linux (autrement dit l'Ubuntu integré dans la version développeur de Windows 10) sur votre machine ... Windows si elle possède au moins 16 Go de RAM =>

et même de faire du multiarchitecture en multissh avec Byobu :

J'ai voulu aller plus loin sur l'usage de Kubernetes et voir comme l'affirmait Canonical, l'exécution d'un cluster Kubernetes entier dans un seul container. C'est possible via l'utilisation de deux technologies conjointes à savoir l'hyperviseur LXD et les containers LXC (en complément de Docker et Kubernetes dans ce cas là) : je pars d'une grosse VM Ubuntu 16.10 64 Bits dans Azure pour arriver à ce schéma =>

Je devrais donc obtenir une VM qui implémente en son sein un hypervieur LXD qui fait tourner un gros container LXC qui lui même exécute un hyperviseur LXD qui va par l'intermédiaure de Juju lancer une série de containers LXC qui constitueront un cluster d'hôtes dans Kubernetes (avec des Workers qui sont dôtés du moteur Docker 1.12 et capables de lancer des images depuis le Docker Hub). C'est donc un mélange de Nested Virtualization / Containerization et c'est juste pour démonter la souplesse de ces différentes technologies ...

Je commence donc par lancer dans la VM Ubuntu un gros container LXC piloté via un bridge réseau par l'hypervieur LXD et j'y installe Juju =>

Dans ce container en exécution, j'y lance un nouvel hyperviseur LXD =>

Une fois que le container est prêt, je peux alors exécuter conjure-up qui est le nouveau paravent open source de Juju (lui même totalement open source) pour y installer Charms et Bundles (les packages et distributions internes proposés par Canonical sur sa bibliothèque :

https://jujucharms.com/ ). Conjure-up se faisant une spécialité du déploiement de solutions complexes de manière assez simple => https://github.com/conjure-up/conjure-up

Lancement de Conjure-Up et sélection de la distribution Canonical Kubernetes :

et selection de mon container LXC local pour effectuer l'installation complête du Cluster :

Juju lance alors le déploiement des charms en arrière fond :

Une fois terminée, avec la commande Juju je visualise l'état du cluster déployé avec au total 8 machines LXC déployées :

et biensûr Juju GUI est là pour assurer la visualisation graphique du cluster déployé :

avec la liste des containers LXC :

avec la récupération du client Kubectl je vois également les endpoints du cluster :

Les infos réseau du container LXC initiales :

je teste alors le lancement d'un POD Kuebrnetes avec l'image Docker de test Microbot qui se lance :

Les PODs sont alors en mode Running et via l'Ingress Controller Nginx fourni dans le cluster il est possible d'atteindre l'endpoint du service Microbot lancé sur le port 80 (et qui utilise un service de Wildcard DNS

encore une fois) :

et effectivement, un simple curl permet l'affichage de la page web en emission sur le port 80 à 'intérieur de containers Docker eux même en exécution au sein de containers LXC dans notre gros container LXC ...

Malgré la présence de la commande "Juju expose", il faut quand même beaucoup de contorsion réseau via la manipulation des regles iptables pour rendre la page web accessible depuis l'extérieur

(c'est un défaut qui devrait être corrigé m'avait dit le solutions architect de Canonical notament pour les services émis par les instances d'un cluster Ubuntu Openstack Cloud sur une base LXD) :

Le tout consomme moins de 3 Go de RAM dans la VM Ubuntu initiale dans Azure (ou bien où vous voulez ailleurs, au niveau des containers cela a peu d'importance : seule les performances des VMs hôtes comptent) ...

Cette petit infographie finale résume l'ensemble de la chaine LXD/LXC et ses liens avec les containers Docker :

Avec la sortie récente de la version 1.5.2 de la distribution Canonical Kubernetes, je teste une chaine de déploiement sur un cluster Kubernetes avec Shippable, un autre outil de CI/CD équivalent à Codefresh, CircleCI ou TravisCI ...

Déploiement ici via les charms du bundle officiel de la distribution avec JuJu et en premier lieu bootstrap d'un controleur MaaS (Metal as a Service) :

et déploiement du bundle :

Une fois provisionnée, le cluster est disponible :

On peut visualiser l'ensemble des ressources consommées par le cluster sur le portail Azure (puisque c'est là qu'a été provisionné le controleur MaaS) :

et du controleur MaaS :

avec le détail de la topologie du cluster via JuJu GUI :

et on voit la présence d'un Master Kubernetes accompagné d'une autorité de certification Easyrsa, de 3 endpoints Etcd, d'un service de Load Balancer pour l'API du cluster Kubernetes et d'un service de réseau overlay (SDN) via Flannel :

Je visualise également les infos du cluster via le client kubectl :

Le monitoring du cluster étant assuré par Grafana et le dashboard fourni des métriques essentielles :

Shippable est une plateforme en ligne qui permet notamment un déploiement automatique sur un cluster Kubernetes :

et j'effectue l'intégration du cluster dans la plateforme via kubeconfig :

et via un fork sur mon dépôt github d'un pipeline d'une applicatioàn Node.js, je peux tester le build automatique d'une image docker ensuite propulsée sur mon compte Docker Hub via le fichier de conf shippable.yml :

et je lance un build et création d'image Docker réussi :

L'image est correctement déployée sur le Docker hub :

et ensuite le fichier shippable-resources.yml permet le déploiement d'un POD sur le cluster Kubernetes :

ce fichier autodétecté permet la visualisation du Pipeline sur le dashboard de la plateforme Shippable :

et l'execution du manifest du pipeline provoque le déploiement réussi du POD :

Je vérifie la présence du POD et le déploiement d'un service via l'Ingress Nginx du cluster Kubernetes permet son exposition sur le port 80 :

Pour des applis Java, JaCoCo peut être utilisé pour du code coverage :