Architecture Microservices 1 : Configuration

Lors du dernier événement interne de Zenika, plusieurs consultants nous ont présenté l’architecture qu’ils avaient mis en place chez leur client. Le client avait des contraintes très particulières : une haute disponibilité et une volumétrie importante réparties sur des applications très variées. Afin de répondre à ces problématiques, les consultants Zenika ont choisi de mettre en place une architecture microservices. Convaincu par leur présentation, je vais mettre en place ce type d’architecture sur un petit projet de démonstration en expliquant les différentes étapes.

Architecture Microservices avec Spring Boot et Spring Cloud

 

Architecture Microservices

L’idée principale derrière l’architecture microservices est la création d’une application capable de grandir facilement qui repose sur un certains nombres de services indépendant, qui peuvent évoluer rapidement. J’insiste sur le fait que les services doivent être petits afin de les rendre plus facilement maintenables. Ce modèle s’oppose au système monolithique, une unique application réalisant tous les traitements d’une entreprise. Ce type d’application est souvent complexe de part la quantité de services qu’elle propose et par ses phases de déploiements qui peuvent etre longue et complexe.

Ce type d’architecture est utilisé par de nombreuses entreprises qui gèrent une quantité importante de clients. Il permet en effet le déploiement de nouvelles ressources de manière rapide et invisible pour les utilisateurs. Ces nouvelles ressources sont intégrées à ce qui est déjà déployé et acquiert la même configuration.

Je ne détaillerai pas ici les avantages et inconvénients de ce type dd’architecture. De nombreux articles débattent déjà sur cela en anglais principalement : Martin Fowler, InfoQ et le site microservices.io. Je vais me concentrer sur la mise en place de ce type d’architecture avec certains outils importants du domaine. Ceci permettra de rapidement voir les problèmes que cela peut poser et comment cela fonctionne très simplement. Pour cela je vais utiliser les outils suivants: Docker, Mesos, Traefik, Eureka, Spring Cloud et une application Java avec Spring Boot. L’objectif est de présenter une architecture simple et fonctionnelle avec ces outils et comment la mettre en place.

Architecture

Dans notre cas d’étude, nous allons débuter avec une application simple donnant l’heure actuelle. Cette application sera développée en Java avec Spring Boot et copiée dans une image Docker afin de simplifier son déploiement. Afin de pouvoir configurer facilement notre application, nous mettrons en place un serveur de configuration, c’est à dire une application Spring Cloud qui sera reliée à un dépôt de fichiers de configuration. Ceci permettra d’éviter des montées de versions laborieuses et des configurations différentes selon les machines installées. Afin de gérer les différentes installations de notre application nous utiliserons Mesos couplé avec l’orchestrateur Marathon. Mesos est un gestionnaire de cluster, c’est à dire qu’il va perrmettre la gestion des ressources physiques à notre disposition. Marathon lui est un orchestrateur d’application, il va automatiser le déploiement des applications sur les ressources du cluster de Mesos. Afin que tous puissent communiquer entre eux, nous allons mettre en place un Service registry qui va enregistrer toutes les adresses des différents services et ressources disponibles. Mesos s’en servira pour identifier les machines accessibles et nos applications l’utiliseront pour faire leurs appels internes. Enfin, nous utiliserons Traefik en tant que Reverse Proxy et Load balancer afin de gérer les accès à notre cluster.

Application Java Spring

Pour commencer, nous allons créer notre application Java. Son objectif est simple : nous donner l’heure et l’adresse IP de la machine sur laquelle elle tourne. Grâce au site de Spring Initializr, nous pouvons facilement obtenir un projet Spring Boot directement utilisable. Cette application est composée d’un fichier Maven simple avec la dépendance Actuator pour suivre différents métriques de l’application. Elle dispose d’un main permettant le lancement de l’application et d’un Web Service qui retourne nos deux valeurs au format JSON. La dépendance Actuator nous fournit plusieurs Web services permettant d’obtenir des informations concernant l’application comme par exemple les différents Endpoint ou la configuration. Nous utiliserons ces services plus tard.

Afin de rendre le déploiement encore plus facile, nous allons insérer notre application dans une image Docker (documentation). Pour cela nous créons une nouvelle tâche Maven et ajoutons un Dockerfile. Ainsi avec une simple commande Maven, notre image sera prête. L’EntryPoint de l’image est la commande permettant de démarrer notre application.

Pour lancer notre application, nous n’avons plus qu’à exécuter ces deux commandes :

Après la commande Maven, on peut voir que l’image va automatiquement être créée et déposée dans le dépôt Docker local. Par la suite lors de l’industrialisation du développement, nous pourrons donc facilement demander à notre outil d’intégration continue de déposer l’image générée sur un hub Docker.

Notre application est maintenant déployée. Par défaut le port de métriques est le port 8080. Cependant, je souhaiterai être capable de changer cette valeur simplement. Sans avoir à réaliser un nouveau commit sur mon projet, ou sans repasser par toutes les machines sur lesquelles est présente l’application. Pour cela, je vais utiliser un serveur de configuration Spring Cloud qui va servir de distributeur de configuration.

Spring Cloud et Serveur de configuration

Spring cloud est un projet Spring permettant de facilement mettre en place des outils récurrents dans les applications distribuées. La version Spring Cloud Config nous permet donc d’avoir une solide base pour notre serveur de configuration de l’architecture microservices. Dans cet exercice, nous n’allons pas créer un projet complet pour notre serveur de configuration. Nous allons utiliser une image Docker existante et lui fournir l’URL de notre dépôt de configuration. Cette image n’est pas mon travail mais celui du propriétaire du dépôt, l’utilisateur Hyness.

Avec cette commande, notre image Docker va être téléchargée et démarrée. Nous avons donc une application Spring Boot capable de nous servir notre configuration. Cette dernière est stockée sur le dépôt git que nous avons mis en variable d’environnement du conteneur. La structure du dépôt est très simple, il suffit de respecter le nommage indiqué dans la documentation de Spring. Pour notre exemple, le fichier de configuration ne contiendra qu’un nouveau port pour les Endpoints de l’Actuator.

Maintenant, nous devons configurer notre application Java afin qu’elle récupère la nouvelle configuration. Pour cela, nous avons juste à ajouter ces dépendances à notre pom.xml.

Maintenant, à chaque démarrage notre application va rechercher son serveur de configuration pour récupérer la configuration relative au profile Spring actif. Nous allons donc créer le fichier whattimeisit-dev.properties sur notre dépôt Git. Et lancer notre image applicative avec deux variables d’environnement : le profil Spring et l’URL de notre serveur de configuration qui doit être fixe.

Le port des métriques est bien différent du port de notre application. La configuration a donc bien été chargée.

Cette première étape permet déjà de simplifier les tâches d’administration d’une application lorsqu’on la déploie sur plusieurs machines. Afn d’atteindre notre objectif d’une application en Microservices, nous verrons ensuite comment faire pour gérer son déploiement, gérer les ressources disponibles et surtout permettre à nos services de communiquer entre eux.

 

 

spacer

Laisser un commentaire