Vagrant 1.6 has been released | Hacker News Reader

Vagrant 1.6 has been released

vagrantup.com

51 pointsknite31 comments

What's new: http://www.vagrantup.com/blog/vagrant-1-6.html

Full changelog is here: https://github.com/mitchellh/vagrant/blob/master/CHANGELOG.m...

While Windows guests look interesting how are people going to get the initial box? Is every individual or organization going to have to create their own box or will there be some way to get a box if you are part of MSDN?

You have to acquire an ISO in some legal way yourself. Then, you can use something like packer-windows which has pre-built templates for various versions of Windows to build Vagrant-compatible boxes in about 10 minutes: https://github.com/joefitzgerald/packer-windows

It isn't as easy as "download pre-built Linux box" but for environments that are using Windows, this workflow has been amazing for them above what they used to do, and is quite fast.

Thanks, I'm going to give this a look since you can use the trial ISO's.

For what it's worth, the same guy makes Packer, a tool to create your own boxes. https://github.com/mitchellh/packer

It even allows you to replace the functionality of Vagrant - in place- to create, spin up, and provision the box all in one command.

It's super awesome.

perhaps the modern.ie dev vms could be boxed up

http://modern.ie/en-us/virtualization-tools#downloads

Edit: Bit the bullet and bought myself this bundle pack from Leanpub: https://leanpub.com/b/vagrant-ansible/ - Vagrant looks like a great tool to have under my belt. Ansible also looks extremely simple compared to Chef and looks like Vagrant and Ansible compliment each other beautifully.

---

I guess this a good a place as any to ask, pardon my ignorance. What part of the workflow does Vagrant solve exactly?

For example, I'm building a business-class Rails application - normally I have RVM create a gemset specifically for that application. I also have PostgreSQL and MySQL installed locally for any app that needs it.

How does Vagrant fit into this workflow, what am I missing? Also, since the 'dev box' is now a virtual machine does that mean I can only ssh into it and edit code with something like Vim? Thanks for the information.

Vagrant makes it so that you can easily make production and local dev exactly the same (using Puppet, Chef, Salt, etc.), even when your developers use many different platforms. This solves all sorts of problems, like, something working locally but not in production, or the half day spent by each developer trying to install and correctly setup some new dependency.

Vagrant can share folders between the host and the VM using whatever shared folders option that Virtualization platform you're using has.

Half day? I've worked in places where this was more like 3 days.

For our team at least, our vagrant box is an exact version mirror (Redis, MySQL, PHP, nginx, git...) and paths of our production servers.

We have our DevOps maintain the box so the rest of the team doesn't have to worry about it. Changes to something, tell every one to pull from git, run vagrant provision and it works.

Saves us a lot of headache in "deploying" new development environments to our team.

Developing on an OS that isn't the same as your production box.

You can SSH to it, but usually you map folders between the host machine and the VM so that you use your local suite of tools on a local drive that is mapped to a location on the VM.

I use Vagrant heavily for testing ops & puppet changes. I've actually created two screencasts on Vagrant [1] and Learning Puppet with Vagrant [2]. Basically, it allows you to quickly spin up canned VM images via CLI, and then repackage/share these for others.

[1] http://sysadmincasts.com/episodes/4-vagrant

[2] http://sysadmincasts.com/episodes/8-learning-puppet-with-vag...

http://docs.vagrantup.com/v2/why-vagrant/index.html has your information.

Yep, I saw that but it doesn't really answer my question. :(

If you're a developer, Vagrant will isolate dependencies and their configuration within a single disposable, consistent environment, without sacrificing any of the tools you're used to working with (editors, browsers, debuggers, etc.). Once you or someone else creates a single Vagrantfile, you just need to vagrant up and everything is installed and configured for you to work. Other members of your team create their development environments from the same configuration, so whether you're working on Linux, Mac OS X, or Windows, all your team members are running code in the same environment, against the same dependencies, all configured the same way. Say goodbye to "works on my machine" bugs.

---

It doesn't answer if I can only ssh into the box and write code there. I need more actual workflow data.

As jeffasinger described, you can sync folders between your local environment and the Vagrant VM. You can edit files locally, save them, and have the changes propagated without SSH'ing into the box. [1]

[1]: http://docs.vagrantup.com/v2/synced-folders/

Edit: Adding source.

I've tried explaining the benefits of vagrant to some of my fellow developers. I've failed every time. I've now resorted to calling it "magical" and "just try it and you'll get it".

At the very least, you can think of it as a nice CLI to the hypervisor on your machine. Something that's consistent across different host OSes - as long as you've got the right version of Vagrant :) That and synced folders is enough of a win in my books.

