Now that you know all about web servers, it is time for you to rent your own. In theory you could contact your ISP and lease an IP address that you could then associate with your laptop. This would make your laptop into a web server! Unfortunately, this has the downside that your laptop must always be available and have enough bandwidth to support your millions of fans. It also creates a significant security risk for your laptop. Instead we want to use a cloud provider that can give you an inexpensive small computer that you can experiment with and throw away any time that you would like. This is actually exactly what many web companies do with their core business, so it should work fine for you.
When you rent a web server, it is physically located in a massive data center located in a place like Virginia, Ohio, Dublin, or Tokyo. Think of a data center as a very secure, climate controlled, warehouse that has hundreds of thousands of computers sitting in massive racks.
Assuming you already have an AWS account it is time to create your web server.
Note
AWS interfaces changes all the time, so the images given below may not match what you see. However, the concepts they represent should all be there in some shape or form.
Important
It is crucial that you use the N. Virginia AWS region because the Amazon Machine Image (AMI) you will use is only available in that region.
-
Open the AWS console in your browser and log in.
-
Navigate to the EC2 service.
-
Change your region (top right corner) to
US East (N. Virginia) - us-east-1. Changing your region to N. Virginia will make it so that your server is located there. -
Select the option to
Launch instance. -
Give your instance a meaningful name. Perhaps use a convention such as [owner]-[purpose]-[version].
-
We have created an Amazon Machine Image (AMI) for you to use as the base for your server. It has Ubuntu, Node.js, NVM, Caddy Server, and PM2 built right in so that you do not have to install them. Paste this AMI ID (
ami-094c4a0be0b642a24) into the search box and press enter. Then select theCommunity AMIstab. If no matches are found, make sure that your region is set toUS East (N. Virginia) - us-east-1(You can check this by looking in the top right corner of the page).This should display the information about the class AMI. If the AMI ID matches
ami-094c4a0be0b642a24select it. -
Select t3.nano, t3.micro, or t2.micro for the instance type depending on how much power you want, how much you want to spend, or if you qualify for a free usage tier. If you qualify for a free usage tier then pick that instance type, otherwise choose the cheapest one. You can always change this later if your server is running slow and needs more power.
-
Create a new key pair. Make sure you save the key pair to your development environment. This needs to be safe in a place that is not publicly accessible and that you won't accidentally delete or commit to a GitHub repository. You will need this every time you secure shell (ssh) into this server (production environment). Note that you don't have to create a new key pair every time you launch an instance. You can use one that you created previously so that all of the servers you create can be accessed with the same key file.
-
For the network settings, make sure the
auto-assign public IPaddress is enabled. For theFirewall (security group)select the option toCreate security groupif this is the first server that you are creating. Allow SSH, HTTP, and HTTPS traffic from anywhere.If you have created a server before, then you already have a security group that you can use, and you should not clutter up your account with additional ones. In that case, use the option to
Select existing security groupand select the name of the existing security group.A security group represents the rules for allowing access to your servers. Security group rules specify both the port that is accessible on your server and the source IP address that requests are allowed from. For example, you could allow only port 443 (the secure HTTPS port) from your development environment's IP address. However, doing so would mean that your web application would not be available from any other computer. You can learn more about security groups from the AWS documentation.
-
If you are using a T3 class server you can take an advantage of the unlimited credit specification. If you are not using at T3 class instance, you can ignore this step. In the
Advanced details, change theCredit specificationtoUnlimited. This allows yourT class(throttled class) server to keep running normally even though it has exceeded its current credit limit. You do incur a minimal charge for when this happens, but the alternative is to always spend more for a larger instance, or to have your server lock up when it hits the limit. For the minimal use that your server will see, you should not normally exceed your limit, but it is nice to not have your server die if you do. Even if you do temporarily exceed the limit, the charges will be mere pennies per hour. -
Select the option to
Launch instance.
It will take a couple minutes for the instance to startup, but once it is marked as running it is close to being ready. Look at the properties for the instance and copy the public IP address.
Open your browser and paste the public IP address for your server in the location bar along with the prefix http://. For example:
http://3.22.63.37If the server has started up, then you should see the following. Otherwise, wait a little bit and refresh your browser again. If the server is marked as running and it has been longer than 5 minutes, then there is a problem.
If that is what you see, then congratulations! You are now running your very own web server that the whole world can see! Time to celebrate with cookies.
Now, let's remote shell into your server and see what is under the hood. Go to your console window and use SSH to shell into the server. You will need to supply the public IP address (copied from the EC2 instance details) and the location of your key pair file that you created/used when you launched your instance. Hopefully, you saved that off to a safe location in your development environment; otherwise you will need to terminate your instance and create a new one, with a new key.
➜ ssh -i [key pair file] ubuntu@[ip address]For example,
➜ ssh -i ~/keys/production.pem ubuntu@53.104.2.123You may get a warning that your key pair file permissions are too open. If so then you can restrict the permissions on your file so that they are not accessible to all users by running the chmod console command:
chmod 600 yourkeypairfile.pemAs it connects to the server it might warn you that it hasn't seen this server before. You can confidently say yes since you are sure of the identity of this server.
Once it has connected, you are now looking at a console window for the web server that you just launched, and you should be in the ubuntu user's home directory. If you run ls -l, you should see something like the following. (Note that the dates might appear different.)
➜ ls -l
total 4
lrwxrwxrwx 1 ubuntu ubuntu 20 Apr 13 15:06 Caddyfile -> /etc/caddy/Caddyfile
lrwxrwxrwx 1 ubuntu ubuntu 16 Apr 13 15:06 public_html -> /usr/share/caddy
drwxrwxr-x 4 ubuntu ubuntu 4096 Apr 13 16:48 servicesThe Caddyfile is the configuration file for your web service gateway. The public_html directory contains all of the static files that you are serving up directly through Caddy when using it as a web service. We will cover Caddy configuration in a later instruction. The services directory is the place where you are going to install all of your web services once you build them.
Once you are done poking around on your server, you can exit the remote shell by running the exit command. That is everything. You will only change a few configuration settings on your server in the future. With rare exception, all changes to the server are done using an automated continuous integration process.
You can stop your server at any time. Don't confuse this with terminating your server which completely destroys it. Stopping your server just powers down the device. This is nice because you don't have to pay for it while it is stopped. However, every time you stop and start your server, it will be assigned a new public IP address. It is important to keep the same public IP address so that you, and others, can always browse to the same place. More importantly, when you create your domain name, you can assign it to an address that never changes.
You have two choices in order to keep the same public IP address:
- Never stop your server.
- Assign an elastic IP address to your server so that it keeps the same address even if you stop it.
Your first elastic IP address is free. However, the catch is that it is only free while the server instance it is assigned to is running. While your server is not running, you are charged $0.005/hr. This is the same cost for running a t3.nano server instance. So if you assign an elastic IP address, you don't save any money unless you are running a more powerful instance and are stopping your instance when you, or the TAs, don't need it.
We would suggest that you do both options. Keep your server running and associate an elastic IP. That way if you do need to reboot it for some reason, you will still keep the same IP address, and it doesn't cost you anything more either way.
Here is how you assign an elastic IP address to your server instance.
-
Open the AWS console in your browser and log in.
-
Navigate to the EC2 service.
-
From the menu on the left select
Network & Security|Elastic IPs. -
Press the
Allocate Elastic IP addressbutton. -
Press the
Allocatebutton. -
Select the newly displayed allocated address and press the
Actionsbutton. -
Select the
Associate Elastic IP addressoption. -
Click on the
Instancebox and select your server instance. -
Press
Associate.
Assigning an elastic IP address will change the IP address for your server, but it will not change again until you release the elastic IP address. If you do terminate your server and create a new one, you can again associate the same elastic IP address with your new server.
Note that your elastic IP address is allocated until you release it, not until you terminate your instance. So make sure you release it when you no longer need it. Otherwise, you will get a nasty $3 bill every month.
The t3.nano instance size has just enough memory and CPU power to meet the requirements of this course if you are careful. However, if you find that your server is running slowly or erratically, you should consider upgrading to a larger instance size. If you have an elastic IP address you can change your instance size whenever you would like and you won't lose your public IP address. You can even stop your server when no one is using it. This is useful because you don't get charged for your server when it is stopped.
- Create an EC2 instance using the class AMI (
ami-094c4a0be0b642a24). - Assign an elastic IP address (highly suggested).
- Test that you can see the default class web page from a browser using the server's public IP address.
If your section of this course requires that you submit assignments for grading: Submit a URL using your web server's public IP address to the Canvas assignment.
Don't forget to update your GitHub startup repository notes.md with all of the things you learned and want to remember. This might include the IP address of your server and the command to remote shell into your server. Do not include the contents of your PEM file, passwords, or keys in your notes.
| Symptom | Reason |
|---|---|
| You can SSH into the server, but you can't use HTTP | Check that your security group exposes SSH, HTTP, and HTTPS. |
| Using the browser to hit my server using my IP was working but now it doesn't | Check that your IP address hasn't changed. Perhaps due to assigning an elastic IP address or stopping your server. |
| My server doesn't come up in the browser | Check that you are not trying to use https before you configure Caddy to use https. |









