L’illusion de la persistance avec SAS Configuration Server

L'administration de SAS Viya 3.5 implique une compréhension fine de son architecture de microservices et de la gestion de sa configuration. Un point technique, qui soulève souvent des questions, est la persistance des modifications de configuration, notamment lorsqu'elles semblent disparaître après un redémarrage ou une mise à jour.

Ce phénomène s'explique par la distinction fondamentale entre la configuration dynamique (gérée par le SAS Configuration Server) et la configuration de déploiement (gérée par Ansible).

Plongeons dans les coulisses techniques du SAS Configuration Server, basé sur Consul.

Le registre de configuration dynamique : Consul (KV)

Dans l'architecture de Viya 3.5, le SAS Configuration Server joue un rôle central. Comme le confirme la documentation officielle de SAS, ce service (basé sur Consul de HashiCorp) est un registre distribué qui gère trois fonctions vitales :

1. La découverte des services (localisation et communication inter-services)
2. L'état de santé (monitoring de la disponibilité des services)
3. La configuration des services (via un stockage Clé-Valeur, ou KV)

Chaque microservice, lors de son initialisation, effectue une opération de lecture (KV Read) sur Consul pour charger sa configuration et déterminer ses dépendances.

Le Mécanisme de Configuration : KV Read/Write

La force de ce système réside dans son dynamisme. La documentation SAS sur les concepts de configuration détaille ce fonctionnement :

• Pour la majorité des services (basés sur Spring), si un administrateur modifie une valeur dans Consul via un KV Write (généralement via
  sas-bootstrap-config ), le service est notifié et relit la propriété à la volée.
• Le changement est appliqué immédiatement, sans nécessiter un redémarrage (sauf exceptions, comme les services non-Spring ou les paramètres de la JVM qui exigent un redémarrage manuel).

Un administrateur peut donc effectuer une modification, la tester et la valider en production. Cependant, cette modification n'est pas nécessairement pérenne.

Le risque de non-persistance : Configuration dynamique vs statique

La source du problème réside dans la hiérarchie des configurations. Ce qui est modifié via KV Write est un changement à chaud. Il ne modifie pas la configuration de déploiement source.

La distinction est essentielle : pour garantir la pérennité d'une configuration, une simple opération KV Write n'est pas suffisante ; elle doit être intégrée aux fichiers de déploiement.

La configuration de déploiement "source", elle, se trouve dans les fichiers de configuration Ansible, et notamment dans le fichier sitedefault.yml.

Voici le processus lors d'un redémarrage complet ou d'une mise à jour Ansible :

1. Viya initie son processus de configuration (via l'outil sas-bootstrap-config).
2. Il lit ses fichiers sources (comme sitedefault.yml).
3. Il applique une politique de "Check and Set" : S'il voit une propriété dans ses fichiers qui n'existe pas dans Consul, il l'ajoute.
4. Si un processus Ansible est exécuté pour appliquer ou mettre à jour la configuration, il risque de recharger les valeurs par défaut définies dans les playbooks, écrasant ainsi les modifications dynamiques qui avaient été faites manuellement dans Consul.

Le kv write est une modification de l'état actuel, tandis que les fichiers Ansible représentent l'état désiré lors d'un déploiement ou d'une réinitialisation.

Assurer la persistance

Pour garantir qu'une modification de configuration survive aux cycles de vie du déploiement, plusieurs niveaux de persistance doivent être considérés :

1. Métadonnées (PostgreSQL) : Il faut distinguer la configuration (Consul) des métadonnées (utilisateurs, permissions, rapports). Ces dernières sont stockées dans le SAS Infrastructure Data Server (PostgreSQL). Elles sont persistantes et constituent la cible principale des sauvegardes officielles de Viya.
2. Configuration Statique (Ansible) : Pour qu'une nouvelle propriété de configuration soit permanente, elle doit être ajoutée au fichier sitedefault.yml (ou un autre fichier de configuration Ansible pertinent) avant l'exécution du déploiement ou de la mise à jour.
3. Modification documentée : Si une valeur existante est modifiée via SAS Environment Manager, ce changement doit être rigoureusement documenté et considéré comme faisant partie de l'état de la plateforme. Il faut s'assurer qu'aucun playbook Ansible ne viendra la réinitialiser à sa valeur par défaut.

Le Flux de configuration Non-Spring

Attardons-nous sur le schéma ci-dessous, extrait de la documentation SAS. Il illustre parfaitement le mécanisme de mise à jour pour un service non-basé sur Spring, qui ne peut pas lire dynamiquement les changements dans Consul.

• Un administrateur utilise l'interface SAS Environment Manager pour modifier une instance de configuration, MyDef.
• Il modifie la Property B, changeant sa valeur de 20 à 30.
• SAS Environment Manager envoie cette modification Consul. La nouvelle valeur (Property B: 30) est enregistrée dans le registre Clé-Valeur (la base de données MyDef2).
• Le service "cible" (qui n'est pas basé sur Spring) n'est pas conscient de ce changement. C'est là que le consul-template daemon entre en jeu. Ce processus surveille activement le SAS Configuration Server pour détecter les changements.
• Le consul-template daemon détecte que Property B a changé. Il va alors lire la nouvelle configuration depuis Consul et l'utiliser pour régénérer le fichier de configuration statique (Server Configuration File) sur le système de fichiers du serveur (en bas à droite).
• Le service associé à ce fichier de configuration ne prendra en compte la nouvelle valeur (Property B: 30) qu'après avoir été redémarré manuellement, car il ne lit ce fichier qu'à son démarrage.

Ce schéma met également en évidence que le SAS Infrastructure Data Server (PostgreSQL) est un composant distinct, gérant les métadonnées (utilisateurs, permissions) et non ce flux de configuration de service.

Conclusion

La gestion de la configuration dans SAS Viya 3.5 requiert de comprendre cette dualité. Les modifications via kv write dans Consul sont efficaces pour des ajustements immédiats, mais elles restent volatiles si elles ne sont pas intégrées dans les processus de déploiement Ansible.

Une administration rigoureuse implique de synchroniser les modifications dynamiques nécessaires avec la configuration statique définie dans les fichiers de déploiement pour garantir la stabilité et la prévisibilité de l'environnement.

Pour aller plus loin...

• SAS Viya 3.5 Administration: Infrastructure Servers (Documentation SAS) : Sur le rôle du SAS Configuration Server (Consul).
• SAS Viya 3.5 Administration: Configuration Properties Concepts (Documentation SAS) : Sur le fonctionnement des KV Write et la différence Spring / Non-Spring.
• Documentation Officielle de Consul (HashiCorp) : Pour comprendre la technologie sous-jacente.
  • Qu'est-ce que Consul ?
  • Documentation du KV Store de Consul