A Better Development Workflow with Vagrant | Hacker News Reader

A Better Development Workflow with Vagrant

taylorlapeyre.me

45 pointstaylorlapeyre40 comments

Don't know if I understand. You have the one develop box with all the languages/server/databases on there. Then when you decide to start a PHP project, you keep a copy of that box in with the project files? Doesn't this result in multiple boxes sitting around?

Or does the Vagrantfile specify the environment and when you vagrant init develop it recreates it?

I've never used Vagrant but am interested in starting to do something like this.

The Vagrantfile specifies the enviroment, and vagrant init develop creates a new Vagrantfile with the base vm specified as "develop".

There's only one box, and you add it to vagrant with "vagrant box add develop path/to/develop.box". After that, you can delete the develop.box file from your computer: it now exists somewhere in the nethers of vagrant's configuration.

So as you find new tools you want to use, do you just update your develop box? Do you have an example of a Vagrantfile you used for a project?

I guess the main thing I can't get is say I have custom nginx settings or MySQL settings I need in a project. Do I setup those through Chef?

Thanks for the article, lots to look into.

It depends. If I begin using something new (say, Go) and end up using it a lot then I will install it on develop and repackage it into the "develop" box again. This takes about 5 minutes.

If it's something specific for a project (i.e., a jekyll website), I just write a quick shell script to install jekyll in the Vagrantfile for that project instead of repackaging the whole box.

As for your second question, yes, you would have a specific Vagrantfile/box for a project where you need a specific enviroment. My "develop" box is a general case.

Here's a (slightly modified) example of a Vagrantfile that I use with a project: https://gist.github.com/taylorlapeyre/5399974

The Vagrantfile specifies the environment as a combination of a base box, VM settings and optionally a provisioning script/recipe/whatever to run. The base box is only stored once, and individual VMs for projects are created from that box and destroyed when you don't need them any more.

It's common to use something like Chef or Puppet to provision the software that you actually need for each project rather than just put everything in the base box, but the author chose to just make an all-inclusive box instead.

I'm still a bit confused - what if you are simultaneously working on two projects that each require a different version of Ruby? Do you have two different vagrant boxes lying around?

You start off with the same baseVM (I used to use Precise32, switched to Precise64 for the first time yesterday). You specify the boxes which is based off your base VM.

From there, the path of evolution for each box will take place individually. If you have a Vagrantfile that specify for one project to use Ruby2.0beta and another Vagrantfile for another project to use Ruby1.9, you essentially have two boxes, two execution environments, but you still code on the same machine.

User chewxy explained it well, but even more simply I just have two different versions of Ruby on my development box. 1.9.3 and 2.0.0.

if nothing else is different, then you can still use rvm inside the VM. If they are different environments (one is a colo rack and one is an AWS instance) then you would want 2 vagrant boxes to more closely duplicate each environment.

Vagrant is the execution environment that you set up, share and whatnots. Your dev environment (IDE, text editor, etc) can still be in the original environment you are familiar with.

For example, just yesterday, a colleague wanted access to Fork the Cookbook's source (he was supposed to be helping out on frontend javascript). But because some bits of the code is written to be Linux specific, he needed a Linux box while working on a non-Linux box.

So I spent 30 mins creating a Vagrantfile, specifying the environment which Fork the Cookbook runs in. He takes it, runs the env, provisions with the existing provisioning script, and tadah, you get an environment where you get to run the code in.

Due to the synced directories, you can code in whatever env you are hosting on: it's like dropbox between your computer and the virtual box. Network pass throughs allow your host (i.e your physical machine) to use networks defined virtually in your virtual computer.

Great for sharing execution env and getting other people started. Not really necessary if you're working alone IMO

> Vagrant is the execution environment that you set up, share and whatnots. Your dev environment (IDE, text editor, etc) can still be in the original environment you are familiar with.

Sorry if i have missed this but how do you execute/debug in the IDE through Vagrant? e.g. how would rubymine use vagrant's ruby binary?

I'm not sure about Rubymine since I'm more of a Python/Golang guy (also I use SublimeText). In Python, there is an IDE called PyCharm that has a remote intepreter function. I expect all good IDEs to have something like that too: remote intepreter/libraries/etc

EDIT: A quick Google yielded this: http://www.jetbrains.com/ruby/webhelp/configuring-remote-int...

Yup, this works with Rubymine and Vagrant. Set this up today for myself. Took a bit of fiddling to get it to work, Ruby 2.0 seems a bit flaky to debug, 1.9.3 works well.

