Vagrant: Create and configure portable development environments
vagrantup.com
vagrantup.com
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.)
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.
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.
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).
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.
:)
* Buy a VMware provider ($79). 98% of the money comes to me.
* GitTip: https://www.gittip.com/mitchellh/
* Buy the Vagrant book: http://hashi.co/vagrant-book I only get a few dollars from this.
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.
$ VAGRANT_LOG=[debug, info, warn, or error] vagrant up
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.
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.
http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reign...
Appeals to authority don't tell us anything about the technology except that somebody we've heard of is using 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:
http://developer.rackspace.com/blog/categories/configuration-management/
http://developer.rackspace.com/blog/cooking-with-chef4.html
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.
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.
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.
Keeping the long story short - it's a configuration management system. Have a look at http://www.opscode.com/chef/
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.
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.
I'd love to promote more committers.
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.
Again, this is based solely on subjective, empirical data.
And yes, Vagrant is awesome.
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.
* 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.
If you mess up your db config while performance tuning, for example, just call vagrant destroy and vagrant up.
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.
Is good.
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.
Episode #4 - Vagrant [1]
Episode #5 - Create a Vagrant box with Veewee [2]
[2] http://sysadmincasts.com/episodes/5-create-a-vagrant-box-wit...
You can download the raw content via these two files, so you can watch locally on your computer (both the same, just different formats):
http://sysadmincasts.com/static/videos/5-create-a-vagrant-box-with-veewee.mp4
http://sysadmincasts.com/static/videos/5-create-a-vagrant-box-with-veewee.webm
Thanks, Justin
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:
GRUB_RECORDFAIL_TIMEOUT=0
grub-update
DEBIAN_FRONTEND=noninteractive dpkg-reconfigure grub-pc
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 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.
(Any other related, interesting technologies I should add to that list?)
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?
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.
> 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#.
Ps. please fix the issue where on disconnect, you can't vagrant ssh back, the only fix I've found is to restart the vm using virtualbox.
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.