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.