Gestion et diffusion des modèles de serveurs et services applicatifs

date:2018-08-29

Contexte

Nous avons organisé une discussion à la suite des décisions sur la méthode d’instanciation du serveur.

La question première était de savoir quel mécanisme utiliser pour créer les utilisateurs nominatifs sur les serveurs maintenant que cela ne sera plus effectué par la commande reconfigure.

Scénario d’utilisation d’une formule SaltStack

Daniel a proposé l’utilisation de formule SaltStack et a donc commencé par présenter l’utilisation des formulas et leur organisation en dépôt Git :

L’idée proposée par Daniel se déroule comme suit :

  1. Le conteneur saltmaster-manager est créé avec une configuration lui permettant de modifier la liste des dépôts Git de formules à utiliser
  2. Zéphir permet de modifier/ajouter des dépôts Git de formules (configuration de gitfs_remotes)
  3. EOLE fournit une liste de formules utilisées par défaut
  4. le déploiement du dictionnaire et des valeurs se fait par eole-configuration-formula actuellement installé par le Dockerfile
  5. La création des utilisateurs se fera par un clone de la formule users-formula
  6. Zéphir définit pour chaque serveur la liste des utilisateurs et les données associées dans les pillars du-dit serveur
    • le login
    • la clef publique SSH
    • si l’utilisateur peut faire sudo
    • …
  7. La création des utilisateurs se fera par la formule dédiée après l’ordre d’exécution de reconfigure sur le serveur par le système des dépendances de SLS.

Questions posés

Quid des informations dans les modèles de serveurs et services applicatifs (base de données « servermodel ») ?

Actuellement, les modèles de serveur références des services applicatifs fournis dans un dataset par la source EOLE dans un format particulier :

  • fichier service.xml permettant de déclarer les éléments du service : variables de configuration, les règles de firewalls, les templates, les services, les paquets, …
  • répertoire templates/ contenant les modèles de fichier de configuration
  • répertoire dictionaries/ contenant les fichiers XML de dictionnaires Creole
  • répertoire extra_dictionaries/ contenant des fichiers XML de dictionnaires Creole supplémentaires
  • répertoire creole_funcs/ fournissant des fonctions python supplémentaires utilisées dans les dictionnaires et template Creole
  • répertoire files/ contenant une arborescence de fichier fourni par le service
  • répertoire pretemplate/, posttemplates/, preservices/, postservices/ contenant des scripts de gestion EOLE pour l’instance / reconfigure

Si nous fournissons des formules SaltStack, nous devrons fournir des services applicatifs dans un autre format, celui des formules SaltStack.

Où mettre le curseur entre Zéphir et le moteur de configuration ?

Fonctionnement actuel du Zéphir :

  • SaltStack est un passe-plat pour la gestion des services, Zéphir ne s’en sert que pour distribuer des fichiers et exécuter des commandes
  • envois d’un fichier config.schema décrivant les variables de configuration
  • envois d’un fichier config.values décrivant les valeurs de configuration
  • envois des modèles de fichier de configuration
  • utilisation de la commande reconfigure sur le serveur (minion)
  • SaltStack est utilisé pour lancer les actions (via des modules, des SLS ou des formulas).

Deux extrèmes vers lesquels nous pouvons aller pour la gestion des services :

  • SaltStack est utilisé pour la gestion des services même s’ils ne sont pas distribué sous forme de formula. A partir de la description fournit par le dictionnaire, on reconstruit une formula directement utilisable par SaltStack. Un autre moteur pourra être proposé. Des adaptations seront surement nécessaire dans les templates, … mais pas dans le dictionnaire
  • Zéphir ne gère que les variables de configuration, tout est fait par le moteur SaltStack :
    • Zéphir permet de définir les serveurs et leur organisation
    • les informations sont extraites de l’environnement Zéphir et sont mises à dispositions des serveurs dans des pillars et les formules SaltStack les utiliserons directement

Nous allons dans un premier temps utiliser la première méthode, avec des bouts de la seconde méthode (notamment pour la création des comptes nominatifs sur les serveurs).

Comment diffuser les fichiers des services

Ce qui est actuellement prévu :

  • Les fichiers (modèle de fichier de configuration, scripts, …) sont actuellement stockés dans la base de données du Zéphir.
  • Leur déploiement nécessite :
    • Une extraction dans le docker saltmaster-manager
    • L’appel à une commande SaltStack afin d’envoyer les fichiers sur le minion

Ce qu’il est possible de faire :

Il serait possible de stocker les fichiers relatifs à un service dans des dépôts Git, au format d’une formula SaltStack :

eole-<service>/
├── CHANGELOG.rst
├── eole
│   └── <service>
│       ├── defaults.yaml
│       ├── files
│       │   └── default
│       │       ├── script1
│       │       ├── script2
│       │       ├── <template1>.creole
│       │       └── <template2>.creole
│       ├── init.sls
│       ├── macros.jinja
│       └── map.jinja
├── LICENSE
├── README.rst
└── TOFS_pattern.md

Dans un premier temps, la formule ne prendrait en charge que la copie des fichiers sur le minion.

Dans l’avenir, il est possible de gérer de plus en plus d’aspect de ce service directement avec SaltStack ce qui permettra une transition en douceur.