Approvisionnement coquille vs coquille marionnette vs chef

Question

J'ai la configuration suivante:

• De nombreux projets différents qui sont différents des dépôts git, mais tous ont pour la plupart la même configuration de serveur
• Chaque projet dépend à son tour de nombreux autres projets et nous utilisons le compositeur de la dépendance gestionnaire afin d'obtenir leur ensemble (langage PHP ici).

Je veux utiliser Vagrant et comprennent un Vagabond fichier dans chaque référentiel, pour les membres de mon équipe peut cloner un dépôt, exécutez vagrant up et être prêt à aller.

Ma question est maintenant orientée vers la mise en service. J'ai besoin d'installer plusieurs outils et les logiciels comme apache, git, mysql et plusieurs paquets php, puis de télécharger certains fichiers (comme un développement récent db dump), mettre tout en place dans /var/www et exécuter le compositeur de la commande d'installation.

Donc une option pour faire cela est d'utiliser un gestionnaire de recettes en utilisant comme chef ou puppet. L'alternative serait d'écrire un fichier bash et l'utilisation du shell de provisionnement.

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 d'avoir besoin de 10 recettes, ce qui signifie que je vais avoir besoin d'ajouter de 200 recettes comme git-sous-module ou de la même façon (aussi chaque membre de l'équipe de cloner le dépôt, puis clone 10 recette dépôts et seulement puis exécutez vagrant pour chaque projet). En revanche, je voudrais juste besoin d'avoir un petit repo avec mon script shell et le clone de 20 fois.

Je suis sans doute raté quelque chose, de sorte s'il vous plaît conseils si je dois opter pour chef / puppet et pourquoi il est logique même si mon dépôts ont tous très semblable à la configuration de serveur.

Answer 1

L'article suivant préoccupations encore une autre CM outil (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 surprise a été la réponse de certains de ces plus célèbres développeurs. En fait, ils ont dit, "Ce est vraiment cool, mais je n'aurai probablement pas le lire depuis mon manuel d'installation/shell-script de flux de travail est bien pour le moment."

J'ai été un peu choqué, mais une fois que j'y ai pensé pendant quelques minutes, j'ai réalisé que leur choix était parfaitement sain et rationnel compte tenu de ce qu'ils savaient à propos de CM-outils.

citation 2:

Pour eux, à l'aide d'un CM outil signifiait semaines d'efforts d'apprentissage des concepts complexes, aux prises avec un processus d'installation complexe, et le maintien de ce système complexe au fil du temps. Ils étaient un peu au courant 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ées à la fin et je pense qu'ils s'appliquent à tous les CM des outils, puppet, chef, sel, ansible...

• Quelle méthode est la plus susceptible de se retrouver dans le contrôle de code source?
• La méthode peut être exécutée plusieurs fois en toute sécurité avec confiance?
• La méthode peut facilement être exécuté sur plusieurs serveurs?
• La méthode qui fait vérifie (tests) de votre serveur pour la correction?
• La méthode peut cibler certains serveurs (web, db, etc)?
• La méthode qui supporte facilement les templates de vos fichiers de configuration?
• La méthode qui va croître de facilement prendre en charge la totalité de votre tapis?

Espérons que cette aide.