Est-il encore utile de présenter Rancher ? Ah, c’est un article sur la présentation de Rancher ? Bon bah oui alors…
Rancher est un orchestrateur léger qui réparti des conteneurs sur un cluster de serveurs. Rancher met à disposition des moyens qui permettent de ranger les conteneurs par service (brique applicative) et par application (ensemble de services). Ceci permet de ranger les conteneurs d’un même projet dans un même ensemble. Rancher permet de scaler le nombre de conteneurs d’un même service et de leur appliquer des règles d’anti-affinité.
Les règles d’affinité et d’anti-affinité permettent de réguler le comportement et la répartition des conteneurs sur les différents hosts, exemple le StackA/ServiceA ne doit jamais se trouver sur le même Host que le StackA/ServiceB, limitant ainsi les impacts système d’un service sur l’autre.
Le mieux dans tout ça, c’est que Rancher est lui-même un conteneur… inception !
Cette description rapide nous permet de rebondir sur le fait que Rancher peut héberger des conteneurs Docker natifs, mais pas que… il permet d’héberger un cluster Mesos, Swarm ou Kubernetes.
Cependant, pour ce qui est de Kubernetes, il faut attendre Rancher 2 pour être à jour dans les versions de K8s (acronyme de Kubernetes), c’est tout frais et par ici : https://github.com/rancher/rancher/releases/tag/v2.0.6.
Rancher 2 a été releasée en avril 2018, mais il est préférable d’attendre que sa version se stabilise avant de l’utiliser. Cette première version GA a été poussée prématurément pour permettre de maximiser les retours sur le produit, donc ne lancez pas une pseudo version bêta de Rancher 2 en production tout de suite 😉
Les fonctionnalités de Rancher
Nous allons dans un premier temps présenter les différentes couches de Rancher : Environments, Stack, Service, Container…
Les Environments
Rancher permet de gérer des clusters, ce qu’il appelle des “Environments”. Chaque Environment est rattaché à des serveurs (base du cluster). Un serveur ne peut pas appartenir à 2 clusters, ça parait logique mais on a toujours une petite voix qui nous dit d’essayer quand même.
Il est possible de filtrer les accès des utilisateurs sur les Environments afin de limiter leur accès, pratique pour que l’interface devRancher accède au cluster de production.
Les Stacks
Pour Rancher, une Stack est la représentation logique d’une application… Oulah ! (ça se complique un peu tant qu’on ne l’a pas utilisé).
Pour vous imager le concept, votre application se découpe en 3 parties (3 tiers) :
- Un frontend (une appli Angular qui tourne sous Apache)
- Un backend (une API en Java qui tourne sous Tomcat)
- Une base de données (une base relationnelle comme MariaDB)
Rancher regroupe tout ça dans une entité logique : une Stack.
Si vous avez une autre application (3 tiers aussi) qui tourne à coté, vous pouvez séparer ces 2 applications dans 2 ensembles différents.
Pour faire simple, les Stacks servent à ranger les applications dans des boites =)
Les Services
Le Service, la suite logique de la Stack. Pour Rancher, chaque brique de votre application est représentée par un service. Un Service appartient à une Stack, et une Stack peut contenir plusieurs Services.
Reprenons l’exemple de l’application décrite juste au dessus. Chaque partie de l’application, frontend backend et base, sont des services. La Stack, qui représente notre application, contient donc ici 3 services.
Le Service est le contenant des Containers (conteneurs), il peut contenir un ou plusieurs conteneurs.
Le Service a des propriétés intéressantes, c’est lui qui gère le nombre de conteneurs du service : le Scale. Ça veut dire qui si un conteneur vient à tomber, le Service Rancher relancera ce conteneur.
Autre propriété liée au Service, le Healthcheck permet de vérifier l’état de santé des conteneurs induits par le Service, ce qui implique que tous les conteneurs du service auront le même système de vérification. Le Healthcheck est défini par la nature du check (Aucun, TCP, HTTP), son port, et son contexte dans le cas du HTTP (/healthcheck par exemple). On peut également définir le nombre, la fréquence et le timeout du Healthcheck.
Les Containers
Le Container est la plus petite entité de Rancher et la plus compréhensible étant donné qu’elle colle parfaitement au conteneur Docker.
Aucune action n’est permise sur les Containers Rancher étant donné qu’ils sont générés en fonction des options du Service.
Il est cependant possible de visualiser les logs générés par le conteneurs (pratique pour débugguer). Rancher n’apporte aucune feature sur ce sujet, donc tout conteneur détruit verra ses logs supprimés. Il faudra penser à exporter ces logs dans une solution centralisée : ELK, Graylogs, Splunk, …
On peut également visualiser la consommation en temps réelle du conteneurs : CPU, RAM, Disque et Réseau. A l’instar de Docker, Rancher ne stocke aucune donnée liée au monitoring, tout ce qui est affiché est mis en mémoire. Si vous rafraichissez la page du conteneur, vous perdrez l’historique des métriques. On va donc logiquement se rediriger vers une autre solution de monitoring que les dashboards embarqués dans Rancher : Splunk, ELK, TICK, …
Comme sous Docker, il est possible de rentrer dans le conteneur avec un prompt (/bin/bash) afin de voir/modifier l’intérieur du conteneur.
Le Load Balancer
Rancher met à disposition un Load balancer interne qui est ni plus ni moins qu’un HA Proxy conteneurisé. Une interface simple est proposée pour faciliter la configuration du HA Proxy.
HA Proxy permet le routage par reverse proxy (Request Host), équivalent du VirtualHost d’Apache, ou par port. La possibilité d’orienter les flux par contexte (Path) fait penser à du microservice. Et le tout part vers un conteneur sélectionnable (facile !) et son port (ça ne se devine pas).
Les options proposées permettent de balayer 90% des cas, ce qui est déjà un exploit pour un soft qui cible tout le monde et toutes les applications possibles.
Si jamais un cas tricky de HA Proxy n’est pas proposé, il est possible de surcharger la conf avec l’encart “Custom HAProxy” qui va insérer la conf dans le fichier /etc/haproxy/haproxy.cfg du conteneur.
L’architecture de Rancher
Un bref schéma qui résume tout ce qui a été expliqué au dessus, vous distinguerez donc les Stacks 1 & 2, Services 1 & 2 et nos containers :
L’installation de Rancher
Comme on peut s’en douter, installer Rancher est aussi simple que de lancer un conteneur, la preuve :
docker run -d --name rancher-server --restart=unless-stopped -p 8080:8080 rancher/server
Rien de bien compliqué, on lance le conteneur “rancher-server” depuis l’image rancher/server sur le port 8080 de la machine, et HOP !
Vous êtes prêt à déployer et à scaler 😉
Dans un prochain article, nous verrons comment appréhender l’API que fournit Rancher pour automatiser les actions.
