Vagrant: A tool for building and distributing virtual development environments | Hacker News Reader

Vagrant: A tool for building and distributing virtual development environments

vagrantup.com

129 pointsmitchellh28 comments

This project has been the love child of myself and John Bender (nickelcode.com) for the past 6 weeks. We're both daily HN readers and would like to use this as a starting point to show Vagrant to the public. Specifically, I'd like to open up to any questions and feedback, so that the HN community can get to know Vagrant. Your feedback is extremely valued. Thanks!

A bit of background on this project: I work at a development company (citrusbyte.com) in LA. I see new projects almost every couple months, and I'm often working on multiple projects simultaneously due to work, freelance, and personal projects. Managing the development environments between many projects on a local machine became a huge burden and a coworker once mentioned developing in a virtual machine. I thought this was a great idea, and Vagrant was eventually born from it.

Like I said before, feel free to ask any questions. If no questions, I value your feedback very highly, so please let me know what you think!

Thanks, Mitchell

Lately I've set up a virtual machine to set up a developing environment. In OSX I can get everything up and running with ports but it isolating it in a virtual machine running Debian or something feels safer and more robust.

I love this idea and will certainly check it out for my next project.

This is so useful!!! I've been doing this manually for a select number of important projects. However, I'm not a Rails dev.

What would it take to work with [language/framework]?

I've skimmed over the docs and here [http://vagrantup.com/docs/getting-started/setup.html] it seems like instead of

  rails init

I could run

  django-admin startproject

Of course! Vagrant is not specific to rails at all!

The getting started screencast I made shows how to setup a LAMP environment: http://vimeo.com/9976342

And the getting started guide shows a rails environment.

Those should get you started on the path to python as well =]

Mitchell

Any plans for a repository of boxes? One with a LAMP stack, Rails stack, Django stack etc. I know I can roll my own and use chef there could be a community maintained repository of often used configurations.

Also, in the screencast you use localhost to address the vm. Any way to assign another ip to the vm? In my current setup my vm's have altenative ips.

Yes, there are plans for a central repository of boxes, but its not an "immediate future" plan. We'd first like to focus on getting Vagrant as stable as possible on the common-case systems.

Hm, changing the IP of the VM. This can't be done via the Vagrantfile at the moment no. But if you do change it manually, you can configure Vagrant to use that VM with "config.ssh.host"

Mitchell

This is one area where we really need feedback as most of the projects that Mitchell and I work on are Ruby/Rails (although Mitchells workload is much more diverse than my own).

Stop by #vagrant if you have any questions!

Hi Mitchell

I love this :-) have myself a bunch of slices and would make sense to consolidate them and run them with Vagrant (also would be less expensive too)

Have a question: does this run on a virtualized environment? For instance, if I get a big instance on EC2 or rackspacecloud, would virtual box work? Of course, this looks like it should be run on a dedicated "barebones" server, but I know I'll run into teams and webdevs who already have hosting at slicehost

mtw,

Thanks! Vagrant was really made to target the development environment, since the production world is pretty well covered in terms of deployment (whereas John and I thought that the development side of things had been neglected).

