Qu'est-ce qui ne devrait PAS être géré par la marionnette?


67

Je suis en train de me familiariser avec la gestion de la configuration en général et d'utiliser puppet pour l'implémenter en particulier. Je me demande quels aspects d'un système, le cas échéant, ne devraient pas être gérés avec marionnette?

Par exemple, nous prenons pour acquis que les noms d’hôte sont déjà configurés avant de prêter le système à la gestion de marionnettes. La connectivité IP de base, du moins sur le réseau utilisé pour atteindre le maître de marionnettes, doit fonctionner. Utiliser puppet pour créer automatiquement des fichiers de zone DNS est tentant, mais les pointeurs inverses DNS doivent déjà être en place avant de démarrer la chose, sinon les certificats vont être amusants.

Alors, devrais-je laisser la configuration IP de la marionnette? Ou devrais-je le configurer avant de démarrer marionnette pour la première fois mais gérer néanmoins les adresses IP avec marionnette? Qu'en est-il des systèmes avec plusieurs adresses IP (par exemple, pour WAN, LAN et SAN)?

Qu'en est-il d' IPMI ? Vous pouvez configurer la plupart, sinon la totalité, avec ipmitool , ce qui vous évite d’obtenir un accès à la console (physique, KVM distant, KVM distant, etc.) afin de pouvoir l’automatiser à l’aide de Puppet. Mais revérifier son état à chaque exécution d’agent de marionnettes ne me semble pas très cool, et j’aimerais avoir un accès basique au système avant de faire autre chose.

Une autre histoire concerne l'installation de mises à jour. Je ne vais pas dans ce point précis, il y a déjà beaucoup de questions sur SF et beaucoup de philosophies différentes entre différents administrateurs système. Moi-même, j’ai décidé de ne pas laisser marionnette mettre à jour les choses (p. Ex. Seulement ensure => installed) et de faire les mises à jour manuellement comme nous y sommes habitués, laissant l’automatisation de cette tâche à plus tard, lorsque nous aurons plus confiance en marionnettes (par exemple en ajoutant MCollective à le mélange).

Ce ne sont là que quelques exemples qui me viennent à l’esprit. Y a-t-il un aspect du système qui devrait être laissé hors de portée de la marionnette? Ou, dit autrement, où est la ligne de démarcation entre ce qui devrait être configuré au moment du provisionnement et celui configuré "de manière statique" dans le système, et ce qui est géré par la gestion centralisée de la configuration?


1
Bonne question. Je suis moi-même curieux de savoir s'il y a autre chose que des configurations spécifiques à une machine pour lesquelles vous ne devriez pas utiliser de marionnette. Eh bien, cela et les machines Windows.
HopelessN00b

6
<vague> Vous ne devriez pas gérer les choses dans la marionnette quand il est mieux / plus facile de les gérer d'une autre manière. </ vague>: p
Zoredache

1
Avec la prédominance des entreprises utilisant Puppet ces jours-ci, je peux voir que cette question suscite beaucoup d'attention au cours des prochaines années
Daniel Li

Réponses:


24

Règle générale: Si vous utilisez la gestion de la configuration, gérez chaque aspect de la configuration possible. Plus vous centralisez, plus il sera facile de faire évoluer votre environnement.

Exemples spécifiques (tirés de la question, tous les récits "Voici pourquoi vous voulez le gérer"):


Configuration du réseau IP

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 le faisiez pas, comment courriez-vous la marionnette pour faire le reste de la configuration?

Mais disons maintenant 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 supposez que votre société soit acquise et que votre nouvelle société mère vous demande de passer de votre adresse 192.168.0.0/24 à 10.11.12.0/24 pour l’intégrer dans leur système de numérotation.

Ou alors vous obtenez soudainement un contrat gouvernemental massif - Le seul problème est que vous devez activer IPv6 RIGHT FREAKIN 'NOW ou le contrat est annulé ...

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


Configuration IPMI

Tout comme pour les adresses IP, je suis sûr que vous avez défini cette configuration avant de placer la machine dans le rack: il est judicieux d'activer IPMI, une console distante, etc. sur toute machine dotée de cette capacité, et ces configurations ne ne change pas beaucoup ...

... 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 que vous devez mettre à jour toutes vos cartes IPMI. MAINTENANT, car ils vont piétiner l'espace IP réservé de quelqu'un.

OK, c'est un peu exagéré ici, mais comme vous l'avez dit - tout peut être géré avec ipmitool, alors pourquoi ne pas laisser Puppet exécuter l'outil et confirmer la configuration pendant qu'il effectue toutes ses tâches? Je veux dire que ça ne fera pas de mal, alors nous pouvons aussi inclure IPMI aussi ...


Mises à jour

Les mises à jour logicielles constituent davantage une zone grise. Dans mon organisation, nous avons évalué marionnette et nous avons constaté que celle-ci "faisait cruellement défaut". Nous l'utilisons donc radmindà cette fin. Il n'y a aucune raison pour que Puppet ne puisse pas appeler radmind - En fait, si nous migrons vers Puppet pour la gestion de la configuration, c'est exactement ce qui va se passer!

L'important est d'installer toutes vos mises à jour de manière standard (standard dans l'ensemble de l'entreprise ou standard sur les plates-formes). Il n'y a aucune raison pour que Puppet ne lance pas votre processus de mise à jour, tant que vous avez testé minutieusement tout pour que Puppet ne gâche rien.
Il n'y a 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 du bon travail tout seul ...


