Now let's configure NGINX to do what we want. Well, let's just SSH into the deploy machine and change into the etc NGINX folder. Oftentimes, on Ubuntu systems or on Unix systems, you're going to see that configuration files go into this etc folder and then under the folder of whatever application you installed.

So you can just kind of remember that. If you forget where config goes, generally, it goes into the etc folder. Inside the etc NGINX folder, take a look at the contents. These are all the files and folders that are used to configure our NGINX instance.

And the most important file that we're going to be working with is this nginx.conf. This is a configuration file. And it tells the NGINX how it should behave and what exactly it's supposed to do. So this is kind of like our code file for NGINX.

And the rest of these things, in here, are supporting files for this configuration file, I'm going to show you a trick, here, to make our lives a bit easier while we're working with this virtual machine. Remember, with Vagrant, that anything we put in the forward slash Vagrant folder is going to be shared with our local machine. So this is just automatically set up for us as a shared folder.

And what I want to do is to symlink this to the one that's in our config directory. That way we can just work on it locally. And every change we make will immediately be reflected in the server. So symlinking is a really handy feature. We're going to use it all the time.

I'm going to use the pseudo command, because we need pseudo privileges to do this. And then the link, symlink-- and I'm going to force it just in case it's a file, which, in this case, it is.

And then we give it the target of the file, where we want to get it from. And that's going to be under Vagrant, config, NGINX, nginx.conf. And then we're going to symlink to that file, the one that's in etc, NGINX, nginx.conf.

And if that succeeds, when we look at the directory contents, now, notice that this file is now a link that points to the one in our local project folder. This'll make our lives a lot easier. Now let's head back to our local machine and open up the NGINX configuration file to customize it.

The nginx.conf file is going to tell NGINX how it should behave. And it's basically a list of these things called directives. Directives, you can think of as a key or some setting.

And the directives have values. For example, this first directive, user, is saying that the user to run the NGINX process should be www-data. Or this could be the Vagrant user or some other value we give for this directive.

The one right underneath it says, how many worker processes should be created? And right now, it's set to automatic. That means it's going to do its best to create as many workers as there are CPUs on the machine.

The PID directive is going to say, where do you want the PID file. The PID file is going to be a file that just contains the process ID of the running NGINX process.

Some of these directives have blocks instead of regular values. So this is a block directive. And inside of the block, which is denoted with these brackets, we can have other directives. This also sets up something called a context. So I'm giving you the vocabulary, in case you see it in the documentation, and you're not sure what it means.

Everything in here is in the events context. Another context is the HTTP context. So this is where we're going to put all the settings related to any HTTP servers that we have. Inside of the HTTP context, we can have multiple HTTP servers if we don't just need to have one listening on port 80.

So any of the directives, up here, are going to apply to all of the HTTP servers that we have running. For example, this is saying to log all access logs.

So that's any client that tries to access a URL, that this server services, to access dot log, and any errors that happen to varlog NGINX error dot log. So we don't need to repeat these settings for every single server that we create.

Scrolling down a little bit more, this setting says that NGINX should try to compress assets or files that are coming across the wire. So it turns GZIP, this compression, on. And it disables it for the Microsoft IE 6 browser.

And down here are some commented out GZIP directives that specify how GZIP should behave. For example, we might say that you want to GZIP just these particular types.

Down a little bit further, the include directive allows us to include another file. And what it will do is literally take that file and put it here, to put the contents of the file here. So it allows us to a separate the configuration into multiple files and make it a little bit easier to manage.

This has been set up for us, automatically, by the Ubuntu installation of NGINX. But this might actually be blank if you're installing on different operating systems. In this case, the way that this is configured is all the individual servers will be put into this sites enabled folder.

So you can see this star means include all the files in this folder. And each one of the individual files will have its own server definition. We can follow this architecture, particularly, if there's a bunch of servers that we're going to be running.

But because we're only going to have one or a handful of them, I'm just going to put them all right here, so it's easier to deal with. So I'm going to start this off, this customization process, by commenting out these lines. And that will also get rid of the default server that's currently running.

So let's create our own server. And to do that, we can use this server directive, which is going to set up a new context. The first directive we can provide inside of this server context is the server name.

This is going to be the host name that we want to use this server for. For example, it might be www.eventedmind.com. Or it might be just eventedmind.com. Those would be two different host names.

And we could say that we want this server block to respond to any requests that are using this as the host name. And we might have another server block that responds to server names where there's a www in front of it. So we can kind of mix and match these servers. For now, I'm just going to call this boom.com.

And the next thing we can provide, the next directive is the listen directive. This is going to say which port do we want this server to listen on? And also, potentially, which IP address do we want it to listen on?

Right now, I want it to just listen on the default IP address for port 80. So I'll type 80, here, and use a semicolon. We always need to put semicolons at the end of each directive, each simple directive in the configuration.

We could provide another option to the listen directive, which is to say that this server is the default server. That way, if there's no host name provided in the request or NGINX can't figure out which one of these server blocks should be used, it'll use the default server.

So now, without doing anything else, we have a server that's listening on port 80. This is the default server. And it's going to try to serve requests where the host name is boom.com.

Any time we make a change to this configuration file, if we want NGINX to recognize those changes, we either need to restart NGINX or to reload it.

So open up a new window here and SSH into the deploy machine. And I can use system control to do that. Usually, if you have a live server, you're going to want to reload instead of restart. That means NGINX will stay running, but it will reload its configuration.

So we can reload NGINX. And then we can check its status by using the status command of system D. The other thing you can do, if you want to check the syntax of the configuration file before reloading it, you can say, pseudo NGINX dash t, use the t option.

And you'll get back a message saying that the syntax is either OK or it's not OK. So if you get any errors starting up NGINX because you have a configuration error, you can use this to see what is wrong there.

Now that we've restarted NGINX or reloaded it, we should be able to say curl dash i localhost dash i to get the headers back. And then we get the standard NGINX page still, just like we had before. Even though we changed the server, the default server, we still get back this HTML page.

The reason for that is because we haven't specified what to do when someone accesses at port 80. So what NGINX is going to do is it's going to serve up a file that is located in var, www, under the HTML directory. And notice this file in here, index.nginx-debian.html?

Well, if we cat that to standard output, notice it's the file that NGINX is serving up by default. So it's going to look in this directory and try to serve up this index file by default. So we'll go ahead and change that next in the configuration.

One of the simplest directives we can use inside of the server block is a return directive. That allows us to return an HTTP status code, for instance 200 or 301 for redirect. And we can also provide a simple text for the HTTP text or simple body text that can go here.

So I'm going to return a 200 status code, here, that says, hello world, with a new line character, so we get a new line. And remember, the semicolon at the end. So what this is going to do, now, is it's not going to try to serve up any files.

It's just going to get to this return statement and immediately return back to the client a status code of 200, with this in the body. This could be useful for things like redirects, which I'll show you another video.

Let's go over here, now, and restart the server pseudo system control. I could actually just reload it. Now, let's see what happens when we curl local host. We just get back this hello world text. And we can use the dash i option to see the headers.

And the status code that's seent back from NGINX is 200 OK. And the text that we said to send back.