[MUSIC]

As I just said, my name is Tim Ambler.

Over the course of this talk,

I'm gonna be taking a look at one of my favorite subjects, which is Vagrant.

The idea that technology changes quickly is a pretty well worn aphorism, but

it's well worn because it's true.

And over the course of the past couple days we've been exposed to a lot of

that changing technology.

Concepts such as full stack JavaScript node, CSS3 animations, Angular Directives.

In the grand scheme of things,

these are pretty bleeding edge, but if I had to put together a list of

the top innovations that have occurred in the last few years in web development,

Vagrant would definitely be at the top of that list for me.

So a bit of background.

My first exposure to Vagrant was around early 2012.

I was serving as one of two lead developers for

a local startup here in Nashville.

At the time, the company's onboarding process for

new developers looked a little something like this.

The steps required to set up your computer so

you could actually start contributing were pretty tedious.

For starters, you had to get Apache installed, then you had to

install a specific version of PHP along with a specific version from MySQL and a,

a, a whole host of other supporting tools that I won't bother getting onto.

Then you go and you import the latest version of the database that happened to

be floating around the office.

To top it all off,

the process of completing all of these steps was dramatically different

depending on whether you have to be on OSX, Windows, or Linux.

It's also worth noting that at this point our back-end infrastructure really wasn't

all that complicated compared to some setups that I've seen.

It would eventually go on to become much more complex as we started

distributing work across multiple servers, but that said this relatively simple

setup was giving us enough headaches during the onboarding process as is.

It was not about to scale.

[BLANK_AUDIO]

When a new developer joined the team, inevitably, what you would see was

this multiple day long process, that looked a lot like a game of telephone.

Where the last person to join the team was forced to impart the knowledge that was

passed on to him by the last person to join, and on and on down the line.

And all of this was just to get you started.

So heaven forbid that something significant actually change,

which it frequently did, and you had to rinse and repeat all over again.

Eventually, after watching one too many people jump through these hoops,

we got the bright idea that there must be a better way.

And sure enough there was.

And for us that better way was Vagrant.

So what is Vagrant anyway?

Well regardless of whether you actually use these tools on a day to

day basis I'm sure that everyone here has at least a passing familiarity with

virtualization products such as VMWare, Parallels, and Virtualbox.

These products are what make it possible for

us to run the latest copy of Windows 8 on OS 10 or vice versa.

These tools have been around for some time, this is nothing new.

But the big innovation that Vagrant brought to the table was the notion that,

hey, wouldn't it be really cool if someone created a utility that allowed you to

write scripts that could then tell these tools what to do?

Scripts that you can share and reuse.

Scripts that can take this messy hairball of pain that is server deployment and

turn it into something manageable and maybe even enjoyable.

And well, Vagrant does that.

So in essence,

Vagrant makes you the conductor of your own personal deployment symphony.

It lets you write scripts and

telling your computer how to make other virtual computers.

You can then interact with as the developer.

In hindsight, it's a pretty simple concept.

It makes you stop and go, well, why didn't I think of that?

But usually the best ideas are like that.

So the notion of being able to take, of being able to create custom servers and

you can then share with your colleagues is pretty awesome in it's own right.

But Vagrant actually takes it one step further.

In addition to running these custom servers in your own environment,

Vagrant also allows you to take those same servers and

launch them remotely on a number of well known cloud platforms.

For example Amazon Web Services, Digital Ocean,

and then Rackspace just to name a few.

So in other words,

when you're actually ready to watch Vagrant helps you alleviate the hassle

involved in actually getting your product out the door in front of other people.

So to summarize everything we've covered so far into under one sentence,

Vagrant takes this and it combines it with these to give you this.

[BLANK_AUDIO]

So now that we've covered a few of the basics about what Vagrant actually is,

let's take at look at how Vagrant can have an impact on specific roles

within the development process.

[BLANK_AUDIO]

For starters, if you're a developer, Vagrant helps you isolate your

dependencies in the configuration within a single consistent, sharable,

disposable environment.

And importantly it doesn't force you to sacrifice any of

the development tools that you're familiar with along the way.

You don't have to SSH into some remote server file VIM for

example if that's not your thing, you can use whatever text editor prefer.

It also relieves you of the tedium of having to juggle different

configurations across multiple projects.

So, if you happen to find yourself working on a project that relies on PHP for

