Assertions et contraintes

Je construis un modèle pour créer un fichier de configuration, et le service qui consomme ce fichier impose des contraintes sur les longueurs des identifiants.

Si un identificateur est plus long que, disons, 6 caractères, le service obtiendra une partie de l'application de la configuration, échouera et laissera le nœud dans un état incohérent.

Comment puis-je effectuer une assertion pour déclencher un échec de transaction de déploiement, empêchant ainsi le service des nœuds cibles d'être mal configuré?

Ma circonstance particulière est Salt, mais je serais curieux de voir comment d'autres systèmes résolvent également le problème.

configuration configuration-management linting

— Michael Mol
source

Eh bien, dans le chef, je vais ajouter une règle de peluchage, soit rspec ou foodcritic, soit assurer la correspondance de l'identifiant dans la recette. Aucune idée de sel, je ne pense pas qu'il y ait une réponse gérénique car chaque gestionnaire de configuration a sa propre spécificité

— Tensibai

Je vais modifier la réponse pour être un peu moins spécifique.

— Michael Mol

À l'heure actuelle, ma réflexion actuelle pour une solution Saltstack + Jinja serait une macro qui tente de lire à partir d'un fichier qui ne peut pas exister. Les autres rendus fonctionneraient différemment. Un moteur de rendu Python, par exemple, serait trivial; jetez simplement une exception.

— Michael Mol

Dans Ansible: vous pouvez utiliser assertou failmodule.

- name: "Make sure web_sites is dictionary"
  fail: msg="web_sites should be dictionary"
  when: web_sites is not dict  


- name: "cluster_name should be shorter than 6 chars"
  assert: 
       that: cluster_name|len <= 6

Dans Puppet: il y a une fonction d' échec évaluée pendant la phase d'analyse qui provoque l'échec de l'analyse sur le serveur (voir la question sur StackOverflow )

 if length($cluster_name) > 6 {
      fail("Cluster name is too long. Should be less than 6 chars.")
 }

— Věroš K.
source