Pourquoi utiliser les scripts Chef / Puppet over shell?


81

Nouveau sur les outils Marionnette et Chef. On dirait que le travail qu'ils font peut être fait avec des scripts shell. Peut-être que cela a été fait dans des scripts shell jusqu'à ce qu'ils arrivent.

Je conviendrais qu'ils sont plus lisibles. Mais y at-il d’autres avantages que les scripts shell en plus d’être lisibles?

Réponses:


56

Un langage spécifique à un domaine fait une grande différence dans la quantité de code que vous écrivez. Par exemple, vous pouvez affirmer qu'il n'y a pas beaucoup de différence entre:

chmod 640 /my/file

et

file { "/my/file":
    mode => 640,
}

mais il y a beaucoup de différence entre ceux-ci:

FILE=/my/file
chmod 640 $FILE
chown foo $FILE
chgrp bar $FILE
wget -O $FILE "http://my.puppet.server/dist/$FILE"
     # where the URL contains "Hello world"

et

file { "/my/file":
    mode => 640,
    owner => foo,
    group => bar,
    content => "Hello world",
}

Que se passe-t-il si le wget échoue? Comment votre script va-t-il gérer cela? Et que se passe-t-il si quelque chose après cela dans votre script requiert que $ FILE soit présent avec le contenu correct?

Vous pourriez faire valoir que l'on pourrait simplement insérer echo "Hello world" > $FILEle script, sauf que dans le premier exemple, le script doit être exécuté sur le client, alors que puppet compile tout cela sur le serveur. Ainsi, si vous modifiez le contenu, il vous suffit de le modifier sur le serveur et de le modifier pour autant de systèmes que vous le souhaitez. Et puppet gère automatiquement les dépendances et les problèmes de transfert.

Il n'y a aucune comparaison possible: des outils de gestion de la configuration appropriés vous font gagner du temps et de la complexité. Plus vous essayez de faire, plus les scripts shell semblent inadéquats, et plus vous économiserez des efforts en le faisant avec puppet.


9
@ Paul Gear, il est simpliste de dire que les outils de gestion de la configuration sont la voie à suivre à long terme. Par exemple, en utilisant AWS, un script de shell peut créer le serveur à partir de zéro, exécuter des tests et, une fois que vous êtes certain que les instances AWS sont correctes, créez une image. Vous pouvez ensuite déployer cette image dans un environnement de prévisualisation ou intermédiaire pour des tests supplémentaires. Une fois que vous validez l'image, vous passez à la production. Les outils de gestion de la configuration n’aident pas du tout dans ce scénario.
Derek Litz

