Approvisionnement Vagrant Shell vs marionnette vs chef
J'ai la configuration suivante:
- De nombreux projets différents qui sont des référentiels git séparés, mais tous ont généralement la même configuration de serveur
- Chaque projet dépend à son tour de nombreux autres projets et nous utilisons le gestionnaire de dépendances composer pour les rassembler (langage PHP ici).
Je souhaite utiliser Vagrant et inclure un fichier Vagrant dans chaque référentiel, afin que les membres de mon équipe puissent cloner un référentiel, exécuter vagrant up et soyez prêt à partir.
Ma question concerne maintenant l'approvisionnement. J'ai besoin d'installer plusieurs outils et packages comme Apache, git, mysql et plusieurs packages php, puis télécharger certains fichiers (comme un db de développement récent), tout configurer dans/var/www et exécuter le composer commande d'installation.
Donc, une option pour ce faire est d'utiliser un gestionnaire utilisant des recettes comme le chef ou la marionnette. L'alternative serait d'écrire un fichier bash et d'utiliser le provisionnement Shell.
Je n'ai pas beaucoup d'expérience avec le chef/marionnette, donc 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 me semble-t-il une mauvaise approche pour aller avec marionnette/chef:
Je comprends que je devrai utiliser plusieurs recettes différentes et que j'utiliserai presque toujours les mêmes recettes pour mes différents référentiels, donc je devrais les inclure toutes dans tous les référentiels. Pensez à avoir 20 dépôts et à avoir besoin de 10 recettes, cela signifie que je devrai ajouter 200 recettes en tant que sous-module git ou similaire (chaque membre de l'équipe doit également 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 un petit dépôt avec mon script Shell et de le cloner 20 fois.
Il me manque probablement quelque chose, alors s'il vous plaît, demandez-moi si je devrais opter pour chef/marionnette et pourquoi cela a du sens même si mes référentiels ont tous une configuration de serveur très similaire.
L'article suivant concerne un autre outil CM ( ansible ), mais je pense que l'auteur fait un excellent travail pour expliquer les avantages de la transition loin 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 développeurs plus célèbres. Ils ont essentiellement dit: "C'est vraiment cool, mais je ne le lirai probablement pas car mon flux de travail d'installation manuelle/de script Shell est bien pour l'instant."
J'étais un peu choqué, mais après y avoir réfléchi pendant quelques minutes, j'ai réalisé que leur choix était parfaitement sensé et rationnel compte tenu de ce qu'ils savaient des outils CM.
citation 2:
Pour eux, l'utilisation d'un outil de CM signifiait des semaines d'efforts 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 étaient quelque peu conscients des avantages, mais les coûts d'utilisation d'un outil CM semblaient trop élevés pour que cela en vaille la peine.
Les avantages par rapport aux 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 de code source?
- Quelle méthode peut être exécutée plusieurs fois en toute sécurité en toute confiance?
- Quelle méthode peut facilement être exécutée sur plusieurs serveurs?
- Quelle méthode vérifie (teste) l'exactitude de votre serveur?
- Quelle méthode peut cibler facilement certains serveurs (web, db, etc.)?
- Quelle méthode prend facilement en charge les modèles de vos fichiers de configuration?
- Quelle méthode se développera pour supporter facilement toute votre pile?
J'espère que cela t'aides.
Mise à jour 2016
Pour ceux qui ont trouvé cela via Google, il semble n groupe de développeurs se dirige vers Ansible pour la simplicité. De la poste:
"Ansible est l'outil de déploiement pour les personnes qui n'aiment pas les outils de déploiement. Il est proche des scripts, ne pollue pas vos serveurs avec des agents ou des serveurs centralisés, et a tout de suite un sens."
Nous l'avons implémenté récemment dans notre architecture de microservices et c'est génial.
- Super simple
- A pris environ une journée pour récupérer
- Vous n'avez pas vraiment besoin d'y penser une fois que vous êtes prêt
Les marionnettes/chefs ont toujours une place dans mon cœur/pile, mais Ansible est tout simplement plus facile.