For anyone who doesn't know. Vagrant acts like a wrapper around VMware, VirtualBox, or even AWS, so that you can easily automate testing. You can also share your Vagrant boxes (images) with others in an easy manner. Vagrant is one of those things, that once you start to use it, you wonder how you managed without it. I have created several screencasts about Vagrant:
Hey, these are great screencasts, just what I was looking for. Would be awesome to see a screencast that shows how to get an EC2 instance up and running using vagrant.
The biggest thing it adds on top of VirtualBox is a consistent workflow. If it helps, think of what Vagrant does technically as useless, and think of Vagrant only as a process discipline: to get a dev environment for any project you "vagrant up", to close it out "vagrant destroy", to access it "vagrant ssh", etc.
As soon as you get this consistent workflow, then you can teach it to your entire organization and the whole company knows that ANY project in the company can be worked on using this workflow without any dependencies on their own machine.
And if ops decides to suddenly change the dev environment from VirtualBox to say... AWS... nothing changes! I've had large companies (200+ developers) switch from VirtualBox to VMware to AWS for their dev environments without their developers ever really noticing.
That is pretty cool.
Of course, on top of this, you get a lot of nice things: you get provisioners, you get automatic network configuration, you get the entire plugin community, you don't have to worry about stability on your own because you tap the collective stability of thousands of users, etc.
Is this mostly appropriate for web development? Could it work for embedded or desktop development? Seems like it might be a lot of overhead if you only need to install an IDE and a compiler.
Presumably this is also mostly used with Linux. How do people manage Windows licenses with Vagrant?
I am using Vagrant to develop a buildroot based embedded project. I had to use NFS for sharing because of hardlinks generated for buildroot. Other than that everything went smoothly.
With vagrant primary mode of interaction is through ssh (although it supports showing GUI on vagrant up). So I don't think it is a good fit for developing Windows or desktop applications.
I use Vagrant daily. Here's an example I was working on today.
I needed to spin up 5 servers, a load balancer and 2 groups of 2 backend servers. I needed to provision them with Chef, have full name resolution, and be able to access the servers from my host machine.
Here's my Vagrantfile
Vagrant.require_plugin "vagrant-chef-zero"
Vagrant.require_plugin "vagrant-berkshelf"
Vagrant.require_plugin "landrush"
last_ip_octet = 10
DOMAIN = "vagrant.dev"
Vagrant.configure("2") do |config|
config.landrush.enable
config.chef_zero.chef_repo_path = "./"
config.omnibus.chef_version = '11.8.0'
config.vm.box = "opscode_ubuntu-12.04_provisionerless"
config.vm.box_url = "https://opscode-vm.s3.amazonaws.com/vagrant/opscode_ubuntu-12.04_provisionerless.box"
%w{default metrics}.each do |backend|
(1..2).each do |i|
config.vm.define "be_#{backend}_#{i}".to_sym do |cfg|
last_ip_octet += 1
cfg.vm.hostname = "be-#{backend}-#{i}.#{DOMAIN}"
cfg.vm.network :private_network, :ip => "192.168.33."+last_ip_octet.to_s
cfg.vm.provision :chef_client do |chef|
chef.node_name = "be-#{backend}-#{i}"
chef.add_role "backend_#{backend}"
end
end
end
end
config.vm.provision :shell, :inline => "/usr/bin/apt-get update --fix-missing"
config.vm.define :lb do |cfg|
last_ip_octet += 1
lb_ip = "192.168.33."+last_ip_octet.to_s
cfg.vm.hostname = "lb.#{DOMAIN}"
cfg.vm.network :private_network, :ip => lb_ip
cfg.vm.provision :chef_client do |chef|
chef.node_name = "lb"
chef.add_role "lb"
end
end
end
This utilizes a few vagrant plugins, vagrant-chef-zero, vagrant-berkshelf, and landrush which are one liners each to install. After that, I can type
vagrant up # build my stack from scratch
vagrant destroy # destroy my stack
vagrant ssh lb # ssh into the lb instance
vagrant provision # execute chef (puppet, ansible, bash, etc)
Can you show me equivalent code that fulfills all my requirements using VirtualBox directly and will allow me to change a couple lines to spin this same infrastructure up in AWS or using VMWare?
Not the parent post, but from my limited use of Vagrant so far, the main difference is that there's a "base" image that you can quickly reset to in order to test the repeat-ability of your deploys. The images also automatically handle VirtualBox's shared folders feature and require little for configuration.
Other than that, I agree it's almost like just using VBox directly.
What? Automatically installing VirtualBox images, and setting them up with a development environment in 2-3 commands does seem "that different than just using VirtualBox directly"?
A shell script that can spin up VirtualBox images and run puppet to provision them isn't very difficult to make and would vastly outperform vagrant.
Vagrant isn't very good as a piece of software, it's very good as a standard, because it can be used as a standard description of a development environment.
I've just spent 5 minutes trying to learn what Vagrant is and how it works. The home page didn't help me with that AT ALL. It's full of vague terms like "development environment" and "work environment" and buzzwords claiming to "maximize productivity".
In your About page, please describe the typical USAGE SCENARIOS of your software and how does it help in those cases exactly.
This is linked in the 2nd sentence in the getting started section that is linked from one of the two biggest call-to-actions on the homepage: http://docs.vagrantup.com/v2/why-vagrant/
Thanks for pointing that out. I still think it would need a concrete example or two. The text is very abstract, long sentences with multiple consecutive adjectives describing how easy it is to use and how powerful it all is. A lot of fluff really. You're trying to sell the idea, not describe how it works.
I'm SURE it's a fine tool and I'm just trying to help you communicating it better. :)
Well to be fair the "Why Vagrant?" page [1] isn't exactly clear about whether this is a tool for building throwaway environments or if it's something I should use to build out production systems:
"If you're a developer, Vagrant will isolate dependencies and their configuration within a single ==>disposable<=="
"If you're an operations engineer, Vagrant gives you a ==>disposable<== environment"
All I can infer from the page is that this is a tool for building throwaway/local environments running on VM's on my desktop. But there isn't any context given on how this relates to my production environments, i.e. getting from Vagrant instance to production, there's a disconnect there for me.
>Well to be fair the "Why Vagrant?" page [1] isn't exactly clear about whether this is a tool for building throwaway environments or if it's something I should use to build out production systems
Yes, very good, I know what Vagrant is I'm just not sure where it fits into my workflow going from dev into production. Neither the official website or that scant Wikipedia article answers my question.
Perhaps if you have enough time to patronise others you could use it more fruitfully to be constructive.
>Perhaps if you have enough time to patronise others you could use it more fruitfully to be constructive.
Sure, but where's the fun in that?
In any case, there's the evergreen "using X in production" Google search. Substitute X gor Vagrant and you'll be well on your way of knowing if it's a good idea or not and how to do it.
I didn't know what Vagrant was. Ofcourse I could have googled a bit but I decided to "test" the webpages whether they provided me the info I wanted. They kinda didn't.
Whether I SHOULD HAVE known about Vagrant, I'll let you decide. ;)
I had hoped that their Docker support would be some magical mechanism that would treat Docker as a kind of VirtualBox. That is, instead of using VirtualBox to create VMs, they would use Docker to create containers. 'vagrant ssh' would then SSH directly into a container instead of the host VM.
Sadly, their Docker support is just a provisioner. :( I can do that myself too in a shell script.
There's not really a way to do that uniformly right now on any system that isn't Linux. I agree that it would be ideal, but the core philosophy behind Vagrant is a single configuration recipe to create portable environments (development). You can do a lot of things in shell scripts, but its still easier to have it all in one place in an easily grokable format.
To use docker on my mac I have replaced Vagrant with boot2docker (http://github.com/steeve/boot2docker). I didn't need all the moving parts anyway - the VM is always the same, the application-specific bits are all defined inside the containers.
I last time I used vagrant was 1.2 on whatever the latest virtualbox at the time was. The performance was about half as good as the host machine. The host machine was running the desktop version of Ubuntu at the time. I was not able to easily identify if VirtualBox's performance problems were CPU or IO bound. If I hear that the performance is close to native, I'll give it another try. Otherwise, I can't see the point.
When I was using vagrant 1.2, lxc containers were not fully functional so I didn't bother trying with lxc. I'll gladly give it another try to see if performance is significantly better than virtalbox. Thanks for the tip by the way.
We're using vagrant and ansible to manage local dev instances with the same ansible scripts responsible for provisioning/deployment to our production boxes. My thought being the less I manage with vagrant, and the more I codify stuff in ansible, the more predictable things are when I go to provision/deploy in production.
I'm thrilled with how vagrant helps the process locally, but at the same time want to do as little as possible in vagrant because it's not applicable/involved when I provision/manage a box @ Linode or Digital Ocean.
Am I under-utilizing vagrant? Or missing a greater benefit by limiting its role?
I'm afraid of upgrading vagrant now like I am afraid of upgrading bootstrap.
Too many things break - it's simply not worth the trouble of upgrading and finding all the gotchas scattered all over the place in my config files and code.
I started the vagrant-spec project to address this. A system like Vagrant is hard to fully unit test because there are a lot of side-effecty things that it does. In many cases, the best way to test it is to run things in a real-life scenario.
vagrant-spec includes a acceptance suite that we're going to be building up in order to test more of the features in a black box manner. It is slow to run but if we verify that things are passing before a release, we should be able to catch most daily use cases.
Vagrant 1.4 is the first release to run through vagrant-spec and while there are some early bug reports in some fringe areas of Vagrant trickling in, Vagrant seems to be a drop-in upgrade for most users. This shows that it is working, to some extent. And it'll only get better.
Of course, if you're nervous about it, it doesn't hurt to wait for a 1.4.1 or so on.
Congratulations to mitchellh and the Vagrant team. Vagrant is a fantastic tool for streamlining workflows, but also an amazing educational opportunity. Disposable Linux servers: Play, experiment, destroy, try again. Thank you for this, I can't believe how much I've learned.
> Work will begin on pulling the Vagrant AWS integration into the core distribution -- to start -- so that you can use Vagrant with AWS (and other providers) right after installing it and without having to juggle plugin versions.
This is awesome, I can't wait. I've been waiting for this!
Most of my projects right now have had all of their Vagrant plugin dependencies, including Vagrant itself, in the Gemfile because I wanted to make sure any developer could get a workable development environment without worrying too much about Vagrant versions. On one hand I like the fact that I can install up-to-date plugins this way, but on the other hand I just want it to work out of the box.
Although I doubt we'll be able to get away from this. More likely it will cause other frustrations such as needing to override a plugin with a monkey patch, etc.
I really like how Gradle has solved this problem. You check in the Gradle wrapper (http://www.gradle.org/docs/current/userguide/gradle_wrapper....) into your source control (it's only 56K), and it automatically fetches Gradle for you if you don't have it. Updating the project's Gradle version is just a matter of changing one or two lines.
It's cool to think that the only requirement for anybody to jump into a Gradle project is to have the JDK installed. "git clone <project>", "./gradlew assemble" is all it takes for you to fetch all your dependencies and build the project.
I think it'd be interesting to see if Vagrant could incorporate something like this; it sounds like it would help your use case.
> It's cool to think that the only requirement for anybody to jump into a Gradle project is to have the JDK installed.
Sounds like a commercial. Many people have good things to say about Gradle's functionality, but too bad about the programming language I have to use with it, i.e. Groovy, at an old 1.x version, with a bloated grammar spec using an old 2.x version of Antlr, i.e. http://svn.codehaus.org/groovy/trunk/groovy/groovy-core/src/...
Too bad I can't use a language with a simplified easy-to-remember grammar, like Scala, to program Gradle.
The latest Gradle release notes http://www.gradle.org/docs/current/release-notes always mention both Groovy and Scala when describing how to build projects, but all the build script example code is in that Groovy language. Will Gradle ever expose an API so developers can choose to use the same language for the build scripts as they do for the projects they're building? Perhaps even ship Gradle with different build language options?
This is fantastic! I just used Vagrant to help automate testing on an email library I wrote (https://github.com/tedivm/Fetch, if anyone is interested- new tests are in the "testing" branch).
Vagrant made setting that up really easy. In fact, the hardest part was scripting different responses for whether the machine was already up or not, and the new Machine-Readable Output will make that far, far easier.
Probably not the right venue, but I'm a bit disappointed addressing the plugin versioning situation isn't listed as a thing for 1.5. There are plugins for managing plugins but they're really less than ideal.
I'd honestly just like to use bundler for it, since it's almost certainly better than anything anyone's likely to make to replace it, but using bundler to run vagrant is currently considered bad for some reason and outputs a frightening warning.
Bundler doesn't work with Vagrant because Vagrant ships with its own Ruby and RubyGems and all that. So... your Bundler you're executing has a really screwed up state of the world.
Its something that certainly needs to be solved, but I think solutions needs more time to mature in my head as well as others.
The problem right now is that plugins create a screwed up state of the world and their usefulness is rapidly climbing.
Installing the vagrant-chef-zero plugin, for example, is a real PITA because the dependency resolution doesn't deal with a json dependency correctly leading to it or chef zero failing to load unless you install them in a very specific order.
On the other end of the spectrum, when you're writing a Vagrantfile it's technically almost impossible to know what's going to happen when a user starts it up because of all the hooks plugins can throw in, and you can't tell Vagrant not to load a plugin (which would be an incomplete solution anyways, since I can't know what plugins or plugin versions will have bad interactions).
I know you wrote vagrant, so you have a more inside perspective on this, but as a user and occasional plugin writer, it feels like with a gemfile I can specify a state of the world that's considerably less screwed up than the completely random world any given user's install of Vagrant might be.
Vagrant is an awesome tool for CI. I have used it extensively with Jenkins to provision environments, AWS deployments and Digital Ocean Servers.
Recently I have used vagrant to easily manage OSX 10.8 guests on vmware-fusion, as the demand to provision environments for ios-related development is on the increase. I am not aware of any other tool that makes this easier. Vagrant RAWKS!
So you can now enforce vagrant versions in your Vagrantfile, which is great, but this is a new feature thus older versions of vagrant won't honour it...so this feature is useless for me, at least for a while. I will continue to do this: https://gist.github.com/badsyntax/7803472
Learning Vagrant @ http://sysadmincasts.com/episodes/4-vagrant
Create a Vagrant box with Veewee @ http://sysadmincasts.com/episodes/5-create-a-vagrant-box-wit...
Learning Puppet with Vagrant @ http://sysadmincasts.com/episodes/8-learning-puppet-with-vag...
Managing Iptables with Puppet @ http://sysadmincasts.com/episodes/18-managing-iptables-with-...