web-dev-qa-db-fra.com

Pourquoi utiliser Chef / Puppet sur des scripts Shell?

Nouveau dans les outils Puppet et Chef. On dirait que le travail qu'ils font peut être fait avec les scripts Shell. Peut-être que cela a été fait dans les scripts Shell jusqu'à ce que cela arrive.

Je conviens qu'ils sont plus lisibles. Mais y a-t-il d'autres avantages par rapport aux scripts Shell en plus d'être lisibles?

scriptingpuppetchefconfiguration-managementprovisioning
82
resting

Un langage spécifique au domaine fait une grande différence dans la quantité de code que vous écrivez. Par exemple, vous pourriez faire valoir 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 s'il y a quelque chose après cela dans votre script qui nécessite que $ FILE soit là avec le bon contenu?

Vous pourriez dire que l'on pourrait simplement mettre echo "Hello world" > $FILE dans le script, sauf que dans le premier exemple, le script doit être exécuté sur le client, tandis que marionnette compile tout cela sur le serveur. Donc, si vous changez le contenu, vous n'avez qu'à le changer sur le serveur et il le change pour autant de systèmes que vous le souhaitez. Et la marionnette gère automatiquement les dépendances et les problèmes de transfert.

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

56
Paul Gear

Ce sera une opinion impopulaire, mais les systèmes de gestion de configuration ne sont pas nécessairement meilleurs. Parfois simple, c'est vraiment mieux.

Il y a une courbe d'apprentissage définie et des frais généraux administratifs associés au système de configuration que vous choisissez. Vous introduisez après tout 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 est resté. C'était toujours quand il y avait un grand nombre de systèmes avec une configuration répétitive et un besoin d'effectuer des déploiements de cookie-cutter configurables.

34
kenchilada

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

L'automatisation devient de plus en plus évolutive et formalisée . Puppet et Chef sont considérés comme des standards de nos jours (vérifiez les offres d'emploi ).

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

23
ewwhite

Chef facilite grandement la gestion et la version la configuration d'une infrastructure complexe, en particulier dans tout type d'environnement cloud, par rapport au fait de devoir ftp ou scp manuellement un tas de scripts Shell organisés de manière non standardisée. Selon le nombre de dépendances que vous devez gérer, la taille de cette victoire peut varier considérablement, ce qui rend la décision de passer à une solution CM non évidente pour beaucoup de gens.

Le véritable avantage (souvent méconnu) de Chef est idempotence. Être en mesure d'être certain de l'état d'une ressource quelle que soit la combinaison de recettes exécutées avec des intérêts qui se chevauchent est un énorme avantage 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 à garantir le succès à grande échelle en simplifiant l'automatisation multiplateforme et la collaboration d'équipe. Bien qu'il soit possible d'accomplir tout cela avec un groupe de scripts Shell bien organisé, correctement entretenu et versionné; vous devez vous demander "pourquoi". Chef/Puppet et des technologies similaires ont vu le jour parce qu'un groupe de SysOps talentueux était fatigué d'avoir à résoudre ces mêmes problèmes encore et encore et s'est mis à nous offrir une meilleure option.

Pièces clés:

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

Des outils de gestion de configuration modernes tels que Puppet et Chef vous permettent de définir état d'un système au lieu de vous soucier de activités nécessaires pour obtenir 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 tenir compte de toutes ces conditions préalables.

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

10
Jon Jaroker

Si les serveurs sont à votre disposition, ou si vous avez raison de tenir debout plus d'un couple à la fois, un système CM complet répondra bien mieux à vos besoins qu'une série de scripts Shell.

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

Personnellement, après avoir beaucoup utilisé Chef lors d'un concert précédent, j'ai essayé de `` rester simple '' lors de ce concert, 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 quelques commandes Shell, vous pouvez simplement exécuter celles avec un bloc de `` 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 presque sûr que Puppet a un analogue, où vous pouvez toujours tirer parti des livres de cuisine et des recettes des autres sans exécuter de 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 intensément que je ne l'aurais fait.

9
gWaldo

J'ai créé un framework d'automatisation de serveur basé sur un script Shell: https://github.com/myplaceonline/posixcube

Je suis sûr que je ne suis pas le premier à faire ce genre de projet mais je n'ai pas trouvé quelque chose comme ça pour répondre à mes besoins, alors j'ai pensé que d'autres pourraient trouver cela utile. Je n'avais qu'une expérience avec Chef, mais comme j'ai commencé à regarder autour d'Ansible et d'autres, je voulais essayer les scripts Shell, et j'aime le résultat jusqu'à présent.

1
Kevin