Comment est-ce que je gère mes services avec Rancher et Consul ?

Mais pourquoi je veux faire ça ?

Admettons que je veuille me mettre aux microservices … ou plutôt aux services packagés dans des conteneurs docker (quelquesoit la taille des dits services).

Je commence par les packager dans des conteneurs Docker et c’est « cool ». Parce que comme ça, je n’ai pas besoin de demander à l’admin sys de déployer du Java partout, mais du Docker.

Donc, j’ai mes services et mon admin a entendu parler (sans doute sur ce blog) d’un chouette truc qui s’appelle Rancher. Et très vite, il veut ajouter une base de données de configuration (parce que mettre les fichiers de config dans les conteneurs, c’est pas terrible … lisez donc 12 factors apps à ce sujet). Donc il me dit d’utiliser Consul. Et Consul, c’est bien pour la config, mais ça fait aussi service registry. C’est-à-dire que ça permet à un service d’en trouver un autre dynamiquement. Un peu comme du JNDI pour les Javaistes … ou du LDAP pour les ancêtres.

Le problème, c’est que Consul fait service registry, et pas service discovery. C’est-à-dire qu’il peut stocker les services, mais pas découvrir quand ils démarrent ou s’arrêtent (enfin pour l’arrêt, si, mais bon, par symétrie, on va considérer ici que ça n’est pas son boulot).

Et comment je fais pour enregistrer mes services ?

Donc, il faut ajouter un composant d’enregistrement, un « registrator ». Coup de bol, il y en a deux pour Rancher :

  1. Gliderlabs registrator
  2. Rancher Registrator

Pourquoi y en a-t-il deux ? C’est assez bien expliqué dans cette chouette question : Do you kill registrator ? Notez que l’auteur de la question est également l’auteur du second registrator … ceci expliquant cela.

Et ça marche comment ?

D’abord, je vous montre le docker-compose.yml, et ensuite on en discute, ok ?

Dans ce fichier, il y a quelques trucs à noter

Attention à la version !

registrator ne supporte l’option useIpFromLabel que dans la branche master. En ancien développeur Java appréciateur des beaux numéros de version, ça me fait mal, mais bon, on me dit que ça marche comme ça dans le monde de Docker …

internal ?

Ca permet à registrator d’utiliser les ports effectivement exposés par les images, au lieu d’utiliser les ports visiobles hors de Rancher, donc ne l’oubliez pas

cleanup, deregister et resync

La doc de registrator est assez claire, mais ça vaut le coup de bien préciser que ces options sont là pour garantir qu’il n’y a pas de services n’existant que dans Consul (ce qui est un peu bête)

useIpFromLabel

A partir de Rancher 1.2, Rancher utilise un système nommé CNI, ce qui fait que l’ip et le port ne sont plus accessibles via le conteneur Docker mais via le label (ajouté dynamiquement par Rancher) io.rancher.container.ip. Du coup, il faut bien signaler au registrator qu’il faut utiliser ce label pour lire l’adresse du conteneur.

Attention aux labels !

Parce que ce registrator est déployé dans Rancher. Il faut donc qu’il soit présent sur tous les hosts (puisqu’il lit la liste des conteneurs depuius le démon Docker local) (d’où le io.rancher.scheduler.global). Il faut également qu’il ait accès au DNS (d’où le io.rancher.container.dns). Les autres options sont moins indispensables.

Et paf !

Une fois que ces opérations sont effectuées, vos conteneurs seront automatiquement enregistrés dans Consul au démarrage, et supprimés de Consul lorsqu’ils s’arrêtent).

Publicités

Générer mon asciidoc dans docker

Non mais pourquoi je veux faire ça ?

Parce que j’ai des collègues qui n’ont pas installé Graphviz. Personnellement, je ne comprend vraiment pas pourquoi. Mais bon, chacun ses choix.

Donc, comme ils n’ont pas Graphviz, et ne veulent pas l’installer, qu’en bonus ils ne veulent installer ni maven, ni java, et qu’ils semblent considérer que Docker est « la meilleure chose depuis le pain en tranches » (un indice : à mon avis, c’est faux), j’ai créé une image docker « kivabien » :

Donc vous prenez ce dockerfile, là, et comme je n’aime pas trop l’idée de publier ça sur le Hub (faut voir aussi que je suis un peu une quiche en docker), ben vous le lancez … avec docker-compose et cette configuration :

d’un habile coup de docker-compose up. Et si tout se passe bien, vous allez retrouver votre dossier target votre doc correctement générée. Notez que, normalement, votre doc pourra contenir du PlantUML, des liens, toute la richesse d’asciidoc.

Elle est pas belle la vie ? Perso, je suis pas sûr, mais on me dit que c’est ça le progrès. Moi je dis ok.

 

Un chtijug dans le textile

Et paf, un chtijug pas à petit prix chez kiabi ! Le site est plutôt sympa, avec un côté plateforme pour théatre d’improvisation (par contre, les spots du fond qui clignotent, ça va pas être pratique pour les épileptiques). Julien (du chtijug) est bien content qu’on sorte des éternels ISEN/IUT B …​ et moi aussi : aller faire ces conférences dans des entreprises, pour des développeurs professionnels, c’est effectivement mieux.