In the case of any debugging in your IDE, you'd want to use remote debugging (which, I believe, rubymine supports). Otherwise, I'd connect to the virtual machine via ssh and debug there.

I haven't used Vagrant, and I believe I now know why.My daily driver is Win8.I have a Debian VM I do my development on.All files are on the VM because Windows sets all file and folder permissions to 755. This means that if I were to delete the vagrant VM I would also be deleting my files. I am exploring possible solutions to this problem.

Similar set up, but I use Cygwin so I can run `startxwin` then run `ssh box -Y` and have have all my applications/workflow running in the Windows taskbar.

Are you saying that when you share a filesystem between your windows 8 host and the Debian guest, that files written from windows have bad perms?

If the files reside on the NTFS Win8 partition, they show up as 755 on Debian.

If the files reside on the ext3 partition on the Debian VM, the permissions are fine and even editing the files from Windows, on a Windows IDE does not change the permissions.

Just to clear up my expectations, if I were to try a similar set-up... When you are using NTFS I'm expecting that you are using virtualbox to mount the filesystem on the guest.

When you use etx3, how are you sharing the files? Like a samba share? or does the virtualbox drive mount work in the other direction, somehow?

FWIW, I do all of my virtualization on ESX, but every time one of these vagrant article comes up I'm tempted to try something local (win 8), to take advantage of the shared filesystem that most of vagrant's magic relies on (as I understand).

I actually wrote a tutorial on this: https://jtreminio.com/2012/07/setting-up-a-debian-vm-step-by...

I'll be re-doing it to use apt-get for everything, but for now PHP is compiled.

I use samba to share files from the VM to my network, and Windows mounts the share as a local drive.

I recently built out a base LAMP stack for Vagrant, using Chef for provisioning if anybody's interested in getting up and running quickly. https://github.com/MiniCodeMonkey/Vagrant-LAMP-Stack

Pretty similar to my workflow, but why do you destroy the box after every session? `vagrant up` on my laptop takes a few minutes at least to build and provision a vagrant machine.

Usually I just use `vagrant suspend`. Seconds vs minutes. Time > organization IMHO.

Of course, but if you do that please also use a CI tool (such as Jenkins) to ensure the Vagrantfile stays valid. It's actually good to rebuild that VM regularly, especially when it's almost time to deploy.

Yeah, close to deploy is different. What does a CI tool do in this case? I'm somewhat unfamiliar with the concept.

If you run your tests in a pristine and isolated environment, then you can be more confident in the lack of side-effects.

Basically, by integrating this into your CI tool, you ensure that all your tests / deploys run through a standardized and pristine environment.

I haven't done it myself, but I've heard that the same effect (clean starting point) can be achieved with snapshots and restores without the waiting time - it is supposed to work very fast.

No particular reason other than freeing up the disk space that the VM uses (which admittedly not much).

or 'vagrant halt'

Anyone has experience using Vagrant with VMWARE?

They just released support for this the other week I believe (Or at least very recently) - And that is specifically why I've been catching up on everything Vagrant lately, as I was specifically waiting on VMWare support. I asked about it in the freenode #vagrant channel the other day and everyone said it should work the exact same as using the VirtualBox provider - except with VMWare.

Does VMware do anything VirtualBox doesn't?

It does everything better.

NOTE: I'm biased, I created Vagrant + VMware. But go ahead and ask VMware users.

I want to say something like that one day :)

+1 for VMWare, havent crashed yet after a year and a half since switching

thanks for your Vagrant + VMware work, that was the biggest thing keeping me from vagrant

Hey there, author of the article here. Just wanted to thank you for your help in closing the issue that I opened about adding GOW support on Windows. It's nice to know that Vagrant has an active and supportive community.

On MacOS, my VirtualBox VMs regularly froze. On VMWare Fusion, they have frozen/crashed far less often.

If you have a mac I recommend to have a look at the boxen project from github.

I did actually look into that, but it kind of did the exact opposite of what I wanted. There's a few reasons I'm not too impressed with Boxen:

- Its goal is to install a whole bunch of binaries and development utilities onto my local machine. I want to keep those segregated.

- It only works with Macs. My only computer at the moment is a mac, but it's not always what I use. I use computers at work that are linux based.

- I found that it was buggy. I wasn't very easy to get it actually working. It required a lot of effort and installation.

So, Boxen isn't for me.

I would go even further and store tmux+vim config inside

I would go even further and use the same provisioning on vagrant as on my production servers so I could set up a mini production environment with whatever dev tools are necessary with just a single command. Recently they added the ability to have multiple machines as well, so all it takes to load up a simulation of my cluster is a single command.

Reply on news.ycombinator.com