Réaliser une API management avec Tyk et docker

Tyk est une solution d’API management open source disponible dans une version dockerisée que nous allons déployer entre un reverse proxy et une API. Comme nous manipuleront plusieurs contenaires Docker, nous utiliserons docker-compose pour tous les regrouper.

L’API management en quelques mots

Le terme d’API Management revient de plus en plus de nos jours avec l’omniprésence des API Rest. Beaucoup de sociétés disposent, ou projettent, de mettre à disposition une API. Les raisons sont multiples : Open Data, architectures micro services, recherche de nouveaux marchés, etc.

Une fois les questions techniques de mises en place d’une API résolues, une autre problématique fait son apparition : comment faire vivre son API ? Et oui, une API c’est comme votre animal de compagnie : il faut en prendre soin pour qu’il s’épanouisse !

Et c’est là que l’API Management intervient. Cela permet par exemple :

  • de sécuriser une API, définir une ou des méthodes d’authentification
  • de contrôler son utilisation via des quotas, des caches
  • de monétiser son utilisation
  • de la versionner
  • de la documenter pour les futurs consommateurs
  • et bien plus encore !

Toutes ces tâches et opérations sont communes à toutes APIs. Ainsi des produits ont fait leur apparition pour éviter de réinventer la roue et nous permettre de nous concentrer sur la valeur ajoutée (le produit). Dans ces solutions, on trouve une pléthore de produits payants ou à abonnement (3scale, IBM, Mashape, Apigee, Restlet, etc.). Mais ici nous allons nous intéresser à un produit open source écrit en Go : Tyk (https://tyk.io/) créé par Martin Buhr https://twitter.com/martinbuhr.

 

Tyk : chercher la petite bête

Pour faire simple, Tyk se décompose en 2 parties : l’application de management et une application web, le dashboard, pour la configurer.

Tyk

Nous allons voir comment déployer Tyk et son dashboard dans notre SI, mais il existe également une solution cloud payante (cf: https://cloud.tyk.io/).

 

Mise en place du SI

Notre SI sera composé d’un serveur Apache (open.local:9092) configuré en reverse proxy vers Tyk. À l’autre bout se trouvera notre API : un simple serveur Apache qui servira 1 ressource (= 1 fichier vide). C’est un peu léger comme API, mais amplement suffisant pour tester notre architecture. Nous avons juste besoin d’une ressource accessible qui nous renvoie un 200 lorsqu’on y accède. Cette ressource sera disponible à l’adresse bouchon.local:9090/horaires/MANG.

code 1 tyk code 2 Tyk

Dans les premières lignes du fichier docker-compose.yml, nous pouvons voir le bouchon qui servira d’API. Nous montons une image d’Apache et nous lui indiquons que son DocumentRoot contiendra notre système de fichiers : bouchon>horaires>MANG. Le port 80 du contenaire est mappé vers le port 9090 de notre machine.

La ligne open (le reverse proxy) se base sur un fichier Dockerfile, qui sert uniquement à copier un fichier de configuration Apache httpd.conf modifié pour utiliser ce serveur comme reverse proxy.

Extrait du fichier httpd.conf

code Tyk 2

Le port 80 du conteneur est mappé vers le port 9092 de notre machine. Enfin, un lien est fait vers le conteneur de Tyk (dont nous verrons la configuration un peu plus loin). Ainsi nous pourrons faire le reverse proxy entre open.local:9092 => api.local:8080/open/.

 

Configuration de Tyk

Toute la configuration qui suit vient directement de https://github.com/lonelycode/tyk_quickstart s’agissant simplement de l’exemple officiel de Tyk. Vous pouvez retrouver le détail des instructions pour faire exécuter l’exemple officiel ici : https://tyk.io/v1.9/setup/docker/.

La seule modification que nous avons apportée est l’indication d’un lien pour que la gateway ait connaissance de notre API bouchon.

Code 4 tyk

Prenons un peu de temps pour digérer tout ça. C’est fait ? Bon alors commençons le détail des instructions :

  • Ambassador sert de lien dynamique entre la gateway et le dashboard
  • Tyk_gateway, notre API management qui sera accessibles sur les port 80 et 8080 de notre machine
  • Tyk_dashboard pour configurer notre API management sera accessible via le port 3000
  • Tyk_redis: base de données utilisée pour stocker les paramètres de l’API management configurés via le dashboard
  • Tyk_mongo: base de données utilisée pour stocker les analytics des API gérées par Tyk

Et… c’est tout! Ou presque. Il reste ensuite à initialiser Tyk pour qu’il ait connaissance de notre API. Et pour ce faire, des instructions ont été scriptées dans bin/setup_tyk.sh.

Encore une fois, ce script est adapté de l’exemple officiel. Il nous permet d’ajouter un utilisateur par défaut pour se connecter au dashboard et de modifier son mot de passe. Tout ça, grâce une API Rest que nous propose le dashboard.

Pour pouvoir indiquer à Tyk tout ce que nous voulons faire avec notre API, nous nous sommes connectés au dashboard, nous avons créé notre API via l’interface, puis nous l’avons exportée au format JSON. C’est ce qui nous a permis d’insérer toute l’initialisation dans notre script de setup.

Ainsi il est très facile de configurer son API, de l’exporter et de la réimporter à nouveau pour une nouvelle installation et déploiement.

 

Et voilà !

Pour lancer notre SI complet il n’y a plus qu’à :

  1. Démarrer le docker-composer: docker-compose -f ./src/compose/docker-compose.yml up -d
  2. Executer le script ./src/setup_tyk.sh

Vous pouvez désormais manager votre API via le dashboard. N’hésitez pas à faire plusieurs essais, sachant que les modifications de configuration dans Tyk sont prises à chaud !

Tyk : focus sur une « petite » solution impressionnante

On ne va pas le cacher, l’API management est une jungle tant le sujet est large et les offres diversifiées. Si vous êtes béotien en la matière, mais avec des problèmes bien concrets (sécuriser une API, optimiser des performances, etc.) une recherche sur internet parmi les principaux acteurs du marché pourrait bien vous embrouiller encore plus les idées.

Tyk semble être vraiment à l’opposé de tout ça en proposant des outils simples répondant directement des problématiques classiques : mises en place de quotas, authentifications, analytics, monitoring, performances, etc. Allez voir par vous-même la liste des features, les articles du blog : tout semble simple et accessible.  Les plus curieux iront jusqu’au code source, mais dans un premier temps testez par vous-même le dashboard. L’interface est sobre et actions possibles sont très logiquement organisées.

Ce focus à l’air trop enjoué pour être objectif et pourtant je n’ai aucun intérêt personnel dans ce produit open source sous licence Mozilla Public License Version 2.0.

Ainsi, essayez juste d’utiliser le dashboard et en même temps un appel à votre API via votre outil préféré (curl, Postman, DHC, etc.). Voyez les modifications prises à chaud à mesure que vous configurez votre API management. Affinez encore vos réglages. Et méfiez-vous lorsque vous présenterez tout cela à votre DSI, il faudra bien justifier vos heures de travail par rapport à une démo effectuée et effective en quelques minutes !

 

Auteur : Nicolas BAPTISTE, Concepteur développeur SQLI Nantes

Nicolas Baptiste

Concepteur développeur SQLI Nantes

3 commentaires
  1. Manuguerra Eric dit :

    Bonjour et merci pour cet article intéressant 🙂 !
    Comment se positionne Tyk par rapport à Kong de NGinx ou Zuul de la stack Spring Cloud Netflix ?
    Quels critères utiliser pour choisir une solution plutôt qu’une autre dans un contexte de projet ?

    Répondre
  2. Nicolas BAPTISTE dit :

    Hello Eric, merci pour ton commentaire. Petite précision, Kong se base sur NGinx mais est édité par Mashape 😉
    Je n’ai pas testé Kong ni Zuul pour le moment. Mais ce que je comprends c’est que Kong semble être vraiment en concurrence par rapport à Tyk mais avec un aspect plus modulaire via ses plugins. Tyk lui est en un seul bloc. Kong se base sur Cassandra ou PostgreSQL pour le stockage et Tyk sur Redis et Mongo…
    Pour moi le gros plus reste l’interface d’administration de Tyk. Sincèrement ce dashboard est très bien fait et archi simple à utiliser. En plus vous disposez d’une API d’administration. Kong ne propose qu’une API d’administration.

    Quant à Zuul, c’est bien une solution de reverse proxy également, mais là c’est un framework java et faut tout écrire soit-même.

    Le choix viendra à mon avis de la taille du projet et de sa complexité. Sans être vraiment expert dans le sujet, je pense que Tyk s’en sort bien niveau performances mais est peut-être moins souple que Kong avec sa logique de plugins. Si demain votre besoin change vous pourrez toujours faire évoluer un plugin ou en créer un nouveau.

    Répondre
  3. David BRASSELY dit :

    Bonjour,

    Merci pour cet excellent article !

    Une autre solution d’API Management OpenSource existe et mélange le meilleur de Kong (extensions, plugins) et le côté pragmatique de Tyk.io
    Il s’agit de Gravitee.io (https://gravitee.io) qui est une solution full OpenSource (Apache License v2) et qui fournit l’ensemble des outils d’une véritable solution d’API Management : Management / Enrollment / Analytics / Reporting / Portal / …
    Gravitee.io est développé en Java (la gateway se repose sur VertX) et est complètement extensible (système de stockage, policy custom, identity provider, analytics, …)

    Petite précision: je suis core-developer de la solution Gravitee.io.

    Répondre

votre commentaire

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Inscription newsletter

Ne manquez plus nos derniers articles !