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

Rôle
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

Rôle
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 configurer le fournisseur d’identités utilisé par celle-ci.

Messages

traefik

Rôle
Le service traefik a pour mission de gérer le reverse proxy / load balancer dynamiquement et de servir les services sur les routes enregistrées

authorization-manager

Rôle
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-manager

Rôle

Le service saltmaster-manager 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

vault

Rôle

Le service vault a pour mission de fournir un stockage de données sensibles aux services de l’application Zéphir pour:

  • enregistrer la configuration des « minion » (clés privées/publiques, fichier de configuration, …)
  • stocker les clés SSH des utilisateur
  • stocker les secrets d’accès aux bases de données
  • …

Messages Le service vault n’a pas de message spécifique. Il n’est pas exposé sur l’extérieur. Seuls les conteneurs y ont accès.

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.