Vagrant creator here. What a pleasant surprise to see this pop up on HN this morning (it was unexpected, to be sure). I just want to shamelessly say that if you're more of a book person, the Vagrant O'Reilly book I wrote was just released this week, and it is a great way to get started:
(And, hopefully as you know, as an author I make barely any royalties on any book sold, so I'm not posting this for financial reasons. I just know some people really prefer books to online docs.)
If you have any input over the sample chapter, it'd be nice if it could represent a portion of a "real" chapter of the book. Right now it just provides the "how to install Vagrant" section, which isn't really representative of the book's content.
Absolutely. I will not cover version 2 of Vagrant until Vagrant 2.0 is actually released. The book uses version 1 configuration syntax running in the latest version of Vagrant. This allows you to get all the benefits of the latest stability improvements, while using a stable configuration syntax.
The book will be fully updated to version 2.0 when that is stable, in the sense that configuration will no longer change. Thousands of companies are already on the latest version of Vagrant and using it without issue.
I'm working on this now. I won't say much more than that until I have something to really show for it.
Development environments are the primary focus on Vagrant because that was the pain point it was initially meant to solve, and it does this quite well. The workflow model Vagrant introduces doesn't translate as well into staging/production yet. I'm actively investigating the use cases here and how Vagrant may adapt to it (if at all).
I was approached by O'Reilly very early. I wasn't even considering writing a book prior to that. However, my experience with O'Reilly has been _fantastic_. I was never writing the book for money, I was writing it for publicity and to help push the project forward. For these reasons, O'Reilly was the clear winner.
Additionally, everyone I've ever worked with at O'Reilly has been very professional, and they've been doing a great job helping push the book forward. They even rushed the production process (editing, indexing, proofreading, printing, etc.) from their typical timelines down to only a couple weeks so the book would be fully ready for VelocityConf in a couple weeks. And they did it! I'll be at VelocityConf signing books.
We switched from hand-configured boxes and a long, "full stack local" setup document to chef + vagrant at my current company (http://parse.ly).
Though it caused some kicking & screaming on the development team, the end result is that every developer has the same development environment, which pretty much matches our deployment environment (in Rackspace Cloud). I also just kicked off our summer intern class, and the interns were able to get productive with our codebase in 1 day despite not having much experience with modern Python web development, because pretty much every local setup step was automated.
I consider the tool invaluable. I don't even install any databases or tools directly on my laptop any longer. With its handy port forwarding feature, you can put all your DBs on a VM, yet still connect w/ CLI clients via your host machine. Then when you do "vagrant halt", all your DBs shut down at once and you free all those resources / memory / etc.
Also, one suggestion -- look into the debug logging level that you can set with an environmental variable. The only thing I found frustrating about Vagrant were situations where it would hang/fail but it wouldn't be clear why. It turns out their debug logging is quite good.
These systems are broadly the same. If you're writing your configuration from scratch, they're all fairly pleasant, and it's mostly a matter of preference. They share most of the same concepts (although the terminology differs) and features. In my experience, their differences are primarily in feel and community.
For feel: Chef gives you Ruby pretending to be declarative. Puppet and Ansible give you something more declarative at the expense of some expressivity. Puppet has its own syntax, and Ansible shoe-horns some procedural aspects into YAML syntax. I prefer Chef here. (Chef also provides a web UI that lets you edit things, but I strongly advise against using it except for managing nodes. Everything else should be code/JSON.)
For community: With configuration management, one of the things you'll want is good community involvement. You don't want to write every cookbook/playbook/module from scratch. From what I've seen, Chef and Puppet have a large head start in this department.
That said, you should be prepared to customize the community offerings. People generally implement precisely what they need, in precisely the way they need it, and your needs will not always align. Fork all of the community offerings so you can modify them while still pulling from upstream. Managing this is decidedly difficult, but there's no better choice. It's one of the areas where git submodules would be really great, if only they were nicer to use. If you're going to use Chef, consider also using Berkshelf for managing your cookbooks.
If you do not have configuration management in place, pick one of the major ones, learn the hell out of it, and get to automating your operations. Having your infrastructure as code that you can run whenever you want, that you can review to see exactly how something is configured, is life changing. Once you get to doing it, you will never want to go back to the bad old days.
Chef and Puppet are quite different, in my opinion.
Based on my exposure, Chef ultimately boils down to being a complex remote execution framework. Puppet makes detect-and-correct more central to its model.
Dell and Amazon leveraged chef to help build Crowbar and Opsworks respectively. Crowbar ... leveraging ... get it?
In any case, noting Opsworks is based on Chef is not an "appeal to authority".[1] That knowing Chef means you have a head start on AWS's official devops tooling, seems a relevant data point for a comparison. (The officially supported devops tooling leveraging a particular CM system is different from simply being able to be managed by a CM system.)
As for Rackspace, here's the CM category of their dev blog:
Quoting a different Rackspace article from Feb 2013:
The Rackspace Private Cloud Certification team sought out and tested a number of bare metal provisioning tools. While there are a number of excellent tools on the market, none seemed to fit quite well. On one hand, some tools were all-encompassing in scope and would try to provide an end-to-end solution. On the other hand, tools were too narrow in scope and provided a solution for a specific operating system or did not provide an appropriate amount of flexibility.
Eventually, we picked a deployment model consisting of a combination of tools that would provide the right balance of features and flexibility. We chose the Razor provisioning engine, combined with the OpsCode Chef configuration management tool.
It's on the list, too, but I (possibly incorrectly) see Chef and Ansible having a more similar philosophy and workflow to each other than to Puppet so I am hoping to eliminate one of them.
How are you reloading your Python application on code changes? Are you just working inside the VM? I've tried VirtualBox shared folders and NFS, and never had any luck getting file change events to propagate from my host to the VM.
Shared folders work well for me & everyone else on me team. Perhaps you should file a ticket for your issue?
Also, if you use port forwarding for all your databases etc. then you could technically just run Python code on your host computer. Indeed, I do this myself usually -- I treat the Vagrant box more like a "deployment target" that just happens to also run the DBs I can use for local testing.
I, too, have had problems. In my case it's an OSX host, Ubuntu client.
Most of my python work isn't webdev so I've never had an issue with it in python but other daemons that do this sort of thing -- Brunch for example -- have given me intermittent trouble. I never did figure it out.
@pixelmonkey i recently implemented a chef/vagrant deployment to the rackspace cloud. I'm extremely curious how you managed to share the setup between rackspace cloud and local vagrant boxes. I used the vagrant-rackspace plugin, and it seemed like I would need a separate vagrantfile for local vs remote deployments.
Vagrant is a nice tool, but I don't like the closed-open source part of it. There are 289 open issues and 79 open pull requests on github right now. It feels like there is a huge community out there who want to move this project forward, but there is the bottleneck of having only one committer who wants to have too much control over it. It's fine and the author can do what he wants, but I'm wondering what the project could achieve if it was more open to contributions and more people could actively work on it.
As a user, looking at those 289 open issues with only one developer, I don't feel at all encouraged to open a new one or send a pull request, because I just see a huge pile of things that the committer will have to wade through before getting to mine.
Actually, the number of issues/pull requests is higher than usual right now. You're right that at the moment I'm a bottleneck. I'm looking to change that (I want to add more committers).
However, historically I think I've been very good about responding to issues rather quickly. Unfortunately, the past 6 weeks I've been quite bad at it as I've been focussing on something you'll hopefully see in a few weeks. Again, this highlights the problem of being a bottleneck.
And just to prove how cool @mitchellh is (or at least to prove the fact that he takes HN comments seriously), he has added another committer to Vagrant today.
Its a great little tool. I have been using it for a over a year now and it simplifies the dev environment issues by sandboxing it. In general, it allows you to isolate your development servers and other such programs and libraries in a sandbox. You can use the editors, browsers etc on your local machine however the servers and other heavy lifting can be done by the vm in the sandbox env. I think this is still bleeding edge stuff as I dont see very many developers using this. Would love to hear experiences of fellow hackers.
One question - I use vagrant with VirtualBox as the provider. Has any body used vagrant with the VMware provider. Wondering if one sees better performance on vmware than virtualbox. Specially when you are running everything (host and guest) on the same hdd.
On my Mac, using VMware was rougly 4 times faster than VirtualBox, particularly when running very long puppet scripts and using memory. I was very happy to pay for the VMware Fusion support and to buy VMware Fusion in the first place (it is 10x better than Parallels for the VM client drivers alone). The tricky bits for me were, at least a few months ago, some of the commands were different and of course the base OS VMs should be different given different client drivers. But it is possible to have one Vagrantfile serve both VirtualBox and VMware Fusion, so devs can choose which environment works best for them.
I've used both. Honestly, I don't have any hard stats to back this up but in a Unix environment, VirtualBox is the way to go. I've done a bit of dev on a Windows machine, for training purposes, and I've found that VMware has better performance.
Again, this is based solely on subjective, empirical data.
Vagrant looks interesting but I am not sure why I would use it. Almost all of my work involves using Clojure and I default to using Postgres except in exceptional circumstances. It is so easy to have the same setup on my OS X and Linux laptops as my servers. I have never run into any compatibility problems, at least that I am aware of.
Vagrant looks more useful for systems with lots of moving parts.
I am starting a new project with Node.js, Meteor and MongoDB - also an easy to set up stack. I will keep Vagrant in mind, but I hope I don't need it.
There are many beautiful aspects of Vagrant. These are true whether you work solo or with a team.
* If your machine is OS/X, but you deploy to Ubuntu then you aren't developing in a realistic environment. Using Vagrant you get to work with OS/X tools, but run your app on an Ubuntu(or whatever) OS. I use NFS file share, edit on the Mac, run in the VM.
* Keeps your machine clean. If you work on multiple projects, perhaps running different versions of Node, Ruby, MySQL, Reis, PostGres, etc, you keep them isolated to their VM.
* You can experiment. Want to try your app out in Arch, a different version of Ubuntu, etc? Spin up a new VM or clone an existing VM.
* Have a new machine? Copy over your VMs and start working right away.
* The environment it setup as a script. Have a new developer for your application? Just send them the scripts to spin up a new VM. I use Bash scripts to configure my VM's, or you can use Chef or Puppet.
It's really nice to be able branch, commit, merge, go back, whatever with your installed infrastructure. This gets even better if you use puppet or chef (or even the shell) for provisioning of infrastructure in concert with vagrant.
Doing the same thing with snapshots and VM clones with VirtualBox alone is similar to zipping your project periodically as a backup strategy. Yeah,, it works, but it has no granularity.
Bottom line though, it feels very liberating at any point to be able to flip the fuckit bit, do a vagrant destroy and vagrant up and just start over. It makes for painless experimentation on your VM, among other things. Once you've got what you want, you can formalize it in your Vagrantfile, puppet manifests or other versioned artifacts of development.
Huh, so can you "branch" a VM with vagrant? Like say I want to make some incompatible/lossy changes to my database schema, can I fork my dev environment, do my migrations to the new schema, and then go back if I don't like it?
Vagrant works by describing a machine or group of machines. It hands off to Chef or Puppet, which then do the job of bringing the naked machine up to something nearly identical to your production environment.
You can snapshot to binary blob too, but having code that rebuilds from scratch is a great way to smoke out certain classes of dependency conflicts. It also provides assurance that if a hurricane turns some data centre into lego bricks, you can rebuild an identical setup somewhere else with a single command.
I like to be able to script my environment and put it in a git repo for others who may join the team, or myself (when I repave my machine, for example). Also I've found the upfront effort to write the recipe (I tend to write lean recipes, rather than use community ones, as I see a lot of bloat and unneeded dependencies) helps me identify dependencies early on. (For example, say I need Selenium or Jenkins - my local machine's Java has been long working, so the cleanroom environment helps me identify gotchas I wouldn't otherwise see until deployment)
Thanks for screencasts - your episode 5 is missing audio making it harder to grock the context, just heads up in case this is unintended so you can fix
I am using a javascript player, which should send you the correct file, based on your browsers support for webm and/or mp4/flash. I have verified that both versions contain audio. So, I suspect there is some browser issue at play here. Anyone else reading this, and who has watched episode #5, want to comment on if it has audio?
Vagrant is absolutely fantastic. But I have an issue with the default precise64 box.
If the vm is shut down abnormally (manual power off from virtualbox, unexpected power outage, etc), next time I run `vagrant up`, the vm would be stuck on grub. It appear to be a problem with ubuntu and I need to start the vm in gui mode (as opposed to vagrant's default headless mode) to resolve this (changed timeout=-1 to timeout=0 in /etc/grub.d/00_header and run update-grub).
The discussion on https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/669481 indicates that a fix has been released, although one wasn't - a 12.04 default server install will STILL happily hang after a boot problem until you press "enter" on your keyboard. Additional reboots will not help.
And given that 12.04 is still the LTS version, it makes Ubuntu unusable for long term remote servers unless you have an IPKVM.
Of course, after 12.04.03 you can update your /etc/default/grub to include:
I was first introduced to Vagrant at my current company - where my manager had prepared a VM + set of Chef recipes for setting up and managing VM hosting our app.
I had spent few days later setting up few VM's for my personal projects - I must say that having easily deployable VM's, each one serving specific purposes, all on my laptop, using just one base box (CentOS in my case) is a really a time saver - especially when dealing with projects utilising multiple technologies. But what is most important is the fact, that all those technologies are not polluting the main machine and creating misc combinations of them is as easy as branching / cloning my Chef + Librarian + Knife repo.
I've used one VM for deploying my several small projects in the past. I'm definitely curious about separate sandboxes for them when developing locally - one chef-solo and vagrant instance for each - but it seems like it would be a lot more expensive to deploy them to separate boxes afterward. Is there an easy way to "merge" them back into one box when deploying?
... I guess that doesn't make sense. I should have the local vagrant/chef-solo mirror how I have my production server; all projects combined. But at least the chef recipes will make it easier to split things apart once I want to separate projects to different servers for traffic reasons.
I wanted to call out the advice from that article to use fabric (if you use python) to control the vagrant+VM instances. You use chef/puppet to configure the VM, and then use fabric to, for instance, switch between virtualenvs for different apps within the virtual host. I used it that summer to work on a web app while I took my daughter to swim lessons, and it was well worth my while.
It seems the future for this kind of projects is very bright. When I have time I'll look into vagrant and docker. I also need to learn either puppet or chef... I've got a busy summer schedule!
(Any other related, interesting technologies I should add to that list?)
Vagrant is great. IMHO every open source project should come with an example Vagrantfile or Dockerfile to help get users/developers up and running quickly.
A noob(ish) question but does anyone here use Vagrant by itself (or w/ chef-solo). For example can you do multi-VM setups directly to the AWS provider and local VirtualBox all on the same single Vagrantfile config? And thanks for the tip on veewee as it looks exactly what I was looking for to build a company basebox for faster testing. Much appreciated.
It looks like Vagrant is designed to help out web developers more than anything else.
I develop primarily for microcontrollers, and it can be a pain to manage toolchains for different architectures. Would Vagrant help with that? Does anyone have an examples of using Vagrant like this?
I've been using it for microcontroller development lately and it seems like a nice way to preserve and share toolchain configuration. You define everything once (compilers, makefiles, drivers, etc) and then share it with people on your team, regardless of what OS they're using. VirtualBox allows you to set up USB port forwarding so you can even program and debug from the command-line.
Has anyone had much luck using Chef solo to provision their Vagrant box AND their production/staging environments? I'm currently attempting this, and it has been kind of a pain in the ass. Chef-solo seems woefully underpowered.
I've switched to using Ansible for this very reason (after getting frustated with Puppet) - I like it a lot. Also I just want to join the choir: Vagrant is awesome!
I haven't done much research, but is there a way to share a running instance with others? Can I configure/setup/tinker-with an instance, suspend it and share that with someone?
I use Vagrant for every project now. I used to work with a single VM with all of my projects, but dependencies were hard. Vagrant makes everything nicely sandboxed.
One thing I found difficult is that Chef or Puppet are hard to combine with Vagrant, not having used either before. The quality of instructions and recipes for simple stacks (PHP, Django, etc) even for Ubuntu require tweaks here and there. I've now however found recipes I've tweaked for both examples that work well.
I have never heard of Vagrant. The home page is, as usual, devoid of information. This is what Wikipedia says:
> Vagrant (software)
> From Wikipedia, the free encyclopedia
> Vagrant is open-source software for creating and configuring virtual development environments. It can be considered a wrapper around VirtualBox and configuration management software such as Chef, Salt and Puppet. Although written in Ruby, it is usable in other programming projects such as PHP, Python, Java, and C#.
It depends on what you want to do. Vagrant's main use case is to automate setting up development environments, whereas I see Docker as more a way of distributing software and its dependencies to production systems.
A key distinction is that since Docker is built on Linux containers (lightweight Linux systems), it expects to share its host's kernel, and must thus be executed on a Linux system.
http://shop.oreilly.com/product/0636920026358.do
Thanks!
(And, hopefully as you know, as an author I make barely any royalties on any book sold, so I'm not posting this for financial reasons. I just know some people really prefer books to online docs.)