Atelier serveur de configuration 2

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 micro service ConfigurationManagement

  • un ensemble de composants (paquets, patchs, dicos...) reflétant sa configuration.

Ceux-ci sont issus d’un micro service ServerModel

Principes de fonctionnement des deux micros services

  • Ces micros services 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.
  • A 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ée par ServerModel de la présence d’un dico et donc de couples variables/valeurs supplémentaires à prendre en compte.

Principes de fonctionnement du micro service 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és d’une configuration parentes ou du ServerModel.

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

_images/zephirServerManagement.png

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é par le uService.
  • La propagation de la modification d’une valeur par défaut ne sera effactive que si la valeur n’a pas été modifié sur une variante fille ou sur un serveur
  • Une action particulière permettra forcée cette valeur par défaut.

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

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

Important

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

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 ...).