 Hello everyone plus one to the seatbelts. We're gonna be moving quickly. Can we get our slides? Okay, my name is Daniel Farrell. I work for Red Hat under the R&D office on the SDN team. I'm D Farrell 07 everywhere. I need to find my clicker Which brings me to I just tweeted out these slides. So if you want to find those, that's how you would do it D F A R R E L L 07 So what's vagrant jumping in we have very little time the quickest way I can put it simplest way I can put it Is that it's a tool for working with virtual machines? In fact, it's a modular framework for working with virtual machines, which we'll see more of in a second It all starts with a vagrant file and it's kind of all orchestrated through that vagrant file So they can be very simple you'll see more examples in a second and then very simple command So vagrant up vagrant SSH, and then we have a shell That's cool But we've been able to work with vagrant with virtual machines to the CLI for a long time So Vbox manage create VM we could wrap scripts around this and have similar functionality Per a very nice rant that Mitchell went and did on hacker news for us We have some inside into sort of the harder problems that they solved with vagrant It you know on top of what could be done with shell scripts a lot of that is around cross OS support So vagrant is a cross OS platform. You can use it with OS X or windows or various Linux distributions It also does a lot of networking out of the box for you So as soon as you stand up your VM all of your networks working and that's cross OS It also does a lot of sync directory work for you So the directory that contains your vagrant file automatically gets synced into your box and vice versa here I'm showing the contents of root vagrant, and then I'm creating a new file Root vagrant foo, and then I'm logging out of the VM and showing that it's been synced back to my local system Finally it solves all these problems in a modular way, which we'll show in a second, which would be very difficult for shell scripts So here's a really important concept Zola and difficult thing There are two really important p words here in vagrant world provisioners and providers provisioners and providers provisioners and providers key concepts providers provide virtualization support Essentially, they magic VMs into existence. There are two types of providers local and remote Local providers are things like virtual box libvert VMware docker. Yes docker so you can manage containers not just virtual machines when I said it's a VM management tool There was a slight white lie there Also remote providers things like open stack digital ocean AWS Second major p word provisioners provisioners provision the VM or they do shared repeatable configuration against the VM There's some simple on-ramp provisioners like the shell provisioner. You can do just inline commands You can point at shell scripts nice little way to get started. They're also powerful options for people who need things like that So ansible roles puppet puppet Chef saw Public modules you can mix and match as a vagrant practitioner. You would then go and mix and match Provisioners and providers based on the knowledge that you have to sort of solve the use case that you need Let's see that through some examples. Here's kind of the most minimal example We're saying vagrant init-m the name of the box that creates the file that we're counting cadding out in the second command here The file says that we want to start with a fresh until seven environment and do no additional configuration We can then boot this virtual machine with vagrant up that downloads our base box If we don't have it cached locally already it boots the VM and it does our cross OS networking and Synced folder or magic we can then connect with vagrant SSH and has a we have a shell on our new machine Second example quickly. This is the shell provisioner So we have the similar configuration on the first line in this case We're starting from a fedora 22 box And then we're saying we want to run this inline shell command which in this our case install some system dependencies using DNF We can boot our box with vagrant up again We do the same networking and shared directory magic and then we run our shell provisioner which will install those system dependencies As we'd expect third example this one uses ansible so first line similar We're starting with a vagrant base box. That's a fedora 22 second chunk is the Configuration for the ansible provisioner basically what's going on is that we're pointing out a playbook file Which is kind of an ansible thing that you don't really need to understand But it's pretty simple We're saying for all hosts as root install open daylight, which is a project that I contribute to and accept all the defaults When we do our vagrant up we do the same magic around networking and such and then we run our ansible provisioner That installs open daylight. We can connect to our box with vagrant SSH And then use pseudo system control is active open daylight to verify that our open daylight system D services running So concluding with some sort of high-level points about why I think you should use vagrant why it's an awesome tool It provides well-defined environments that you understand right so you know what you installed You'd know what's configured in this environment. You can go back and reference that easily It's also easy to share those environments with your team members Oh, this can be like your individual team members in a company particularly powerful for open source communities though I will attest as we use it all the time in the upstream The vagrant file that sort of defines all of this is done is inversion control So there's lots of benefits around that looking at the history the contributions going back in time Being able to review code as it's changing and such It also replaces binary VM artifacts, which is sort of the traditional thing that we're switching out here So be involved VM blobs have issues around figuring out what software is installed in them And copyright things that follow from that So this is a nice win for open source projects as well your environment and code shipped together So when you get pull your repository, you also get the vagrant file that defines the environment of how to run it You're able to reuse existing logic around configuration management So if you have a complicated project that you've solved The deployment with an ansible role or something you cannot duplicate that effort and just consume it and vagrant Your local deploys and your remote deploys like very similar So if you're dev working on software on your local box and you're an odd and you have an ops person as well Their deployment pipeline will look very similar to stand up and tens of these pieces of software in production That's all I have and I'm out of time. My name is Daniel Farrell again. De Farrell is seven everywhere. Thank you for your time