example and you don't happen to have the required version on your Mac.

You don't have to worry about it.

Finally, every developer has at one point tried to

track down Bubba the colleague whose response is well it works on my machine.

Vagrant alleviates that problem, because with Vagrant,

there is no such thing as my machine.

You're all working in an identical environment.

If you're and operations engineer, they can you provide you with a disposable

sandbox in which you can create and test infrastructure management scripts.

If you want to, say, experiment with running the latest version of MongoDB or

mess around with Reddits for example.

Vagrant lets you do that locally, and

then with the same scripts, remotely on your cloud provider of choice.

And finally, if you're a designer,

Vagrant let's you focus on what you do best, design.

Vagrant ensures that you have access to the same running environment that

the developers on your project do the same, but

without forcing you to dig through the underlying details.

And as a technology stack, the powers of project changes as in inevitably will,

your environment will track right along with it.

Without requiring you or anyone else to fiddle with your computer settings.

So that takes care of our initial introduction of vagrant.

Why don't we get our hands dirty, dirty with some actual examples.

First a few obvious prerequisites, you'll want to install virtualbox.

I mentioned this earlier in the presentation.

This is a free alternative to paid products such as VMware and parallels.

While Vagrant supports VMware and Parallels, most of the examples that we'll

be looking at today are designed with the expectation that you're using VirtualBox.

And since one of our main goals is to create an development

environment that can be shared with anyone the fact

that VirtualBox is free provides us with a solid baseline from which we can be

sure others can operate it without having to buy anything.

You'll also want to install Vagrant, obviously.

Both of these come with a simple installation wither, wizard and

take only a couple of clicks.

Nothing out of the ordinary here.

And finally I'll be using some custom configuration scripts that

I found personally to really ease the transition into Vagrant.

And you can find those on GitHub.

And obviously, you'll have access to this slide after this presentation.

[BLANK_AUDIO]

[SOUND] Okay, so, let's assume for

the moment that you are completely new to Vagrant.

You just installed VirtualBox, you just installed Vagrant, now what do you do?

Once we started by creating our first virtual server.

I'm going to go to my desktop and I'm going to create a folder called mybox.

I'm going to CD into that.

And then I'm gonna type Vagrant init hashicorp/precise32.

And I'll tell you what this means here in a moment.

In order to explain what I'm doing here I'm going to have to

take a very brief detour.

The people behind Vagrant and

the Vagrant community at large provide a large number of order called base boxes.

These are very basic,

generic servers without a lot of extra stuff installed that you might not want.

These are great resources on which you can build your own custom foundation.

You can find base boxes for Ubuntu, Debian, and CentOS, just to name a few.

Pretty much every well-known distro is represented.

And if it's not, you can create your own, which we'll get to in a later example.

But going back to the current example.

When we typed Vagrant init hashicorp/precise32, we were referencing

one of these pre-existing base boxes that the community has made available.

It's actually possible to pull in a base box from any URL, but

a recent addition to Vagrant is a website that you can find at vagrantcloud.com and

I'll pull that up in my browser now.

I've explored this a little bit and didn't find much of value here.

Essentially Vagrantcloud is Vagrant's official site for posting and

sharing boxes, but it's entirely optional.

They attempt to monetize this by charging you for the ability to host private boxes.

But again, you can host things anywhere.

So the important thing to note here is that hashicorp/precise32 is

just a shorthand notation that,

when used, references a box that has been shared on Vagrant Cloud.

So, that being said,

going back to our first example, we ran Vagrant init specifying base box to use.

In this example we're using Ubuntu precise 32,

which is a pretty good generic default, a good place to get started.

If we take a look at the contents of this folder now,

[SOUND] you'll see that we have one file, and it's called vagrant file.

This is the configuration file that tells our bots how to behave.

[SOUND] This is what the default vagrant file that vagrant creates looks like.

It's in here that we can specify settings such as our box's IP address,

forwarded ports, allocated RAM, host name, and other things of that nature.

It's written in Ruby which I'm not a big fan of but we'll come back and

talk about configuration a bit more in our next example.

For now, I'm just going to clear this screen here.

I'm going to type Vagrant up.

This will boot up our new server.

We'll see some status messages printed out to the console that keep us posted as to

what's going on.

When the process finishes, our server is ready for use.

Vagrant provides a shortcut for

signing into the server, which we'll use here in a second.

