Linking to a Domain

00:00 Linking to a Domain. In this section of the course, you’ll work through how to purchase, set up, and link a domain name to your existing application. The example domain seen in this course uses Namecheap, but don’t take this as an unequivocal endorsement.

00:18 There are more than a handful of other options, such as domain.com, GoDaddy, and Google Domains. But for clarity of impartiality, Namecheap has not paid anything for being featured as the domain registrar of choice in this course.

00:34 Create an account on Namecheap, making sure to set up two-factor authentication. From the homepage, start searching for a domain name that suits your budget.

00:44 You’ll find that prices can vary drastically with both the top-level domain and the hostname. When you’re happy with the choice that you’ve made, purchase the domain.

00:55 This course uses the domain deploydjango.site, but you’ll have your own. As you go through this course, remember that deploydjango.site is just an example domain and isn’t actively maintained. Also, remember that you’ll need to replace any references to it with the domain that you purchased to get the code to work.

01:15 When picking your domain, keep in mind that choosing a more unusual site name and top-level domain typically leads to a cheaper price. This can be especially helpful for testing purposes.

01:27 Once you have your domain, you’ll want to turn on WithheldForPrivacy protection, formally known as WhoisGuard. This will mask your personal information when someone runs a whois search on the domain. On Namecheap, you can perform this during the purchase process.

01:47 Next, it’s time to set up the DNS record table for your site. Each DNS record will become a row in a database that tells a browser which underlying IP address a fully qualified domain name points to.

02:00 In this case, we want deploydjango.site to route to the public IP address that we chose earlier on. To do this, select Account and Domain List,

02:15 select Manage next to the domain,

02:21 pick Advanced DNS, and then, under Host Records, add two A Records for your domain.

02:36 You can add the A Records as seen on-screen, but remember to replace the IP address seen on-screen with your public IP address.

02:52 An A record allows you to associate a domain name or subdomain with the IP address of the web server where you serve your application. As seen on-screen, the Value field should show that public IP address of your VM instance.

03:05 You’ll also have noticed there are two variations for the Host field. Using @ points to the root domain, deploydjango.site in this case, and using www means that www.deploydjango.site will point to the same place as just deploydjango.site.

03:22 This is a subdomain that can send users to the same place as the shorter domain name. Once you’ve set the DNS host record table, you’ll need to wait for up to thirty minutes for the routes to take effect.

03:36 You can now kill the existing runserver process.

03:44 You can confirm that the process has gone with pgrep or by checking active jobs again.

04:03 With all these things in place, you’ll also need to tweak a Django setting, ALLOWED_HOSTS. This is the set of domain names that your Django app is allowed to serve.

04:22 The leading dot (.) a subdomain wild card, allowing both the www and the plain versions of the domain name to work. You should keep this list tight to prevent HTTP host header attacks.

04:37 You can now restart the WSGIServer, but with one slight change to the command used to invoke it.

04:47 Note that the address port argument is now 0.0.0.0:8000, while none was previously specified.

04:57 As you saw before, specifying no address:port implies serving the app on localhost:8000. This meant that the application was only accessible from within the VM itself.

05:08 You could talk to it by using httpie, as you saw, but you couldn’t reach your application from the outside world. Specifying an address:port of '0.0.0.0:8000' makes your server viewable to the outside world, although still on port 8000.

05:25 The 0.0.0.0 is shorthand for “bind to all IP addresses this computer supports.” In the case of an out-of-the-box cloud VM with one network interface controller, using 0.0.0.0 acts as a stand-in for the public IP address of the machine.

05:44 Next, use the tail command to view output from nohup.out so you can see any incoming logs from Django’s WSGIServer.

05:55 Now it’s time for the moment of truth. It’s time to give your site its first visitor. From your machine, enter the appropriate URL in the web browser. Remember that the one seen on-screen applies to the domain used in the course, so you’ll need to substitute your own domain.

06:12 You should see the page respond quickly in all its glory. Note that this URL is accessible to you—but not to others—because of the inbound security rule that you created earlier on.

06:25 Now return to the shell of your VM. In the continuous output of tail, you should see something similar to what’s seen on-screen. Congratulations, you’ve just taken the first monumental step towards hosting your own website.

06:37 You can close tail by pressing Control and C in the terminal window. Despite the success, you should pause here and take note of a couple of gotchas embedded in the URL.

06:50 First, the site is served only over HTTP. Without enabling HTTPS, your site is fundamentally insecure if you want to transmit any sensitive data from client to server or vice versa.

07:03 Using http means requests and responses are sent in plaintext. Fixing this falls outside the scope of this course, but if you check out this Real Python article after you complete this course, you’ll be able to delve into this topic and get your site up and running using HTTPS. Secondly, the URL uses a non-standard port 8000 versus the standard default HTTP port number 80. It’s unconventional and a bit of an eyesore, but you can’t use 80 yet.

07:37 That’s because port 80 is privileged, and a non-root user can’t—and shouldn’t—bind to it. Later on, you’ll introduce a tool into the mix that allows your app to be available on port 80, but there’ll be more than one step needed to allow that to happen.

07:53 The first part of this process is to replace Django’s development server, and that’s what you’ll be looking at next.