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

server-manager

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 mode roundrobin ou random. 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.