You just have to type Vagrant SSH and now we're signed in.

I'll type a few commands here just to give you a lay of the land.

But again this is just a standard Ubuntu precise 32 server.

It doesn't have anything running locally.

Not a lot of services installed.

It doesn't do much because we haven't told it how to yet.

But, again we'll touch on that in our next example as well.

When we're done with this box, you can do a couple of things with it.

First of all, I'm going to exit out.

Now I'm back to the console I'm on that.

We could put to sleep with vagrant suspend.

We can bring it back up by simply typing vagrant up again.

It should just take a second.

Now it's back up.

We could SSH back into it if we like.

Or when we're completely done with it, we can type Vagrant destroy.

It's gonna ask me to confirm.

And the effect of this is that it's as if we never started it up in the first place.

[BLANK_AUDIO]

So now that we've walked through this example of setting up a default box,

let's start doing some stuff that is actually useful.

But before we do, as I mentioned a few minutes ago, let's come back and

talk about configuration for a moment.

I mentioned that Vagrant is configured with a single file named vagrant file

that's written in Ruby.

I'll show you the contents of that again.

I'm personally not a fan of Ruby but

regardless of how you feel about it I think that one thing is for sure.

It's not a universal language.

And by that all I really mean is that it's not as quickly grasped by

everyone as something like say, JSON.

And when it comes to configuration that's what I want.

I want a format that is immediately approachable by everyone,

regardless of whether they've used Ruby or not.

And for that reason I've gotten in the habit of having my own personal data file.

I've configured it such that all it does is it parses the contents of

another JSON configuration file and

uses that to set all the various Vagrant settings that you'd like to use.

This is what that actually looks like.

[BLANK_AUDIO]

Really straightforward.

[BLANK_AUDIO]

So right off the bat you'll notice that we have a servers array that can take one or

more objects, each of which describes a virtual server to be created.

Most of the examples that we'll be working with involve spinning up a single server

but we do have the option of defining multiple servers that can work together.

And we will eventually work with an example that does just that.

I'm assigning the server a custom host name.

As a result, when the box is ready I'll be able to access it directly,

at the modernweb.site domain name.

I'm also no longer referencing the hashicorp/precise32 base box that

we used in our last example.

I'm actually referencing a box of my own creation that I have made available in

my public Dropbox folder.

We'll talk a bit more about how that works here in a minute.

A timezone setting allows us to automatically set

the appropriate timezone on our new server.

And scripts that's a little bit more in depth,

we're gonna hit that in a later example as well.

One final thing to take note of you'll notice that we have a paths object that we

specify as well.

It's here that we can specify one or more mappings that will enable us to

map files on my map to paths on the server.

In this example,

these settings will result in the files on my map that are located within

the repos/modernwebsite folder being available on this server at /opt/site.

This is important because this will allow us to keep working with

these files on our host computer.

And again in my case on my Mac using my preferred editor, which happens to be bba.

As I make changes they will be immediately reflected on the virtual server as well.

[SOUND] So, with that being said, let's setup our next server.

But at this time, this, this time, let's get a little more sophisticated with it.

Before we do that,

though, I need to talk about one other Vagrant concept known as repackaging.

I've already mentioned base boxes.

These are generic boxes without any extras added on to them.

No additional services or programs like Apache or Nginx, MongoDB or

Node are installed for you.

These boxes provide you with a clean slate from which you can work.

Now, let's imagine for a moment that you've spun up one of the base boxes.

You've signed in. You've installed Node.

You've installed MongoDB and a few other dependencies that you want.

Now you've got to use this box as current state, as your baseline moving forward.

Obviously you don't wanna have to do this manually every time you spin up the box

because that defeats the whole point of what we're trying to accomplish here.

So how do you go about doing that?

There are a couple ways to do this, but

one of the easiest that I've found is the repackaging process.

Repackaging allows you to take a Vagrant server you have running,

then repackage it as a brand new base box that you can then share with others.

And I'll show you what that looks like right now.

[BLANK_AUDIO]

So, several minutes ago, I destroyed this example server that we were looking at.

I'm actually gonna bring it back up and once it's up I'm gonna sign in again and

I'm going to install Nginx.

This is a pretty popular lightweight web server.

Box is ready.

Vagrant SSH.

Sign in.

Just a couple of steps that I have to walk through to get Nginx installed.

