Qu'est-ce qui ne devrait PAS être géré par une marionnette?
J'apprends mon chemin à travers la gestion de la configuration en général et j'utilise marionnette pour l'implémenter en particulier, et je me demande quels aspects d'un système, le cas échéant, devraient ne pas être géré avec une marionnette?
À titre d'exemple, nous tenons généralement pour acquis que les noms d'hôtes sont déjà configurés avant de prêter le système à la gestion des marionnettes. La connectivité IP de base, au moins sur le réseau utilisé pour atteindre le marionnettiste, doit fonctionner. L'utilisation de marionnettes pour créer automatiquement des fichiers de zone DNS est tentante, mais les pointeurs inverses DNS devraient être déjà en place avant de démarrer la chose ou les certificats vont être amusants.
Dois-je donc exclure la configuration IP de la marionnette? Ou devrais-je le configurer avant de démarrer la marionnette pour la première fois mais gérer les adresses IP avec la marionnette néanmoins? Qu'en est-il des systèmes avec plusieurs IP (par exemple pour WAN, LAN et SAN)?
Qu'en est-il de IPMI ? Vous pouvez en configurer la plupart, sinon la totalité, avec ipmitool , vous évitant ainsi d'avoir accès à la console (physique, série sur réseau local, KVM distant, etc.) afin qu'il puisse être automatisé avec marionnette. Mais revérifier son état à chaque exécution d'agent de marionnettes ne me semble pas cool, et les lumières de base sur l'accès au système sont quelque chose que j'aimerais avoir avant de faire quoi que ce soit d'autre.
Une autre histoire concerne l'installation des mises à jour. Je ne vais pas dans ce point spécifique, il y a déjà beaucoup de questions sur SF et beaucoup de philosophies différentes entre les différents administrateurs système. Moi-même, j'ai décidé de ne pas laisser les marionnettes mettre à jour les choses (par exemple, seulement ensure => installed) et faire les mises à jour manuellement comme nous sommes déjà habitués, laissant l'automatisation de cette tâche à un jour ultérieur lorsque nous serons plus confiants avec la marionnette (par exemple en ajoutant MCollective au mix).
Ce ne sont là que quelques exemples que j'ai en tête en ce moment. Y a-t-il un aspect du système qui devrait être laissé hors de portée de la marionnette? Ou, d'une autre manière, où se situe la frontière entre ce qui doit être configuré au moment de l'approvisionnement et configuré "statiquement" dans le système, et ce qui est géré par une gestion de configuration centralisée?
Règle générale: Si vous utilisez la gestion de la configuration, gérez tous les aspects de la configuration que vous pouvez. Plus vous centraliserez, plus il sera facile de faire évoluer votre environnement.
Exemples spécifiques (tirés de la question, tous les récits "C'est pourquoi vous voulez le gérer"):
Configuration du réseau IP
OK, bien sûr, vous avez configuré une adresse/passerelle/NS sur la machine avant de la déposer dans le rack. Je veux dire, si vous ne l'avez pas fait, comment courriez-vous la marionnette pour faire le reste de la config?
Mais disons maintenant que vous ajoutez un autre serveur de noms à votre environnement et que vous devez mettre à jour toutes vos machines - Vous ne voulez pas que votre système de gestion de configuration le fasse pour vous?
Ou dites que votre entreprise est acquise et que votre nouvelle société mère exige que vous passiez de votre adresse 192.168.0.0/24 à 10.11.12.0/24 pour l'adapter dans leur système de numérotation.
Ou vous obtenez soudainement un contrat gouvernemental massif - Le seul problème est que vous devez activer IPv6 FREAKIN 'NIGHT ou l'affaire est soufflée ....
On dirait que la configuration du réseau est quelque chose que nous aimerions gérer ...
Configuration IPMI
Tout comme avec les adresses IP, je suis sûr que vous avez configuré cela avant de mettre la machine dans le rack - Il est juste de bon sens d'activer IPMI, la console distante, etc. sur toute machine qui a la capacité, et ces configurations ne ne change pas grand chose ...
... Jusqu'à cette acquisition hypothétique que j'ai mentionnée dans la configuration IP ci-dessus - La raison pour laquelle vous avez été obligé de quitter ces adresses 192.168-net est parce que c'est IPMI-land selon vos nouveaux suzerains d'entreprise, et vous devez aller mettre à jour toutes vos cartes IPMI MAINTENANT parce qu'ils vont piétiner l'espace IP réservé à quelqu'un.
OK, c'est un peu compliqué ici, mais comme vous l'avez dit - tout cela peut être géré avec ipmitool, alors pourquoi ne pas laisser Puppet exécuter l'outil et confirmer la configuration pendant qu'il fait toutes ses autres tâches? Je veux dire que ça ne va rien faire de mal, donc nous pouvons aussi bien inclure IPMI ...
Mises à jour
Les mises à jour logicielles sont plus une zone grise - Dans mon organisation, nous avons évalué la marionnette pour cela et l'avons trouvée "manquant cruellement", nous utilisons donc radmind à cet effet. Il n'y a aucune raison pour que Puppet ne puisse pas appeler radmind - En fait, si/quand nous migrons vers Puppet pour la gestion de la configuration, c'est exactement ce qui va se passer!
L'important ici est d'avoir toutes vos mises à jour installées de manière standard (soit standard dans toute l'organisation, soit standard dans les plates-formes) - Il n'y a aucune raison que Puppet ne devrait pas lancer votre processus de mise à jour, tant que vous avez soigneusement testé tout pour que Puppet ne gâche rien.
Il n'y a également aucune raison pour que Puppet ne puisse pas faire appel à un outil mieux adapté à cette tâche si vous avez déterminé que Puppet ne peut pas faire un bon travail tout seul ...
Ne réinventez pas la roue.
Oui, vous pouvez avoir 50 ressources utilisateur virtuel fantoche et les réaliser au besoin dans vos modules ... mais si vous le pouvez, utilisez LDAP.
Je parle d'une expérience amère. Bien que ldap ne soit pas encore une option ici.
Un autre exemple consiste à extraire les fichiers hôtes, plutôt que d'utiliser simplement DNS.
- Puppet n'est pas un système d'orchestration. En particulier:
- Puppet n'est pas bien adapté à l'orchestration VM, car les machines virtuelles ont leur propre cycle de vie qui doit être respecté.
- Puppet n'est pas bien adapté à la gestion des versions d'application/aux mises à niveau complexes. Des marionnettes autonomes pourraient être exploitées pour cela, mais au moins ce n'est pas Puppet en contrôle, mais plutôt vos scripts wrapper ou un robot humain, ce qui est bien.
- Puppet n'est pas un bon système de gestion des utilisateurs (il doit gérer chaque entrée utilisateur, même les utilisateurs supprimés, pour être efficace. Alors, trouvez une autre solution)
- Puppet n'est pas une bonne base de données de configuration (envisagez d'utiliser une base de données externe quelconque et une ENC, Hiera ou une colle similaire)
Bien sûr, vous pouvez faire toutes ces choses avec Puppet .. mais ce n’est tout simplement pas la meilleure solution pour eux. Parfois, vous devez poser le marteau et aller chercher une clé.
Puppet est cependant extrêmement bon pour maintenir la configuration de base d'une machine et installer les outils qui vous permettent de faire VM et libérer l'orchestration, la gestion des utilisateurs, etc.
Je suis principalement d'accord avec voretaq7, mais avec quelques mises en garde.
Je configure rarement l'adressage IP en marionnette, à moins que le système n'utilise DHCP (je suppose que la plupart des grands fournisseurs de "cloud" le font). J'ai eu des situations où j'ai cassé des configurations de réseau avec marionnette, mais je n'ai pas pu les corriger avec marionnette car le nœud n'avait aucun moyen de contacter le marionnettiste.
Je suis assez convaincu que la gestion des mises à jour appartient aux outils système, et je ne vois pas l'utilisation de marionnettes comme un cron glorifié comme une amélioration.
Dans mon cas, j'ai un script bootstrap qui charge la configuration système minimale (Ubuntu): Ruby, Rubygems, build-essential, git, etc. Mes manifestes Puppet sont gardés sous contrôle de version, et Je clone simplement le référentiel. À partir de là, mon script bootstrap fait l'hypothèse que hostname --short Est valide et tente de puppet apply /root/infrastructure/puppet/hosts/$( hostname --short ).pp.
Pour répondre à ta question:
- Mes scripts supposent une connectivité réseau de base (DNS, IP) et ne la gèrent ni ne la modifient;
- Mes scripts supposent que l'identité de la machine est correcte et ne la change pas;
- Mes scripts supposent Ruby/Rubygems/Git est présent, mais do le gère ensuite.
Pensez que vous n'avez pas besoin d'utiliser une marionnette pour la configuration du réseau. C'est une fois une chose configurée habituellement. Vous pouvez également obtenir de la merde si vous avez une ou des erreurs avec IP ou MAC ou quelque chose de similaire qui apportera une marionnette.