Two years ago I wrote a blog post about hosting Node.js servers on Scaleway. I have now started using Nginx to allow me to host multiple sites on one €2.99 a month server.

This tutorial will help you build a multi site hosting environment for Node.js servers. We are going to use a pre-built Ubuntu server image from Scaleway and configure Nginx as a proxy. SSL support will be added by using the free letsencrypt service. I have written this post to remind myself, but hopefully it will be useful to others.

Setting up the account

1. Create an account on scaleway.com – you will need a credit card.
2. Create and enable SSH Keys on your local computer, scaleway have provided a good tutorial https://www.scaleway.com/docs/configure-new-ssh-key/. It's easier than it first sounds.

Setting up the server

Scaleway provides a number of server images ready for you to use. There is Node.js image but we will use the latest Ubuntu image and add Node.js later. At the moment I am using VC1S servers which is a dual core x86.

• Log into the Scaleway dashboard and click “Create server”
• Select the VC1S server and the latest Ubuntu image currently Xenial.
• Finally click the "Create Server" button.

1. Within the scaleway dashboard navigate to the "Servers" tab and click "Create Server".
   1. Give the server a name.
   2. Select the VC1S server and the latest Ubuntu image currently Xenial.
   3. Finally click the "Create Server" button.

It takes a couple of minutes to build a barebones Ubuntu server for you.

Logging onto your Ubuntu server with SSH

1. Once the server is setup you will be presented with a settings page. Copy the "Public IP" address.
2. In a terminal window log into the remote server using SSH replacing the IP address in the examples below with your "Public IP" address.

   
   $ ssh root@212.47.246.30
   

   If, for any reason you changed the SSH key name from id_rsa remember to provide the path to it.

   
   $ ssh root@212.47.246.30 -i /Users/username/.ssh/scaleway_rsa.pub
   

Installing the Node.js

We first need to get the Node.js servers working. The Ubuntu OS does not have all the software we need so we start by installing Git, Node.js and PM2.

1. Install Git onto the server - helpful for cloning Github repo's

   
   $ apt-get install git
   

2. Install Node.js - you can find different version options at github.com/nodesource/distributions

   
   curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
   sudo apt-get install -y nodejs
   

3. Install PM2 - this will run the Node.js apps for us

   
   $ npm install pm2 -g
   

Creating the test Node.js servers

We need to create two small test servers to check the Nginx configuration is correct.

1. Move into the top most directory in the server and create an apps directory with two child directories.

   
   $ cd /
   $ md apps
   $ cd /apps
   $ md app1
   $ md app2
   

2. Within each of the child directories create an app.js file and add the following code. IMPORTANT NOTE: in the app2 directory the port should be set to 3001

   
   const http = require("http");
   const port = 3000; //3000 for app1 and 3001 for app2
   const hostname = '0.0.0.0'
   
   http.createServer(function(reqst, resp) {
       resp.writeHead(200, {'Content-Type': 'text/plain'});
       resp.end('Hello World! ' + port);
   }).listen(port,hostname);
   console.log('Load on: ' + hostname + ':' + port);
   

NOTE You can use command line tools like VIM to create and edit files on your remote server, but I like to use Transmit which supports SFTP and can be used to view and edit files on your remote server. I use Transmit "Open with" feature to edit remote files in VS Code on my local machine.

Running the Node.js servers

Rather than running Node directly we will use PM2. It has two major advantages to running Node.js directly, first is PM2 daemon that keeps your app alive forever, reloading it when required. The second is that PM2 will manage Node's cluster features, running a Node instance on multiple cores, bringing them together to act as one service.

Within each of the app directories run

$ pm2 start app.js

The PM2 cheatsheet is useful to find other commands.

Once you have started both apps you can check they are running correctly by using the following command:

$ pm2 list

The result should look like this:

At this point your Node.js servers should be visible to the world. Try http://x.x.x.x:3000 and http://x.x.x.x:3001 in your web browser, replacing x.x.x.x with your servers public IP address.

Installing and configuring Nginx

At this stage we need to register our web domains to using the public IP address provided for the Scaleway server. For this blog post I am going to use the examples alpha.glennjones.net and beta.glennjones.net

Install Nginx

$ apt-get install nginx

Once installed find the file ./etc/nginx/sites-available/default on the remote server and change its contents to match the code below. Swap out the server_name to match the domain names you wish to use.

server {
    server_name alpha.glennjones.net;

    location / {
        # Proxy_pass configuration
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_max_temp_file_size 0;
        proxy_pass http://0.0.0.0:3000;
        proxy_redirect off;
        proxy_read_timeout 240s;
    }
}