This should only take about 30 seconds.

[BLANK_AUDIO]

Almost done.

All right, so now that I've updated Ubuntu, I'm gonna install Vagrant.

I'm, I'm, I'm, I'm sorry, I'm gonna install Nginx now.

[BLANK_AUDIO]

Done.

Okay, so what have I done here?

I booted up a brand new base sever, signed in, and installed Nginx.

So now I'm gonna exit out.

And I'm gonna type vagrant package --out then I'm gonna give it a target file and

in this example I'm just gonna save it to my desktop.

[BLANK_AUDIO]

So what it's gonna do now, it's gonna shut down the server,

it's gonna export it out to a .box file which you can then host anywhere you like.

In the next several examples that we look at, I'm using such a box.

I've got it in a public Dropbox folder.

This usually takes anywhere from two to three minutes.

It varies a little bit.

We're not gonna sit here and watch this.

So I'm gonna go ahead and cancel out of that.

[BLANK_AUDIO]

And that's it.

Just real quick before we move onto the next example.

I'm gonna pull up my public Dropbox folder for a second.

[BLANK_AUDIO]

This is the base box that I'll be using in the next couple of examples.

It's 1.7 gigs.

Obviously the size is gonna vary based on what you install on your server, but

this is fairly typical.

[NOISE] All right, so, our next example.

Now that we have a solid grasp on what repackaging is and

how that works, we can move forward.

For this time around though I'll be setting up a box that we already set up

with a solid set of dependencies that I find myself often [INAUDIBLE].

I package it for use, reuse, and,

and place the result in box file integrated within my DropBox folder.

A link to that box will be included with the slide that you get

after the presentation.

I'll also be using my preferred Vagrant file, but reads its

configuration setting from a jSON file instead of making you learn Ruby.

[NOISE] All right.

So, let me just bring up our next server.

[NOISE] This is the configuration

file that we're gonna be

using as the server spins up.

It's got a guest IP of 10.0.320.

I'm assigning it a domain name of modernweb.site.

I'm assigning a name to this base box that I'm using, and

I do that because what's that gonna tell Vagrant to do is, as we move forward and

create other servers on top of this, it's gonna match that name of the URL.

I've already downloaded this, I don't need it again.

I'm also specifying the pads that map to this particular folder right

here to slash up slash site on this service that we're creating.

We're gonna be in the central time zone.

And also gonna have it spin up my local web browser and

point it to a specific URL when it's ready.

You also notice here that I'm specifying an apt script to run.

So what this is doing is it's looking in a scripts folder, that I've included.

And it's using, in the scripts that I

specify in this configuration file to provision this server.

So if you take a look at apt, at app I’m sorry.

All its going to do is its going to cd into slash opt slash site.

That’s that’s again that’s the folder that maps to my local fo

folder on my mac where I happen to have a project.

It's going to start a, a node instance.

I actually need to put in my password here.

It's asking me for my password because the way in

which these folder passes are set up is via NFS and it, it wants to know my

administrator's password to modify some user setting from my back.

[BLANK_AUDIO]

And so, here we are.

Server's running.

The ma, the mappings were set up.

Once the box was ready, it ran, it looped through the app scripts that we set up.

And it started a running node instance.

It then immediately opened a tab in my web browser that took me

to this project on [UNKNOWN] 3,000.

That's a pretty simple example of a Vagrant project.

Now I can move onto

something a little

more advanced.

[NOISE] Give me just one second here.

All right.

So. I’m going to take the example that we

just ran through.

I’m gonna stand up again, but this has been modified in a minor way.

I I don't know how many people here are using their own production or

how you're doing that.

Typically when I do that I often find myself not directing traffic

directly to that running node instance.

That's usually abstracted behind something like say, for example, Nginx.

And this script that we're running right now is actually going to allow us

to do that.

[BLANK_AUDIO]

So a few minutes ago we looked at this slash apt script.

Very, very basic.

Just a couple line that you can see here.

It's just seeding and, and slash up slight.

It's running forever start index.js.

Those of you that are familiar with node and have, have used Forever before,

you know exactly what that is But if we look at this Nginx script that I've

got right here, this starts to get quite a bit more complicated.

I'm not gonna run through the contents of this.

It's really not that important.

But, basically the concept that I'm,

I'm trying to push here is the fact that you could create these batch scripts

