Bootcamp
Search…
2.11: Deploy Server to Cloud

Introduction

In Coding Basics and Project 1 we deployed our apps to the Internet using GitHub Pages. This was sufficient because our apps only involved static (i.e. non-changing) HTML, CSS, and JS files and no persistent data. To persist user-generated data on the Internet across multiple users and visits, we will need a place on the Internet to store that data (e.g. a database), and a place on the Internet with logic to manipulate that database. We can accomplish this by deploying servers to the Internet, i.e. the "cloud".
In recent years popular software services like Firebase have emerged that enable us to manipulate and store data in the cloud by calling APIs, without deploying our own servers. While convenient, these services are less customisable than managing one's own servers. Many companies continue to deploy their own servers due to specific requirements (e.g. database language, security), and their engineers need to know how to manage servers. At Rocket, we will first learn how to deploy and manage our own servers before using more convenient abstractions such as Heroku or Firebase.
Cloud service providers such as Amazon Web Services (AWS) and Google Cloud Platform (GCP) enable us to deploy our servers to the Internet without buying hardware. Instead, we "rent" AWS and GCP's hardware at a fraction of the cost in a data centre of our choice, located in the major regions of the world. AWS was the first major cloud service provider, gaining popularity in the 2000's, currently the most popular cloud service provider, and the one we will start with.
AWS' first product was EC2 (Elastic Compute Cloud), that allows engineers to rent computers remotely and run code on them. EC2 machines are "on the cloud", meaning we can rent and unrent these machines on-demand using AWS' website dashboard or even automated scripts. One of the geniuses of EC2 is that users can rent virtualised computer "instances", which seem like standalone machines to renters, but are only 1 of multiple virtual computers rented by multiple tenants running on a single computer. This helps AWS increase resource efficiency and reduce costs.
In this module we will rent a (free) AWS EC2 instance, clone our server code onto it from GitHub, and run our server for the public. We will access our EC2 instance via a public IP address it provides.

Create AWS Account

If you haven't already, create an AWS account here.

Create an AWS EC2 Instance

Log into AWS EC2 using this link. That link ensures we are in the Singapore AWS region, which will give us the best latency (assuming we are in Singapore).
Click the Launch Instance button.
Click to choose the Ubuntu Server version 20.04 AMI (Amazon Machine Instance). An AMI is a "snapshot" of a computing instance. In the listed options, each AMI represents a different operating system. AMIs can also be used as snapshots of instances we wish to replicate with specific software installed on them beyond the OS, e.g. Node.js.
Select the free t2.micro instance type. t2.micro will be sufficient for our needs, and will not cost us anything if we are not running other servers on EC2. You may receive an email that your EC2 usage has exceeded 85% of free usage, but the t2.micro will never exceed 100% of free usage.
After selecting an instance type, skip ahead by clicking on the Configure Security Group tab. We use security groups to control access to resources in AWS. By default, EC2 enables SSH (secure shell) on port 22, which is the mechanism that allows us to login to our remote machines via our terminal. More on this later.
We will update our security group to accept public HTTP requests on port 80, so that we can send requests to our server. Click Add Rule and select HTTP from the Type dropdown.
Selecting the HTTP Type should automatically set the Port Range to 80.
Click the Review tab and click the blue Launch button at the bottom to launch our machine.
AWS will display a modal and ask us about how we plan to access the instance.
  1. 1.
    Choose to create a new key pair, name it, and click the Download Key Pair button. Key pairs are typically stored in the ~/.ssh directory on Unix machines by convention. More on SSH in a later section.
  2. 2.
    Move your SSH key pair to your ~/.ssh folder in your Unix filesystem. If this folder doesn't exist, create it with mkdir. This is the standard place to store SSH keys. For WSL users, see a past student Porter's notes here.
  3. 3.
    After downloading the key pair, click the Launch Instances button. There will be no way to login and manipulate our EC2 instance without our key pair. The key pair is based on public-key cryptography, a common alternative authentication method to username and password.
We should now see the Launch Status page. Click the link (text is our instance ID) in the green box to view our EC2 instance list.
In the instance list, click on our machine's instance ID to see that instance's details.
The instance detail page will show our instance's public IP. Note there is also a private IP address used for private communication within AWS, similar to the private IP in a LAN network. Read more on IP addresses in AWS here.
The "open address" link defaults to https, which won't work with our http-only server code. Setting up our servers with HTTPS requires an extra step of procuring an SSL Certificate, which we will not discuss yet.

