Epic 2 : Gestion de la persistance des données Zéphir (clos)

Identifier les données devant être persistantes « à long terme ».

Contexte

Définir un modèle de données pour gérer la persistance des données communes à l’ensemble des microservices.

Environnement

• le serveur Zéphir

Explication

Dans l’application, nous devons gérer :

• des utilisateurs, leurs droits, leurs rôles

• des serveurs avec leurs sites, leurs zones, leurs machines. Ces éléments seront regroupés dans des “conteneurs” (UO) permettant de déléguer la gestion de l’ensemble des objets à des rôles.

• des modèles de configuration (module, variante, service applicatifs). Ces modèles seront :

  • soit modèles EOLE (et mis à jour par EOLE),
  • soit des spécialisations des modèles EOLE,
  • soit des spécialisations de spécialisation.

• un serveur sera relié à un modèle de configuration

• un modèle de configuration n’est pas obligatoirement un « module EOLE ». Nous pouvons gérer des serveurs sous un OS non Ubuntu (ex: Centos)

• le schéma de données devra être multi-version EOLE.

• Un micro service de mise à jour de la BD sera en charge des modifications

• des informations confidentielles

Problématique du partage des données (micro services)

Deux solutions sont envisagées concernant la gestion des données dans l’architecture

• Une base de données “globale” contient l’ensemble des informations (Database per service), celle-ci étant accessible par l’ensemble des micro services.

  Avantages :

  • Pas besoin de passer par le bus de message pour récupérer les données.
  • pas de problème pour effectuer des requêtes croisées.
  • intégrité de la base plus facile à assurer (transactions possibles).

  Inconvénients :

  • Une modification du schéma de la base peut impacter l’ensemble des micro services.

• Chaque micro service gère ses propres données (Pattern: Shared database). Ne présage pas de la séparation des données (tables ou bases séparées, …).

  Avantages :

  • Chaque micro service peut faire évoluer son schéma de données sans impacter les autres.
  • Possibilité d’utiliser des moteurs de stockage différents selon les besoins.

  Inconvénients :

  • Demande de faire passer les données par des messages entre micro services.
  • Maintenir l’intégrité des données est plus compliqué (évènements si changement, …).
  • Les requêtes sur des données de plusieurs services sont plus complexes (jointures).

Uns solution de stockage des données confidentielles pour la gestion des clés privées, des accès aux bases de données est proposée : Vault

• L’API HTTP de Vault est accessible par l’ensemble des services - Le service Vault n’est pas exposé. Il n’est utilisable que par les conteneurs. - La gestion des tokens (root_token) et des clés de déverrouillage n’a pas été étudiée.

  Le token root et les clés se trouvent dans le répertoire /var/lib/zephir/vault_secrets Les conteneurs doivent monter un volume pour y accéder

  • Le service vault utilise le backend file pour stocker le coffre dans le répertoire /var/lib/zephir/vault du maître le service vault monte ce répertoire dans un volume /srv/vault
  • Étudier l’utilisation du backend consul
  • Étudier la gestion des tokens et des clés de descellement
  • Étudier la gestion des rôles et des policies

Diagramme de classes

Le fichier de référence est créé avec l’outil Dia (en mode non zippé). Il s’agit du fichier ModelZephir.dia