that you can run programmatically whenever you boot up a box.

And these scripts, then instruct the server on how to do it's thing.

How to set it up, how to do things that you want it to do.

So you can see, I'm no longer hitting the sever at port 3,000,

I'm hitting it at port 80.

And it will do that, because I've now got

this running node inst, that I was going to.

[BLANK_AUDIO]

So what I'm gonna do next is I'm gonna destroy this intens-,

. instance and run through another example.

[BLANK_AUDIO]

One thing that I frequently find myself running into when I'm working on a project

that has Vagrant is, so I've created this box that I've given to my colleagues.

You know, they're coming in at the beginning of the day.

They spin it up.

They start working on the project.

That's all well and good.

But when the box is up and running.

And they go into the app that we're building.

They need to have a, a basic set of data to power the thing.

We need a shared schema we can reimport over and over.

I'm going to show you how I typically go about doing that in this example.

I'm just going to hit Vagrant up again.

[BLANK_AUDIO]

And if we take a look at this data script that I'm now using right here.

My scripts configuration, I'm just running app and data.

In here, these are just some basic Bash commands where I'm,

I'm telling MySQL to create a new database.

I'm importing some data from a couple of FLAC files.

And as a result, when the server's up running, we can launch the app and

it's going to work exactly how we expect it to.

This should just take a second.

When it's done, I'm gonna sign in for the SQL portal [UNKNOWN] Mongo and

show you what the data base are set up like we'd expect them to be.

Should take just a second.

By the way, if anyone has any questions as we're looking at this,

feel free to throw them out there, I'd love to hear them.

[BLANK_AUDIO]

All right. So the server's up and running.

It's ready.

I'm gonna grab SQL Pro over here now.

[BLANK_AUDIO]

And you can see we've got our database set up just like we want it.

It's got some sample data that we can use.

This app is good to go and it's ready to be used.

All right, well that illustrated it, and I'll destroy this box again.

[BLANK_AUDIO]

And now I'm going to show you that I referenced earlier in the presentation.

So, everything that we've looked at so far has shown how you can setup

a single server, but one of the, the more exciting things that,

that I find about vagrant is that you can use this thing not to just create these

really simple servers, you know, one-off things that do their thing.

You can actually use Vagrant to create really, pretty sophisticated deployments

comprised of multiple servers that can talk to each other.

That, you know, have a,

a really nice separation of concerns where you get the server a that can do

each one thing, you get the server b that does this specific thing, and

they work together, together, to create this really nice distributed product.

And what we're gonna do now is show an example of how that works.

So, again, in all the other examples that we've looked at in

our configuration files, we should find a single server right here.

What we're gonna do now is actually to find two to find two servers here.

I'm calling one ModernWeb1, and I'm calling the other ModernWeb2.

This first one has an IP of 10.0.3.20.

I just gave this second one 10.0.3.21.

I'm gonna hit the, I'm gonna give the first a domain name of modernweb1.site,

second one will have moderweb2.site.

Other than that they're pretty much identical.

So, when I type vagrant up again it's now gonna loop through both of

these definitions and

create two identical running servers here on my Mac that I can interact with.

[BLANK_AUDIO]

This should take just about 30 seconds or so.

Scrolling back here through the right now.

I'm looking at some of the questions that we got here.

Aaron Bigs,

How did you get your Vagrant to read your JSON instead of the Ruby Vagrant file?

While this is loading up, I"ll show you that right quick.

Again, I've got the sources I've given up,

I'm going to give everybody access to it after the presentation.

But this is what my Vagrant file looks like.

If you scroll down here there's not much more than what you see.

I've broken everything down into a couple other

smaller Ruby library files that I'm then pulling in.

But to answer your specific question, how I'm loading that from a JavaScript,

I'm sorry, from a JSON file.

The Vagrant file, it's just a Ruby file, that's all it is.

So all I did basically, and

again, I'm not really a big Ruby guy, so I had to do a little bit of research and

I ended up doing this, but I'm just saying require JSON, which is a Ruby construct.

Now I'm looking through and

I'm saying if config.json loaded up, then I've got that, that hash object.

I can then loop through in Vagrant and spray.

The server's not quite ready yet, but it almost is.

You are back in port 3,000.

Is that correct?

I think it is.

I, I think I had the first example, not the first example.

Maybe it was the second example where I installed Nginx and