Maintenant, si vous voulez gérer des centaines de serveurs dédiés que les utilisateurs utilisent quotidiennement (et que vous avez peu de contrôle sur ce qu'ils font, à tort ou non), vous devez utiliser des outils de gestion de la configuration.
Derek Litz

6
Ce n'est pas un exemple très convaincant. Je pourrais commencer par wget et je ne finirais pas dans un état étrange. Le fichier est-il comme une transaction qui sera annulée si l'une des étapes échoue?
PSkocik

33

Ce sera un avis impopulaire, mais les systèmes de gestion de la configuration ne sont pas nécessairement meilleurs. Parfois, simple est vraiment le meilleur.

La courbe d’apprentissage et les frais administratifs sont associés au système de configuration choisi. Après tout, vous introduisez une dépendance. Comme pour toute automatisation, vous devez également veiller à ce que la sécurité soit maintenue dans les configurations déployées.

Je n'ai eu que quelques cas où nous avons déployé la gestion de la configuration et cela a été bloqué. C'était toujours le cas quand il y avait un grand nombre de systèmes avec une configuration répétitive et qu'il était nécessaire d'effectuer des déploiements configurables de type cookie.


10
Lorsque les coûts de gestion de l'environnement sont si élevés, la gestion de l'automatisation est vraiment moins chère. S'il est plus simple de scripter les modifications gérées dans Git ou de configurer un multiplexeur SSH, nous le faisons. Le plus important pour moi est de surveiller les systèmes et de vérifier que tout fonctionne comme prévu. Tant que je suis alerté lorsque quelque chose est mal configuré, la manière dont il est configuré n'a pas d'importance.
Kenchilada

10
@ewwhite "Quand décidez-vous d'automatiser ou non?" xkcd.com/1205
MikeyB

3
Des outils plus modernes, tels que Ansible, ont considérablement moins de temps de déploiement / gestion que Chef ou Puppet, ne nécessitant que peu ou pas de dépendances (Ansible, en particulier, est sans agent). Cela abaisse vraiment la barre pour l'adoption.
GomoX

2
@ewwhite Vous automatisez quand vous voulez pour votre productivité personnelle. Vous apprenez en automatisant, vous n'apprenez pas en effectuant des tâches banales. Apprentissage = augmentation de la productivité et amélioration itérative. L'automatisation se combine à cela pour produire plus de points positifs. C'est une boule de neige positive au lieu d'une boule de neige négative. Progrès technique vs dette technique.
Derek Litz

2
@ABB Non, ce n'est pas implicite. Je ne mentionne même pas les scripts shell, je mentionne l'automatisation en tant que pratique générale. Vous pouvez automatiser des tâches à l'aide de scripts shell et apprendre l'abstraction de script au lieu de procéder manuellement, ce qui vous évitera non seulement de reprendre la tâche, mais vous évitera des erreurs. En outre, vous devriez pouvoir écrire votre prochain script un peu mieux que le dernier. Une boule de neige positive ... Cependant, si vous êtes un expert en écriture de scripts et que vous n'écrivez pas quelque chose que vous ferez de nouveau, cela ne vous aidera pas à apprendre ni à vous faire gagner du temps.
Derek Litz

23

Vous avez répondu à votre propre question ...

L'automatisation devient de plus en plus évolutive et formalisée . La marionnette et le chef sont considérés comme des standards de nos jours (consultez les offres d'emploi ).

Les scripts shell co-liés ont leur place, mais ils ne sont pas évolutifs dans le contexte du mouvement DevOps. La lisibilité en fait partie.


7
Les scripts de shell sont-ils en quelque sorte moins formalisés? Citer des offres d'emploi rend-il un argument convaincant? Et un devops est une honte, car il est sous-exploité en tant que développeur. Le lien ne dit rien vraiment sur l'évolutivité. Est-ce que l'affirmation que les scripts shell ne sont pas évolutifs? Je pense que Puppet est intéressant, mais pas nécessairement pour les raisons de la réponse.
Acumenus

Les offres d'emploi reflètent le véritable marché des compétences spécifiques. Oui, l'utilisation de la gestion de la configuration dans le but recherché est plus évolutive, plus robuste et plus facile à documenter que les scripts shell. J'ai été dans de nombreux environnements et la plupart des scripts que je vois ne sont pas conçus de manière à qualifier la "qualité de la production" et sont organisés de manière à gérer les exceptions. Voir la réponse acceptée pour comprendre pourquoi.
ewwhite

1
"Et un devops est vraiment dommage, car il est sous-exploité en tant que développeur." Ce n'est tout simplement pas vrai. DevOps est une spécialisation du développement, tout comme le développement Web. Les modèles et les pratiques de développement de logiciels s'appliquent toujours. Vous devriez lire sur DevOps.
Chaim Eliyah

13

Chef facilite beaucoup la gestion et la mise en version de la configuration d’une infrastructure complexe, en particulier dans tout type d’environnement cloud, au lieu de devoir manuellement ftp ou scp un ensemble de scripts de shell organisés de manière non normalisée. En fonction du nombre de dépendances que vous devez gérer, la taille de ce gain peut varier considérablement, rendant la décision de passer à une solution CM une solution peu évidente pour un grand nombre de personnes.

Le véritable avantage (souvent méconnu) de Chef est son idempotence . Le fait de pouvoir être certain de l'état d'une ressource indépendamment de la combinaison de recettes exécutées avec des intérêts qui se chevauchent constitue un avantage énorme par rapport à la configuration de script shell. Si vous avez maintenant des scripts shell pour la configuration, demandez-vous combien d'entre eux peuvent être exécutés plusieurs fois sans conséquences involontaires / indésirables?

