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 :

Image for post
Image for post
Image for post
Image for post

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

Image for post
Image for post

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

Image for post
Image for post
Image for post
Image for post

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

Image for post
Image for post

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

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

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

Image for post
Image for post

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 :

Image for post
Image for post
Image for post
Image for post

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 :

Image for post
Image for post

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

Image for post
Image for post

Et notamment les containers avec Node.js :

Image for post
Image for post

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 :

Image for post
Image for post
Image for post
Image for post

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) :

Image for post
Image for post

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

Image for post
Image for post

Et la même chose pour les containers Linux :

Image for post
Image for post

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

Image for post
Image for post
Image for post
Image for post

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

Image for post
Image for post
Image for post
Image for post

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 =>

Image for post
Image for post

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

Image for post
Image for post
Image for post
Image for post

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 :

Image for post
Image for post

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 :

Image for post
Image for post

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 :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

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

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Et le cluster Kubernetes est actif :

Image for post
Image for post
Image for post
Image for post

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 :

Image for post
Image for post

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

Image for post
Image for post

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

Image for post
Image for post

avec lancement de celui-çi :

Image for post
Image for post

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

Image for post
Image for post
Image for post
Image for post

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.

Image for post
Image for post
Image for post
Image for post

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

Image for post
Image for post
Image for post
Image for post

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

Image for post
Image for post

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 :

Image for post
Image for post
Image for post
Image for post

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

Image for post
Image for post
Image for post
Image for post

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 :

Image for post
Image for post

et je le lance :

Image for post
Image for post
Image for post
Image for post

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

Image for post
Image for post

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

Image for post
Image for post

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

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

et enfin pour l’image classique x86 :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

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

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

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

Image for post
Image for post

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 :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

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

Image for post
Image for post

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

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

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

Image for post
Image for post
Image for post
Image for post

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 :

Image for post
Image for post
Image for post
Image for post

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

Image for post
Image for post

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 :

Image for post
Image for post
Image for post
Image for post

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

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

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

Image for post
Image for post

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

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

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

Image for post
Image for post

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 :

Image for post
Image for post

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

Image for post
Image for post

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

Image for post
Image for post

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

Above the clouds, the sky is always blue ...

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store