SSH to Log In

SSH stands for "Secure Shell" and is one of the most common and secure ways to access servers remotely. It allows us to "log in" to remote servers and manipulate them via the command line. SSH communication is encrypted. Read more about how to access EC2 instances via SSH here.
  1. 1.
    If we haven't already, unzip and store the key pair files from our EC2 instance in ~/.ssh on our Unix machines (use Ubuntu if on Windows). For WSL users, see a past student Porter's notes on this here.
  2. 2.
    Change the permissions of the downloaded key file to 400. This means the owner of the key file (i.e. you) will be able to read and write to this file. Read more on Unix file permissions here.
    1. 1.
      We will need to replace <KEYFILE_NAME> in the following commands with the name of our downloaded keyfile.
    chmod 400 ~/.ssh/<KEYFILE_NAME>.pem
  3. 3.
    Log into our EC2 instance with the SSH command. The -i parameter specifies the keyfile to use. [email protected] specifies we wish to login to the server as the ubuntu user, the default user for Ubuntu machines. Replace <KEYFILE_NAME> with our downloaded keyfile name, and <EC2_PUBLIC_IP> with our EC2 instance's public IP.
    ssh -i ~/.ssh/<KEYFILE_NAME>.pem [email protected]<EC2_PUBLIC_IP>

Just Another Computer

We are now in a terminal on a computer rented from AWS.
  1. 1.
    Try command line commands to see what's on this computer. This computer has no GUI (graphical user interface) like Windows or MacOS to click around.
    ls -la
  2. 2.
    Are there any files or directories that you also have on your own computer? Use cd if you need to.
  3. 3.
    To prove this is just like your computer, create a file.
    touch mytext.txt
  4. 4.
    Try any other command line commands you would like. Are there any you can or cannot run?

Install Node

Install Node on our EC2 instance with the following commands. We will use Node to run our server below.
curl -sL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt-get install -y nodejs
On the Ubuntu operating system (and all other Debian derived systems), APT is the family of commands that manages system packages. Read more about APT here. Other popular package managers like Homebrew are less commonly used on Ubuntu.

Run a Server

Clone the example server code from Rocket Academy's GitHub. GitHub is the primary way we will be transferring files to and from our servers. We could use a more direct file transfer method such as SCP (Secure Copy Protocol), but that allows more potential for human error.
  1. 1.
    Clone the repo
    git clone https://github.com/rocketacademy/file-server-example-bootcamp.git
  2. 2.
    cd into the cloned directory
    cd file-server-example-bootcamp
  3. 3.
    Start the server. sudo gives us root user permissions that we need to execute Node in this context.
    sudo node index.js 80
  4. 4.
    Send a request to the server at our EC2 instance's public IP address. It should look something like http://<MY_EC2_IP_ADDRESS>/index.html.

Logout

Type exit or use the Ctrl+D keyboard shortcut to log out of SSH. Note that once we log out, our server will stop running.
exit

Create a Permanently Running Server

By default, when we log out our server will stop running. Run the following command to keep our server running even after we log out of our instance.
nohup sudo node index.js 80 &
​nohup stands for "no hang up". The & after our command tells Unix to run the command in the background, freeing our shell instance to perform other commands, such as exit to logout.

Quit the Permanently Running Server

Each running process on a computer has an ID. To quit the server running in the background we have to find the ID number (PID, which stands for Process ID) and use it to kill that process in the instance.
  1. 1.
    Use the ps command to get a list of all processes. -a means "all", and -x will give us more detailed information the command for each process.
    ps -ax
  2. 2.
    ps -ax output may be quite long. To identify our server process, we can filter the list of processes by using the Unix pipe command (|) to send the output of ps to the grep command. grep is a search and filtering command.
    ps -ax | grep node
Sample ps -ax output
  1. 1.
    The PID will be in the left-most column of ps output. Copy the PID and use it to run kill, which will kill the relevant process. We will want to use sudo with kill because we had to use sudo to start the server process.
    sudo kill <NODE_SERVER_PID>
  2. 2.
    Verify that our server is no longer running by attempting a request.

Further Reading

  1. 1.
    Read more about how AWS uses private IP addresses here.
Copy link
On this page
Introduction
Create AWS Account
Create an AWS EC2 Instance
SSH to Log In
Just Another Computer
Install Node
Run a Server
Logout
Create a Permanently Running Server
Quit the Permanently Running Server
Further Reading