Tout commence par le besoin du client
Comme toute plateforme informatique, celle de notre client dans le secteur public est en perpétuelle évolution pour s’adapter et répondre aux différents besoins, surtout au niveau de l’optimisation des ressources d’infrastructures consommées.
Cherchant une expertise lui permettant de s’orienter vers la conteneurisation, notre client s’est dirigé vers Metanext.
A l’issue de l’étude d’opportunités sur les conteneurs, le client souhaite être accompagné dans la réalisation d’un PoC (Proof of Concept) sur la conteneurisation dont les objectifs sont les suivants :
- Expérimenter la conteneurisation ;
- Tester et choisir les outils (images, registry, package manager, distribution Kubernetes…) ;
- Etudier les opportunités ;
- Identifier la complexité de conteneuriser une application ;
- Éprouver des solutions de chaînes CI/CD ;
- Monter en compétences par étape (création des images, Docker standalone, orchestration).
Une revue détaillée des solutions du marché
Aujourd’hui, plusieurs solutions permettant de répondre aux besoins exprimés par le client sont disponibles sur le marché.
Parmi les solutions figurent Rancher, PKS et OpenShift qui sont les 3 solutions les plus souvent utilisées.
Il est important de souligner que notre client n’est pas intéressé par le Cloud Public. Et donc il n’envisage pas de tester ou de voir les fonctions proposées par les fournisseurs de Cloud public.
Rancher
Rancher, projet open-source créé par la société Rancher Labs, est un orchestrateur des clusters Kubernetes.
Il permet de déployer un ou plusieurs clusters Kubernetes sur de multiples plateformes (vSphere, Bare-metal, Openstack, AWS, GCP, Azure, …) et également de centraliser la gestion des politiques de sécurité du réseau et des pods. (1) 
PKS
PKS est une solution issue du partenariat entre VMware, Pivotal et Google. Il ne modifie pas Kubernetes et n’apporte pas de surcouche ou d’interface intermédiaire. Il permet de créer des clusters Kubernetes à la demande.
Plusieurs clusters Kubernetes peuvent résider sur une même plate-forme mais aussi pour plusieurs usages, Dev, Test, Intégration Pre-prod…, en restant indépendants et isolés. (2) 
OpenShift
OpenShift est un PaaS (« plate-forme en tant que service ») qui s’appuie sur Kubernetes et permet de construire, déployer et gérer des applications dans des conteneurs.
Avec cette plateforme open source, les développeurs peuvent créer, tester et exécuter leurs applications, puis les déployer dans leurs plateformes.
OpenShift prend en charge les langages de programmation Node.js, Ruby, Python, PHP, Perl et Java. La plateforme est extensible, ce qui permet aux développeurs d’utiliser d’autres langages. (3)
Finalement seuls Rancher et OpenShift ont été retenus par le client.
Afin d’avoir les deux solutions rapidement fonctionnelles et de pouvoir tester les différentes fonctionnalités proposées, nous avons choisi pour le PoC les architectures et les méthodes de déploiement les plus simples.
Un PoC avec Rancher …
Dans le cadre du PoC, nous avons utilisé la version conteneurisée sur une VM.
Pour un environnement de production il est préférable de déployer sur un Cluster composé de trois nœuds Kubernetes RKE (Rancher Kubernetes Engine). (4)
Après avoir déployé un cluster Rancher, nous l’avons utilisé pour déployer un Cluster Kubernetes, composé d’un Master-Node et de deux Worker-Nodes.
Dans ce déploiement, nous avons utilisé la méthode custom ‘Personnalisée’ sur des VMs déjà préparées avec le système d’exploitation et les packages nécessaires.
Ensuite, pour que notre client puisse voir les points forts de Rancher, nous avons déployé le cluster Kubernetes en passant par l’API vSphere.
Rancher prend alors en charge le provisioning des VMs, l’installation de Kubernetes et la création des PV (Persistent Volume) sur VMware.
Déploiement
Rancher.lab offre une méthode de déploiement très simple, il suffit juste de démarrer le conteneur en utilisant la commande suivante :
| # docker run -d –name rancher –restart unless-stopped -p 8080:8080 -p 443:443 rancher/rancher:stable # docker logs -f rancher // surveiller le bon démarrage de container. |
Afin de mettre en place le cluster Kubernetes, nous avons utilisé l’interface graphique fournie par Rancher en remplissant quelques informations comme :
- Le nom du cluster :
- La version de Kubernetes et le fournisseur réseau :
- Le rôle de chaque Host-node, puis exécution de la commande générée pour chacun :
- À faire !
Dans le but de conserver la configuration de Rancher, nous vous conseillons de la sauvegarder dans un volume à part, car elle va être utilisée lors du premier démarrage du conteneur :
#docker volume create --name rancher_data #docker run -d --name rancher --restart unless-stopped -p 8080:8080 -p 443:443 -v rancher_data:/var/lib/rancher rancher/rancher:stable
… et un PoC avec OpenShift
L’architecture choisie est composée d’un Master-Node et deux Worker-nodes.
La machine Bootstrap est la machine « déployeur », qui est utilisée uniquement lors du déploiement du Cluster et qui sera supprimée dès que le Cluster est prêt.
Déploiement
Le déploiement d’OpenShift est moins facile que celui de Rancher, il se fait en plusieurs étapes. C’est pour cela nous n’allons pas tout détailler.
La première partie consiste à préparer l’environnement, c’est-à-dire :
- Configurer les entrés DNS (Type A, SRV, PTR et wild-card);
- Configurer le Load-Balancer. Ce dernier sert au début à accéder à la machine Bootstrap, une fois la plateforme lancée, nous allons l’utiliser pour le Ingress-Controller ;
- Configurer le serveur Web pour permettre au Bootstrap de récupérer le fichier de configuration au premier démarrage ;
- Créer le template OVA sur la plateforme VMware ;
- Préparer les fichiers “. Yaml”, manifests et Ignition ;
- Convertir les fichiers “Ignition” générés en base64 ;
- Réserver les adresses IP sur DHCP ;
- Cloner les VMs (Bootstrap, Master, Worker 1 et 2) pour le cluster OpenShift avec l’insertion des configurations en base64. Ces configurations sont utilisées pendant le premier démarrage ;
- Lancer le processus de bootstrap ;
- Valider les certificats ;
- Finaliser l’installation des addons (DNS, prometheus, Grafana, Dashboard…).
À éviter !
Il est préférable d’avoir le serveur Web et le Load-Balancer dans deux machines séparées.
Dans le cas où ils sont dans la même machine, il faut penser à modifier le port d’écoute du serveur web en 8080 au lieu de celui par défaut (80). Le port 80 est utilisé par le ingress et donc cela évitera des conflits de ports.
Il est important de souligner que le déploiement d’OpenShift doit être terminé autant que possible le même jour. En effet, RedHat fournit des certificats de courte durée et ils risquent d’expirer avant que votre déploiement soit terminé.
Il faudra alors recommencer le déploiement ! (5)
Notre retour sur la complexité du déploiement et les fonctionnalités proposées par les deux solutions évaluées
Nous arrivons à la fin de cet article et après notre retour d’expérience sur les PoCs avec Rancher et OpenShift.
Voici une synthèse sur les différences constatées pendant le déploiement :
| Déploiement | Rancher | OpenShift |
| Rôle | Orchestration des clusters | Orchestration des conteneurs + PaaS |
| Type | OpenSource | RedHat |
| Complexité installation | Faible | Haute |
| Complexité Opération | Faible | Modérée |
| Dépendance à la solution après déploiement (*) | Non | Oui |
| Management Multi-Orchestrateurs, Multi-Clouds | Oui | Non |
| CI-CD | Possible d’utiliser Jenkins mais il n’est pas intégré par défaut | Jenkins intégré par défaut |
| CNI (Conteneur Network Interface) | Canal, Weave, Flannel et Calico | OpenShift SDN |
| Registry privé | Non intégré | Intégré |
(*) : Si le client n’est pas satisfait de Rancher, il peut le désinstaller en gardant ses Clusters Kubernetes. Par contre, OpenShift ne peut pas être supprimé car le Cluster Kubernetes y reste attaché.
En conclusion
Cette mission a été très intéressante pour moi car elle m’a permis de découvrir deux solutions de pointe très privilégiées dans le marché IT.
J’ai trouvé ces solutions très puissantes. Elles englobent plusieurs technologies et proposent des fonctionnalités très diversifiées ce qui rend le choix entre elles difficile.
Je considère ce projet comme un défi pour moi car l’environnement de production était très restreint et il fallait adapter les solutions.
C’était la première fois que notre client utilisait la conteneurisation et donc nous l’avons accompagné dans la mise en place des solutions et transféré notre savoir-faire. Et c’est ce qui me plaît chez Metanext !