 Rubber ducks rubber ducks. Yeah, so I wanted to give a little bit of background the Basically my sole interest in vagrant was getting local host web web hosting set up in a way that didn't completely suck I you know way back when I started I just used a shared host because it worked and it was what I was ultimately hosting on I'm it up getting a Mac when I joined Lullabot I ended up starting to use like local actual web hosting like the pre-installed Copy of Apache that came with it Then eventually I ended up moving to like Mac ports and think and you know other things that what you compile your own PHP stack locally because I wanted to resolve, you know Some incompatibilities and tests like PHP 5 3 and stuff and then finally I ended up sort of caving and starting to use MAMP just because It sort of encapsulated a lot of stuff that I didn't want to have to worry about myself but and Part of this is just like a pure aesthetic thing, but I despise ma'am Hate ma'am. I I understand that it's like good for getting up and running, but it's a huge pain I've got a desktop and a laptop and it's just sort of doubled the amount of potential like oh I've got to install a new OS upgrade or something broke kind of hassles that I was encountering with it and running the local host web server with like you know full, you know Apache solar and Memcache and APC and all that stuff on my actual local machine ended up just putting a lot of moving parts on the machine That I was just using day in and day out and if anything broke or I needed to reinstall everything It was like this, you know day and a half long epic journey of making sure I went back through all the steps And got PHP, you know back up and running and all the hosting stuff on my local machine like happy Which just kind of sucked So oh and the other thing that really took me over was when we started working with when we were working with clients They had some on-ball server setups There was just no way to effectively simulate it. I'm using my local machine I had you know and somebody who had needed to test with engine X. I either just had to roll the dice and say oh well Okay, I hope it works with you know engine X. I've been testing it on my local Apache server And then we had also ended up running into some PHP very specific version in compatibilities on one client site That I just wish I could have like set up Complete absolute clone of the machine they were setting on which all ends up pointing to like virtual machines and that's where I ended up starting to look at virtual box and then started looking at vagrant because I Understood that I could use something like you know VMWare or virtual box to set up a virtual machine But then I was gonna have to go through all of the actual setup process every time I wanted to do that You know get the OS installed You know it was basically like all of the setup process I had to do for my local host But I was doing it in a VM instead and that was annoying And I'm not so much of a ninja that I already had scripts lying around to automate any of that stuff So that's where vagrant comes in Everybody like knows what vagrant is show of hands does anybody not Okay, I'm assuming that's everyone showing their vins to say they know what vagrant is It's basically just like a set of ruby scripts that let you manage like virtual boxes from the command line in a nice clean way So it's super cool It automates a lot of the stuff that I would have been doing manually and it can tie in with puppet or chef to do actual customization of the virtual machine that you just instantiated so theoretically you could have like a vagrant box that's just a completely pre-built ready-to-roll like Just archive of a production server that you flip on and you're running locally and you know It's already got all the software installed and everything or you could just start with a bare bones like you know a Buntu vagrant box. It's just Clean install of a bun to and then you could use either chef or puppet scripts that automatically Execute after vagrant starts up the machine So it'll instantiate the clean machine and then run all these chef scripts or puppet scripts that you have in order to Turn it into the kind of ritual machine that you want and that's the approach I ended up taking Is anybody I know I Know Ben you've worked with puppet a lot Is anybody here worked much with chef I'm gonna take that as a rousing no Basically it divides like the instructions for how to set up the virtual machine into like three basic bins There's cookbooks, which are like you know just a big collection of you know instructions for you know different setup stages and you know Files that you know would need to be installed on the server and stuff like that So you could have like a lullabot servers cookbook or a Drupal sites cookbook or a lamp software cookbook They can contain a bunch of individual recipes like set up a patchy or Set up memcache or set up a patchy as a back-end server for a varnish front-end And then another recipe could be set up varnish to talk to the Apache server that you just had Jeff where does um Jenkins fit into the mix between chef and puppet. I have no idea. I've never used Jenkins We're using that on a few projects, and I like it I'm wondering how familiar or similar it is between the two of them continuation integration server that just sort of like orchestrates all of the inner operation of the different things like the unit testing and the VM provisioning and stuff like that, right? So this would come much later after chef and puppet Jenkins is is more like a nice UI on Cron Oh, okay Thank you That's a fancy name for Cron Yeah, so it it like a really fully automated like server farm or something like that is probably going to use a bunch of those different pieces And I'm not even sure vagrant would necessarily even be part of the mix with something like you know The lullabot server setup, but it would definitely use like either chef or puppet or something like we're using You know Ben's using puppet to manage that stuff but like some sort of automated set of tools to you know say we want a Solar server and that's the kind of stuff that you know either, you know Puppet or chef would be able to automate like but so there's the cookbooks There's the the individual recipes and then there's also roles in chef So you can have a role that wraps up a bunch of different recipes and a bunch of different Configuration data that are contained in all of your different cookbooks so you could say one of the roles is back-end search server or another role could be a single box dev instance and It basically is just a list of all of the individual chef recipes to run when setting up this new Instance, so then you would tell vagrant. I want a new vagrant box Or I own a new virtual machine. I wanted to use the base a bunch of lucid box And I want you to use these chef recipes and set it up for the Single box dev server role and it just goes through Makes new base a bunch of box and then runs all those chef scripts and then sets it up And there you have a virtual box running. That's it in a nutshell the problem was Almost all of the like the prefab stuff that I found was either somewhat broken or Didn't work just the way I wanted so I ended up having to sort of go down the rabbit hole and actually learn how some of the Stuff worked like actually learn how to write my own chef scripts, which was Not what I was expecting when I thought this will be way way way easier than just customizing php on my local machine but the good news is like and this is something that then probably has Has had the gospel on for for a long long time But like once you actually get something like the chef's scripts or the puppet scripts for something like this It's just automatic. You just say go run that script that I finally ironed everything out It's almost like setting up an install profile and you know automating everything, you know It's annoying the first time through but then it's literally just a button push So should I shut up and just like Show how it's working locally Sure, I think we got the gas okay cool Let's see Okay, so this is is Very very basic setup. I don't have any virtual boxes running right now But I'm going to just to completely do this from scratch so I'm going to go into my work directory and And crazy there, but I've got some of my own already down grips already set up So I can just say get clone my own repository and There let's see So basically it's it's pretty straightforward. This has just a bunch of existing chef cookbooks Vagrant integrates with chef solo out of the box without really doing too much more Chef and pop it or both set up so you can manage a bunch of Servers, but there's also chef solo, which is basically just using it on your local machine without integrating to any external servers and When if you're setting up Vagrant A folder called cookbooks can just contain all of your you know cookbooks and rolled definitions and stuff like that for chef so most excuse me most of the action with This Most of the action with this is just in all of the cookbooks that were set up I based this on the Vagrant project on Drupal.org Which had a bunch of pre-existing Recipes and roles and cookbooks set up it had it basically divided it into site cookbooks which were just core lamp utilities like getting Apache and Memcache and Varnish and stuff like that all in place. It also I think Comes with x debug and xh prof already set up It also comes with a bunch of Drupal specific cookbooks. So you can set it up to do things like Pre-install a Drupal 7 site as part of the chef setup But I actually didn't want it to do that I it got a bunch of others it got all the underlying lamp stuff that I wanted just right But I did not want it to actually do You know, I didn't actually want it to You know try to pre-install a copy of Drupal 7 for me So what it is is I and what I did was Let's see Jeff since this runs in a VM will it conflict if you are running mamp pro? It shouldn't okay Let's see. I can answer that if you want. Oh go for it Yeah, it's it won't conflict because your virtual machine gets a Separate IP address depending on depending on how you have your networking setup for a virtual box You can give it an IP address on your local network So that any other machine on your internal network can see it or it can be a private IP address that only your host machine can see so Well, ma'am can be running on your main machine You can have as many virtual machines as you want running on port 80 on their own IP address Right. Oh, thank you. And that's basically what this the vagrants the vagrant file is All you need once you've got vagrant installed all you really need to do to you know start up a new VM is you go into a folder and you type vagrant in it and it creates one of these vagrant files It's basically instructions for the virtual machine that it will instance then you type vagrant up and it launches the machine clones the VM, you know basically does all the setup and Starts running a virtual machine But you can then go in and customize this vagrant file with all kinds of options like what IP address should it use And that's how you would have multiple VMs running simultaneously You would have a bunch of different VMs you would assign each of them a different IP address And you can also do things like port forwarding so that you know port 80 on your local machine maps directly to inner What maps directly to port 80 and stuff like that? You can also do things and this is actually where it gets cool You can set up things like local shared folders Inside of the vagrant directory that are just treated as internal directories on the VM So right here. I'm saying that there should be a slash vagrant directory On the virtual machine that just is The folder in which my vagrant file lives on my local machine That also means that I've got like a public and private folder that are just some folders inside of my The current directory I'm using on my local machine that I'm going to use as my dock route for web stuff And the private folder I use for private file storage on Drupal These are just set up so that I have some easy to point to you know local URLs So that if I use say Backup and migrate on the virtual machine. There's an actual, you know, what it considers not web addressable Folder on the local machine that I can have it automatically back up DB images to on the virtual machine that will just end up appearing Inside of my folder where I've got the virtual machine definition on my local machine So it's sort of like I can have the virtual machine that thinks it's backing up But all it's really doing is spitting out the sequel file to another subfolder of the directory that I've got all the vagrant files stored in so It's it works and this chunk right here is actually where the vagrant file Says what different chef recipes should be run to set up this server and there's one custom Let's see There's a Drupal lamp development Role that I ended up creating. It's a slightly customized version of the one that comes with the the vagrant the Drupal vagrant project Basically, it doesn't do anything particularly Drupal specific. It just sets up, you know, XH prof X debug, you know my sequel It doesn't do varnish Because I didn't want to add that in when I was doing some of this local stuff But the vagrant project does come with an alternate role that you could set up It puts varnish in in front of that and runs Apache on a port 880 But the idea is it just creates a public folder inside of this folder that I you know just created for vagrant That is just the web root so I can just with this I can set I can run vagrant I can download this I type vagrant up and that just instantiate each the virtual instantiates the virtual machine runs the chef recipes necessary to you know set up this role and Then I have an empty doc root Inside of the public directory that I can just drop a copy of Drupal into and go through the install process like usual I kind of prefer that to having chef try to automate that stuff mostly just because I'm still Getting used to it enough that I am not comfortable being out of control of some of those steps But you can also do things like set up what the local host aliases are So if you were running say a bunch of different sites all in one VM You could point a bunch of different local host aliases to that and these are like locally on the VM itself what What URLs it will consider aliases for 127. Oh one And then also I just use pair to install the latest version of drush right here Sadly, this document is roughly like three days of my life. I Wish it weren't but it was basically just a process of sort of picking through and learning not just some of the vagrant configuration options but also how the chef chef setup stuff worked and Okay, so vagrant file aside You can so I've got that and I can just say vagrant up In that folder and so now what it's doing is going through and setting up the you know It's using a loose 32 box as its base It's making the actual VM and as soon as that hits 100% now It's going to start going through and actually running all of the chef scripts that do the setup One of the things that I wanted to do with this and one of the reasons I started Tweaking a lot of the vagrant settings and learning how to work with chef was the default Drupal vagrant project comes with Basically the assumption that each one of those little host aliases you set up each domain name you tell the virtual machine This is a site you're running it will set up a different the default Drupal vagrant project set up a different Full copy of Drupal for each one of those domains So it's like it's actually running parallel Drupal instances inside of the VM And I wanted it to just to be one Drupal instance per VM Using multi-site to do that and that's why I ended up going in and customizing things But the chef all of the chef configuration data includes things like the default Apache V host Configuration and stuff like that. So in your chef cookbooks, you could say like just here's my Apache config file Here's my V host files. Here's the V host that needs to be set up for each site that gets spawned off And here's all the config options in that V host and stuff like that So it mostly was just a matter of slowly but surely picking through and finding the stuff in the default Drupal vagrant project that I needed to change Getting it ready The other thing that I really wanted to be able to do is I didn't want to have to mess with my hosts file Every time I set up one of these VMs. I just wanted to be able to run one VM at a time and you know instead of using like you know Test.dev for every single VM. I was working with or something like that. I wanted to be able to use distinct the Domains and I didn't want to have to edit my hosts file which turned out to be stupidly weird But has anybody ever used DNS mask? It's just like a tiny little DNS server that you can install on your local on your Mac If you have homebrew you just type brew install DNS mask and It pretty much takes care of the rest But basically you can just give it like one or two line config file that says treat anything, you know any domains ending with VM or you know dev.vm or something like that as local host and You then can use wildcard aliases or whatever which is really handy if you're if you're testing like a multi-site with a bunch of Subdomains you can just say treat my client.dev as you know anything Anything underneath that top level domain should be on my local host and DNS mask will take care of it There's a couple of other funky tricks that I'll probably like post the DR about That may not be necessary But I ended up learning a lot of crazy things about how OS X does DNS resolution because I wanted to work that to work on My laptop even when I was going around on other Wi-Fi networks without having to reset anything It's amazing how much time I will spend so that I can be lazy and not Spend five minutes when I'm in a coffee shop going back and changing my network settings But Yeah, it turns out actually fully configuring and provisioning of the VM takes a little bit of time So all that's just chugging along Are there any other questions? I've got a bunch of I've got a bunch of notes about like a couple of the specific things that This makes possible and some of the upsides and downsides, but Is this Proving useful at any point or there are things that would need to be clarified. I Might have missed something there It doesn't need to do this whole process every time you want to start the VM, right? No, this is just the very first time you fire up the VM. Okay This is like the vagrant setup Process, then you can just do a suspend command and a resume command to start and to stop and start it And that takes like, you know a second or two. Okay is much Yeah that The the first day the first couple of days I was doing this I was doing a lot of you know full setup That doesn't work like I needed to I'm just gonna wipe it clean and destroy it and do another setup Which is probably not terribly efficient, but I'm a big believer in the Just burn it to the ground and start fresh until everything works the way you like it And then later once you know how to get it working the way you like it learn how to customize it on the fly but you know I That was actually one of the things that kept burning me when I was trying to do local host setup With just the the built-in OS X PHP and Apache stuff any kind of customizations that I did It was really really frustrating to roll back any of them It basically required either saving like complete parallel copies of all of my config files or like, you know Getting my entire it's set directory You know in git or something ridiculous like that or just reinstalling Mac OS which felt Suboptimal as a way of changing my local host setup Jeff would you say this is the type of thing that each developer would want to have Customize and or is this something that you'd have like a single gatekeeper that makes sure everybody within a group is running the same Environments if that depends and that's actually something. I think we've talked about a couple of times If we're doing like a project where we're like, okay for the next, you know In nine months, you know, there's gonna be six of us who are working on X It might make sense to have a single centralized, you know standardized setup where we say this is you know anybody on project X this is the you know vagrants the vagrant setup and the puppet scripts or the chef scripts or whatever that will get you a Dev workstation for this project or it might even make sense to make a customized Virtual box self because the way that I'm setting it up with chef and everything Assumes you're using a baseline like a bunch to box and then customizing it with With post-insult scripts. You can just create a canned box. That's like, you know Here's Drupal.org in a box with a prescrubbed Database and everything already set up, you know, even the the right version of Drupal already installed and everything ready to go And I think the Oscar project that a couple of people had linked to That's how it works. It's actually it actually is a pre-built Virtual box Instance that's already set up for Drupal development and the vagrant file for the Oscar project is really really short It doesn't even come with chef or puppet scripts. It just says here's the virtual Here's the box that you're gonna be using fire it up I didn't necessarily like that because I wanted to get a workflow that Just by customizing the the chef scripts for a particular VM I could like tweak it for one client or another rather than having to feel like I was maintaining all of these different like Hard boxes that we're running. So that was that's a little different But it we would probably make sense like on projects where we wanted to make sure everybody's absolutely on the same page To have at least standard setup scripts or maybe a box But for just you know a client gave me access to their SVN repo and I need to you know get it up and running Just firing up one of these but you know firing up one of my generic boxes has been working pretty well and it looks like It looks like that's running and So this is obviously headless, right? Yes. Here's my sign. Oh I don't have a job I was gonna say what kind of disc space do you end up using with all of these different? Stored images I need to I need to double-check but it's probably like a gig and a half per VM the way I've got it set up The nice thing is What if I'm religious about You know having the public and private directories are just you know source control, you know basically source controlled copies of The code base and I use something like backup migrate or whatever to clone the DB Before I shut it down. There's not really any penalty for doing a full vagrant destroy and tossing the entire Virtual machine image if you like aren't going to be working on something for a month or so And then doing a vagrant up. It's just you know, you lose that, you know, five or ten minutes of doing the full Setup process when you need to you know, sort of re-image the new VM and run all the scripts And then you know you have your code base and you just have to you know stick the stick the you know My sequel image back in place. So that ends up working out pretty pretty well I usually have like maybe two or three VMs really actually Living on my hard disk suspended at any given time But I have you know a couple of tweaked vagrants, you know vagrant scripts and chef and you know altered versions of these Chef scripts for specific sites that I've tinkered with or specific clients that I just have sort of ready to be Reconstituted into a full VM if I need to jump back to them. Does that make sense? Yeah, it does and actually the other nice thing was this meant that if I wanted to move something to my laptop or you know If I needed to actually transition to another machine I wasn't trying to make sure that all of my local host Customizations were the same from one machine to another and all of them were in sync with PHP versions and stuff like that All I've got to do is say, okay I've got you know the vagrant setup file and the chef scripts that I've been using here I've got the the repo that's checked out and here's the DB image. I just need to sling those over to my To my laptop on a USB stick and then I can just reconstitute the VM there and because I'm using the basic lucid 32 box for most of my stuff I just have one sort of you know base box with a copy of Ubuntu on it That it uses as a starting point when it's cloning these things. Does that make sense? Yes, it does I Have more questions. I'm gonna play dumb here because when it comes to virtual machines. I pretty much am dumb If I wanted to like edit all of the edit if I want to edit code on the site How does it? How does the VM expose the like Drupal's? Okay code so that I can access it and say the finder or Okay, so that's the awesome. That's actually the really really awesome part And this is what I was first like freaked out with freaked out about about a year or so ago when I first started thinking about using a VMs I did not want to have to like SSH and use you know, VIM because I'm sorry like the three of you who are actually badass and use VIM for stuff. That is just not my cup of tea But basically inside of this directory where I did my check out of the vagrant config files There's a public directory and inside of that public directory on my local Mac I'm already in the public directory That's basically just the web root for the VM It's a shared folder that any changes I make here immediately appear on the VM It's a Magic portal into the VMs disk structure or vice versa So like I just stuck that index.html file here on my local on my local machine and Spotlight Yeah, I assumed it was something like that, but just wanted to make sure I was Understanding how it worked and that I wasn't going to Pigeon hole myself into having to use VIM because then yeah been more confusing. That's a special kind of hell but Yeah, like what I usually end up doing is I'll just clone my I'll just clone this get repo with my vagrant config stuff Then I'll clone the client's repository Into the public directory and if they have just their Drupal instance at the root of their repository Everything's just ready to go if let's see and If they have it like inside of a doc root folder or I'm checking out a full SV entry and I need to go into a particular Branch or something like that I would just go in and edit this line where I can say that slash vagrant slash public on the VM Goes to the public directory or I could say Doc root Trunk and you know like one of my clients they've got you know their repo organized with doc root and then inside of that There's all their different SVN, you know branches and stuff like that So just changing that line in the vagrant config file would say the public directory Drill down this let this deep and that's what should actually be treated as web root By the VM Pretty much everything about this setup is geared around me only having to change like two or three lines in the vagrant in the vagrant file to actually get us the VM up and running with the client's code or with you know a simple, you know Drupal instance that I can do some tinkering with just because There's a couple limitations to that like I've got all of them going on the same IP and my local DNS You know my little automatic DNS thing that means I don't have to edit my host's file Always points everything to the same IP no matter what I'm doing So if I really wanted to have like four VMs running at the same time All I would really need to do is customize each one of them So they're at a different IP and edit my host address so that you know the different domains that each one of them are using point to the correct local IP I Only really usually run one VM at a time so I haven't run into that but you know I Basically just wanted it to be absolutely no friction or at least as little friction as humanly possible Between me typing something on the command line and being able to start futzing around and you know Writing a module or you know actually testing something in the browser Yeah, how do you actually end up like Getting Drupal in there. Do you end up just like creating a sim link to wherever your repository checkouts are? Actually, no, I usually check them out right here or like yeah, you can just do a drush DL or whatever So yeah, actually like doing your your repository checkouts right in your in your right folder and the get ignore file for my For this like for all my vagrant and you know config in the chef cookbooks There's also a get ignore file that says ignore of the public and private directories. So I don't I don't accidentally risk like you know Accidentally dumping somebody's SDN repo into my you know get repo if I if I just do a blind add and check in or something like that Which also means that I can just keep revisioning any of the chef files locally if I need to And all of this can fix stuff for the VM lives in one repo and all of the actual Drupal code base lives in a different repo How good is vagrant at like you have that vagrant up that kind of sets everything up and runs everything how good is that at Pulling in other commands or parameters so that you can you know throw it variable So say you wanted to have your have so I have so I have all my Repositories in a repo folder, right? Of course, they're all a bunch of checkouts What if I wanted to do vagrant up and then? The name the the location of one of those repositories so that it would automatically create a sim link into it from my public I don't think vague I don't think like you can necessarily pass stuff into the command on the command line to vagrant to do stuff like that But there's a lot of really crazy stuff you can do in your vagrant file basically anything that chef can do you can trigger And there's a bunch of different config options for the VM itself You could also wrap the vagrant setup command in it's in a shell script of your own devising or something like that Like I think that's one of the things that the drush vagrant project does it provides a bunch of drush commands That like edit your local host files for you and then check out a vagrant box And then you know and then you know do a vagrant setup and stuff like that That was another one of the ones that I looked at when I was trying to decide how I wanted to do that But it just felt like it added a lot of extra moving pieces with drush That I needed to get working correctly so that like drush could edit my host file without hosts file without breaking and stuff like that And I mostly just wanted to make sure that I could actually consistently get the VMs working on my own without that and Since doing that. I haven't really had any problems I don't necessarily want to like be able to type a drush command and then have it do all of this provisioning for me But yeah, you know you you could totally wrap it wrap it like that and just have a script that says You know pull down the repository you want to you know do the vagrant setup at makes him links Whatever Then it's the question or yeah, so what you're saying. It's it's more of a you probably do that process before Vagrant vagrant doesn't really handle that Yeah, yeah, they probably handle some of that though Yeah, it could I mean like all of the shit all of the chef and puppet stuff that vagrant is doing is on the VM itself So it's mostly like saying you know Fire everything up start the VM and then do all of this configuration work using chef or puppet to the VM itself If there's stuff that you want to set up locally You could although now that I think about it though Because the vagrant Directory like where your vagrant file lives and where your public directory lives because that's actually accessible To the VM you could have the VM do the actual checkouts and stuff like that if you wanted to It it It's pretty much just a matter of taste and how you actually want to set it up and that's sort of like the this this Drupal vagrant, you know development Thing that I got said the set of scripts that I've got going is mostly just like what I wanted for my workflow And what I wasn't particularly happy with in a lot of the other vagrant based Drupal workflows that I was seeing So it's not necessarily like the right and correct magic way to do it. It's just a combination of You know the recipes to run to get all of the basic lamp stack and Drupal support utilities running Getting a baseline Apache, you know Apache v-host setup that lets me do wild card domains and Point it all at the web route That's just locally shared in the vagrant directory as the public folder so that I can just on my local Mac dump whatever I want to in there Yeah, I guess the the use case. I'm thinking of is is kind of like, you know having these scripts like in your actual repository for your project so that when you do the Stupid dog But as soon as you'd have I got somebody coming I gotta go Okay, but yeah, I mean like you could in like the root directory of a Project in addition to like your Drupal checkouts and stuff like that. You could definitely have like a vagrant file Sitting there and maybe a couple of chef cookbooks that would allow someone to set up like a local development instance Once they've checked out the entire repository There would there's you know nothing to There's nothing that says just because there's a vagrant file sitting in that folder that someone has to actually run it and create a VM If somebody wasn't using vagrant it would just happen to be a vagrant file sitting there Just like you know if you just like there are rake files in there if Ruby developers have been scampering through a project like Module Monday is actually one of those That I already have a VM set up and if there's already a VM in place It's a lot speedier. I'm gonna say it's a lot speedier and then it's gonna totally gonna take like five minutes Yeah, okay, that's better But let's see and That's basically like my canned module Monday site that I have with you know pre-built dummy text and whatever modules I'm currently installing and Inside of this directory It's just a base Drupal install and The module mod the module Monday site is actually just running out of the default folder at the moment because it you know It's a freestanding VM. I didn't really need to actually set up multi-sites or anything like that and I can just download whatever it is that I'm currently working on install it and if I need to and like this particular you know VM or you know my module Monday site has gotten completely cluttered with like The installation and testing cruft from like 60 different modules. I can just run vagrant destroy vagrant up And I've got a clean one again, and I just have like canned sequel database that I created from the site with like 20 nodes already created That I can restore from so it lets me sort of wipe it back to you know a clean slate really really easily I think That's all I've got here. There's a couple other caveats that I'm still trying to figure out Because I'm using like host only networking I can't access These VMs from other machines on my network Like I can't say use my iPhone to test one of the sites that's running in one of these VMs because it's only visible to The machine that I'm running the VM on I know like you know Ben mentioned a little bit ago that there are other networking modes You can put it in where you can work that stuff out I just haven't ironed out the the details of how I would need to do that Because of the way that I've got my DNS stuff set up I can't run more than one VM without at least manually, you know doing host host tweaking and also I need to go in and fix some of the permissions because Drush on the VM itself like if you SSH into the virtual machine Drush doesn't actually have right access to the Drupal directory. Only the Apache process can really do things like that and It's also Honestly a little bit sluggish compared to really running on local host But I think a lot of that is because of the mechanism that I'm actually sharing the public directory with These share folder lines in the vagrant file I'm not using NFS to do the file sharing and apparently if you set the sharing mode to NFS in the vagrant file It's like five times faster for file access which They say only really matters when you've got hundreds or thousands of files that are being accessed which basically is a Drupal installation So I think that's probably something that I would want to you know that I want to check out in the future But that's kind of it I've got a bunch of notes that I wrote up for this that I'm going to post to the DR Just in terms of like the upsides and downsides and the links to all of the stuff that I used when pulling these things together Any other questions or comments or stuff that yeah, I got a question. Um, I'm not sure if I was In the clouds thinking When you mentioned this but you actually went out and downloaded virtual box before you could do any of this, right? Yeah, um vagrant has actually built on top of virtual box. It's like it's required you go out and download that manually, right? And is it tied to any specific version? It works with the latest one I don't think there are any like weird things going on Sometimes when virtual box gets updated like it's you know two or three days before a vagrant update comes comes out If you know there are some incompatibilities, but they usually stay in pretty good sync and you're running all this from command line It doesn't actually launch that a GUI that you so Okay, but if you do launch virtual box, you can actually see all of the different VMs that I've got So, you know, it's okay cool They interoperate pretty nicely a vagrant is basically just like a set of really nice command line utilities for automating the process of working with those boxes instead of Using the you know using the virtual box interface and manually SSHing and doing it all things all that stuff yourself. All right Yeah, virtual box has a pretty complete command line Utility, but it's a real bear to use so it looks like vagrant just kind of puts a nice wrapper around that Yeah, and I think the fact that it ends up encapsulating a lot of it in like the vagrant file And let's you point to chef and puppet just really really streamlines a lot of that because the nice thing is is because The vagrant file itself Includes stuff like, you know, what chef role should this VM I'm creating be configured for you can actually Accumulate a nice collection of like puppet scripts or chef scripts that apply to a lot of different things You don't necessarily have to like build up a complete set of puppet or chef can speak scripts for every different VM You can sort of just have your nice library that you work with and then inside of the vagrant file You just say oh well This is an engine X server that I you know that I'm gonna be doing Ruby development on or I didn't you know Whatever crazy combination you want to you can just sort of mix and match that stuff by saying add these two roles and run this recipe and then also set up the my sequel root password and You know add a local host address and then you know run this pair command And you know you the vagrant file itself can just have a bunch of that stuff jammed into it And you don't necessarily have to either roll your own custom box or anything like that So it's it's really really nice once I sort of Got over the hump of all of the different individual moving pieces that I needed to get in place for it to work crickets So I may have missed this earlier, but So the the chef files Those are run locally on the virtual machine. That's what you said, right? Yeah, where do you store the? the I guess your library of chef strips or is that part of the The virtual box image you downloaded. No, no, that's actually part of the game repository The like the vagrant triple the triple vagrant project came with a bundle of its own chef scripts So like the actual get repository that I have that I use just as a starting point for when I'm spinning up a new VM Includes That includes this Just lamp and Drupal configuration chef cookbooks and and stuff like that so Basically, it carries around its own chef stuff and that's what this is chef solo So it's not like using a central chef configuration server or anything like that It just sort of has a bundle of its cookbooks that it carries around with it Okay, so that's not something that's in the virtual box image that you're cloning It's it's something that's in your local file system that Vagrant basically uploads to the virtual machine. Exactly. Well, I technically because this entire This entire directory You know with the chef configuration scripts and the vagrant file and stuff like that is Accessible inside of the VM at slash vagrant It because like this whole folder is a shared directory on the VM it can just run the chef scripts from right here Okay, I see Running VMs with directories that point to the host machines directory can sort of It can start to feel like you're pointing a camcorder at the TV It's attached to occasionally, but it it all does work. So Anything else I think I think it'd be really cool if we could get to the point where like projects have at least, you know Some standard scripts to get like the base machine set up in a way that you know is reliable if only because when doing local development, it's really easy to forget that there are like certain specific pieces, you know moving pieces on the actual server That we're going to need to account for like whether it's goofy a PC configurations or you know they're using engine x instead of Apache or something like that and just having Having this stuff set up to actually work that way when doing development just feels like it's it's saved a lot of hassles That's that's all that's all the exciting stuff. I've got I'm not sure it was actually super exciting but I was ridiculously stoked about it just because it meant I would never have to like Try to manually install a different point version of PHP on my local Mac ever again It seems like a pretty cool Idea in a way to like set up local environments and especially like thinking about the ability to Have a development environment that closely matches your not even closely that exactly matches your Production environment and as you know, we have the scenario now like a couple of sites I work on some of them use engine x and some of them use Apache and it's nice to be able to Actually replicate the environment that your site lives on Thinking about that and for me like I mostly am working on internal sites Which are all running on Ben's puppet scripts How hard would it be to convert some of the stuff that you're doing with chef to use? Puppet instead not a lot about how either of those it would probably actually not require any Conversion actually, I think Ben you've mentioned the puppet scripts that you use To provision Lullabot servers you also use to like run your run your VMs Yep, and the thing is a chef basically if you look at that vagrant file Right here where it says like provision using chef solo Wait, I'm not sharing my screen anymore But there's basically a line where it says I'm about to tell you know you run these provisioning scripts and stuff like that You tell it do this with chef solo You can also just change that to do this with puppet and you can give it a directory of puppet puppet scripts instead of chef Recipes and it goes through the same process And the the puppet scripts that well in general the puppet scripts don't have to have a puppet server to run You can always run them locally, so if you're just to get check out of our our puppet repository You could just point the local puppet instance at those modules and it would work Yeah, it's I mean one it for me It was a process of like getting over the hump of you know getting an actual workflow that I liked Running without just completely depending on somebody else's preconfigured boxes and stuff like that I still used a lot of the chef stuff from the vagrant project But just I have gotten to the point now where I would probably be a lot more comfortable playing around with other configuration approaches like maybe moving to puppet or something like that that it just felt like There were the all of those initial pieces of things that I just had to get before I was comfortable adding additional Variables and now it actually feels like it's running really really smoothly. I think That's pretty much all I got Any other questions any other comments does anybody actually already have a much better vagrant setup running on their local host I Take poll requests Your vagrant scripts somewhere that I Could get a copy of them or look at them Deal those from you. You can indeed I'll I'm gonna post the The address of the GitHub repo where I got all this stored and right now it's just set up So if you weren't doing the DNS Tweaky stuff that I'm doing literally all you would have to do is check out this repo If you've got vagrant in virtual box installed, you just have to add a host alias To your it's a hosts file and run vagrant up and then you would have one of these VMs in place Yay, I Think that's it. We're like 11. So I'll I'll I'll stop keeping everybody here but thanks for coming thanks for the questions and I'm really looking in forward to starting to poke around in the Puppet scripts that Ben has set up know that I actually feel like I can't get vagrant running all by myself Ready to actually go for the industrial level stuff that then set up Nice work Jeff. Yeah, thanks eating. This is really cool. Thanks. See you later. I'll still is on you