Transcript
  • Servers and Tools

Setup the Project

From the class:  Getting Started with NGINX

The setup for this class is a little bit more involved than what you might be used to. So it's going to make use of knowledge that we learned from the SSH class and also from git deploy. But I'm going to walk you through it quickly to make sure that you're all set up and that you can follow along.

If we take a look at the contents of this directory after you clone the project, you're going to see the regular app files and also the vagrant file to configure our virtual machine. Let me give you a tour of that vagrant file. It's going to have a few new things in it.

And when you scroll down, notice first that I'm giving it an IP address. And if you go all the way to the bottom, I've added some provisioning scripts. And this is going to get us to where we got in the git deploy class. We did that by hand last time, but I don't want you to have to go through all of that by hand again. And so instead of doing that, I just scripted it out to happen automatically.

And to give you a quick sense of this, first we're going to install Node.js. We're going to create the application directory that we can deploy to in the apps folder, and here's where we actually create all the different app folders. We're going to set the permission so that the group has write access. We set the group user ID every time we create a new file.

And then here's where we're going to initialize they git repository so we can push up to it. We're going to upload the post-receive hook and they systemd service up to the machine. And then once that's done-- just scroll down a little bit further-- gonna run this shell script that copies the post-receive hook into the git hooks directory, and then it changes the ownership so that it's correct, and does the same thing for boom service, except it copies it to the systemd folder in lib, and then it enables the boom service so that next time we deploy, the service is enabled and we can start it as usual.

The rest of the contents of the project are just like the app that we saw in the git deploy class. So there's an HTML file here. The name of the application I've called boom because I'm so excited to deploy it. And it has a JS and a CSS file.

The bin folder has a server file that we can use to start up the server. And inside the config directory are all the different things that are going to be used to config and to deploy the service. Inside the public folder, I'll talk about that when we get to assets. But right now, there's just a text file in there, one that I'm going to show you how to deliver through nginx.

Now, the server for this class is not using any framework. I just built this myself because I want it to be very, very simple with no other dependencies. And this framework could have been written in any language. I happened to choose JavaScript and Node.js, but it could easily be Ruby. It just needs to be an HTTP server that can listen for HTTP requests. So it's going to listen on port 3,000, just like last time.

And if I quit out of this, the only thing I need to do to get this all set up is to say vagrant up-- or to set up the virtual machine, at least. This process might take a little while, a few minutes. And once it's done, we'll set up our SSH so that we can use the regular SSH command to get into the machine.

You might see a few red messages during that process. But don't worry unless it fails completely. If you get a message that says it just didn't complete, then worry about that. But otherwise just go ahead and vagrant ssh into the box. Let's just do a quick safety check and make sure everything is OK.

First of all, we should have a directory under apps, and it should contain our boom application. If I change into that, you should see the directory structure for our deployment environment. And the current directory should have a git folder inside of it. It does.

And we should check whether or not the boom service was uploaded correctly. So I can say sudo systemctl status boom, and it tells me that it is. It knows about it. It's an amazing application. And it's loaded, but it's just inactive. So we haven't started it. Yet and that's fine. The reason we haven't started it is because we haven't pushed up our application yet. And we'll do that in a second.

And so when you're done with the safety check, just exit out of this. And next up, what we need to do is to update our SSH config so that we can use the regular ssh command instead of vagrant ssh. And again, this also allows git to use the SSH config.

So I'll use the vagrant ssh-config command. And again, as a reminder, it just prints to standard output all of these settings required to connect to the SSH server. So it's going to give us the path to the identity file, for example, the port that it should connect to, and the user that it should use. What we're going to do is take that output and append it to the SSH config for our system.

So use the two arrows, not one arrow. Otherwise you'll replace the file. We want to append to it. I'm going to append it to the SSH config from my home directory, and then open up the SSH config file just to make sure that it's OK.

So here's what was just appended to that file. And I'm going to change the hostname from default to deploy so that it's a little bit easier to remember. It's a little bit more descriptive. And I think everything else here looks great. And so to test it out, we can say ssh deploy. And that should drop us right into our virtual machine, if everything worked correctly.

Next up, let's get our code pushed up to the server using the regular git deploy process. So first I'm going to add that deploy server as a remote-- git remote add deploy, and then the address of the server. So we can use that host name that we just created in the config. So deploy apps/boom/current. That should be good enough. And we can just verify with a remote with a -v option.

And then I'll push up, deploy to the deploy server the master branch. And if that all works, what we should see is a bunch of messages from the git deploy class, like the fact that we are deploying the master at this particular commit. And we've started up the boom service, and here's the message that systemd is sending us back, saying we've got a pid, and everything seems to be working correctly. There's no error messages here.

And we can quickly verify that by just curling the IP address or the HTTP server-- so 192.168.33.10, port 3,000. And what we should get back is an HTML page that looks like our app. Everything looks good. If you want to double-check it, you can SSH into the deploy server and use the ps command to see-- ps facts should be good enough to see that we have started up the server.

And here it is. It's run by node, and here's the file that starts up the server. So everything looks really good. Now that we're in the server, the next thing we need to do is to actually install a nginx. That wasn't part of the automated process.

To install nginx with all of the documentation and components that we need, you could say sudo apt-get install nginx-full. And you can pass it the -y option to skip asking you whether you really want to install it.

Once that process completes, nginx should be installed, and it should have started automatically. Again, we can verify that by taking a look at all of our processes. And it's down there at the bottom. You can see that nginx started up, and it's got a couple of workers waiting for connections. And it's also automatically now listening on port 80, our web server port.

We head over to a web browser and type in the IP address, we get the nginx page. And we don't have port 80 here because that's the default for any website. And so this all happens automatically just by installing nginx.

Now we have two web servers running. We have one that's running on port 80-- that's the nginx. And we have another one that's running on port 3,000. And that's our node application. So both right now are public because we're just playing around.

So we've got two servers. And next up, we're going to configure nginx to work as a proxy to our application.