 coolest thing ever. And I think they're going to change. If what I'm going to present today doesn't change the way you work, then virtual machines will change the way you work in the next five years. So I'm Mitchell Oshimoto. That's the avatar page everywhere. I live in Seattle, Washington right now. That's the background of this year. But I fly down here all the time. I want to give a quick shout out to LA review grade. If you want cool ideas, you just want to hack with really smart review people like Evan Phoenix. Go to this thing every Tuesday, it's really fun. And at the same time, I want to give a shout out to Seattle.RV because I go to this every week as well. Well not as well, depending if I'm in Seattle or LA. And the same deal. And at the same time, all my work and my presence here are sponsored by Engineering. And so they get a slam. So let's take a look at how do we work now. I'm going to focus on web development. But you should know there's a lot of people using virtual machines for a lot of other problems as well. But the original problem I built data for was the solve web development issues I had. So that's an example we need. This should look familiar to most of you. It's a three step process that you should all be familiar with. The first step is checking out your source code from somewhere. The second process is kind of a mystery. And the third is usually the server is up and running. And by this third step, I mean, you could go online and interact completely with the website. Every part of the website should work. But I want to focus specifically on the second point here. This is always kind of like black magic. There's a few different ways this could work. The best case scenario is you ever read me that looks like this. And this is like, if I worked on a project and saw this, I'd be really happy. Because this almost never happens. But usually check out your source code and you follow the steps and you try to install this on your local machine. More likely you check out the source code. You try to run it. You see what stack traces are thrown and slowly cobble it together. But that's what we're looking at. And thank you, Brian. G-willigers. G-willigers. Most of you probably aren't thinking this right now. This is how you work and you're okay with that. You think that's how it's supposed to be. But there's actually a lot of problems with this. And I'm going to go through them real quick. The first problem is it's not repeatable. So on a very basic level, that just means if you have a laptop and a workstation, you've got to do this manual stuff on both. Which is a time issue, but really just kind of annoying. But the more important issue is you can't really go back in time. You set this all up. Imagine you work on a website and you work on some major new feature, which has a lot of code change, maybe infrastructure change. And all you're working on at your boss is, well, you've got to fix some bugs on your main website because that's launched and what you're working on isn't. And so your only option right now is to try to bandaid your infrastructure to work with your old website and hope that you could continue fixing things. Or perhaps just throw everything you have away, work on another machine or who knows. So that's an issue, not possible right now. The other issue is it's not verifiable. So this, I mean, you could get your infrastructure running, you could run your unit integration test and they could all pass and so everything seems okay. But since you're running a readme and it's a manual process, you can't actually verify everything set up correctly. So if you have slight configuration differences or version differences, or maybe your system had changed something, you won't actually know until down the road. And this problem will happen at some point and it's going to be one of those problems that you're going to find on a Friday night and it's going to take until Saturday afternoon to fix and you're going to realize it's not good. And then the third problem is it's not isolated. Test, test. The third problem is it's not isolated. And again on a very surface level, very basic, you are running your web server on the same, and your old infrastructure on the same machine as you're running a Twitter plan and your browser and all sorts of other crap we run on our local machines. And modern operating systems are good, like this probably won't get in your way and it'll never be a problem. But a bigger issue or more real thing is if you're working on a mature website, it's probably more like a service oriented architecture. There's going to be multiple pieces that talk to each other one way or another. And you're going to try to run this all on your own machine. And the example I give is, I talked to someone that works at white pages and they have a separate server that does this, I guess it's a standard thing in the white pages and yellow pages industry where it takes a human entered address and they just send it to the service and it returns this queryable binary format that they can use internally. And their developers actually just try to run this on their own machine. And it's meant to run a completely different infrastructure. So trying to run it alongside your web server and all that doesn't work too well. So you're not isolated. So now virtual machines are the answer to all these problems and more. They're isolated, I don't think I need to explain this, they're just inherently isolated, you all know that. But more importantly, with the isolated nature, you can run multiple virtual machines and simulate that service oriented architecture I was talking about. You get repeatability at through beta DevOps here because your company probably has a system and the system is like sole purpose. It's getting paid to efficiently and safely set up your servers. So he probably has scripts to set up your servers. So why aren't we using these scripts to set up our development? Because they're already done and they will match production exactly. So any bugs you have on development will exist on production. And you can also model complex relationships. And so this is kind of going back to the service oriented architecture. You can do a lot of things that you can't do on your local machine. You can simulate latency between virtual machines. You could throw up a cluster of virtual machines and work them together and then just demolish one of them and see how your system reacts. And it's really hard to do this on just in a single address. And for the business people or the managers or directors of engineering out there, these are a couple points that you could also use to convince your boss to leave an idea. You get faster resource onboarding. And by that I mean if you hire someone, they don't have to spend a day learning infrastructure or anything. You just throw them a virtual machine image and they should be able to get committed by that day. And designers could do it too. Designers like this a lot because usually the way it works is you sacrifice an engineer's time and an engineer's time is really expensive and we all know that. And you sacrifice half their day or even the full day where they sit with a designer and they set up the whole thing on the designer's machine so the designer could sit there and just basically either read on their website to test their designs. But with a virtual machine, they could just run it all the time and they could run any version of the website. And for more visual people, this is a slide I showed at the Meetup Room but that almost took out, but people liked it. This is what your development looks like right now and the goal is to make it look like this and possibly a multiple of these virtual iOS OSs up there that all of us can make. This is exciting. If you're not really excited right now then you should get that checked out. It's not human. So by now I hope I convinced you that using virtual machines is a pretty good idea and what you're doing right now is kind of crazy but we all are doing right now is kind of crazy and I'm going to introduce Baker as a way to solve this problem and Baker is a tool that myself and John Bender, I don't know where he is but he's out there. We wrote about it over a year ago now and we basically took the manual steps out of setting up a virtual machine and since then it's evolved into quite a beast. And so what is it? The tool for managing your development environments it basically allows you to describe your virtual machines in a version controlable way and also gives you a command line tool to spin up virtual machines, destroy virtual machines, etc. You can think of Baker kind of as the local EC2 hosts. You can just think of them as instances on your computer and a really important point is this it was built with the original goal and it still to this day stays out of your way because as web developers over the years we've developed processes that make us really efficient at what we do. We have our special text editor, Emacs or Vim or something crappier. We have our web browser, Firebug, Web Inspector, whatever you have. When we see a stack tray, so we see something that's not working right we know exactly what to do to start debugging that thing and we usually fix it really fast and so any tool that comes and threatens that shouldn't be used without a significant amount of evidence so instead of doing that just doesn't change anything, you continue working the exact same way and I'll show that and how does it work there's two parts to how it works the first part is the vagrant file which is the same thing in spirit as a make file or gem file or rake file or a fad file or x file and it just describes the virtual machine in a very concise way so that vagrant knows how to set up what you're doing and then the second part and this is metagone version control so that you could go back at any point as well and the second thing is a command line tool that's why it's in monospace font there and that gives you access to spin up machines provision them SSH into them so first let's look at the vagrant file and like I said its purpose is to describe the VM and it's really short it's currently Ruby, it's all written in Ruby and for the foreseeable future it will be Ruby but it's something but you just describe the VM really short and here's an example of a vagrant file and this is kind of the bare minimum you need to get a VM up and running think of this box thing as an AMI if you speak EC2 it's basically just a base image so that every time you spin up a VM it's all an operating system because that would defeat the purpose of spinning up an instance to like 30 minutes so this could get, this just clones a hard drive and builds a, and here's a slightly more complicated example that your VM is provisioned with Chef so if your system in has who knows what Chef is here everybody, cool, or pump it same spirit if your system in has Chef scripts you could actually use them to provision your VM and in this case we're just using Chef solo and telling it to use the Apache 2 recipe and you see the same box thing and if you're a puppet user it's fast and bold I'm not trying to say that Puppet's simpler than Chef here but Puppet has its own set of options but you don't need them whereas with Chef you do and you could also use a Shell script if you don't know Puppet or Chef and you still want to use this stuff and maybe you do have it read me and you can do it this way too and then all these can be composed as well so maybe you want to do a Shell script to bootstrap your machine to prepare for something else then you want to run Chef, you can do that just put them in the right order, it's imperative here's another cool thing to do you could network the VM to a static IP so this literally means when this VM comes up and I type 33.33.33.10 in my browser I want it to actually go to the VM and onto whatever actually that's actually the Department of Defense and you probably won't ever have to go there it's a safe IP to use well a lot of people try to network it to 192.168.something or 10.0.something because they're like oh well my router uses that for my own local network so I'll use it too but if you stop on one of your previous computers IPs it really tricks out your computer and it has no idea, I don't know enough about the networking stack and BSD or Linux to know what's going on but I just know that it doesn't go to the VM and it doesn't go to that other computer it just goes to a black hole and nobody knows what's going on and I get bug reports like weekly about this for more advanced websites you can actually do multiple VMs in a single layer file so if you're running a service-oriented architecture you could do this sort of thing and you could just think of them as functions where there's scope so that VM object is just the config object that's specific to the VM that's defining and you could spin up all the VMs in the cluster a few of the VMs whatever you want I mean if your architecture is like 10 VMs that doesn't really make sense to run on a machine so you could spin up a few at a time and if you use the networking that I showed as long as they're in the same slash 8 block like at the end that last number there's only one thing that changes between them all those VMs can communicate to each other using those IPs so if you have a service-oriented architecture that's how you test it and then I'm not going to go through each of these that's really boring but this is the vagrant command line thing and these are just some there's a few more of the things that you could do with it kind of as a git style you give it the vagrant binary to see all of them there's like two more than this but I don't want to keep going but first this all my examples I just open sourced this over lunch but the examples will be here don't try to run them on the internet if you're blessed enough to get internet here because running any of them will attempt to pull down megabytes stuff like Apache and image magic and stuff like that and you just won't get it to work and you're going to think it's vagrant's fault and it's not my fault so do it at home it's really cool and I'm going to show you what it looks like it's just like the apple background yeah it took for my apple it just works what else I hear some smart ass comments I know phoenix all these VMs last night where the internet is not terrible so they're all up and running but I could show you some of the help but I guess I'll be over a second commitment issues so this isn't the refinery CMS who knows what refinery CMS is this year okay if you don't know I didn't know until yesterday I was looking for a good example I found it it's a pre-built urban rails it's supposed to be installed and run but it actually has a bunch of dependencies so getting it installed and running on your own computer is actually a huge pain so I set up a vagrant file and puppet recipes to get it up and running so if you check out that gary bow that I showed you and go into the refinery CMS and run b, I shoulda used it b is my alias for vagrant but if you run vagrant up then that's it and you wait about 15 minutes but you'll actually have refinery CMS up but running on your computer without you doing a single thing other than this and it's kind of what the output looks like the VM was already created so it didn't import the initial VM but it runs through all this stuff boots the VM and then it provisioned it down here and you can see it's succeeded so if I go to the web address now that's what you've seen already with more examples all in one see there's more options for puppet and then assigns it to 33333310 and then if I go to that in my browser you can see that it's doing the setup process for refinery CMS and this is all running in a VM this is, I don't even have a web server installed on my computer and it works so I can click so the next example and I know you all know track is it's the python based issue tracker thing and who here has ever tried to set up track was that a huge pain? yeah it's so much of a pain in fact that years ago I actually had to set up track and I tried so hard to do it I couldn't do it that we resorted to using text files for issues because track is impossible to set up and so if you clone out this repo I've got a track and just run bacon hub track will be completely installed from scratch I'm not distributing images with track pre-installed it's actually using bare bones and installing everything from scratch and so track will be up and running and if you look at so I'm using all these big open source projects as examples but you can imagine that it's your actual website which at some critical point, critical mass becomes a huge pain in the butt to install too and so same exact thing except that I amounted to .12 so that it doesn't stop on the other one all these games are running together so I go to .12 I have track, I've been running really exciting I didn't get the login working because apparently it just doesn't work out of the box and I started looking at the documentations and it has all these cryptic like command line arguments you're going to pass and it wouldn't be that hard I would just have to modify a couple files to do it but it just doesn't make any sense and the last example is really simple it's just actually a PHP it's nothing more than a PHP hosting thing a virtual host setup the exact same thing you've seen with .14 and each of these VMs is taking up 5 under 12 megs of RAM not they don't usually take up the whole thing at once but the myth that virtual machines are heavy is not true this machine now has 8 gigs of RAM because I routinely have around like 6 VMs running at once but that's only a recent thing I've had up to 4 VMs running completely fine not noticing at all the 4 gigs around PHP info the reason now that I did this really simple thing is I want to show you how your workflow would work with vagrant and I don't want to dare edit track files because God knows what that will do and I don't want to edit rails specifically either because I don't know the internal or refinery CMS so yeah we're going to edit some PHP now it's a Ruby conference please I guess the important point is all this is running on my own computer the ZMAX is obviously this is an SSHDN anywhere this is on my own computer and the contents of this PHP directory is just the vagrant file and index.php the puppet folders that are needed for provisioning and so I'm going to edit that index on PHP on my computer and you're going to see the changes go live instantly I can't move as fast as instantly but trust me that it's instantly this could have been a mistake I haven't used PHP in 4 years and I'm just now realizing this but we'll do something just so feel free to substitute either of those 2 D80s with your own but this is edited now let's go check it out this is my browser on my computer just on the original to change refresh uh oh let's save it you can see how that works you can imagine it works the same way with your own sometimes you just need to dig into the server and see what's going on maybe you need to read log files which aren't available in this shared folder or maybe you just have to install some software and check things out no problem you can just run throw you straight into a real SSH prompt and this is on the VM so you don't see anything but if I go to the by default it's the slash vegan directory but you can change you can use the shared folder so if I ls here I'll do the big one you can see these are the exact same files these are the exact same files but if you use this in any real project you'll actually use NFS which vagrant does on its own it's completely automated you just add a flag and it just does it because virtual box shared folders don't work past like 1000 files and I've opened a bug and it's been closed as not a bug and there's actually a bug open for about 6 years or something now and they're just not going to fix it it's a feature the bug is a feature if you pass 1000 files what are you doing with virtual machines anyway that's what they think I guess so yeah so that works and then let me show you all the commands so you can see all the commands here I have I want to mention that if you want to get started with vagrant the initial download for like the base image is like 500 megabytes I have a flash drive with me here that you can just copy on your computer and use later so if you're interested in just playing around with this playing around with this may when you get home just let me know and we can just copy it on your computer and the other cool thing is this is about 6 down there's this vagrant package if provisioning is starting to take like hours you can take hours on a really large website then you can provision your thing package it into a new base image and you can use that for then on and then it won't have to provision anything and I'm actually working for the next version of vagrant we're going to have completely changed kind of the way this is working yeah so it's an open source project it's at vagrant.com I've been told it has very good documentation but there's a lot that isn't documented at the same time but it's enough such that you'll be totally fine you're getting started with that though sounds like a good idea screencasts Shane but yeah it's open source you can take a look at how it works it's written in Ruby that's why I'm speaking about the Ruby conference but it's pertinent to everybody so tell your friends and I think that's it do you have any questions? Brian I know what do you mean by alias? oh okay it's not possible yet but the only reason it's not there's ways to make it work and there's a bunch of people actually working on it right now but no one's got a good solution yet but for now I would say it's been a multiple or two machines that you can and that could be your temporary solution more questions? okay so the second thing I've seen your screencasts wait a minute my what this oh okay so yeah I have a vagrant screencast I made it in March of 2010 when I released the vagrant 0.1 and a lot of the stuff still works because I've been lucky enough to be pretty good about backwards compatibility but a lot of it also doesn't work it doesn't highlight some of the strengths that I found over the year of development so I need to redo that someday can you do configurations for load balancing on multiple DNS? yeah using Chef for something you could easily do load balancing if you're familiar with Chef, they use the JSON DNA they use the Chef Solo and you can easily just hard to code the IP addresses or if he's a Chef server Chef server support is built in so the upcoming environments support coming out you can easily hook it into our search of the server for all the web nodes grabs the IPs and magically configures load balancers yep yes completely so even to the point where I showed you where they mount to slash vagrant I changed the mount point that the shareholders used to what they actually are in production which is usually at slash serve srv slash and so I changed it to that and they use the exact same recipes completely as production I'm trying to think of any differences the only difference the only difference I guess is with Chef I know you mentioned you mentioned Puppet and I used Puppet's examples but I used Chef in production and Chef server I have two Chef servers one for development and one for production so Chef the development one is where I put all the staged recipes that aren't ready for production and then they eventually end up in production so I'm sharing my recipes yep I noticed that you were using Lucid are you using Lucid 32 are there any other boxes available or I only officially myself make Lucid 32 and Lucid 64 but the community has made karmic boxes devian lenny boxes cento s maverick a bunch if you're interested in this jump on the mailing list and expect a long road map email about what I'm working on and then you'll see how this is all going to be a lot better in a few months a lot more you can look everything up any other questions? I saw one back there I worked with RE so do you have any plans to scale out the number of visual machines or scale them down okay I saw the question I should have been repeating the questions but do I have any plans of vagrant to scale up and scale down the motion machines and I'm just going to answer no because I don't think that's the problem that vagrant is trying to solve but you could easily vagrant is scriptable, there's documentation on the website to using vagrant as a library and I would say that you could easily write like a pull poverty provider or whatever RE's to control vagrant VMs as well and I guess on that note I am also working one of the things I'm working on is supporting multiple more hypervisors this is on virtual box that's an important point I didn't mention it this is all virtual box and virtual box is awesome but I'm also working on supporting like KVM and other stuff but that don't hold a breath it's really complicated and I've decided to pull up until after I would say six months to a year any other questions environment and then somehow swap out for production to use like Amazon to structure and then run the recipes on top of that kind of hybrid virtualization environments do you want them to communicate or are you just saying just for development and production distinctly the question is can you set up virtual box for local development but then use EC2 for production and completely, I mean Baker doesn't do anything specifically to help you with that except maybe push upon you good DevOps practices but by creating portable Chef recipes and by sharing them between development and production you really just have to have like a boot share script to launch an EC2 instance and run the same recipes and it should set up exactly as it's developed any other questions what is the main chain is Vagrant battle tested Vagrant is used by a lot of companies I don't know an exact number but on each release there's usually around a thousand downloads nowadays but I know that a lot of companies John, Benders, Originate Labs uses it full time, CitrusBite the company I work for uses it full time but we're small consultancies there's also pretty big big shops like there's one that and Vagrant works on Windows and they develop Rails this formula doesn't work but they they use Vagrant for all the developers in order to develop in a Linux environment on front windows God help them but it's pretty well tested to the point where I have to release betas now to make sure that corporate customers don't get just off and made for breaking so it's safe to use