Virtual Server & PM2

[00:00:00]
>> Okay, let's go ahead and do this together, and I will walk and talk at the same time. So we're creating a virtual host, virtual server, whatever you wanna call it. So essentially, it's a virtual server. It's a fake server according to NGINX, we can create infinite number of servers on top of our server, which is running on top of the server which is running on DigitalOcean.

[00:00:23]
Super meta, no one's laughing so I can tell you your brain is at its limit cuz that was pretty funny. I had that one saved up but let's create a virtual server here. So we're gonna call it server. Pretty original. That's just what NGINX it's called to create a virtual server.

[00:00:40]
We want it to listen on port 80, not port 90, and we want it to be the default server for all requests that are coming in. And the syntax highlighting here is actually pretty nice and then we wanna listen again, Colon, colon, colon port 80. And again, default server.

[00:01:04]
So that :::80 is just the IPv6. So we're listening on both just in case we get some requests via over IPv6. Colon, we're still gonna put the route as /var/www, we don't need to, but it'll make a good fallback page just in case. And we can say the root there is index or index.html.

[00:01:27]
They're the files it's gonna look for first. Again, we don't really need to do that, but it doesn't hurt to be extra safe. So the server name is actually important. It's important for routing requests. For this particular virtual server, it doesn't matter cuz this is the default. So all requests are gonna go here anyways.

[00:01:47]
However, when we get to a part self domain, the server does the matter cuz that's the request coming and saying I want to go to test.jemstack.lol or something like that. But in this case, you can keep a blank or I'm gonna say my are rename so jemstack.lol the best of all stacks.

[00:02:08]
Last we need to make a location block. We talked about location blocks tell NGINX where to route the request to. So in this case, we're gonna use that proxy pass directly. So now instead of being a web server, NGINX is just a proxy. It's gonna take the request saying, you need to go here, and there we go.

[00:02:25]
So proxy_pass http://127.0.0.1:3000. Almost forgot my semicolon, there we go. Okay, So did we do something wrong? Hmm, I don't know. We'll say nginx-t, There's a problem. Nginx-t will run through our configuration and just double check before you restart NGINX and make things bad. It will just validate all your configuration files.

[00:03:07]
So one thing we didn't do is we created a new sites enabled, but we didn't actually link it to anything. So let's go ahead and do that now. So we need to edit our actual nginx comp file. We're gonna remove the default. We're only gonna put in the sites enabled for full stack.

[00:03:25]
We don't have to do this. This will just make our life easier. We're not dealing with the default anymore. We don't have to worry about us being caught anymore. So you may have to scroll to find the virtual hosts in your etc nginx conf. And then just delete the one that says etc nginx enabled default or anything related that we only want our one virtual host running right now.

[00:04:03]
So I will do that now. Of course, I need to sudo this, don't get caught like me when you make a bunch of changes and you didn't fix it. And I'm like, where's everything? I'm just gonna type slash and I'll say virtual. Didn't find it. There we go.

[00:04:28]
Case sensitive, question. Yes.
>> Could you explain more of why we use nginx instead of just using node directly,
>> Yeah, great question. The question is, why don't we use nginx and not know directly? NGINX is faster. It's like I said it's written in C. It's a lower level language then no GS, which is written on top of C++, I forget.

[00:04:54]
But it's fear when no js is built on top. I mean, it's built on top of JavaScript which is built on top of something else. Nginx has a lot more capabilities than our notes server like if we wanna change where we log compression turning on HB2 and turning on SSL doing all that in node, we can do it but it's a pain in the butt I've done it before.

[00:05:14]
It's not fun messing with certs. Whereas nginx, this is all built in because it's bread and butter. It's what it does all the time. Nginx can handle way more requests and proxy them. It can act as a load balancer. It can do everything node can do, but much, much faster and much more efficiently.

[00:05:29]
So that's why we use nginx. When we get to, if we had, say, multiple servers we wanted to run, how would you handle that? If I have one node server and I have a Python server? How would you handle that, yeah you can do routing somewhere but at some layer you have to do the routing to your IP address.

[00:05:46]
So it's better to have the centralized router where everything's maintained and it's just directing the requests out. And when we get to things like subdomains and load balancers, you'll see the real power of nginx why this all makes sense. So I'm gonna delete this line. Actually, I'm set to modify it Cuz we don't want to sites enabled and we wanna be really specific, so we just want, we don't want all the sites enabled.

[00:06:13]
We want just the one full stack frontend. And let's write quit. Let me just check my own instructions, make sure I didn't do anything wrong. So we wanna validate the nginx configuration, nginx-t. Can I open logfile, push denied. These are directed to really make sense. Maybe I need to sudo that one.

