Découverte de noeuds zéro de couteau

Question

Je fais connaissance avec le chef et je veux construire mon flux de travail sans serveur central (en utilisant zéro chef et zéro couteau). Tout fonctionne bien, cependant, chef-zéro stocke des informations sur les nœuds dans les fichiers .json qui sont assez volumineux et trop souvent modifiés pour être stockés dans le dépôt git, et je voudrais réanalyser les serveurs chaque jour ouvrable plutôt que de stocker leurs définitions dans le référentiel - Cela devrait être facilement automatisable car nous n'avons pas beaucoup de serveurs. Existe-t-il une commande qui me permettrait d'ajouter des nœuds convergents existants à zéro-chef en fournissant simplement leurs informations d'identification ssh? Je sais que knife zero bootstrap <node-ip> fera l'affaire, mais cela déclenche aussi des convergences supplémentaires que je ne veux pas avoir.

Answer 1

La question était basée autour des hypothèses erronées:

• Je pensais que le noeud de chef persiste et gère son propre état. Ce n'est pas. L'état du nœud est sérialisé à la fin de l'exécution par le chef et transmis au serveur, il n'est donc pas possible de redécouvrir le nœud alors que je tentais sans chef. Si vous avez besoin d'attributs de serveur, vous pouvez essayer de faire converger un nœud avec une liste de lancement vide; Puisque les listes d'exécution ne sont pas conservées sur le nœud lui-même, ceci devrait être une opération sûre.
• Je pensais également que chef-zéro est en quelque sorte gérer l'état du nœud d'une autre manière que d'utiliser des fichiers json. C'est la raison pour laquelle j'ai essayé de spécifier directement les rôles de nœuds dans json alors qu'ils sont constamment reconstruits à partir de run_list, donc j'étais confus de voir mes rôles ne pas s'appliquer; cela fait "découverte" dont je parlais pas du tout nécessaire.

La structure suivante est suffisante pour le chef de zéro pour voir le noeud et convergent avec succès:

{ 
    "name": "sonarqube.srv.company.my", 
    "automatic": { 
    // automatic attributes are managed by ohai, so be ready that next 
    // chef run may use another fqdn if you haven't pinned it with 
    // any means possible 
    "fqdn": "99-199-255-99.srv.company.my" 
    }, 
    "run_list": [ 
    "role[role-1]" 
    "recipe[cookbook::recipe]" 
    ] 
} 

Si vous stockez des définitions comme ça dans git, vous avez toujours votre infrastructure à portée de main et peut faire knife converge name:sonarqube.srv.company.my à tout moment, et cela bat tous mes besoins. Mon flux de travail personnel contient le répertoire managed-nodes avec des spécifications de noeud comme ci-dessus qui écrase le répertoire nodes sur bin/reset script bash inclus. Tant que je les garde stockés avec des listes de course et des attributs, tout fonctionne comme un charme. Cependant, si vous choisissez un flux de travail similaire, souvenez-vous que vous n'avez pas besoin de liste complète d'attributs sans que le chef ne fonctionne correctement sur le noeud.

La nécessité d'un flux de travail de chef purement git sans serveur persistant est dictée par des raisons internes que je voudrais ne pas divulguer. _{^{Ok, je voulais juste idempotent ansible.}}

Félicitations à @Tensibai pour tous ses efforts.

Answer 2

Juste pour être clair, vous décrivez simplement la fabrication de votre propre (mauvais) chef serveur. Si vous voulez une gestion centralisée, vous devriez probablement utiliser Chef Server et vous épargner du temps :)