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

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?

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 ...

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.

• 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.

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.

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.

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.