Transcript from the "Subdomains" Lesson
>> Next, let's create a subdomain. Subdomains are really useful. For example, when I work on Netflix.com I'm not directly developing on Netflix.com, I'm developing on our development environment. So it's gonna be like dev.netflix.com or something like that. It's not accessible to the public, obviously. But that's the usefulness of a subdomain as you don't have to create an entirely new URL.
[00:00:23] That means you have to create new cookies, etc. When you use a subdomain, it's a subset of your main domain, but it's much easier to work with. You don't have to go through as much trouble. So let's create a subdomain called blog. Or you can call whatever you want.
[00:00:39] I'm gonna call it blog because it's easy to reason about. So, it'll be blog.jumpsack.lol. So the first thing that we have to do is we have to create an A record on DigitalOcean. Now, you've already done that before, so I'll let you do that now. All right, so probably the hardest part is remembering where to look on DigitalOcean.
[00:01:02] For once you get to the domain, and if you want to cheat, you can say, networking slash domains, and it'll take you to the right place. To create a record, we just say blog, and it's gonna fill in the rest for me. And I create the record. Great, for right now, it's not doing anything.
[00:01:19] Nginx doesn't know how to handle these requests, so we're gonna need to create a new virtual server, Or just another server to deal with this. We don't necessarily have to, but let's say I wanna redirect my blog to an entirely different application. Let's say I had a blog running in Django written in Python, or not necessarily directing to my node.
[00:01:40] So this way we can have multiple parts in your domain redirecting to entirely different applications using nginx. So to create a server, create a new server. And this is what it's going to look like. So you remember where to create servers? That's in your /etc/nginx/sites-enabled. And just call it blog, blog.yourdomain.com, or blog.fullstackfrontend.
[00:02:12] The name actually doesn't matter too much. All right, let's go through this together, just in case you're wondering what are these things? Let's go over the the nginx virtual host config again. So what I'm gonna do is, clear, I'm going to sudo vi /etc/nginx sites-enabled/, And I'm gonna just gonna call it blog.fullstackfrontend.
[00:02:48] You can call it whatever you like, but it's really helpful if you're making a subdomain to prefix it with the name of the subdomain. All right, so next I'm gonna create a server block, and that starts with server. And I'm just going to close it off you down here, you know me.
[00:03:11] Next, I wanted to listen on port 80 for now, listen 80. And then we're gonna listen on 80 but on ipv6, And this probably the most important part, right here is you have to tell nginx where to go, based on the requests. So the requests are always be coming from blog.URLdomain.com.
[00:03:38] So we had to write that out explicitly, because remember, this isn't the default server. This is a different server entirely from our default one we created earlier. So, server_name and it's blog.jemstack.lol, that's your server name. Then all we do is do what we did before, we're gonna use proxy pass and create a location block.
[00:04:03] So location to any requests coming from blog, And for now we're just gonna proxy pass that, because we're not gonna create a new server for this entirely, but it's pretty easy to do it. And it's easy to proxy pass to an entirely different port, entirely different system and service.
[00:04:25] So, http://, I'm just gonna use a shortcut of localhost instead of 1 to 7. You can use either 1. Every single proxy to 3000. Again, when the first time you did this, you're like, this is weird. You do it again, you're like okay, now, I sort of see how nginx server blocks work.
[00:04:50] The last thing we have to do is update our nginx conf. Because remember, we didn't set it to pick up everything in our sights enabled block, we were really specific about it. So, I'm just gonna tab up and say, sudo vi /etc/nginx/nginx.conf. And we're gonna create another line here for the include.
[00:05:21] Doesn't really matter. So we're gonna say include, that new server, virtual house we created, nginx/ sites-enabled. /blog.full stack, front end. And this if you're running the trouble, this is probably the thing that we forgot. It's pretty easy to make this mistake. And the last one, and what do we have to do anytime we modify the configuration of a running process?
>> Restart it.
>> That's right, we have to restart it. That one's the easy one. You're like why isn't it working, Jim? Cuz we didn't restart it, nginx doesn't know. So sudo service, nginx restart. And as always, we generally try to run the sudo nginx-t just to validate our configuration, but this one's pretty straightforward.
[00:06:26] But it's running into issues like nginx is throwing up some sort of weird messaging, do nginx-t to validate your configuration. So now, I feel like this might have proxied fast enough, it might have updated fast enough. So, blog.jemstack.lol, it may not have gotten there yet. Yep, it did.
[00:06:53] There, we just created a subdomain, and we see how easy it is to create a another application, maybe an entirely different node application. We'll just change the port that we're proxy passing to. Yeah, not too bad. What I love about this particular exercise is if we did it earlier, we're talking about nginx, you'd be like, what is all this stuff happening?
[00:07:11] But now because we've done it enough times, we see the purpose for every single line and how all the systems work together from the name server to updating your nginx config, and restarting the whole process.