En plus de l'excellente réponse donnée par Adam, Vagrant relie tout ensemble. Bien que Chef et Puppet (et Salt et scripts shell et tout autre provisionneur que vous souhaitez utiliser) soient des choses séparées, Vagrant les relie toutes et les fait fonctionner avec juste un vagrant up.

Cette commande va :

1. démarrer la machine virtuelle si c'est tout ce qui est nécessaire, mais elle va aussi
2. créer la boîte à partir de votre boîte de base spécifiée si ce n'est pas encore fait, mais si vous n'avez même pas la boîte de base sur votre machine, elle va d'abord
3. la récupérer depuis son URL et la télécharger sur votre machine.

Vous n'avez pas à penser à tout cela. Disons que vous passez à un projet différent, lancé par un collègue. Vous venez de vérifier le code de votre dépôt, et exécutez vagrant up, sans vous soucier de télécharger des ISO ou d'installer quoi que ce soit, ou de vous demander quelle version de quelle distribution vous devez utiliser pour ce client particulier, ou si vous avez une copie d'une machine virtuelle qui a déjà tout ce dont vous avez besoin.

Vous n'avez même pas à vous soucier de savoir s'ils ont configuré les choses en utilisant Chef ou Puppet ou simplement des scripts shell. (D'accord, vous pourriez devoir exécuter bundle install ou vous assurer d'avoir tout installé, mais ce n'est quand même pas un gros problème.)

En reliant tout ensemble et en fournissant une interface unifiée pour tout cela, cela peut rendre beaucoup plus facile tous les cas d'utilisation, sauf les plus simples. Au début, vous pouvez avoir l'impression de simplement réapprendre une nouvelle façon de faire ce que vous faites déjà, mais une fois que vous approfondirez l'utilisation de Vagrant, vous découvrirez que vous pouvez faire beaucoup plus avec beaucoup moins d'efforts. Cela en vaudra largement le temps investi initialement.

Voici deux autres cas d'utilisation pour les développeurs que Vagrant simplifie (par rapport à "plain" VirtualBox). Je n'ai pas vu ces cas d'utilisation spécifiquement mentionnés dans les réponses précédentes.

1. Vagrant aide à maintenir les plateformes de développement et de production aussi proches que possible. Dans un monde idéal, vous provisionneriez l'environnement de production avec LES MÊMES scripts utilisés pour provisionner la VM Vagrant, minimisant ainsi les surprises au moment du déploiement.

2. Tests d'intégration et intégration continue : Vagrant est facile à contrôler depuis les tests, et donc des ensembles de machines entières peuvent être facilement contrôlés à partir d'outils tels que Jenkins lors de l'exécution des tests.

Oui, "plain" VirtualBox peut également être utilisé ici - mais les conventions utilisées par Vagrant rendent plus simple la mise en place de ces scénarios.

La capacité d'intégrer Chef ou Puppet à la provision de VM est essentielle. La plupart des utilisateurs de Vagrant vous diront qu'ils exécutent 'vagrant provision' et occasionnellement 'vagrant reload' beaucoup plus souvent que 'vagrant up' ou 'vagrant destroy'. Ces tâches indiquent que le vrai travail ne consiste pas à démarrer/arrêter les VM, mais à les 'gérer' par la suite.

Posez-vous une question meilleure (posée par des utilisateurs compétents de Chef, en tout cas), pourquoi utiliser Vagrant et pas knife avec le plugin approprié (nous allons parler du plugin virtualbox, dans un instant) ? Par exemple, transmettre des valeurs d'argument stockées dans un databag à un plugin knife est (beaucoup) plus intelligent, flexible et gérable que de jongler avec un seul grand Vagrantfile. Je définis généralement mes ressources 'dynamiques' comme le nombre de CPUs, la quantité de mémoire, quel OS déployer, le nom d'hôte, l'IP, les routes, etc., dans des databags chef afin de ne pas avoir à modifier ma recette constamment ;-). Modifier un databag via l'interface web de Chef est une tâche de saisie de données vraiment facile que je peux confier aux opérateurs les plus juniors. Avec un Vagrantfile, vous modifiez constamment le code et croyez-le ou non - le code se casse - ce qui garantit pratiquement que vous ne confierez JAMAIS de simples modifications au personnel des opérations.

En dehors du fait que knife n'a pas encore de plugin pour virtualbox (bien que j'envisage un prochainement), il existe déjà des plugins pour la plupart des produits de virtualisation 'entreprise', y compris vmware, xenserver et à peu près tous les principaux fournisseurs de 'cloud', également. Cela signifie que knife est bien supérieur à ce que Vagrant offre si/quand vous êtes prêt à passer à autre chose que virtualbox. Pour l'instant, la communauté de Chef semble satisfaite de laisser les utilisateurs de virtualbox galérer avec Vagrant en n'intégrant pas les APIs de virtualbox pour un plugin knife. Il y a un plugin knife-vagrant qui permet d'utiliser des databags pour transmettre des arguments. Mais, il nécessite toujours le logiciel Vagrant et son Vagrantfile monolithique pour fonctionner.

Donc, je vais prendre un risque et dire que Vagrant n'est définitivement PAS 'meilleur' que Chef avec knife; mais nécessaire (pour l'instant) si vous insistez sur virtualbox et peut-être 'plus facile' que de gérer chef avec des databags, à condition que vous ayez un environnement assez simple à gérer.

Vagrant abstrait les machines virtuelles, ce qui vous permet de facilement passer d'une implémentation de machine virtuelle à une autre. Vous pouvez passer de Virtual Box à AWS ou Digital Ocean. C'est comme utiliser SQL au lieu d'un langage spécifique à une base de données.

Vagrant permet aux développeurs de configurer rapidement leur environnement avec une seule commande et c'est exactement le même que celui des autres. Ceci est important dans les grandes entreprises où les développeurs viennent et partent souvent. Cela peut réduire le temps de configuration de 3 jours à 1 heure.

+ Ce qu'Adam a dit.

(Je n'ai toujours pas trouvé d'utilisation pour Chef ou Puppet cependant...)