server {
    server_name beta.glennjones.net;

    location / {
        # Proxy_pass configuration
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_max_temp_file_size 0;
        proxy_pass http://0.0.0.0:3001;
        proxy_redirect off;
        proxy_read_timeout 240s;
    }
}

Test that Nginx config has no errors by running:

$ nginx -t

Then start the Nginx proxy with:

$ systemctl start nginx
$ systemctl enable nginx

Nginx should now proxy your domains so in my case both http://alpha.glennjones.net and http://beta.glennjones.net would display the Hello world page of apps 1 and 2.

Install letsencrypt and enforcing SSL

We are going to install letsencrypt and enforcing SSL using Nginx rather than Node.js.

1. We start by installing letsencrypt:

   
   $ apt-get install letsencrypt
   

2. We need to stop Nginx while we configure letsencrypt:

   
   $ systemctl stop nginx
   

3. Then we create the SSL certificates. You will need to do this for each server, so twice for our example:

   
   $ letsencrypt certonly --standalone
   

   Once the SSL certificates are created. You should be able to find them in ./etc/letsencrypt/live/

4. We then need to update the file ./etc/nginx/sites-available/default to point at our new certificates

   
   server {
       listen 80;
       listen [::]:80 default_server ipv6only=on;
       return 301 https://$host$request_uri;
   }
   
   server {
       listen 443;
       server_name alpha.glennjones.net;
   
       ssl on;
       # Use certificate and key provided by Let's Encrypt:
       ssl_certificate /etc/letsencrypt/live/alpha.glennjones.net/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/alpha.glennjones.net/privkey.pem;
       ssl_session_timeout 5m;
       ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
       ssl_prefer_server_ciphers on;
       ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
   
       location / {
           # Proxy_pass configuration
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header Host $http_host;
           proxy_set_header X-NginX-Proxy true;
           proxy_http_version 1.1;
           proxy_set_header Upgrade $http_upgrade;
           proxy_set_header Connection "upgrade";
           proxy_max_temp_file_size 0;
           proxy_pass http://0.0.0.0:3000;
           proxy_redirect off;
           proxy_read_timeout 240s;
       }
   }
   
   server {
       listen 443;
       server_name beta.glennjones.net;
   
       ssl on;
       # Use certificate and key provided by Let's Encrypt:
       ssl_certificate /etc/letsencrypt/live/beta.glennjones.net/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/beta.glennjones.net/privkey.pem;
       ssl_session_timeout 5m;
       ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
       ssl_prefer_server_ciphers on;
       ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
   
       location / {
           # Proxy_pass configuration
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header Host $http_host;
           proxy_set_header X-NginX-Proxy true;
           proxy_http_version 1.1;
           proxy_set_header Upgrade $http_upgrade;
           proxy_set_header Connection "upgrade";
           proxy_max_temp_file_size 0;
           proxy_pass http://0.0.0.0:3001;
           proxy_redirect off;
           proxy_read_timeout 240s;
       }
   }
   

5. Finally let's restart Nginx:

   
   $ systemctl restart nginx
   

   Nginx should now proxy your domains and enforce SSL so https://alpha.glennjones.net and https://beta.glennjones.net would display the Hello world page of apps 1 and 2.

Letsencrypt auto renewal

Let’s Encrypt certificates are valid for 90 days, but it’s recommended that you renew the certificates every 60 days to allow a margin of error.

You can trigger a renewal by using the following command:

$ letsencrypt renew

To create an auto renewal

1. Edit the crontab, the following command will give editing options

   
   $ crontab -e
   

2. Add the following two lines

   
   30 2 * * 1 /usr/bin/letsencrypt renew >> /var/log/le-renew.log
   35 2 * * 1 /bin/systemctl reload nginx
   

Resources

Some useful posts on this subject I used

• How to secure nginx with lets encrypt
• How to deploy nodejs applications
• Configuring nginx as a reverse-proxy

This tutorial will help build a simple hosted Node.js server using scaleway in just a few minutes. We are going to use a pre-built server image from scaleway and a Node project from a Github repo. I have written this post to remind myself, but hopefully it will be useful to others.

Setting up the account

1. Create an account on scaleway.com – you will need a credit card.
2. Create and enable SSH Keys on your local computer, scaleway have provided a good tutorial https://www.scaleway.com/docs/configure-new-ssh-key/. It's easier than it first sounds.

Setting up the server

Scaleway provides a number of server images ready for you to use. The Node.js images is a little bit dated so we will use the latest Ubuntu image and add Node.js later.

1. Within the scaleway dashboard navigate to the "Servers" tab and click "Create Server".
   1. Give the server a name.
   2. In the "Choose an image" section select the "Distributions" tab, page through the options until you can select the latest Ubuntu, currently "Ubuntu Vivid (15.04 latest)".
   3. Finally click the "Create Server" button.

