71 votes

Qu'est-ce qui ne doit PAS être géré par Puppet ?

Je suis en train de me familiariser avec la gestion de la configuration en général et d'utiliser Marionnette pour le mettre en œuvre en particulier, et je me demande quels aspects d'un système, s'il y en a, devraient no être géré avec Puppet ?

A titre d'exemple, nous prenons 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 de Puppet. La connectivité IP de base, au moins sur le réseau utilisé pour atteindre le puppetmaster, doit fonctionner. Il est tentant d'utiliser Puppet pour créer automatiquement des fichiers de zone DNS, mais les pointeurs inversés DNS doivent être déjà en place avant de démarrer le système, sinon les certificats vont être bizarres.

Dois-je donc supprimer la configuration IP de Puppet ? Ou dois-je la configurer avant de lancer Puppet pour la première fois, tout en gérant les adresses IP avec Puppet ? Qu'en est-il des systèmes avec plusieurs IP (par exemple pour le WAN, le LAN et le SAN) ?

Qu'en est-il IPMI ? Vous pouvez en configurer la plupart, si ce n'est la totalité, avec ipmitool pour vous éviter d'obtenir un accès à la console (physique, série sur réseau, KVM distant, etc.) afin de pouvoir l'automatiser avec Puppet. Mais revérifier son état à chaque exécution de l'agent Puppet ne me semble pas très cool, et l'accès de base au système est quelque chose que j'aimerais avoir avant de faire quoi que ce soit d'autre.

Une autre histoire est celle de l'installation des mises à jour. Je ne vais pas m'étendre sur ce point précis, il y a déjà beaucoup de questions sur SF et beaucoup de philosophies différentes entre les différents administrateurs système. Personnellement, j'ai décidé de ne pas laisser Puppet mettre à jour certaines choses (par exemple, seulement ensure => installed ) et effectuer les mises à jour manuellement comme nous en avons l'habitude, en laissant l'automatisation de cette tâche à un jour ultérieur lorsque nous serons plus confiants avec Puppet (par exemple en ajoutant MCollectif au mélange).

Ce ne sont que quelques exemples qui me viennent à l'esprit en ce moment. Y a-t-il un aspect du système qui devrait être laissé hors de portée de Puppet ? Ou, dit autrement, où se situe la limite entre ce qui doit être mis en place au moment de l'approvisionnement et configuré "statiquement" dans le système, et ce qui est géré par la gestion centralisée de la configuration ?

26voto

voretaq7 Points 78924

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 du type "C'est pourquoi vous voulez le gérer") :


Configuration du réseau IP

OK, bien sûr, vous avez configuré une adresse/une passerelle/NS sur la machine avant de la déposer dans le rack. Je veux dire que si vous ne l'aviez pas fait, comment auriez-vous pu lancer Puppet pour faire le reste de la configuration ?

Mais disons que vous ajoutez un autre serveur de noms à votre environnement et que vous devez mettre à jour toutes vos machines. Ne voulez-vous pas que votre système de gestion de la configuration le fasse pour vous ?

Ou disons que votre entreprise est rachetée, et que votre nouvelle société mère demandes que vous passiez de votre adressage 192.168.0.0/24 à 10.11.12.0/24 pour vous adapter à leur système de numérotation.

Ou vous obtenez soudainement un contrat gouvernemental massif. Le seul problème est que vous devez activer l'IPv6. EN CE MOMENT MÊME ou l'accord est rompu....

On dirait que la configuration du réseau est quelque chose que nous aimerions gérer...


Configuration de l'IPMI

Tout comme pour les adresses IP, je suis sûr que vous avez configuré cela avant de mettre la machine dans le rack - C'est juste du bon sens d'activer l'IPMI, la console à distance, etc. sur toute machine qui en a la capacité, et ces configurations ne changent pas beaucoup...

... Jusqu'à cette acquisition hypothétique que j'ai mentionnée dans Configuration IP ci-dessus -- La raison pour laquelle vous avez été forcé de libérer ces adresses réseau 192.168 est parce que c'est le pays de l'IPMI selon vos nouveaux maîtres, et vous devez aller mettre à jour toutes vos cartes IPMI MAINTENANT parce qu'elles vont piétiner l'espace IP réservé de quelqu'un.

