Epic 4 : Gestion des modèles de serveur (en cours)¶
E4-1 : Implémentation d’un service de stockage de fichiers (clos)¶
Contexte¶
L’application Zéphir doit pouvoir stocker un certain nombre de fichiers liés à des entités métiers, notamment les fichiers associés à une ApplicationService.
Proposition¶
Créer un service dédié au stockage/récupération de fichiers, potentiellement via une solution du type https://minio.io/ ou https://docs.mongodb.com/manual/core/gridfs/. Dans la mesure du possible, le support de stockage devrait effectuer de la déduplication et de la réplication. Ce service devra pouvoir être interrogé via le broker de message. Les opérations CRUD devront pouvoir être effectuées sur un fichier. Chaque fichier devra être référencé par un identifiant unique.
Critères d’acceptation¶
- Un message transmis par l’API HTTP permet d’enregistrer un fichier sur le service de stockage. Si un identifiant de fichier est fourni, le fichier doit écraser un fichier existant. La réponse contient le (nouvel) identifiant du fichier sur le service de stockage.
- Un message transmis par l’API HTTP permet de récupérer un fichier existant sur le service de stockage via son identifiant.
- Un message transmis par l’API HTTP permet de supprimer un fichier existant sur le service de stockage via son identifiant.
E4-2 : Création de la base de données et gestion des migrations du schéma dans l’infrastructure Docker (clos)¶
Contexte¶
Le domaine fonctionnel « ServerModel » va devoir manipuler et persister plusieurs entités métiers. Il faut définir une stratégie de gestion du cycle de vie de ces entités.
Proposition¶
Identifier un moteur de base de données pour les entités du domaine « ServerModel » Définir une stratégie de migration du schéma de données (si le moteur de BDD n’est pas sans schéma) dans le contexte de l’infrastructure Docker
Critères d’acceptation¶
- Un moteur de base de données a été choisi pour le domaine « ServerModel » et ce choix est argumenté.
- Une méthodologie de migration du schéma de données est documentée et une première implémentation de cette méthodologie est créée pour les entités du domaine ServerModel
- La documentation devra si possible servir de support pour les implémentations des futurs services
- La stratégie de migration est fonctionnelle dans le cas où plusieurs instances du service sont démarrées en parallèle
E4-3 : Amorçage de la base de données à partir du jeu initial (clos)¶
Contexte¶
La base de données du domaine ServerModel doit être amorcée à partir du jeu défini dans le répertoire dataset pour l’environnement de test.
Proposition¶
Définir une stratégie d’amorçage de la base de données à partir du jeu de données initial et implémenter une première version fonctionnelle.
Critères d’acceptation¶
- Le jeu de données est correctement chargé dans la base de données du domaine « ServerModel »
- La stratégie d’amorçage est documenté dans la doc technique
- La stratégie d’amorçage est fonctionnelle dans le cas où plusieurs instances du service sont démarrées en parallèle
E4-4 : Service « contrôleur » pour les modèles de serveur: lister/afficher les modèles de serveur existants¶
Contexte¶
Les entités du domaine ServerModel doivent être interrogeable par les autres services de l’application Zéphir.
Proposition¶
Implémenter un service qui permet d’exposer les entités du domaine ServerModel sur le bus de message de l’application Zéphir.
Critères d’acceptation¶
- Un service est implémenté et défini un certains nombre de message permettant de récupérer la liste des ServerModel disponibles ainsi que leurs sous propriétés/entités
- Ce service fonctionne en mode multi-instances
E4-5 : Service « contrôleur » pour les modèles de serveur: gestion des sous modèles de serveur¶
Contexte¶
L’application Zéphir doit permettre la création de sous modèles de serveur
Proposition¶
Implémenter un service qui permet de créer des sous modèles de serveur
Critères d’acceptation¶
- Un service est implémenté et défini un certains nombre de message permettant de créer/mettre à jour des sous modèles de serveur
- Ce service fonctionne en mode multi-instances
E4-6 : Définir la stratégie de mise à jour des modèles de serveur « racines »¶
Contexte¶
EOLE (ou le MTES) va maintenir un certain nombre de modèles de serveur (modules EOLE + versions). Les instances de Zéphir en production devront pouvoir récupérer les mises à jour de ces modèles et les nouvelles versions de manière automatisée et sécurisée. Des acteurs externes à EOLE devront pouvoir également déployer automatiquement leurs mises à jour de la même manière. Dans le cas où il existerait des modèles enfant des modèles de serveur mis à jour, l’utilisateur Zéphir devrait être au minimum notifié et les conflits potentiels devraient être minimisés/détectés/signalés dans la mesure du possible.
Proposition¶
Définir une stratégie de déploiement des mises à jour des modèles de serveur et implémenter une première version de cette stratégie (conteneur de données avec montage de volumes ? Archive avec récupération HTTPS ?)
Critères d’acceptation¶
- Une instance de Zéphir est capable de récupérer une mise à jour des modèles de serveur et l’intégrer dans sa base de données.
- La procédure est automatisée.
- La mise à jour est signée et versionnée.