Using Vagrant and Chef for Reproducible, Isolated Rails Development Environments | Hacker News Reader

Using Vagrant and Chef for Reproducible, Isolated Rails Development Environments

gofullstack.com

57 pointstristanoneil20 comments

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

I 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.

I'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-...

berkshelf makes this a breeze, fyi. I do it for all of my AWS instances

Just want to point out that if you're using an encrypted filesystem, vagrant up will fail if NFS is enabled. The workaround is to use rsync to maintain the synced folders, a feature introduced in Vagrant 1.5. Just use vagrant rsync-auto to keep the guest folder in sync automatically with your local folder. If you modify files within the VM (like with a bundle install that modifies your Gemfile.lock or with rails generators), I recommend installing the vagrant-rsync-back plugin (https://github.com/smerrill/vagrant-rsync-back).

Good to know. My filesystem is encrypted, running Mac OS X Yosemite, and it does work but I know there are a few other cases where NFS will crap out. As I mention this setup is pretty naive but could see making NFS optional using environment variables. That plugin looks pretty cool though, will look into it.

Never has the issue with full-disk encryption om my mac, but ran into this when using ubuntu's encrypted home. I use a symlink for ~/repos directory ans now it works fine :)

We use this at work and it's awesome. Solved a lot of big problems and a lot of little problems, like "works on my machine but not prod" and rebuilding your dev env when you switch machines. etc.

The one thing that became a problem was managing vmware (the plugin is a closed source one, so it was hard to debug any issue that came up with it - easily solved by writing our own open source one)

My workflow is very similar, except with Vagrant + SaltStack for all my development images, which has saved me so much time when bringing new developers onto a project. Thumbs-up.

One thing that's bitten me a few times is case-sensitivity when using NFS and HFS+ -- still wishing I could find a solution that didn't require setting up an additional partition on my host machine.

I tried using Vagrant on my company Macbook but found it much slower than just running everything on OSX. Does anyone have any tips for improving the performance?

If you haven't tried it with NFS that'd be the first place to start, it makes a _huge_ difference.

File I/O is the big bottleneck. For our python/front-end stuff it's a dream (We use Vagrant+ansible). We have a Java portion as well and getting decent compilation performance has thus far been impossible.

I use a fairly simple bash script to initialize my rails vagrant instances. Total of 34 lines including comments and didn't require learning any new config tools.

While I'd favor using proper config management this was a much better use of my time.

Those 'quick n dirty scripts' will work for you (and work well) but when others need to rely on them it gets messy. At my company we have 50 developers and everyone relies on "Jeff's script". No one really touches it because no one really gets it and Jeff might move across the country soon. :(

We're using Fig (and docker-osx) for this. One command to set up the environment and another to bring in a database copy. I recently formatted and upgraded to Yosemite and was able to get back to work in under a half hour.

Haha I was literally studying this yesterday. Vagrant Cloud's search function is surprisingly broken, it was surprisingly hard to find a box running Ubuntu Trusty, Rails 4.1 and rbenv.

I may be missing something, but isn't this what Docker is for?

Things have changed some since these answers were posted, but answers 2 and 3 here are written by the authors of vagrant and docker, respectively.

http://stackoverflow.com/questions/16647069/should-i-use-vag...

And the bonus of using Docker is you can use the same image you develop on to test with, and the same image you test with in production.

This not only avoids the "Dunno, works on my system" but also the "Dunno, works in dev/test"

A Vagrant VM is a full fledged environment, useful for thick stack setups such as LAMP or LAMR or MEAN. While you can somewhat abuse Docker to fit this role by using supervisord or somesuch, it is much more suited to having exactly one process per container.

You could potentially even combine the two approaches and have a Vagrant VM with a small Ubuntu stack that has docker installed and then have a set of docker containers, one per component or service.

That said, the Docker abuse setup is fairly common. I'm in the process of doing one myself right now. :)

Reply on news.ycombinator.com