OpenAPI chez Kiabi

Il y a deux ans, Kiabi a lancé une API web. Je ne vais pas vous reprendre tout l’argumentaire développé par le speaker sur les API, parce que personnellement, je connais déja (oui, je ne suis pas vraiment pédagogue). Cela dit, il explique bien les différents aspects positifs de la définition d’une API (quand les slides seront disponibles, ce sera plus clair). L’un des plus grands bénéfices étant évidement l’accélération des développements : en découplant le développement back-end et le développement front-end, on peut accélerer ce dernier.

OpenAPI, c’est le troisième niveau du développement d’API dans l’échelle suivante :

  1. API interne
  2. API publique, mais uniquement exposée aux partenaires (avec évidement de l’OAuth, et peut-être de l’API management)
  3. API publique, exposée et source de revenus.

Définition

Pour développer l’API, Kiabi a d’abord défini des concepts généraux :

  • API Kiss
    • incluant une API affordance, c’est-à-dire intuitive dans son usage, et suggérant même ses bons usages
    • avec une sémantique claire
    • et en ne fournissant qu’une seule façon de faire une chose
  • Réutiliser des standards et des types d’API existant

Par contre, il faut éviter d’utiliser le jargon fonctionnel interne (ce qui est un point à mon sens super intéressant). Laissez-moi détailler ce point un instant. Dans votre entreprise, vos fonctionnels sont là pour définir le vocabulaire métier. Vous comptez sur leur sérieux. Mais quand vous développez une API publique, vous n’utilisez pas ce vocabulaire … C’est de la schizophrénie ? Non, à mon avis, c’est plutôt que le vocabulaire interne dérive, se jargonifie, et perd son adhérence avec le réel. Du coup, c’est DDD ou pas ? A mon avis, et contrairement à certain homonyme, oui.

A partir de ces concepts, Kiabi a défini une refcard qui reprend l’ensemble des concepts et des règles de fonctionnement définies. Chose curieuse, cette refacrd inclut la liste des codes HTTP retournés par les applications Kiabi. Ca me paraît curieux : le W3C a défini ces codes pour des raisons qui peuvent arriver, non ? Alors pourquoi ne pas tous les utiliser ?

Implémentation

Et donc, les implémenteurs implémentent leur API à partir de ces règles, et elle est définie en comité (argh) avec une platrée d’architectes transverses (re-argh). Evidement, ça qualifie le projet comme non-agile, mais en un sens, je comprend le besoin de cohérence du bazar. Et de la même manière, l’implémentation se fait sur une plateforme standard : Tomcat, CXF, JSON, …​

Management

Pour gérer tout ça, Kiabi a mis en place un API Manager (Software AG Webmethods API machintruc) qui ne semble pas fournir tous les services, puisqu’il y a quand même un Apache en frontal (apparemment pour faire de l’URI rewriting). Ils ont également un portail d’API pour développeur, évidement indispensable pour permettre aux développeurs d’utiliser les différentes API proposées. D’une façon amusante, le speaker insiste lourdement sur le fait que ce portail d’API permet aux développeurs d’utiliser facilement les différentes API. Ca trahit à mon sens plus le choc culturel qu’est cette ouverture que le challenge technique de ce portail (ne serait-ce que parce que StackOverflow, Goodreads, le fournissent déja depuis …​ quoi …​ 5 ans ?).

Démo

Pub

Kiabi organise au mois de juin un hackathon. Bon, personnellement, je ne suis pas fan de ce genre d’événements. Mais si ça vous branche …​

traefik

Pourquoi faire un autre reverse proxy (par rapport à, par exemple, nginx ou HAProxy) ? A cause des miccroservices.

Avec les microservices, on gagne un tas de nouveaux outils :

  • Des conteneurs (Docker, rkt)
  • Des orchestrateurs (Docker Swarm, Kubernetes, Mesos, Rancher)
  • Des outils de service discovery (etcd, Consul, Zookeeper)
  • Et des reverse proxy

A quoi ça sert ? A connecter le réseau privé au web en respectant l’état des microservices. Souvenez-vous, Christophe Furmaniak en avait déja parlé lors d’une session sur Rancher.

Les reverse-proxyes open-source (HAProxy et nginx) ont une configuration statique. Du coup, quand les microservices sont déployés, il faut

  1. Arrêter le proxy
  2. Changer la configuration
  3. Redémarrer le proxy

Pas très pratique.

traefik, lui, lit sa configuration depuis l’orchestrateur. Du coup, pas besoin de redémarrage. Plutôt cool …​ Et pour être rapide, c’est du go. Et d’un coup, je comprend pourquoi le go progresse : avec le build statique, une image Docker d’un programme go ne contient pas de dépendances, et c’est chouette ! (pour ceux qui aiment ça). Attention, je ne dis pas que c’est bien. Je dis juste que Go est plutôt bien adapté au monde Docker.

Démo

Et d’un coup, je comprend l’affection de Quentin Adam pour les gestionnaires d’abréviation : lancer des conteneurs docker en ligne de commande pendant une démo, ça peut merder facilement …​ Parce qu’Emile a eu quelques soucis liés à la connexion internet … sensible et aux commandes docker un peu longues.