It takes a couple of minutes to build a barebones Ubuntu server for you.

Logging onto your server with SSH

1. Once the server is setup you will be presented with a setting page. Copy the "Public IP" address.
2. In a terminal window log into the remote server using SSH replacing the IP address in the examples below with your "Public IP" address.

   
   $ ssh root@212.47.246.30
   

   If, for any reason you changed the SSH key name from id_rsa remember to provide the path to it.

   
   $ ssh root@212.47.246.30 -i /Users/username/.ssh/scaleway_rsa.pub
   

Adding Git, Node and your GitHub project onto the server

1. Move into the top most directory in the server

   
   $ cd /
   

2. Install Git onto the server

   
   $ apt-get install git
   

3. Install Node.js - you can find different version options at github.com/nodesource/distributions

   
   curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -
   sudo apt-get install -y nodejs
   
   apt-get install nodejs
   

4. Install PM2 - this will run our Node app for us

   
   $ npm install pm2 -g
   

5. Clone your Node repo from GitHub. The space and word "app" at the end of the command tells git to place the project contents into a new directory called "app"

   
   $ git clone https://github.com/glennjones/hapi-bootstrap.git app
   

6. Move into the new app directory

   
   $ cd app
   

7. Install Node packages

   
   $ npm install
   

8. Setup the basic environmental properties. Note your app needs to use process.env.HOST and process.env.PORT to set its network connection

   
   $ export PORT=80
   $ export HOST=0.0.0.0
   $ export NODE_ENV=production
   

Running Node server

Rather than running Node directly we will use PM2. It has two major advantagaes to running Node directly, first is PM2 deamon that keeps your app alive forever, reloading it when required. The second is that PM2 will manage Node's cluster features, running a Node instance on multiple cores, bringing them together to act as one service.

$ pm2 start app.js -i 0

The -i 0 flag tells PM2 to run in cluster mode and use as many cores as it can find. The PM2 cheatsheet is useful to find other commands.

For feedback on the state of the server

• List - $ pm2 list
• CPU / Memory Monitoring - $ pm2 monit

View your running app in the browser

View your app from the "Public IP" in any browser

 

 

 

Other useful information

Updating app using Git pull

If you wish to update your app just log on to the server using SSH and use git pull

1. SSH into server - $ ssh root@212.47.246.30
2. Move into new app directory - $ cd /app
3. Git pull latest code - $ git pull

Using a private GitHub repo

There are a few ways to pull a private GitHub repo using SSH keys from a remote server. I use the "Personal access token". You can generate these tokens in the settings area of GitHub and use git clone with this URL structure:

$ git clone https://{token}@github.com/glennjones/glennjones-net.git/ app

Saving server setup for later use

You can setup your own images based on your running server for easy deployment by using snapshot and image features of the service. I did this to create a basic Ubuntu 15 and Node 4 image for this project.

Performance

You will often hear Scaleway C1 servers being compared to the Raspberry Pi 2 in terms of spec, which makes you think it maybe slow. Using all 4 cores they seem perfectly fine for my personal projects. I have yet to find a good set of benchmarks against other services, which would be useful. This blog is running on scaleway as of (2015-09-30).

Mongodb Issue

Scaleway C1 servers and Mongodb do not play very well together. There is a version you can get to work, but it's not well supported or considered production level.

• https://community.scaleway.com/t/mongodb-64-bit/465
• https://community.scaleway.com/t/datacenter-and-64bit-plans/917

Solutions maybe to move db operations onto dedibox by the same company or use one of the Mongodb hosting services and live with some network latency.

More complex deployments

You can deploy much more complex setups with multiple Node servers, load balancers etc. I am very interested in trying out the Electric Search. At the moment building all this into images that you can deploy is quite complex for none devops people.

I am still playing with this service but so far its proved interesting and I have moved at least 5 of my small personal sites over.

I was working on a library where I needed to resolve a relative URL using a base URL with JavaScript in the browser. After googling I found the relatively new window.URL API documented on MDN. It allows you to create a URL object that returns a resolved URL, which was great, just what I needed!

var url = new URL('/test.htm', 'http://example.com');
console.log( url.toString() );  
// output is:  http://example.com/test.htm

As with all new API’s I don’t expect all the browsers to support them straight away, but that’s OK I can test for the existence of APIs such as window.URL and use a fallback or polyfill. The code should look something like this.

