Services¶
Liste¶
Sont listé ici les services “métiers” constituant l’application Zéphir.
Le code source associé à ces services est disponible dans le répertoire services/<nom_service>
.
api-bridge
¶
- Role
- Le service
api-bridge
a pour mission d’exposer au “monde extérieur” les fonctionnalité de l’application Zéphir. Il permet également d’ajouter aux messages les informations de contexte tel que l’utilisateur à l’origine de la requête. - Messages
- Le service
api-bridge
n’a pas de message spécifique. C’est un passe plat qui peut émettre tous les messages déclarés comme “publiques”.
identity-manager
¶
- Role
- Le service
identity-manager
a pour mission de stocker et fournir les identités des utilisateurs de l’application Zéphir. Il communique également avec l’API Gateway afin de configurater le fournisseur d’identités utilisé par celle ci.
Messages
console
¶
- Role
- Le service
console
a pour mission de fournir un console interactive accessible via SSH aux utilisateurs de l’application Zéphir. La console permet la connexion par identifiant/mot de passe (si l’IdentityProvider configuré le permet) et par clé SSH.
authorization-manager
¶
- Role
- Le service
authorization-manager
a pour mission de fournir une API aux services de l’application Zéphir permettant de vérifier/modifier les droits d’accès des utilisateurs aux différentes ressources de l’application.
Messages
saltmaster
¶
- Role
Le service
saltmaster
a pour mission de fournir une API aux services de l’application Zéphir pour:- exécuter des actions sur les machines distantes (“minion”) appairées au processus salt-master.
- connaître l’état des actions demandées (“jobs”).
Messages
user-manager
¶
- Rôle
- Le service
user-manager
a pour mission de fournir une API aux services de l’application Zéphir permettant de rechercher/modifier des comptes utilisateurs.
Messages
Gestion de la redondance¶
Afin de tenir face à la montée en charge, l’application Zéphir suit le modèle de conception de mise à l’échelle horizontale.
Les services doivent donc pouvoir fonctionner en mode “multi-instances”. Pour ce faire, plusieurs points doivent être respectés lors de l’implémentation des services:
- Le patron de conception “publish/subscribe” est à préférer au modèle “rpc” pour la publication de messages.
- L’enregistrement de
handlers
sur le bus de message doit se faire en moderoundrobin
ourandom
. Voir la documentation du projet Crossbar à ce sujet.
Gestion des versions multiples¶
Il est possible qu’au cours du cycle de vie de l’application Zéphir plusieurs versions d’un même service cohabitent. Les raisons à l’origine de cette situation peuvent être multiples:
- Le format d’une des messages du service évolue et introduit un changement non rétrocompatible
- Le service utilise un service externe qui en évoluant a créé un changement non rétrocompatible.
La méthodologie pour gérer ces cas est la suivante:
- Tout changement non rétrocompatible sur le format d’un message déjà utilisé en production introduit automatiquement une montée de version de ce message pour les changements apportés.
- Si le service associé ne peut pas gérer les deux versions du message (l’impact est trop important sur la base de code et/ou la version initiale du message est dépréciée), deux instances du service seront démarrées, chacune gérant leur propre version du message.
- Si un autre service doit être agnostique face à cette différence de version, un service “routeur” sera implémenté permettant de transformer le message entrant en fonction de la version cible.