Vagrant provisionnement shell vs marionnettes vs chef
j'ai la configuration suivante:
- beaucoup de projets différents qui sont des dépôts Git séparés, mais tous ont la plupart du temps la même configuration de serveur
- chaque projet à son tour dépend de beaucoup d'autres projets et nous utilisons le gestionnaire de dépendances composer pour les rassembler (le langage PHP ici).
Je veux utiliser Vagrant et inclure un fichier Vagrant dans chaque dépôt, pour que les membres de mon équipe puissent cloner un dépôt, exécuter vagrant up
et être prêt à aller.
ma question est maintenant dirigée vers le provisionnement. J'ai besoin d'installer plusieurs outils et paquets comme apache, git, mysql et plusieurs paquets php, puis de télécharger quelques fichiers (comme un récent dump de développement db), de tout configurer dans /var/www et d'exécuter la commande composer install.
donc une option pour faire cela est d'utiliser un manager en utilisant des recettes comme chef ou marionnette. L'alternative serait d'écrire un fichier bash et d'utiliser l'approvisionnement shell.
je n'ai pas beaucoup d'expérience avec le chef / puppet, alors, naturellement, il semble plus facile d'utiliser l'option shell, mais je veux comprendre si ce n'est pas une bonne / option viable à long terme.
Pourquoi il me paraît une mauvaise approche pour aller avec puppet / chef:
je comprends que je vais avoir à utiliser plusieurs recettes différentes et presque toujours utiliser les mêmes recettes pour mes différents référentiels, donc j'aurais de toutes les inclure dans tous les référentiels. Envisager d'avoir 20 repos et ayant besoin de 10 recettes, cela signifie que je vais avoir besoin d'ajouter 200 recettes comme un git-submodule ou similaire (aussi chaque membre de l'équipe doit cloner le référentiel, puis cloner 10 référentiels de recettes et seulement ensuite exécuter vagrant pour chaque projet). En revanche, j'aurais juste besoin d'avoir une petite reconnaissance avec mon script shell et de le cloner 20 fois.
je manque probablement quelque chose, alors s'il vous plaît conseil si je devrais opter pour chef / marionnette et pourquoi il a un sens, même si mes dépôts ont tous un très configuration similaire du serveur.
2 réponses
l'article suivant concerne encore un autre outil de CM ( ansible), mais je pense que l'auteur fait un excellent travail d'expliquer les avantages de la transition vers des scripts shell.
http://devopsu.com/blog/ansible-vs-shell-scripts/
citation 1:
ce qui m'a vraiment surpris, c'est la réponse de certains de ces fameux devs. Ils ont dit en gros, "c'est vraiment cool, mais je ne vais probablement pas le lire depuis mon le workflow manuel-install/shell-script est parfait pour l'instant."
j'ai été un peu choqué, mais après y avoir réfléchi quelques minutes, j'ai réalisé que leur choix était parfaitement sain et rationnel compte tenu de ce qu'ils connaissaient des outils CM.
citation 2:
pour eux, l'utilisation d'un outil de gestion de la communication a exigé des semaines d'effort pour apprendre des concepts complexes, se débattre avec un processus d'installation complexe et maintenir ce système complexe au fil du temps. Ils ont été quelque peu conscients des avantages, mais les coûts de l'aide d'un CM outil semblait trop élevé pour faire cela en vaut la peine.
les avantages sur les scripts shell sont résumés à la fin et je pense qu'ils s'appliquent à tous les outils CM, marionnette, chef, sel, ansible...
- Quelle méthode est la plus susceptible de se retrouver dans le contrôle à la source?
- Quelle méthode peut être utilisée plusieurs fois en toute sécurité avec confiance?
- Quelle méthode peut facilement être exécutée contre multiple les serveurs?
- Quelle méthode vérifie (teste) l'exactitude de votre serveur?
- Quelle méthode peut cibler certains serveurs facilement (web, db, etc)?
- Quelle méthode supporte facilement l'établissement de vos fichiers de configuration?
- Quelle méthode se développera pour supporter facilement toute votre pile?
J'espère que cela vous aidera.
mise à jour 2016
Pour ceux qui ont trouvé ce par le biais de Google, il semble un tas de développeurs se rapprochent de L'Ansible pour la simplicité. Post:
"Ansible est l'outil de déploiement pour les personnes qui n'aiment pas les outils de déploiement. Il est proche du script, ne pollue pas vos serveurs avec des agents ou des serveurs centralisés, et fait juste un sens immédiat."
nous l'avons mis en oeuvre récemment dans notre l'architecture microservice et ça a été génial.
- Super simple
- a Pris environ une journée pour ramasser
- ne pas vraiment besoin d'y penser une fois que vous êtes prêt
marionnette / chef ont toujours une place dans mon coeur / stack, mais Ansible est juste plus facile.