was putting everything on port 80.

I'm not necessarily doing that every single time now.

All right, and our two servers are now up and running.

You'll notice that since I got my Vagrant file set up to automatically load

in my browser, any URLs that I set with open URL, it did that for me.

So here I've got modernwebtwo.site, modernwebone.site, and

to illustrate how these things are, are, are capable of talking to

each other I'll just show you real quick, I can ping both of them from my Mac.

[SOUND] As mentioned earlier,

I gave this one an IP of 10.0.3.20, you can see that here.

Same deal with modernwebtwo.site.

[SOUND] 10.0.3.21.

And I can SSH directly into either of these boxes by typing vagrant, ssh, and

then specifying the ID that we assigned in a very specific box.

So I can say vagrant ssh moderweb1.

And that's gonna take me in.

And that command Vagrant SSH, that's just shorthand, something that Vagrant

opens up for you, but obviously these are actual running servers.

So, if you just want to use SSH and provide a, an ID list or

a hostname, you can just as easily do that.

But now that I'm signed in to modernweb1.site I

can actually ping together a box from more than this server.

You can see in here again it's getting that same IP address 10.0.3.21.

So that pretty much wraps up this particular example.

What you're seeing here though I feel is pretty powerful.

I mean you can use this to create some really pretty sophisticated deployments.

The number of servers you spin up simultaneously is, is

really only limited by the capabilities of the computer that you happen to be using.

How can we get local configuration examples?

They are not in our GitHub vagrant repo.

Okay I haven't actually pushed those up yet.

I put those together just for

today's example and I haven't, again I haven't pushed them up yet

but I will be happy to do that after we, we get off the presentation.

It's no problem at all.

All right, so with that being done, I'm gonna exit out.

And I'm going to destroy both of those boxes.

Vagrant destroy.

It's gonna confirm both of them for me.

[BLANK_AUDIO]

Done. And so

I have no servers running right now.

It's, it's as though, you know, I, I haven't done anything.

Our box is back to its pristine state.

So our next example is going to involve ultimately what could potentially

be one of the coolest accidents of Vagrant which is the ability to take one of

your script technicians and use that to deploy jQuery remote [UNKNOWN].

So, I'm just going to repeat the process that we've done now a few times.

I'm going to copy this configuration over, put it in our config.default.json file.

And you'll notice it's a little bit different from some of the ones that

we've gotten used already, but I am specifying a couple extra [UNKNOWN].

I'm saying provider Visual Ocean.

I'm also passing some provider settings.

So I'm, I'm giving this a name, and

we'll sign into my Digital Ocean account here in a second.

You'll see this pop up I've got a token here.

And for those of you that are paying attention,

this is just a temporary token and

that I am gonna wipe out after we get off the call.

image, specifying, you know,

the picture I want to use, the region that I want to put it in.

I don't know how many of you here are familiar with Digital Ocean,

but they are absolutely fantastic in my estimation.

The pricing is significantly cheaper than what you're gonna find on

Amazon Web Services.

They do occasionally have a couple of hiccups in terms of reliability, but

they're getting better every day.

I can also specify what region that I want to put this server in.

So much like Amazon Web Services or any other, you know,

well known cloud provider, they've got servers all around the country,

all around the world and you can specify what region you want to put it in.

So let's say for example I'm creating this fairly sophisticated deployment and

I'm expecting a lot of traffic.

I could have one server running on the east coast.

I could have one running on the west coast.

They have a San Francisco region that you can tap into.

So, with this in here now, I'm going to boot this up.

Francois they are great.

Yeah I love Digital Ocean.

How long can you keep the servers up?

For days, hours, months?

You can keep it up for as long as you want.

You can keep it up until they go out of business.

Which I don't expect because they're pretty well funded.

And it's not a fly by night operation.

If you haven't heard of Digital Ocean before check them out.

They're, they're really getting a lot of traction.

[BLANK_AUDIO]

All right, so

this might take a little bit more than one of the inside of our previous examples.

Obviously on having to communicate with Digital Ocean and,

and now send out some outbound traffic that I haven't had to before.

But it really shouldn't take that long.

While it's doing that I'm just gonna jump back over to make up the migration file.

Just like in all the previous examples, I'm specifying some paths here.

And it's going to map these local folders to this Digital Ocean

server that I create.

There's going to be one slight difference here.

If I'm making changes to these files now.

