Rancher est une plateforme de gestion de container complète et performante. C’est un projet open-source crée par la société Rancher Labs. Société qui produit également RancherOS, une distribution linux ultra-minimaliste façon « container » similaire à CoreOS.

L’intérêt de Rancher réside dans sa simplicité, de par son interface web et sa rapidité de déploiement pour orchestrer une multitude de containers en production. Il se base sur docker-machine, et Rancher viens tout juste de sortir en version 2.0.

L’interface web est très complète, avec un catalogue d’applications communautaire, la possiblité de déployer soi-même sa propre instance et les nombreuses options disponibles, haute-disponibilité, contrôle d’accès, analyse de log, stockages, certificats…et encore plus !

Table des matières

Mise en place

Lab

Au niveau de mon cluster de mon machine, je vais avoir un MasterRancher qui sera donc mon master (captain obvious), et qui déploieras sur mes différents slaves RancherSlave1 et RancherSlave2. J’ai adapté les fichiers hosts de chacun pour qu’ils puissent se joindre entre eux par nom DNS et ainsi avoir un lab oéprationnel.

Installation & démarrage

Sur le MasterRancher

$ sudo docker run -d --restart=always -p 8080:8080 rancher/server

Le flag always associé à l’option —restart permet à mon orchestrateur de redémarrer automatiquement si il est stoppé pour X raison indépendamment de notre volonté (si le container est arrêté manuellement le flag ne sera pas pris en compte, dans ce cas-là il redémarrera soit manuellement/soit au redémarrage du daemon docker).

Parmis les autres flags dispo on trouve :

• —restart=no, ne pas redémarrer automatiquement le container (option par défault)

• –restart=on-failure, redémarrer le containeur si il sort à cause d’une erreur qui à un code de sortie différent de zéro (pas bon signe)

• –restart=unless-stopped, redémarrer le containeur à moins qu’il ne soit explicitement arrêté ou que Docker lui-même ne soit arrêté ou redémarré

Après le lancement du container en background, l’interface web est maintenant accessible sur le port 8080 du MasterRancher.

Prise en main

Initialisation

Dès le départ, Rancher nous demande d’ajouter un hôte Linux avec une version supportée de Docker ( > 1.12.3) . Il s’agit de déployer des machines sur lesquelles seront supportés nos applications et services, un peu à la docker-machine.

Il est possible d’utiliser différents drivers comme Amazon, DigitalOcean ou d’en customiser différents avec OpenStack, 1&1, vSphere, vCloudAir (récemment racheté par OVH à VMware) etc..

Je choisis pour ma part custom, car mes hôtes se situent sur mon réseau local.

Une fois la commande lancée sur mes clients, le téléchargement de l’agent rancher sous forme d’image Docker va commencer avec différents arguments lors de son lancement : mappage de volumes, flag –rm (permet de supprimer automatiquement le système de fichiers dès l’arrêt du container), flag –privileged (permet au container d’accéder à tout les périphériques de l’hôte et de le lier avec AppArmor ou SELinux par ex.)

$ sudo docker run --rm --privileged -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/rancher:/var/lib/rancher rancher/agent:v1.2.7 http://192.168.43.212:8080/v1/scripts/64FE3D3553E6F50D9718:1483142400000:8KiFLo06sVLLMIvDhk3ND93sM30

Il est intéressant de noter qu’après le lancement de l’agent rancher sur mes nodes, différents containers sont lancés à la suite pour une administration et une vue totale depuis mon MasterRancher : état de santé, tâche planifiée, scheduler, recensement des containers présents, services réseaux..

Mes différents nodes sont bien visibles sur l’interface de Rancher

Interface Web

Stacks

Le menu stacks, qui permet d’avoir une vue de l’ensemble de nos stacks et des services qui y sont associés avec une vue infrastructure/utilisateur.

Plusieurs stacks y sont présentes par défaut lors de la jonction des slaves, indiquant les services qui y tournent et les containers équipés de ce service.

Plusieurs mode d’affichage du stack sont disponible :

Le mode liste

Le mode graphique

Et le mode YAML avec le docker-compose.yml et un petit nouveau.. rancher-compose.yml

Le rancher-compose.yml fonctionne dans le cadre d’une stack via l’interface web, et fonctionne exactement de la même manière que si l’on avais lancé les containers via l’interface Rancher. Ils utilisent les mêmes appels API. Pour activer les fonctionnalités supplémentaires qu’offre l’orchestrateur Rancher, rancher-compose.yml peut parfaitement remplacer le fichier docker-compose.yml déja présent.

L’outil Compose de Rancher est similaire à celui de Docker (numéro de version, ordre de démarrage, networks) malgré quelques différences, et la documentation officiel est très claire de ce sujet-là : il faut savoir utiliser Docker Compose pour manier Rancher Compose.

Catalogue

Le menu catalogue, qui fournit un des modèles d’applications pour faciliter le déploiement de celles-ci.

Le catalogue Library, avec des modèles certifiés et maintenues par Rancher Labs.

Le catalogue Community, qui contient des templates crée par la communauté Rancher, et qui ne sont pas maintenus par Rancher Labs. Cela se passe sur le GitHub.

Il est également possible de définir soit-même son propre catalogue, d’en ajouter où d’en supprimer avec un système d’URL Git

Infrastructure

Le menu infrastructure, permettant d’avoir une vue complète et détaillée des différents éléments qui composent l’infrastructure : hôtes, containers, stockages, secrets…

Je vais par exemple ici ajouter un container manuellement

Il est nécessaire de prendre quelques minutes pour visualiser tout les paramètres proposés, c’est très complet comme pannel et largement suffisant pour bien gérer et cloisonner son instance ! Toutes les options prises en charges par $ docker run sont également prise en charge dans Rancher.

Lors du lancement, Rancher va automatiquement choisir un hôte (dans mon cas RancherSlave2) sur lequel sera déployé le container. De plus, en cas d’erreur, les logs du container sont très facilement consultable et surtout LISIBLE 😀

Magique non ?

Déploiement d’un stack en quelques clics

Nextcloud

Mon propre cloud personnel, disponible dans le catalogue communautaire. Une analyse rapide des fichiers du mainteneur m’indique que quatres containers seront déployés : nextcloud, mariadb, nextcloud-data avec un mappage du /var/www/html et mariadb-data et un mappage de /var/lib/mysql sur mon node.

Les variables à renseignés seront disponibles dans les options de configurations, avant de démarrer le stack.

L’instance est maintenant via accessible via l’IP de mon RancherSlave2 car il s’occupe de Nextcloud, et RancherSlave1 quand à lui de la base SQL.

RocketChat

Son propre Slack en ligne, et en plus un bot avec qui discuter :P. Un rapide coup d’oeil sur les différents fichiers compose : un container mongo sans mappage de volume, un container rocketchat basé sur l’image officiel, accessible port 3000 et lié avec la BDD Mongo, et un troisième container qui sera le bot Hubot !