Blocs réutilisables d’arguments et d’environnement¶
Disponible depuis Auton 1.5.0 et 2.0.0rc3.
Un endpoint peut déclarer import_config et toute combinaison des six imports suivants :
Import |
Paramètre chargé |
Contenu du fichier |
|---|---|---|
|
|
Liste de chaînes conservant l’ordre et les doublons |
|
|
Mapping des noms de variables d’environnement vers des chaînes |
|
|
Booléen, liste de noms d’options ou mapping de règles |
|
|
Booléen ou liste de noms d’options |
|
|
Booléen, liste de noms de variables ou mapping de règles |
|
|
Booléen ou liste de noms de variables |
Utilisez la même syntaxe que pour les règles client en ligne. Le fichier importé contient directement la valeur, sans enveloppe args: ou allow-args:. Par exemple, un fichier allow-args.yml peut contenir :
- month
Cela autorise une occurrence de --month VALUE ou --month=VALUE. Voici un fichier plus sélectif :
month:
regex: '20[0-9]{2}-(0[1-9]|1[0-2])'
repeatable: true
Niveaux d’import autorisés¶
Une configuration principale ou un catalogue déclare les endpoints. Chaque endpoint peut importer une configuration. Celle-ci peut importer plusieurs blocs différents, notamment les six ci-dessus, mais pas une autre configuration, des variables, des utilisateurs, des modules ou un catalogue d’endpoints. Tous les blocs sont au même niveau. Aucun ne peut contenir d’import, même imbriqué dans une liste ou un mapping. Les clés d’import réservées ne peuvent donc pas servir de noms de variables d’environnement ou de règles dans ces blocs.
Les imports de blocs peuvent aussi être écrits directement à côté de plugin ou dans config en ligne. Chaque directive accepte un nom de fichier local non vide, pas une URL ni une liste de fichiers. Les chemins relatifs partent du répertoire du fichier déclarant l’import, après résolution des liens symboliques vers le fichier réel. Ils ne dépendent pas du répertoire de travail du démon.
Priorités¶
La configuration importée fournit les paramètres initiaux. Les imports de blocs déclarés directement sur l’endpoint les remplacent. Le config en ligne remplace les deux. Dans une configuration, une valeur explicite comme allow-args remplace le résultat de import_allow_args. Le remplacement concerne le bloc entier, mappings et listes compris : utilisez [], {} ou false selon le cas pour effacer une valeur. Il n’y a ni concaténation de listes ni fusion récursive des mappings. Cela évite qu’une restriction en ligne conserve accidentellement des permissions d’une liste partagée. Chaque import déclaré est chargé et validé, même si sa valeur sera remplacée.
Chargement et erreurs¶
Les blocs sont des données YAML simples, sans rendu Mako ni balises d’inclusion exécutables. import_config conserve ses modèles Mako contrôlés par l’administrateur et les vars précédemment chargées ; ces modèles sont du code de confiance. Les chaînes d’arguments et d’environnement fixes conservent leur formatage habituel à l’exécution.
Les fichiers absents, types ou règles invalides, clés YAML en double, imports imbriqués interdits, alias YAML récursifs et imbrications excessives provoquent une erreur de configuration au démarrage. La source d’un bloc est limitée à 1 Mio et 32 niveaux de conteneurs. Les diagnostics identifient le bloc ou le chemin sans afficher les valeurs des arguments ou de l’environnement. La résolution se termine avant l’initialisation des plugins d’endpoints. Redémarrez le démon après modification de ces fichiers ; les paramètres chargés sont des instantanés, pas des lectures à chaque requête.
Le vérificateur de migration hors ligne n’exécute jamais les modèles des composants. Si les permissions effectives dépendent d’un import, il demande une vérification manuelle et émet par précaution les avertissements de permissions absentes. Confirmez les règles effectives au démarrage avant de migrer.
Les imports n’accordent aucun accès client à eux seuls. Les args et env fixes restent des paramètres serveur, tandis que allow-* et disallow-* régissent les ajouts du client.