[00:06:52]
Okay, so you may have to sudo the nginx-t because it has to access some of the log files like var log or air log which usually acts as a sudo. So if you sudo nginx-t, it's just validating you wrote everything correctly so what's next thing we do anytime we modify a configuration file, we restart the process.

[00:07:14]
So sudo service, What's next, restart, restart, reload. And now Let's check it out. Bob. Hey, we're getting somewhere in one. My domain name is finally hooked up. All right, yours may not be but hopefully it's propagated out. But what are we missing? Now we got the port, what are we missing?

[00:07:49]
We're not running a server. We never actually started our application. We wrote it but we never, it's all the steps along the way and it's really easy to miss these things. So let's go ahead and fire up Our node server again, or let's go back to our server, clear, and we'll just say node app.js.

[00:08:13]
So we started our server. Let's keep it running and switch the window here. Hey, hopefully you're here. There's a lot of in between steps, which we will simplify in some ways but, congratulations, you did it. You bought a domain. You hooked it up to your server, you created the server from nothing.

[00:08:42]
And I mean nothing. We had install everything ourselves. We had to handwrite all this stuff, we had to hand tune our nginx configuration, but now it's all connected. Now you're probably in a place that you're much more familiar with as a front end engineer which is NPM installing some modules, maybe Express, maybe React and you can build a full web page just from where we're at today.

[00:09:02]
So we got to the place that hopefully most of you are comfortable with. If you wanna find, you can use NPM install create react app or something like that. And you can build a full fledged service just from the steps we did here. Now, of course, the danger of running that node is running node app.js.

[00:09:26]
It works now, but the minute and I close my laptop, I'm gonna disconnect that Shell and the shell's gonna exit and it's not gonna run anymore. So this is the last step we're gonna do today because I wanna make sure your webpage stays up and running for now.

[00:09:40]
But we're gonna start a process manager called pm2, and this is installed globally, I wanna make make it clear so we're doing sudo npm i- g, this globally pm2. Pm2 is gonna keep our node application up and running even if we close the shell, or even if we close the exit the terminal.

[00:09:58]
So let's go ahead and do that now. So I'm gonna kill my server now. So sudo, oops, apps, old habit npm i. Pm2 and we'll say it's a global install the order doesn't matter. All right, so npm install, this we should be pretty familiar with now. So let's go ahead and pm2, run pm2, start our app.js.

[00:10:41]
And we can set it to watch if we want Unknown option -t. I don't know why it's -t, I didn't do anything, but that's fine. So let's check it out pm2, is it lists? Nothing running. So I did something wrong here. Pm2 start apps, yes may take up a watch.

[00:11:12]
There we go. That's right --watch. But that's all right. So now we can say pm2 lists. And even if I close my shell right now, it's gonna keep the application up and running cuz remember, we're still in the server and we're just keeping this process alive. But if we, say, had to reboot our server or something like that, we wanna make sure our application comes back online so we don't have to manually do it every single time there's an update or something like that.

[00:11:40]
Fortunately, pm2 is really powerful so let's just do that. Say PM2 save, which is gonna save our current process list, our current configuration. We're gonna say, pm2 startup. It's gonna give us some funky command about adding things to the path. You can just copy this whole command. And this is just adding it to the system data on startup.

[00:12:06]
There we go. So now, if our server reboots or anything, pm2 is gonna bring up our node application and it's running in perpetuity. Whoo!
>> What about server errors? Like, will the server restart? I'm just thinking of it like, node mod locally, like restarting the server anytime there's a file change or anything like that.

[00:12:32]
Would that, cause pm2 handle that kind of situation with like EHRs server?
>> Yeah. So pm2 is always gonna, that's what's great about if it's a server crash for some reason, it will always bring it back up. Now the level of configuration you want on the pm2 whether it sends you an email every time it restarts or just logs it.

[00:12:50]
You generally wanna know that if your server is crashing all the time, you may not detect that because pm2 is gonna keep you starting in the background and you never see it. So you gonna look at the logs or make sure you're piping the log output to somewhere you can see it, like an email or something like that.

[00:13:05]
But that's a great question, yeah, that's the danger of a process manager, it can hide a lot of the downsides. And watch. I think it's a --watch. I'll fix that will allow you to restart the server if you make a change. So pm2 is really, really nice. It does a lot of hard work for us.

[00:13:25]
And you saw that long path command we had to copy. That would be a pain if we had to do that ourselves. So pm2 just generates that for us, and we just copy and paste.