3 ms·
This is pretty much what I do when developing as it's a good idea to make your dev environment as close to production as possible. I do however substitute chef
by hackerboos 12y ago
This is pretty much what I do when developing as it's a good idea to make your dev environment as close to production as possible.
I do however substitute chef for ansible as I found chef difficult to use on a single server (chef-solo was flakey) and bootstrapping is a pain.
For writing anisble playbooks to use with Vagrant I found the following post very useful - http://hakunin.com/six-ansible-practices http://hakunin.com/six-ansible-practices
- orenmazor 12y agoberkshelf makes this a breeze, fyi. I do it for all of my AWS instances
- casey_lang 12y agoI've got my system built and working using Puppet but plan to move to Ansible when I have a day to mess around with it. I found "Taste Test"[1] by Matt Jaynes to be a nice and quick (if slightly expensive) comparison between the various configuration managers. [1]https://devopsu.com/books/taste-test-puppet-chef-salt-stack-ansible.html https://devopsu.com/books/taste-test-puppet-chef-salt-stack-...
- kcorbitt 12y agoI have the same setup. Vagrant for VMs with an Ansible provisioner. I reuse about 80% of my playbooks between production and development, and the places they differ is primarily in setting up my dev environment nicely with the shell and SSH access to prod and all that. It really helps to have everything both locally and in prod "disposable"... a couple of times I've run into hairy slightly strange behavior locally and it's great to be able to blow it away, run "vagrant up" again and in 20 minutes have a pristine, matching-prod dev environment.