But keyist answers your question best. I've quoted his response below:

  "Could you perhaps turn convert a Vagrant project into an EC2 instance for deployment?"

  That's where Chef comes in. Vagrant uses Chef (http://wiki.opscode.com/display/chef/Home) for provisioning VMs. It's basically software configuration management (same category as cfengine or Puppet) -- you write cookbooks that specify how a system should be set up (see http://github.com/opscode/cookbooks/raw/master/nginx/recipes... for an example).
  If you write your Chef configuration the right way (ie not hardcoding anything to a set of system specifications), you can take the same set of Chef cookbooks you write and deploy to EC2 or any other Linux box, virtual or no.
  So with Vagrant you can essentially pass around a virtual machine configuration amongst your team and be confident that the entire team is coding and testing in a near-exact replica of the production environment. Not that this was impossible before, but Vagrant streamlines the process.
  I've provisioned 20+ servers with Chef and once you have a solid base configuration you can take your attended time on a full server stack (nginx, memcached, post{gres,fix}, munin... the works, essentially) to less than 10 minutes.

Hiya Mitchell -- Sweet-looking project. What sort of effort would be required to use a Windows-based VM?

(Would you even recommend using Vagrant with Windows VMs, or is there any alternative I should look at? I'd like to automate my currently manual provisioning for various windows-based consulting work I do, but also set up VM-based continuous integration for some cross-platform software I'm writing.)

The various "actions" which build up the behavior of the various Vagrant commands are tightly tied to a unix-based VM at the moment (see [1] for an example at the bottom).

John and I have discussed this and we're trying to figure out a way to pull out this logic so its specific to each box, so windows VMs would be possible.

That being said, assuming a windows VM has SSH, a quick hack would be to modify these actions to run the proper commands and it should work fine.

[1]: http://github.com/mitchellh/vagrant/blob/master/lib/vagrant/...

I had to read through most of the site before I had a good idea of what exactly this was, but it does sound very interesting.

What about deployment? On the site, you only talk about local development environments. Could you perhaps turn convert a Vagrant project into an EC2 instance for deployment?

"Could you perhaps turn convert a Vagrant project into an EC2 instance for deployment?"

That's where Chef comes in. Vagrant uses Chef (http://wiki.opscode.com/display/chef/Home) for provisioning VMs. It's basically software configuration management (same category as cfengine or Puppet) -- you write cookbooks that specify how a system should be set up (see http://github.com/opscode/cookbooks/raw/master/nginx/recipes... for an example).

If you write your Chef configuration the right way (ie not hardcoding anything to a set of system specifications), you can take the same set of Chef cookbooks you write and deploy to EC2 or any other Linux box, virtual or no.

So with Vagrant you can essentially pass around a virtual machine configuration amongst your team and be confident that the entire team is coding and testing in a near-exact replica of the production environment. Not that this was impossible before, but Vagrant streamlines the process.

I've provisioned 20+ servers with Chef and once you have a solid base configuration you can take your attended time on a full server stack (nginx, memcached, post{gres,fix}, munin... the works, essentially) to less than 10 minutes.

Is it still possible to use puppet instead of chef? We have a lot of puppet manifests written.

The Vagrant code is modular enough that puppet support should be fairly straightforward to add.

For a quick hack, you'd primarily change this file http://github.com/mitchellh/vagrant/blob/master/lib/vagrant/... to perform the necessary commands for a puppet setup. You'd need to add support for puppet configuration as well at http://github.com/mitchellh/vagrant/blob/master/lib/vagrant/...

The main goal John and I had initially was to get Vagrant working and released so others could benefit from it. Since we mostly use Chef, thats what we went with first.

Making the provisioning system modular is definitely on the radar, but keyist is absolutely correct in the above response.

It looks like it generates solo.rb and dna.json files based on what's in the Vagrant file, which is pretty cool, and I see there is a single cookbook path relative to the project directory. Is there a way to specify a site-cookbooks path, too?

Not at the moment. There will be extensive work on the chef provisioning system in Vagrant before the next minor release (0.2), I'll add this to the list.

Mitchell

Awesome. This is a very interesting project.

>I had to read through most of the site before I had a good idea of what exactly this was, but it does sound very interesting.

I did too, but I wasn't that dedicated to it and still don't know really, because I skim and read paragraphs selectively.

My suggestion is that you communicate what this is within one or two big sentences near the top.

Thanks, this is something we're definitely working on.

To just get an idea of the problems Vagrant solves, I recommend the "Why Vagrant?" page: http://vagrantup.com/docs/getting-started/why.html

"You clone your code repository with 'hg clone'. Now you can clone your development environment with 'vagrant up'."

(Do I have the right idea?)

You have the right idea. =]

You use 'principals' on this page when you should use 'principles'.

Thanks, updated the page.

This seems to be a very useful tool, one question though, what was the rationale behind choosing VirtualBox, have you done any benchmarks against Xen or Kvm or other hypervisors

VirtualBox was chosen since it is an open source, free choice which is available on Windows, Mac, Linux, and Solaris. It is simply the easiest way for developers to get started with a virtualized development environment.

Neither John nor I are familiar with any other virtualization platform, but making Vagrant modular enough such that this is possible is definitely a good idea for the future.

Thanks!

Yes please! I would love to have Xen support included ...

Reply on news.ycombinator.com