FranceConnect et les clusters de containers hybrides / mixtes dans Cloudwatt, Outscale, Azure et Scaleway …

Il est possible aujourd’hui de mixer containers Linux et Windows dans différentes technologie d’orchestration de containers comme démontré ici :

En effet, je commence par lancer un cluster avec Docker Swarm Mode constitué d’un noeud Maître sous Linux Ubuntu 16.04 64 Bits dans Outscale et de deux noeuds esclaves Windows Server Core 2016 dans Azure avec une topologie de ce type :

J’ai donc lancé mon instance Ubuntu 16.04 dans Outscale :

et j’ai lancé mes deux instances Windows Server Core 2016 (qu’il faut piloter comme des serveurs Linux en lignes de commande) :

Je prépare ces noeuds en utilisant notamment Chocolatey (une sorte d’apt-get ou yum pour les environnements Windows) :

Chocolatey me permettant l’installation d’OpenSSH et de Docker :

Je commence par initier le Swarm Master suivi d’un Overlay entre ces trois noeuds :

Et surtout l’opération de “labellisation” de ces noeuds (des labels comme dans Kubernetes) pour les différencier entre noeuds Windows et Linux et indispensable pour l’exécution des containers Linux ou Windows :

Il faut signaler d’importantes avancées dans le domaine des containers Windows avec notamment l’arrivée des Nano Servers Insider avec une taille rédhibitoire :

avec ces tailles réduites (quasiment au même niveau que pour les containers Windows) :

Et notamment les containers avec Node.js :

Comme je ne dispose pas de Windows Server Insider dans Azure pour faire tourner ces Nano Servers Insider, je me contente pour FranceConnect de ce Dockerfile avec les Nano Servers classiques sur la base de cett excellent travail de Stephan Scherer :

L’image Docker Windows generée est très light en taille comparée aux images classiques (qui atteignent le giga pour les images Windows) :

J’en profite pour lancer des containers Windows sous forme de service uniquement pour les noeuds Windows du cluster Swarm :

Et la même chose pour les containers Linux :

J’ai donc un mix de containers Docker Windows et Linux en exécution :

Et le détail des containers Windows en exécution :

Pour le moment le load-balancer integré dans docker Swarm Mode ne fonctionne pas encore pour les noeuds Windows. Ceux-çi vont génerer des ports aléatoires pour ces containers Windows en exécution : une des limitations actuelles =>

Une stratégie serait par exemple d’utiliser un Reverse Proxy Node.js pour atteindre ces containers :

Mais Microsoft recommande tout simplement l’utilisation de Nginx pour répertorier ces ports et les exposer via la fonction de Load Balancing de ce serveur :

Avec ce procédé, je réussis à afficher un portail de démo FranceConnect Particulier sur la base de containers Linux et Windows et sur le port 80 :

Autre expérience avec un cluster Kubernetes mixte avec encore une fois un noeud Maître sous Linux Ubuntu 16.04 64 Bits et deux noeuds Windows Server 2016 :

Je commence donc à lancer mon cluster Kubernetes mixtes via Azure Container Service :

Et le cluster Kubernetes est actif :

J’en profite pour reconstruire l’image Docker du démonstrateur FranceConnect afin de lui faire subir une sérieuse cure d’amaigrissement via Alpine Linux et ce Dockerfile :

Et la taille est considérablement réduite après un nouveau build dans le Docker hub :

Je relance via ce fichier YAML un POD de containers Windows dans le cluster Kubernetes :

avec lancement de celui-çi :

Le load balancer dans Azure attaché à ce cluster Kubernetes me fournit une adresse IP externe ou est exposé le service FCP Démo :

Autre expérience mais cette fois-çi en mixant les architectures matérielles : je lance un cluster Kubernetes avec un noeud Maître dans Cloudwatt sous Ubuntu 17.04 64 Bits et deux noeuds Linux ARM 32 Bits et 64 Bits dans Scaleway.

En effet Scaleway offre la possibilité de lancer ce type de serveur notamment avec les Cavium aux processeurs ThunderX :

et dôtés par défaut du moteur Docker :

Via Kubeadm, j’installe ce nouveau cluster et les labels me permettent encore de différencier les noeuds en fonction de leurs architectures matérielles m’offrant ensuite la possibilité de lancer des containers par type de matériel :

Pour cette expérience je dispose d’images du démonstrateur FCP en ARM 32 et 64 Bits :

Je vais créer un premier déploiement en ARM 32 Bits avec ce fichier YAML qui utilise via les labels un paramêtre sélecteur de Noeud :

et je le lance :

J’utilise le Nodeport pour exposer mon service FCP en ARM 32 Bits :

et j’obtiens la page d’accès au démonstrateur FCP via le port indiqué :

La même chose pour l’image ARM 64 Bits :

et enfin pour l’image classique x86 :

Via le déploiement d’un Ingress Controller utilisant Traefik et Ngrok, je dispose du dashboard Kubernetes et de Grafana :

Avec ces ports hétéroclytes, j’utilise HAProxy sur le noeud maître pour n’obtenir qu’un seul port en TCP 80 :

Avec tous ces déploiements, je décide d’utiliser Azure Traffic Manager pour avoir un équivalent d’AWS Route 53 afin d’obtenir un seul endpoint unifiant tous ces containers x86, ARM 32 et 64 Bits sous Linux et Windows et des affinités géographiques :

et je peux le transformer en short-URL pour l’utilisation du protocole Eddystone dans les beacons :

ou de l’utilisation de cet endpoint pour génerer une application dite native pour les mobiles :

Je termine par le chatbot de test créé pour FranceConnect via API.ai et basé sur la FAQ de la page partenaires :

J’ai en effet generé une image Docker affichant une interface simple de dialogue entre un éventuel utilisateur et ce chatbot sur la base de questions simples :

Via encore Alpine Linux, l’image est ridiculeusement petite :

Je vais la tester en utilisant la preview d’Azure Container Instance où de manière surprenante on a la possibilité de lancer un container dans Azure sans avoir à créer de VM Hôtes Docker et avec une facturation à la seconde :

via l’Azure Cloud Shell , je lance un container de ce chatbot de test :

L’IP publique qui m’est retournée va me servir à atteindre l’interface de dialogue :

et je peux tester ce chatbot avec de petites questions simples (il utilise un moteur d’apprentissage utilisant du Machine Leaning) :

On visualise les logs genérés par le container en exécution :

et on a l’impression d’un container qui se substitue à une vraie VM dans la console (même s’il ne faut pas oublier le caractère éphémère d’un container dans la droite ligne de la métaphore des Pets and Cattle). Sachant que ce container utilise une sorte de Kubernetes managé dans Azure en backend :

Les fichiers du projet créé dans API.ai sont présents dans le dépôt du chatbot dans Github :

Une évolution des containers à suivre puisqu’ils ouvrent une inifinité de possibilités …

Originally published at telegra.ph on August 14, 2017.