Rancher - La Ruée vers le conteneur
Les conteneurs sont de toutes les réflexions aujourd’hui. De fait, un nombre croissant de projets d’orchestration voient le jour, essayant de répondre aux problématiques du Container as a Service (CaaS) et du conteneur en production. L’une des réponses précédemment présentées est OpenShift, une autre est Rancher.
Cet article a pour but de vous présenter Rancher, et de balayer l’ensemble des fonctionnalités du produit. Il s’adresse à une population familière avec Docker, se posant la question de l’orchestration de conteneurs.
Que propose Rancher ?
Rancher propose une plate-forme où il est possible de démarrer des conteneurs, sur divers environnements de manière isolée, résiliente et distribuée. Le tout emballé dans le but d’une mise en place et une utilisation simple : on provisionne des hôtes, sur lesquels vont se déployer des conteneurs.
Dès la première page de sa documentation, Rancher annonce ses ambitions : “une plate-forme open-source qui met à disposition des mécanismes spécialement conçus pour le fonctionnement de conteneurs en production”. Tout un programme.
Réussir ce pari, c’est résoudre a minima les problématiques de :
- Réseau : faire communiquer entre eux des éléments volatiles, de manière sécurisée et le plus étanche possible aux dysfonctionnements
- Stockage : le stockage sur un conteneur n’est par défaut pas persistant
- Load-balancing (répartiteur de charge) : s'abstraire du nombre de conteneurs et de leur éphémérité en n’ayant qu’un seul point d’entrée pour un service donné
- S_ervice discovery_ (découverte de services) : être capable de scaler en cas d'un changement de charges ou de capacité (perte d’un hôte, d’un conteneur)
- Gestion des ressources : ajouter des hôtes à votre pool, qu’ils soient situés dans votre salle serveurs, ou sur un cloud public
Certains de ces points sont adressés par Docker, mais nous sommes capables de dire aujourd’hui que cela est incomplet, preuve en est la prolifération de projets d'orchestration de conteneurs comme Kubernetes, OpenShift, Marathon (Mesos), Nomad ou Rancher.
Rancher n’est pas à confondre avec RancherOS, développé en parallèle par Rancher Labs. Ce système d’exploitation est comparable à CoreOS . Il contient le minimum nécessaire pour faire fonctionner Docker, packagé dans une image de 20 Mb.
Un “poor lonesome cowboy” ?
Ceci mis à part, la stratégie choisie n’est pas de concurrencer frontalement ces solutions, mais de s’en servir pour alimenter son offre, tout en se rendant attractif en comblant leurs manques et en offrant une couche d’abstraction pour faciliter l’exploitation. Pour preuve, si Rancher propose une solution d’orchestration de conteneurs “maison” du nom de Cattle, Rancher intègre la possibilité de la remplacer par Swarm ou Kubernetes.
Les promesses
Créez et exploitez votre CaaS privé. Cela signifie laisser l’utilisateur déployer lui-même son application, en piochant dans une réserve de ressources préparée par les équipes d’infrastructure et mise à sa disposition. L’utilisateur est celui qui a la main sur la politique de déploiement de son application, laissant à Rancher le soin d’abstraire les services nécessaires (de calcul, de réseau, de stockage…) parmi tous les hôtes auxquels il a accès.
Un hôte peut être n’importe quel serveur (physique ou virtuel) sur lequel est capable de fonctionner Docker 1.9.1+. Ajouter un hôte à un cluster Rancher est simple comme lancer un conteneur. Voilà dans l’idée.
Présentation des fonctionnalités
Rancher est capable de provisionner nativement des hôtes sur de nombreuses plateformes (ex : AWS, Rackspace, ….), avec une intégration fine des API de ces fournisseurs.
Sur ceux-ci, l’installation de la “tuyauterie” est automatique et paramétrable. Par exemple, la suppression d’une instance EC2 dans l’interface de Rancher le décommissionnera de votre compte AWS. En dehors des hébergeurs supportés, un hôte peut être à peu près n’importe quel serveur.
Rancher crée un réseau virtuel privé par environnement, assurant une communication entre les hôtes étanche et sécurisée grâce à un tunnel IPSec. L’intérêt est de se retrouver avec une série d’hôtes de provenances diverses (datacenter, cloud privé, cloud public, …), capables de communiquer comme s’ils se trouvaient sur un seul et même réseau local privé.
Rancher propose une série de “Templates” de services, dans son catalogue : mise en place d’un ZooKeeper, d’un Hadoop + Yarn, d’une pile ELK, d’un GlusterFS, etc… Bien sûr, il est possible d’intégrer vos propres modèles à ce catalogue. En quelques commandes, votre application se déploie, selon la stratégie de base, ou personnalisée par vos soins.
Le load-balancing des conteneurs et des services, entre tous les hôtes, quels qu’ils soient, est intégré dans Rancher. Un load-balanceur est un objet à part entière, qui s’intègre à un service. Sous le capot, c’est la solution standard du marché HAProxy qui permet cela.
On retrouve également au catalogue des services DNS externes reposant sur Amazon Route 53, CloudFlare, DNSimple ou encore PointHQ. Comme toujours, il est rendu facilement possible d’ajouter un service qui ne serait pas encore “au catalogue”.
La montée en niveau d’un service est facilitée par une mécanique de redirection du trafic, permettant de tester le composant modifié et ses dépendances avant de le rendre disponible à tous (“rolling upgrade”).
Diagnostiquer les bugs peut se faire depuis l’interface, où il est possible de monitorer un conteneur (CPU, RAM, I/Os et utilisation réseau), visualiser ses logs, ainsi qu’ouvrir une invite de commande. Néanmoins, si cela est accessible “par conteneur” et “par hôte”, obtenir ces informations pour un “service” ou un ensemble de conteneur n’est pas prévu au programme pour le moment.
Une stratégie de placement (affinité entre les conteneurs et les hôtes, voir notre article sur le sujet) est également proposée en utilisant simplement des labels. Par exemple, un load-balancer pour notre application web sera labellisé comme suit dans notre docker-compose.yml :
labels:
# Je souhaite ne me deployer que sur un hôte dont la valeur du label "web_exposed" est "yes"
io.rancher.scheduler.affinity:host_label: web_exposed=yes
# Je ne dois jamais me déployer sur un hôte disposant déjà d’un container dont la fonction est "lb"
io.rancher.scheduler.affinity:container_label_ne: function=lb
# Ma fonction à moi est "lb"
function: lb
Facteur différenciant à l’heure actuelle, la gestion du stockage. Snapshot, backup et restore des volumes persistants de Dockers sont intégrés à Rancher via Convoy, une couche d’abstraction au stockage. Le travail de mise en place de solutions comme GlusterFS ou NFS est également disponible, sous forme de services pré-configurés dans le catalogue.
Enfin, Rancher est multi-tenants : en tant que solution de CaaS, Rancher propose un mécanisme de gestion d’utilisateurs : il est possible de créer des environnements séparés (dév, test, prod…) et de brancher l’identification à un annuaire existant (Active Directory, Github ou OpenLDAP).
Rancher est une solution intéressante, avant tout pour son packaging. Nous avons en face de nous un produit bien fini visuellement, qui propose en plus un catalogue de services à mettre en place en quelques commandes. Ce catalogue permet de déployer des solutions indispensables à ce type de plateforme, comme le service discovery ou le stockage distribué. La facilité de mise en place est également un plus : le ticket d'entrée est très faible, et on peut démarrer ses tests dès le premier hôte. Des éléments restent néanmoins, à l'heure actuelle, à améliorer ; les plus importants pour nous étant la gestion de la montée de version de la plateforme, et l'absence de haute disponibilité intégrée pour votre serveur maître. Espérons que la version 1.0, prévue pour fin mars, saura adresser ces points !