After the server gets created it's not going to be immediately reflected.

As a matter of fact, it's not going to be reflected at all.

All it's doing here in this case is it's just pushing them out to

the server when it's ready.

Just a one way push.

There is no back and forth.

[BLANK_AUDIO]

Great. Okay.

So creating a new droplet.

droplet, again if you're not familiar with Digital Ocean,

this is just their terminology for an instance.

Just marketing speak.

Assigned IP address.

It's almost ready.

You can see it's Rsyncing the folder out, and at this point we can probably already

go ahead and, and look at my Digital, Digital Ocean cap and see this pop up.

Yep, there it is right there.

[BLANK_AUDIO]

And the server's ready.

[BLANK_AUDIO]

I could have just as easily SSH'd into this thing by,

by going directly to this IP address right here.

But just as in all the previous examples, since Vagrant graded this thing and

is, and is aware of it, I can type Vagrant SSH,

and it's just going to basically alias that.

And do an SSH into this remote server, but

again I could just as easily SSH directly into the IP if I wanted to.

So I'm gonna exit out of that.

Destroy it just as we had in all of our previous examples.

[BLANK_AUDIO]

And I've got a couple of other examples here that I

want to run through real quick.

That I feel are, are, are gonna illustrate some pretty useful things that I've

come to rely on pretty frequently.

The first one is,

is going to be an example of how you can use mbrak within Vagrant.

I don't know if any of you are familiar with that.

This is a fantastic service.

I don't know if Brian Neimeyer is on the call right now or

not, but I believe he's the one who actually introduced this to me.

So what I'm gonna do now is I'm just gonna go back to our previous example.

The first one that we did.

I'm just gonna spin up a really basic box.

[BLANK_AUDIO]

Since I'm really not doing much here or

running any additional scripts this should just take a second.

[BLANK_AUDIO]

I appreciate everybody showing me a little bit of patience here.

Obviously the topic at hand it's not the kind of thing where you can

just spin these up instantaneously.

It does take a couple seconds, but big picture really not a lot of time.

[BLANK_AUDIO]

Almost done.

[BLANK_AUDIO]

Almost.

[BLANK_AUDIO]

It's asking me for my password again.

Again, it asked me for my password so it can set up these path mappings.

[BLANK_AUDIO]

All right, so I've created a new instance of this really basic server.

I, I haven't installed node on it or, or, or done a lot fancy things with it.

I just booted up this really basic server.

And now I'm gonna SSH into it.

When it was ready it opened up the stat in my browser and took me to the site.

And so you can see here obviously it does have engine X.

So it's got something running on port 80.

So what I'm gonna do now is illustrate how you can use this

really nice service called Ngrok.

And that's N-G-R-O-K.

I'm just gonna say Ngrok, I'm gonna get port 80.

And what it's actually going to do now is it's going to

create what's called a reverse SSH tunnel.

And that's just a, a fancy phrase which means anybody on the,

on the public internet can now hit this URL right here.

And it's going to route that traffic to port 80 on my box.

And importantly, you'll note that I didn't have to do anything else.

I didn't have to, you know, mess around with the settings on the router,

I didn't have to open up a specific port.

It just works.

It's really nice too because if we go to our browser and hit that URL.

Go.

[BLANK_AUDIO]

Might be might be having internet trouble here.

There we go.

Okay. You can see I'm

hitting 5470d93f.inroc.com.

It's really cool because as you're doing that

you can keep an eye on what's running here in the terminal and

it's gonna show you the traffic, the requests that are coming through.

And you can actually go to ngrot.com and

they provide you with an online tool set for, for using deeper analysis of

that traffic What I'm showing you right here is actually free.

But for a very minimal one time fee, you can get some extra services.

You can get custom subdomain names.

So you could point everybody to, you know, yourcustomname.ngrok.com.

For those of you that wanna get a little more sophisticated with it,

Ngrok is actually an open source tool.

So you can install this on your own server and

completely push their service out of the picture for you and host this yourself.

[BLANK_AUDIO]

So, what we're seeing there is pretty powerful.

I, I don't know everybody's background this year.

I can tell you a couple ways that I frequently find myself using this tool.

Let's say that I'm, I'm working on a,

a single page application that has a series of, of mocha tests behind it.

I don't know how many of you here are familiar with tools like Selenium or