Edit: I noticed you are asking about workflow. That's another thing about Vagrant. I use it like a swiss army knife for various tasks as needed. It isn't really part of a workflow per say. I do a lot of exploratory programming, trying out new stacks/packages/tools, etc. It fits well with that kind of use case.

There is an argument about installing development "cruft" directly on your host OS versus the use of virtualization.

I personally hate have long running processes always on in the background of my host OS. It slows things down, and it's not the purpose of your OS. You end up suing a non-standard OS (wayyyy different than production, especially on your Macintosh where the file system isn't case sensitive, to give 1 example).

Some people "need" to install software directly on their host OS because VM's take up too much battery power and they often work too far from an outlet. That can make sense, but I still cringe at the idea.

I think Docker provides the best of both worlds here. We have real isolation from our host OS without having to virtualize an entire OS - It even removes a whole layer of battery-eating virtualization! (Hypervisor, I believe)

Docker (for local development) will let you get very close to your production OS while still being easy to use and (relatively) light-weight.

Unless you develop natively on Linux, Docker must still run inside of a VM, so there is no real battery savings.

And how is it different or better than the VirtualBox command line, which is quite extensive?

Vagrant also seems to have something in common with docker, though with VMs instead of containers, though I'm not totally clear on that either.

It's different and better because it moves the abstraction layer up a few notches.

First, Vagrant supports much more than just VirtualBox (maybe not a big deal if you only want to use VirtualBox).

Second, Vagrant comes with a nice configuration layer allowing you to specify what OS and VM options you want to use (maybe not a big deal if everyone in your group is already comfortable with the VirtualBox command line).

Third, it handles provisioning new VM's using the provisioner of your choice, like Chef, Puppet, regular old shell scripts, etc. (Maybe not a big deal if everyone in your group is already an expert at using the chosen tool e.g. knife).

Fourth, it wraps up all of the previous steps (plus a bunch more), so that people can just clone the current box and type 'vagrant up', and have a working copy of the production/staging/test/dev network. (Maybe not a big deal if everyone in your group is already an expert at setting up that network).

Anyway, I know that all comes off a bit glib, but Vagrant really shines in automating a bunch of not-necessarily difficult manual steps. I'm pretty sure it doesn't do anything that can't also be done through a variety of other mechanisms (being well-versed in the VirtualBox command line, for example), but so far, I've found it to be more pleasant to use than dealing with all those other mechanisms.

I don't really know about VirtualBox Command Line, but from a simple URL Vagrant creates a VirtualBox instance, then after simple configurations (e.g., copying a private key), can transfer the control to a provisioning script (e.g, Ansible). You have all your server configuration in an version controlled text file, runnable with a simple command, allowing you to freely tweak your server.

Primarily from it's integration with provisioners (Puppet, Chef, etc, even inline shell commands), it's folder share support and the conventions you get that make it easy to build a sane lifecycle around (vagrant up, vagrant suspend, vagrant destroy).

http://www.vagrantup.com/blog/vagrant-1-6.html

> Boxes can now be compressed with LZMA - LZMA compression can result in much smaller boxes in a lot of cases, and Vagrant can now decompress LZMA-compressed boxes.

any word on how this is enabled, or does it just work? I didn't see anything in the package or box docs.

thanks.

Just works. Actually, LZMA compression has always works on Linux/Mac. Vagrant 1.6 is just the first release to also support LZMA compression on Windows as well. Since it is supported on all platforms, we're able to advertise it a bit.

I've just started using Vagrant, but am not quite sure how it relates to production.

Can I use Vagrant to build out my production server too? Or would I just use Chef/Puppet/Ansible with the same playbook/recipe on both my Vagrant powered VM and non-vagrant powered production machine?

I use Salt (used to use Puppet) to build out my Vagrant box(es) in development.

When I'm good to go, I use Packer with the same Salt configuration to build an image and push it to AWS/DO/RackSpace as needed. Makes it super easy to develop and deploy on exactly the same machine, and the Vagrant/Packer configurations are typically fairly minimal so there's very little set-up time once you've written out your Salt/Puppet/etc configurations.

I believe Vagrant is for quickly and repeatably building development environments - I don't think it's meant for production.

Look into packer for building out Production images, and Chef/Puppet/Ansible for additional configuration ontop those images.

I'm really impressed with Vagrant's documentation: http://docs.vagrantup.com/v2/ Super clean, easy to read, and well organized. Nice job!

I could not live without vagrant anymore. Developing inside vm, having a linux env on my windows machine, testing stuff, testing ansible/chef setups with a testing vm... It's so easy :)

Love Vagrant, so useful.

Reply on news.ycombinator.com