if(window.URL){
	var url = new URL('/test.htm', 'http://example.com');
	console.log( url.toString() );
else{
	// do something else – fallback or polyfill
}

In this case it does not work because the URL API is actually two overlapping specifications and designed in such a way to allow for one to break the other if they are not implemented together. This is because they both lay claim to the window.URL object. The two specifications are:

• The File API specification defines static members for Blob URLs like URL.createObjectURL and URL.revokeObjectURL.
• The URL API specification defines the creation of new URL objects that parse URL strings.

The problem

The IE team have implemented just the File API specification, which is not wrong in itself, but if you try use the URL object in IE10 as specified in the URL API specification it throws an error and stops the code execution. Testing for window.URL will not help you as it does exist in IE10 and IE11.

I don’t think IE throwing the error is the issue. Its more of a case of how did the wider web community design APIs that end up clashing?

The workaround

You need to write something like this:

// test URL object for parse support
function hasURLParseSupport (){
	try{
		var url = new URL('/test.htm', 'http://example.com');
		return true;
	}catch(e){
		return false;
	}
}

if(hasParseURLSupport()){
	var url = new URL('/test.htm', 'http://example.com');
	console.log( url.toString() );
}else{
	// do something else
}  

Not meeting expectation’s

Having done a bit of UX design in my time I would class this issue of one of not meeting developers expectations. At least to me using a try/catch block is not how I expect to have to deal with the implementation of new APIs. This should have been resolved at the API design stage before they became public in the browsers.

Wasting time

It took me quite a bit of research to work out what the issue was (2-3 hours) and come up with a small workaround I could trust. Mainly because I had to start reading the specifications and running browser tests.

Going forward

• As IE10 will be with us for many years the only practical way to use the URL object will be to use more complex tests like the hasURLParseSupport above.
• This issue should be recognized in the two specifications that lay claim over the URL object.
• The places that provide documentation of the APIs like MDN should discuss the issue and provide code examples of workarounds.
• The W3Ctag should review overlapping specifications in fine detail to provide advice on implementation at this level.

I may have got the above wrong

I would just like to point out I am just a web developer and not part of the specifications community that created URL APIs. It’s possible that I may have missed some element of the specifications that deals with this issue. I do not know about the whole history of the URL object and all the discussions of its design. Please let me know if any of the above is incorrect of or can be added too and I will change the post.

Links

• https://developer.mozilla.org/en/docs/Web/API/URL
• http://www.w3.org/TR/FileAPI/
• https://url.spec.whatwg.org/#api

Over the last couple of years I have been thinking about how we view each other through the web, the content we post and the interactions we have. Like many people, I am not happy with the path Facebook and Twitter are taking us on.

Rather than just get upset at the every increasing monoculture that is slowly distorting the early promise of the web. I want to help build a new type of relationship that we can all have with the web and these sites. These are the ideas that have directed me.

Shoeboxes and mementoes

When I was a child, my brothers and I all had a shoebox each. In these we kept our mementoes. A seashell from a summer holiday where I played for hours in the rock pools, the marble from the schoolyard victory against a bully and a lot of other objects that told a story.

We all collect mementoes of some sort, they are the stories that we use to define ourselves. These stories are not static things built in stone, but a living part of us. We often reshape them through time as our view of life changes or our memories colour them. They are also used in different combinations to weave the way we present ourselves to the different groups of people in our lives.

The webs idea of memory is not humanistic

Today large amounts of humanities online content is published on social networks. These sites seem to consider every bit of content/interaction to have the same level of importance. In a recent talk Maciej Ceglowski said:

The Internet somehow contrives to remember and too much and too little at the same time, and it maps poorly on our concepts of how memory should work

Maciej Ceglowski, beyond tellerrand 2014

The incumbent social networks seem unable to forget a single piece of content we give them, as it is required to power their business model of profiling us for advertising. At the same time we don’t have enough control within these spaces to curate our stories. To be able to group together those things that are important to us and subdue those that are not. I would like to build publishing environments that map to the way we keep mementoes and tell stories.

My presence on the web needs a new foundation

For me to rebuild a presence on the web I need to take back control of how I create, collect, distribute, store and publish my content. Only then can I curate a more personalized representation of myself.

Transmat

I have been working with a small group to build transmat.io, it:

1. Collects digital content for publishing, it’s not just a file store.
2. Has a content creation and collection interface that is designed for mobile first and for social content such as status updates and check-ins.
3. Simple distribution tools that link pre-existing services, allowing you to control your own content while still being part of the conversation on social networks.
4. Imports pre-existing archives from Twitter, etc.
5. Provides a simple API allowing the reuse of content i.e. in blogs.
6. Provides auto backup in HTML for longevity.

Transmat is just a foundation on which I am going rebuild my blog. It’s not a story telling tool in itself, it’s more like my online memory from which I can pull and weave content from.

I also hope Transmat and all its tools will help others collect and reuse their digital content so they can weave their own stories. If you’re interested why not sign up for an invite. https://transmat.io