Serveur de configuration

Deux problématiques

• l’édition de la configuration : pour cela, l’outil gen_config semble tout-à-fait adapté tel quel (nécessité quand même de mise à jour du logiciel).
• l’édition d’une valeur sur un groupe de serveurs : une valeur d’une variable de configuration donnée nécessite d’être changée par lot (groupe de serveur, tags sur des serveurs, sélection de serveurs...)

La difficulté est de savoir, dans tous les cas,

• d’où vient une variable (d’un module, d’une variante...)
• d’où vient la valeur affectée à une variable (modification par lots, par groupe...)

Définitions

Un serveur est un objet possédant à minima :

• des couples clés valeurs reflétant sa configuration. Ceux-ci sont issus d’un microservice ConfigurationManagement
• un ensemble de composants (paquets, patchs, dicos...) reflétant sa configuration. Ceux-ci sont issus d’un microservice ServerModel

Variantes de configuration

Héritage de variantes : Ancienne définition

Une variante propose un ensemble de valeurs par défaut à la création d’un nouveau serveur.

limitations :

• si on change la valeur d’une variable dans une variante, elle ne sera pas répercutée sur les anciens serveurs basés sur cette variante
• on ne sait pas si cette valeur a été définie par l’utilisateur ou bien si elle vient de la variante
• la valeur de la variante est censée être une valeur par défaut, mais si l’utilisateur demande à revenir à la valeur par défaut, c’est impossible car on ne sait plus quelle était la valeur de la variante

Nouvelle définition

Une variante propose un ensemble de valeurs par défaut des serveurs. Le lien est conservé avec la variante. De plus, une variante peut hériter d’une autre variante.

Important

L’héritage de variante est une des demandes de base du nouveau Zéphir.

L’héritage de variante permet :

• une valeur n’est enregistrée que dans la variante (et non dans la configuration du serveur)
• si une valeur n’est pas trouvée sur un serveur ou une variante, la valeur est récupérée dans la variante parente.

Note

Proposition technique : tiramisu2 permet de gérer les variantes de configuration (voir les réflexions).

Lien entre les serveurs et les modèles de serveur

Un serveur modèle est défini par un ensemble de dictionnaires XML qui ont été applatis en un seul fichier. À partir de ce XML, on génère une variante de configuration. Des variantes filles vont hériter de ces variantes de configuration. Ces variantes sont identiques en termes de description XML, mais les valeurs des variables renseignées peuvent être différentes.

Dans ces variantes, on pourra alors associer des serveurs pour définir des configurations effectives.

Architecture des microservices

Les modèles de serveur et l’outil d’édition de configuration

Principes de fonctionnement des deux microsservices

• Ces microsservices fonctionnent en parallèle mais doivent communiquer entre eux (via le bus de message).
• Ils fonctionnent par héritage.
• Les héritages peuvent être multiples.
• À chaque fois que l’on a une structure fille dans ConfigurationManagement, son pendant doit exister dans ServerModel.

Ce principe établi, cela permet, que ConfigurationManagement soit informé par ServerModel de la présence d’un dico et donc de couples variables/valeurs supplémentaires à prendre en compte.

Principes de fonctionnement du microservice ConfigurationManagement

• L’éditeur de configuration gen_config permet d’afficher l’ensemble des variables connues ainsi que leurs valeurs.
• Les variables sont alimentées par le ServerModel.
• Les valeurs par défaut sont héritées d’une configuration parentes ou du ServerModel.

Considérons les 3 variantes de configurations du schéma.

Si un utilisateur modifie une valeur val1 d’une variable var1 au niveau de la variante de configuration 1

• Tous les nouveaux serveurs auront la valeur val1.

• Pour un serveur existant la valeur de la variable var1 peut être différente de la valeur par défaut. Elle pourra être signalée par le microservice.

• La propagation de la modification d’une valeur par défaut ne sera effective que si la valeur n’a pas été modifiée sur une variante fille ou sur un serveur.

• Une action particulière permettra de forcer cette valeur par défaut.

  À l’issue d’une modification, la sauvegarde entraine une notification à destination :

• du microservice de log (main courante, cahier d’exploitation)

• du microservice de versionning

Important

Ce mécanisme d’héritages verticaux et d’alimentation par le microservice ServerModel permettra d’implémenter la notion de variables/valeurs de site.

Par exemple, considérons que :

• variante de configuration 1 corresponde à un Amon,
• variante de configuration 2 corresponde à un eSSL avec les configurations type d’un Ministère,
• variante de configuration 3 corresponde à une DDT,
• modèle de serveur 2 comporte toutes les fonctionnalités supplémentaires propres à un Ministère (ex. serveur ftp pour base antivirale McAfee),
• modèle de serveur 3 comporte un dictionnaire (comportant par exemple des variables de type nom, adresse, CP, ville, géolocalisation ...)

On reproduit quasimment à l’identique le comportement actuel (on ne parle pas des actions). Mieux, on introduit une “variante de site” qui permettrait d’avoir des variables communes à toutes les machines d’un site (passerelle par defaut ...).

Les messages

Messages extérieurs impactants le microservice :

• la re-génération du XML applati
• lorsqu’un serveur a été créé
• lorsqu’un serveur change de Modèle de Serveur
• lorsqu’un serveur est supprimé
• lorsqu’une information extérieure impacte la configuration (sondes sur le serveur qui détecte un changement, ...)

Messages “utilisateurs” :

• demande de modification de la configuration d’un serveur (avec numéro du serveur) en retour l’utilisateur obtiendra l’url d’accès à gen_config
• demande d’enregistrement de la configuration du serveur

Messages du microservice vers l’extérieur :

• informe quand la configuration d’un serveur est modifiée

Édition d’une valeur sur un groupe de serveurs

TODO