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?
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.
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.
la source
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.
la source
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:
la source
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.
la source
chmodne présume pas que le fichier existe, car il a été créé ou testé par le script.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.
la source
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.
la source