D'accord, c'est un peu tiré par les cheveux, mais comme vous l'avez dit, tout cela peut être géré avec ipmitool Alors pourquoi ne pas demander à Puppet d'exécuter l'outil et de confirmer la configuration pendant qu'il effectue toutes ses autres tâches ? Je veux dire que ça ne va rien faire de mal, alors autant inclure IPMI aussi...


Mises à jour

Les mises à jour logicielles constituent une zone grise -- Dans mon organisation, nous avons évalué Puppet à cet égard et avons constaté qu'il présentait des lacunes importantes. radmind à cette fin. Il n'y a aucune raison pour que Puppet ne puisse pas appeler radmind. En fait, si et quand nous migrerons vers Puppet pour la gestion de la configuration, c'est exactement ce qui se passera !

L'important ici est que toutes vos mises à jour soient installées de manière standard (soit standard dans l'ensemble de l'organisation, soit standard au sein des plates-formes). Il n'y a aucune raison pour que Puppet ne lance pas votre processus de mise à jour, à condition que vous ayez tout testé en profondeur pour vous assurer que Puppet ne gâche rien.
Il n'y a pas non plus de 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...

11voto

Sirex Points 5377

Ne réinventez pas la roue.

Oui, vous pouvez avoir 50 ressources utilisateurs virtuelles Puppet et les réaliser selon les besoins dans vos modules... mais si vous le pouvez, utilisez LDAP.

Je parle d'une expérience amère. Bien que ldap ne soit pas une option ici, pour le moment.

Un autre exemple est la diffusion de fichiers d'hôtes, au lieu d'utiliser simplement le DNS.

8voto

  • Puppet n'est pas un système d'orchestration. En particulier :
    • Puppet n'est pas bien adapté à l'orchestration des VM, car celles-ci ont un cycle de vie propre qui doit être respecté.
    • Puppet n'est pas bien adapté à la gestion des versions des applications et aux mises à niveau complexes. Les exécutions autonomes de Puppet pourraient être exploitées pour cela, mais alors au moins ce n'est pas Puppet qui contrôle, à la place c'est votre wrapper scripts 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 l'entrée des utilisateurs, même ceux qui ont été supprimés, pour être efficace. Trouvez donc une autre solution)
  • Puppet n'est pas une bonne base de données de configuration (envisagez l'utilisation d'une base de données externe de quelque sorte, et d'une colle ENC, Hiera ou similaire)

Bien sûr, vous pouvez faire toutes ces choses avec Puppet mais ce n'est tout simplement pas la meilleure solution pour elles. Parfois, vous devriez poser le marteau, et aller chercher une clé à molette.

Puppet est cependant très efficace pour maintenir la configuration de base d'une machine et installer les outils qui vous permettent d'orchestrer les VM et les versions, de gérer les utilisateurs, etc.

2voto

Dans mon cas, j'ai un bootstrap script qui charge la configuration minimale du système (Ubuntu) : Ruby, Rubygems, build-essential, git, etc. Mes manifestes Puppet sont conservés sous contrôle de version, et je clone simplement le dépôt. A partir de là, mon bootstrap script fait l'hypothèse que hostname --short est valide, et tente de puppet apply /root/infrastructure/puppet/hosts/$( hostname --short ).pp .

Pour répondre à votre question :

  • Mes scripts supposent une connectivité réseau de base (DNS, IP), et ne la gèrent pas ou ne la modifient pas ;
  • Mes scripts supposent que l'identité de la machine est correcte, et ne la modifient pas ;
  • Mes scripts partent du principe que Ruby / Rubygems / Git est présent, mais faire le gérer par la suite.

2voto

Paul Gear Points 3883

Je suis en grande partie d'accord avec voretaq7, mais avec quelques réserves.

  • Je configure rarement l'adressage IP dans Puppet, à moins que le système n'utilise le DHCP (je suppose que la plupart des grands fournisseurs de "nuages" le font). Il m'est arrivé de casser des configurations réseau avec Puppet, mais de ne pas pouvoir les corriger avec Puppet parce que le nœud n'avait aucun moyen de contacter le puppetmaster.

  • Je suis fermement convaincu que la gestion des mises à jour doit être confiée aux outils du système, et je ne pense pas qu'utiliser Puppet comme un cron glorifié soit une amélioration.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X