Re: Mises à jour. Une chose qui peut vous causer des problèmes avec puppet lors de l’exécution de vos mises à jour, c’est lorsque le service essentiel est corrigé, par exemple: mysql, apache - vous ne voulez pas que ceux-ci redémarrent par caprice. Puppet fournit des moyens de verrouiller la version de ces packages, c'est pourquoi je l'ai évité tout en bénéficiant de mises à jour générales pour d'autres éléments de base.
Thinice

@thinice C'est un bon point, mais mon contrepoint habituel est de frapper les gens sur le dos de la tête et de crier REDUNDANCY vraiment très fort :-) demandez à l'équilibreur de charge de décharger la moitié des serveurs afin de pouvoir les corriger, puis de transférer tout le monde sur les machines corrigées afin que nous puissions effectuer l'autre moitié. Fonctionne bien, mais vous avez besoin de la redondance intégrée à votre environnement.)
voretaq7

10

Ne réinventez pas la roue.

Oui, vous pouvez disposer de 50 ressources utilisateur virtuel de marionnettes et les réaliser au besoin dans vos modules ... mais si vous le pouvez, utilisez LDAP.

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

Un autre exemple consiste à extraire des fichiers hôtes, plutôt que d'utiliser simplement DNS.


3
Je reconnais tous ces mots, mais je ne suis toujours pas sûr de ce que vous essayez de dire.
Chris S

2
J'essaie de dire; La marionnette est un lieu central "d'information". Il en va de même pour DNS et LDAP. N'essayez pas de faire leur travail avec des marionnettes, c'est épouvantable ... Je dis ceci après avoir vu des fichiers géants / etc / hosts être expulsés avec des marionnettes chaque fois qu'un nouvel hôte rejoint le réseau.
Sirex

3
Les gens utilisent-ils vraiment Puppet au lieu de LDAP pour gérer les comptes d'utilisateurs?
Joel E Salas

2
Chaque outil a sa place, mais l'utilisation de marionnette pour la gestion de compte d'utilisateur ou de LDAP pour le stockage de fichiers est abusive .
Hubert Kario

1
C'est certainement un usage ab ...
jldugger

9
  • La marionnette n'est pas un système d'orchestration. En particulier:
    • Puppet ne convient pas à l'orchestration des machines virtuelles, car celles-ci ont un cycle de vie qui doit être respecté.
    • Puppet n'est pas bien adapté à la gestion des versions d'application / aux mises à niveau complexes. Les marionnettes autonomes pourraient être exploitées à cette fin, mais au moins, ce n’est pas le contrôle de Puppet, ce sont 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 d'utilisateur, même les utilisateurs supprimés, pour être efficace. Trouvez donc une autre solution)
  • La marionnette n'est pas une bonne base de données de configuration (envisagez d'utiliser une base de données externe et 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 eux. Parfois, vous devriez poser le marteau et aller chercher une clé.

Puppet est toutefois extrêmement efficace pour maintenir la configuration de base d'une machine et pour installer les outils vous permettant d'effectuer la VM et de publier l'orchestration, la gestion des utilisateurs, etc.


Plus qu'un petit problème: Puppet peut être configuré pour ajouter et supprimer des utilisateurs avec ou sans gestion de chaque utilisateur. Cela dit ... il est en quelque sorte inutile de ne pas gérer tous les utilisateurs et terrible de gérer tous les utilisateurs. J'utilise puppet pour ajouter des comptes de service, mais pas des comptes d'utilisateurs.
Art Hill

2

Je suis principalement d'accord avec voretaq7, mais avec quelques réserves.

  • Je configure rarement l'adressage IP dans marionnette, à moins que le système utilise DHCP (je suppose que la plupart des grands fournisseurs de "cloud" le font). J'ai eu des situations où je cassais des configurations de réseau avec marionnette, mais ne pouvais pas les corriger avec marionnette car le nœud n'avait aucun moyen de contacter le maître des marionnettes.

  • Je suis plutôt convaincu que la gestion des mises à jour appartient aux outils système, et je ne pense pas que l'utilisation de marionnette en tant que client glorifié soit une amélioration.


1

Dans mon cas, j'ai un script d'amorçage qui charge la configuration système minimale (Ubuntu): Ruby, Rubygems, build-essential, git, etc. Mes manifestes Puppet sont conservés sous contrôle de version et je clone simplement le référentiel. À partir de là, mon script de démarrage fait une hypothèse hostname --shortvalide et tente de le faire puppet apply /root/infrastructure/puppet/hosts/$( hostname --short ).pp.

Pour répondre à ta question:

  • Mes scripts reposent sur 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 changez pas;
  • Mes scripts supposent que Ruby / Rubygems / Git est présent, mais le gèrent par la suite.

0

Pensez que vous n'avez pas besoin d'utiliser marionnette pour la configuration du réseau. C'est une fois configuré chose habituellement. Vous pouvez aussi avoir des conneries si vous commettez une erreur avec IP ou MAC ou quelque chose de similaire qui amène par marionnette.


2
Jamais eu à changer la passerelle par défaut sur plus de 100 serveurs à la main? Heureusement que vous;)

@EricDANNIELOU Je suppose que cela pourrait être considéré comme un +1 pour laisser marionnette gérer la configuration IP des interfaces réseau;)
Luke404

@EricDANNIELOU Essayez de faire cela avec bash, le cycle "pour" et les autorisations utilisateur appropriées (sudo vers root ou root directement) et sed / perl / etc. :)
Evgenii Iablokov

1
Je ne pense pas que les scripts bash "pour" cycle et sale sed / awk / vi soient plus sûrs que scm pour la configuration réseau. Et une fois que vous avez configuré les marionnettes pour tout le reste, il n’est pas très pratique d’avoir ssh "pour" en boucle uniquement pour la configuration du réseau.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.