Une solution CM appropriée contribue à la réussite à grande échelle en simplifiant l'automatisation multiplate-forme et la collaboration en équipe. Bien qu'il soit possible d'accomplir tout cela avec un groupe de scripts shell bien organisé, bien géré et mis à jour; vous devez vous demander "pourquoi". Chef / Puppet et des technologies similaires ont vu le jour car un groupe de talentueux SysOps en avait assez de devoir résoudre ces mêmes problèmes encore et encore et a décidé de nous offrir une meilleure solution.

Pièces clés:

  • Idempotence
  • Facilité de gestion des dépendances (versioning)
  • Organisation normalisée (acceptée au niveau de l'industrie)
  • Abstraction pour séparer les tâches de configuration du serveur des détails au niveau du système
  • Capacité à tirer parti des connaissances de la communauté (ce qui garantit de respecter tous les principes ci-dessus)

3
L’impuissance n’est guère impossible avec ss. Les dépendances sont bien gérées par yum / apt, etc. L'acceptation n'est pas pertinente. La connaissance de la communauté existe pour les art. J'accepte cependant que le fait de ne pas avoir à copier un grand nombre de scripts et de configurer les systèmes de manière centralisée est utile. J'entends marionnette nécessite un agent côté client.
Acumenus

10

Les outils modernes de gestion de la configuration tels que Puppet et Chef vous permettent de définir l' état d'un système au lieu de vous soucier des activités nécessaires à la réalisation d'un serveur configuré.

Par exemple, votre commande chmod suppose que le fichier existe, que l'utilisateur propriétaire du fichier existe, que les répertoires ont été créés, etc. Votre script doit donc prendre en compte tous ces préalables.

Les outils de gestion de la configuration basés sur des états sont plus simples: vous devez simplement vous assurer que le fichier dispose des autorisations appropriées. Comment cela est réalisé est le problème de l'outil.


1
En fait, my chmodne présume pas que le fichier existe, car il a été créé ou testé par le script.
Acumenus

9

Si des serveurs sont à votre disposition ou si vous avez des raisons de vous lever plus d'un couple à la fois, un système CM complet répondra mieux à vos besoins qu'une série de scripts shell.

Si vos besoins en matière de construction sont modestes (ou si vous souhaitez artisanalement artisanalement des serveurs de commerce équitable biologiques en libre-échange), restez simple.

Personnellement, après avoir beaucoup utilisé Chef lors d’un concert précédent, j’ai essayé de faire en sorte que tout reste simple, mais j’ai vraiment manqué les primitives, les abstractions et le pouvoir fournis par Chef. Même si vous arrivez à une situation où vous pourriez obtenir ce dont vous avez besoin à partir de deux commandes shell, vous pouvez simplement les exécuter avec un bloc 'commande', en entrant vos commandes shell exactement comme vous les écririez dans shell.

Cela dit, vous pouvez exécuter Chef sans serveur (chef-solo), et je suis à peu près sûr que Puppet a un analogue, où vous pouvez toujours utiliser les livres de recettes et les recettes des autres sans faire appel à un serveur central.

Un autre avantage est la communauté: il y a beaucoup de gens (dont beaucoup seront plus intelligents et / ou plus expérimentés que vous). Personnellement, j'adore quand quelqu'un d'autre a fait mon travail pour moi, souvent plus que je l'aurais fait.


1

J'ai créé une infrastructure d'automatisation de serveur basée sur un script shell: https://github.com/myplaceonline/posixcube

Je suis sûr que je ne suis pas le premier à réaliser ce type de projet, mais je ne pouvais pas trouver quelque chose de similaire pour répondre à mes besoins. J'ai donc pensé que cela pourrait être utile pour d'autres. Je n'avais qu'une expérience avec Chef, mais lorsque j'ai commencé à regarder Ansible et d'autres, je voulais essayer les scripts shell, et j'aime le résultat jusqu'à présent.

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.