Creator of Vagrant here. Pleasantly surprised to see Vagrant on top of HN! Vagrant has matured a lot in the past year (since it has been on HN) both in the core but also in the community. There are now tons of plugins available, there is an O'Reilly book out, and much more. Most importantly, I think, is that the project has added 3 more core committers in the past few months.
And Vagrant 1.4 is also under heavy development with tons of great new features and bug fixes upcoming. See my Twitter stream for more info.
If you have any questions, feel free to ask. And thanks for the support!
Thank you for producing such an awesome piece of software. I have been doing my local development on a Vagrant box for about a year now and in that time I have been able to move from OS X to Linux almost seamlessly thanks to Vagrant.
The only problem I have with it is the slowness of the default shared folders mechanism. Guess I need to bite the bullet one of these days switch to NFS.
This will allow us to much more quickly add in more implementations of this mechanism, some of which may provide excellent performance at the expense of perhaps being more difficult to setup or slower to start up. But the importance is that the framework is now _there_.
This kinda goes against the grain of Vagrant, but VMware + NFS + PHP still seemed slow to me and I switched things around to use Samba. Now my code/tests run "locally" to the VM and I edit code over samba
Vagrant makes the nfs setup very easy to do. The performance difference is day and night when you have disk access. Even things like 'git status' is significantly faster. If you install the vb guest plugin it will make things even easier [1]. Issue I've run into is that I any get it working on a colleagues Mavericks host - there's all sorts broken on there though....
The performance is acceptable most of the times, other than when I am running one of those PHP frameworks that includes a million files to process each request.
I'm seeing the same problem, running the phpunit tests from a PHP framework inside a Vagrant box (Ubuntu 12.04 as host and guest, VirtualBox provider, current vagrant). The tests run >3 times slower than on the physical machine. I have no idea what is causing the sluggishness.
NFS is no silver bullet. In exchange for performance and reliability you lose some production/development parity. You need to special case your provisioning script to guard against any FS permission changes.
That's the reason why I gave it up the last time I tried it. IIRC, there's a requirement to run 'vagrant up' with sudo and that does things which I don't like.
Maybe, I'll try something like leaving the files on the guest and mount it on the host using SSHFS. My write performance will take a hit when I am editing files, but, if I can get rid of the sluggishness it will be worth it.
Is there any way to automatically generate a provisioning script based on what was installed on the guest machine? For example, I do "vagrant ssh" and then install my whole development environment and it creates a script to do it every time based on what changed?
Right now it has frontends for bcfg2, cfengine, chef, puppet and shell scripts. It's not perfect, but it does a pretty good job of giving you a base set of provisioning rules you can then refine by hand.
Not within Vagrant itself. This is really the realm of configuration management tools. As far as I know, no tools do this reverse engineering because it is a fundamentally very difficult problem, but many of the config mgmt tools make it very easy to translate shell commands to rudimentary scripts for their systems.
Vagrant doesn't, but blueprint[0] seems to be a decent tool for generating puppet manifests. I haven't used it personally, but an Ops guy at work has had some success with it.
For me the biggest barrier to adopting Vagrant was getting my rails stack setup in an easily reproducible way. It took me a while to get my laptop environment setup the way I like, so I was hesitant to have to start that process again.
Well, Vagrant is a utility that wraps popular virtual managers such as virtualbox and vmware under a single user interface (the vagrant command line) and provide configurations to setup a VM along with user-defined boostrap scripts (puppet, chef, ansible, salt, bash script, etc).
Based on the way you describe you situation, I think the barrier is in configuration management. That is, writing a puppet or an ansible script is still very time consuming. A vagrant machine in general is nothing more than a vanilla server after a full install.
For me, I am beginning to investigate the possibility to create a system package (e.g. debian package) for all the apps I need to run. I think FPM will help.
I asked for a refund of the VMWare plugin the same day I purchased it, over a week ago and have received no response. It doesn't work reliably compared to the virtualbox one and requires windowsesque multiple restarts to make it work at all.
A counterpoint for anyone reading this who is considering the paid VMWare plugin: it works flawlessly for me.
On my MacBook Pro with Mavericks, it uses less CPU than my VirtualBox Vagrant boxes and feels snappier overall (boxes start and stop faster, Apache/nginx feel quicker, shared file updates are fast). It was definitely worth the money for me – not having to deal with flaky Mavericks support in VirtualBox alone is worth the price.
For anyone building their own VMWare boxes with Packer and Fusion, note that there's a known issue with shared folders in the current version of VMWare Tools (6.0.2). The workaround is to download Fusion Tools version 6.0.1 and install that instead, as mentioned here: https://communities.vmware.com/thread/462543 Here's a shell script to automate that under Ubuntu if you need to: https://gist.github.com/anonymous/c641a4b0c4ef7b45f07e
Though it's worth mentioning that Ansible is supported as a provisioner out of the box now, you can actually use vagrant with any configuration management system you can imagine; just set the target ip to 127.0.0.1, ssh port to 2222, user to vagrant, and ssh key file to ~/.vagrant.d/insecure_private_key.
(Thats for boxes set up with the default configuration, obviously it would be a little different if you were running a more complex system.)
The only issues I hear about 4.3 are people who have _upgraded_ (not fresh installed) to Mavericks on OS X. Personally, a fresh install of 4.3 on Mavericks and I have no issue.
Mavericks and VB 4.3(4.3.2) doesn't really go hand in hand together, I wasted several hour the day before on trying to configure it properly to no avail, downgraded to 4.2 later on. It's better to stick with 4.2 if you are on mavericks.
I recently acquired a Macbook as my laptop. Vagrant had been a ridiculous blessing. Instead of fiddling around with Macports and Brew and all that nonsense[0], I just Vagrant Up a Ubuntu instance and tadah!
[0] Seriously, developing in R and Python in a OS X environment where you need stuff like Gtk and CairoDevice, it can drive you to tears. Go on OS X was a pleasure.
Similar setup for me as well. I usually develop on my Linux desktop but I also have a MacBook Air. I'd go nuts if I had to actually configure Postgres or an MQ server on it (or even manually in a VM). With Vagrant I have the exact same VM for both machines and its setup via a single "vagrant up".
An even more extreme example is a testing VM I setup with 5 copies of Postgres installed[1]. No mucking about locally and it's one command to spin it up. Way better than manually setting it up and so much easier to share too.
Your testing VM setup sounds like it might be really useful for the pgjdbc-ng project (a project to create a new JDBC driver for Postgres).
I was looking through the project issues on Github yesterday, prior to starting to play around with it and your comment reminded me that one of them was a note from the main developer asking for suggestions on automated testing. Perhaps you could send a pull request ?
Also check out Rove.io (formerly called Hospice.io)
Basically, I code in OS X (sublime text), but the environment the code is run in is essentially Ubuntu (or whatever nonsensical CentOS slow ass thing that I may have to deploy for)
Ah I see, very cool. You mentioned something about Gtk and Cairo — do you ever interact with the VM graphically, or do you only use it as (what amounts to, I suppose) a networked Linux sandbox running inside OS X.
Also, how do you push code to the instance to run/deploy the code?
Vagrant mounts a filesystem at /vagrant on the guest vm with the contents of the folder where your Vagrantfile is. Typically this means you include a Vagrantfile in the root dir of your project, and then your entire project folder is available on the guest box.
I strongly suggest investigating the NFS mount option for this feature if you're using Virtualbox, as the performance difference is substantial over Virtualbox shared folders (which is the default for the /vagrant mount).
I've not tried running anything graphically. My previous machines for the past 7 or so years have been linux. I have my own bootstrap scripts for Python and R and some of the libs require RGtk2 and stuff, which couldn't really work on OS X without a lot of fiddling (but installing them on Ubuntu machines were a breeze).
So when my bootstrap scripts failed, I ran them on a Vagrant based instance instead. Problem solved.
Both. Vagrant creates a virtualbox vm and does the appropriate networking bits to let you ssh into it easily. Even does portforwarding so you can easily reach webservers on the vm on an easy to remember port # from the host (ie localhost:8080 is vm1, localhost:8081 is vm2, etc)
I still don't get vagrant. I create an image in VirtualBox. clone it, then provision with Ansible. The thing that has always bothered me about vagrant boxes is it has stuff baked into the image. I want state EXACTLY like I get on a bare VPS, which is just SSH and root account.
Reverting to a snapshot is faster than using vagrant command line and rerunning all scripts.
I also can't get why people are so excited about vagrant. To start a VM from a base image and invoke Ansible to deploy just require a few commands - The good thing is you can make sure the deployment procedures is the same no matter in development or production environments, as the only dependency is Ansible.
Unfortunately even that's not enough. Vagrant has a lot of dependencies for designers on OS X, and if you bring in NFS (instead of the nearly unusable folder sharing), becomes insanely complicated to explain. Prebuilt Vagrant package with reasonable OOTB folder sharing speed would be perfect IMO.
In theory, you can get an identical VM in any of Vagrant's supported environments. So you set up a dev Virtualbox and deploy on ec2. In practice, I'm sure this requires extensive testing each time you try it.
Also, on Mac OS, the Vagrant install pollutes /usr/bin for no discernible reason. That directory is for the system, not 3rd-party software. See GitHub.app for an example of properly packaged command-line software.
You can also make your own images with the data pre loaded. At one point I was creating/updating/destroying a lot of VMs via Vagrant so to speed things up I made my own images. Then instead of fetching the base precise-64 image and provisioning atop it I could start off with an up to date fully baked VM.
As a bonus you can put them on a local http server and your whole team can download them. Just update the URL in your Vagrantfile.
This is actually what I'm attempting to do right now. Our prod database is Oracle, and trying to automate the installation of Oracle is a huge PITA. So I'm doing it once manually (or somewhat manually at least), and I'll just freeze that vm into my own box that other devs can use at work.
I love vagrant but I'd be interested to know if any pure designers really get much use out of it. It seems a shop that is so well-run as to provide a great vagrant setup for designers would also be a shop that creates project separations/workflows that don't require designers to have a running environment to do their job.
(yes, only in unicorn-land are code-bases separated so cleanly that developers are far-away from application logic...but I'm just speculating that a scenario in which it's more beneficial than time-consuming to setup a turnkey Vagrant solution for a pure designer is also a rare scenario)
I think most designer even don't know how to install vagrant or virtualbox and how to use command-line. In my opinion, it might be better to provide another tutorial for pure designers.
I don't use Vagrant, but it is on my radar. I have a manual virtualbox setup and a few shell aliases that enable me to quickly boot/shutdown virtual environments I need. To anyone who wants to do the same, read a bit about VBoxManage [0]. You can do a lot to manage virtual machines on virtualbox through it.
That said, the nice thing Vagrant brings to the table is it supports multiple providers. I can't seem to see a solid listing of which in their documentation, but they mention by name at least virtualbox, vmware, and AWS. The use of a Vagrant file to configure a new machine is also nice. You can get similar behaviour with Chef/Puppet, or as I do scp in a shell script file and run it.
So, what excites me most about projects like Vagrant and Docker getting popular is that I hate flailing around with build dependencies. I was amazed with apt-get build-dep the first time I used it, but even that has let me down a few times in the past. It's much better than it used to be, but all I want for Christmas is every project to provide a easy to access environment I can grab and build their project with. We seem to be getting closer and closer to this being provided by default, instead of an exceptional circumstance.
We use Vagrant/Chef as part of our production and development workflows at Conspire. Anyone can trivially spin up a complete dev environment—DB, frontend and backend—on their local machine or log in to our staging machine (an EC2 instance) and interact with our production cluster using Vagrant.
Plus, deploying to production is just a matter of a quick "git pull && ./build.sh && vagrant provision" and checking that everything came back up correctly.
Setting all this up took a long time but it was worth it in the end. At the moment we're just using Chef Solo because we only have four machines to deal with. I imagine we'll move to Chef Server at some point in the future.
I'm unsure how exactly chef does its thing, but I found that using puppet apply (similar to Chef Solo), was far superior to using puppet server (which we use for production).
Maintaining usable certificates, sharing them with other devs, synchronising puppet plugins etc was just far too much work, and very time consuming. I also found it a lot nicer to have the explicit puppet configuration right next to the code that runs on it.
I don't know if these kind of setbacks will be similar with Chef Server or not.
Maybe spend some time looking into puppet then? Although if you've already got everything setup there's probably no need to change. That said, I should probably look into chef a little more than I have.
I've tried looking into salt a couple of times, but I find the documentation really lacking. The information is too spread out. I just took another look at the docs and it appears to do just about everything puppet does, but is much easier to configure (puppet-db/mcollective salt-alternatives are default).
Is there a canonical tutorial that's worth reading?
When I looked at Chef, I decided that it was too much overhead, Chef Solo and its brethren didn't really fix the issue. I found Sprinkle to do what I needed, although the documentation can be confusing.
Anyone with experience setting up a win7 under vagrant? All the instructions I found online were cumbersome to the point of not offering much above a basic VirtuaBox setup (E.g. They require you to activate your windows and then re-image).
I think there are two big deterrents for our development team in switching to Vagrant. The team currently works on a single m1.xlarge development server so that they don't have to download the mysql databases to their laptops. That's one. The second one is that they frequently send links to their sites for client review.
I love the concept and would love to make it work for us if we could somehow overcome these.
What kind of dependencies do you usually have in a web app that would lead to the configuration problems described in the designer part? Our designer only needs to to check out the code and make an ssh tunnel for the database for it to work (PHP and webserver already installed on Macs) so not sure what good Vagrant would do.
I've had vagrant pop up, but have yet to explore it. That said, I have many fabric scripts for setting environments up. The link has little detail (first page) on how it would benefit me with an existing toolset.
Are there examples where vagrant compares to something like an existing fabric script?
Vagrant is great if you want to share VMs with co-workers. If you're using Windows and I'm using OSX and we're working on the same project that will be deployed to an Ubuntu machine, we can each `vagrant up` our own virtual machine and they will be exactly the same. Puppet or Chef provisioning of that vagrant VM will be very similar to using fabric to fully configure everything, with the added nicety that there are a tonne of puppet and chef configs that can be reused (not so much with fabric I've found).
So vagrant doesn't give you anything you don't already have if you're just configuring a VM, except maybe the networking and shared folders. But being able to share that VM, destroy it, and rebuild it is where vagrant makes a lot of sense.
Thanks. I wish links where X will solve Y addressed related w/o digging. Sometimes mobile clients aren't the best to search for the related comparison.
Btw, I find the unrelated downvote on my original comment amusing. I wish we could see those doing up/down votes.
How about testing your fabric scripts? You can have a vagrant box configured exactly like your production server and do deploys to it locally using the exact same fabric scripts (just change the requisite fabric env settings). No surprises when you deploy to production.
I have a Linode. It's available anywhere. e.g During I code, my brother asks me to watch his soccer game, and I keep working from a soccer field with my IPad; http://instagram.com/p/dNcNfREmwT/
I live on a big island in the southern hemisphere. Working remotely on a Linode is painful due to latency even with mosh. I tied Fremont for ages but the latency was too much so I moved to Tokyo which is a little better but I still prefer to work with a VM locally. Vagrant gets the job done but I would prefer an alternative.
I don't like Ruby. I don't like running virtualbox when I could be running an lxc jail with something like docker. I think I will be ditching OS X and moving back to a Linux desktop as soon as I find the right laptop.
My VPS is in London, never noticed any latency in Turkey and US. I guess Linode now has bunch of more cities, check them out.
For laptop, I recommend Macbook Air. The design, is a master piece of minimalism. As a guy who used Xmonad for years, I think OSX and a Linux VPS is the zen combo.
Turkey is really close to London. Domestic traffic in Australia travels further than that. It is quite a different matter round tripping packets across the pacific to another continent. I can do minor edits on a Linode but I much prefer using a local solution like vagrant. I would like to ditch OSX but the hardware/os combo is hard to beat.
I do the same, and love it. It really frees me to work anywhere, and instantly connect to an already-running dev-box just where I left it last time.
However, the only problem I have convincing my teammates is that they use TextMate/Sublime, and that's the only thing that seems to break this, where Vagrant is potentially easier (you can share a local folder).
I tried things like rsync and fuse over ssh, but they seem a bit sluggish or not-so-transparent. I wish there was some tool that would solve this.
That's a nonissue for anyone that only codes on one device, and it comes with dependence on a decent internet connection. When you have a decent sized team I imagine a vagrant box and git pull are probably a better option anyways. Plus vagrant is free.
i really like the concept of vagrant and have been using it for all my development for a couple of months, sadly even with using NFS(on OSX) its quite slow when working with larger frameworks.
So i might be going back to local servers and just put DB server and services inside a VM.
And Vagrant 1.4 is also under heavy development with tons of great new features and bug fixes upcoming. See my Twitter stream for more info.
If you have any questions, feel free to ask. And thanks for the support!