Sauce Labs, that allow you to run an automated test suite against your product.

But having this tool allows me to use those third party services.

And then tunnel their traffic into my box and

not have to worry about well is my router setup?

Are they gonna be able to get through?

It just works.

It's a simply appliance.

We're running a little short on time, but

that's fine cuz I only have one more example.

[SOUND]

All right.

I've stored the server already, and then spin it back up.

One thing that I frequently find myself frustrated with in

terms of app development is email testing.

So most of the products that I work on, they, they tend to take a tack of,

all right, well, when somebody registers,

we're not gonna have them create their own username.

We're just gonna say, give us your email.

That's gonna serve as your user name and we're gon-,

we're gonna keep the barriers to entry really low.

We're gonna let them into our app right away.

But we do eventually want to validate that email address and

make sure they're not spamming us.

We actually got another, another person on the end of this line.

And so testing the, you know, that process.

Testing out all of the transactional emails that go out from an app,

that can be kind of a pain to deal with.

One of the nice things about working with Vagrant is that you can

put some solutions in place to deal with that.

So, in this particular instance, this server actually has its own

email server running on it, and it has users inside of it.

So, what that means is that I can send email to users at this box.

I can say you know, sending an email to user1@favorite.site.

And then I can just hit port 8000.

Maybe it's port 8080.

I actually have what's called Roundcube running on this box.

It's just a really simple PHP-based email client.

yeah.

So we're running a little bit short on time here.

Instead of just, you know, dragging you through it how all this works lets see if

anybody's got any more questions.

Regina is there anything else that anybody'd like to talk about,

any questions you have or, or

any insights into how you happen to be using Vagrant at the moment?

[BLANK_AUDIO]

Regarding the guest IP aspect of the config, how did you choose it?

Is that router specific?

Would it make more sense to use a 198.162.XX address?

I honestly don't remember where I got that number.

I, I've been using Vagrant for a while now and

I think that's just the number I've seen that, I happen to just have stumbled on.

I think that you can, again, you could just as easily have used in any,

any local IP or adding scene that you want.

Obviously you don't want to use something that could actually be a real remote IP

address, but anything that's know a local subnet would be just fine.

[SOUND] When I get it right, you always need one.

If I get it right, you always need one origin box.

Is that correct?

Could you expand on that a little bit?

I'm not sure that I know exactly what you mean by origin box.

If you bring up a box with a cloud provider does Vagrant destroy,

delete the VM there?

Yes it does.

At least I can,

I can tell you with 100% certainty that it does in the case of Visual Ocean.

I hadn't used all of them but

I'm gonna venture to guess that they all pack in the same way.

But in, in, with this particular provider for Digital Ocean, yes, it does.

One existent virtual box.

Yeah, I don't think you, yeah you always need to define at least one server to use.

If I'm understanding you correctly, I'm not sure if can understand a situation

which you would wanna use it without defining servers at all.

But yeah, you definitely need at least one server.

So real quick, let me just make one more comment.

In terms of how I find people objectively using this tool.

If you happen to find yourself in a project where you have multiple developers

working on a single code base typically what I

find people doing is having a single GitHub refill in which that project lives.

And then underneath that refill they've got a vagrant folder.

And within that folder live these files that we were looking at.

The ones that you're gonna have access to GitHub after the call.

And what.

Do as I say.

All right we have a new guy here, girl here going to start on this project.

Clone this [UNKNOWN].

See me in the emulator for worm.

Hit Vagrant up and then you're good to go.

And it's really as simple as that.

It provides you with this nice appliance that can track right along with it.

Without requiring people to, to go though all these tedious steps of

setting this stuff up on [INAUDIBLE] server.

How would you do this if you had parallels?

Like I mentioned earlier in the presentation,

yes Vagrant absolutely supports parallels.

It supports VMWare as well.

I haven't used parallels before or

I shouldn't say I've never, it's, it's been quite a while.

Pull up the documentation,

essentially what you're gonna do is take the same scripts that we were using here,

and instead of pointing it to Digital Ocean or pointing it to,

to Virtualbox you're gonna override that and say point it to parallels.

You may run into a,

a, a couple of instances where you have to tweak a couple of the settings, for

example, if, you know, parallel support's doing one thing in one way that

Virtual Docs just doesn't support, you might have to tweak it a little bit.

But you know, 98% of the stuff is going to fork right on over.