NodeJS

Deploying Node.js to Linux Servers: Traditional Linux deployment for Node.js services

Posted on by HKT

In this section, we will explore the traditional Linux/Unix service deployment. We’ll do this with a virtual Ubuntu instance running on our laptop. The goal is to create background processes that automatically start during boot-up, restart if the process crashes, and allow us to monitor log files and system state.

Traditional Linux/Unix server application deployment uses an init script to manage background processes. They are to start every time the system boots, and cleanly shut down when the system is halted. The name “init script” comes from the name of the first process launched in the system, whose traditional name is /etc/init. The init scripts are usually stored in /etc/init.d, and are typically simple shell

scripts. Some operating systems use other process managers, such as upstart, systemd, or launchd, while following the same model. While it’s a simple model, the specifics of this vary widely from one operating system (OS) to another.

The Node.js project itself does not include any scripts to manage server processes on any OS. Implementing a complete web service based on Node.js means that we must create the scripting to integrate with process management on your OS.

Having a web service on the internet requires having background processes running on a server, and those processes have to be the following:

  • Reliable: For example, they should auto-restart when the server process crashes.
  • Manageable: They should integrate well with system management practices.
  • Observable: The administrator must be able to get status and activity information from the service.

To demonstrate what’s involved, we’ll use PM2 to implement background server process management for Notes. PM2 bills itself as a process manager, meaning it tracks the state of processes it is managing and makes sure the processes execute reliably and are observable. PM2 detects the system type and can automatically integrate itself with the native process management system. It will create an LSB-style init script (http://wiki.debian.org/LSBInitScripts), or other scripts as required for your server.

Our goal in this chapter is exploring how to do this, and there are several routes to achieving this goal:

Traditional VM management applications including VirtualBox, Parallels, and VMware let us install Ubuntu or any other OS within a virtual environment. On Windows, Hyper-V comes with Windows 10 Pro and offers a similar capability. In these cases, you download an ISO image of the boot CD-ROM, boot the VM from that ISO image, and run the full OS installation as if it was a regular computer.

You can rent inexpensive VPSes from one of hundreds of web hosting providers around the world. Often the choice is limited to Ubuntu servers. In these cases, you’re handed a pre-baked server system ready to go for installing server software to run websites.

A new product, Multipass, is a lightweight VM management tool, based on lightweight hypervisor technology, and is available for every desktop computer OS. It gives you the exact same starting point as you’d get by renting a VPS or using VM software like VirtualBox, with a much lower system impact than traditional VM applications such as VirtualBox. It is like getting a VPS from a hosting provider, but it’s on your laptop.

There is no practical difference between these choices from the standpoint of the tools and commands required to launch background processes. The Ubuntu instance installed in VirtualBox is the same as the Ubuntu on the VPS rented from a web- hosting provider, and is the same as the Ubuntu launched in a Multipass instance. It’s the same OS, the same command-line tools, and the same system management practices. The difference is in the performance impact on your laptop. With Multipass, we can set up a virtual Ubuntu instance in a few seconds, and it is easy to have multiple instances running on a laptop with little or no performance impact. The experience of using VirtualBox, Hyper-V, or other VM solutions is that using the laptop feels quickly like walking through molasses, especially when running multiple VMs at once.

Therefore, in this chapter, we will run this exercise on Multipass. Everything shown in this chapter is easily transferrable to Ubuntu on VirtualBox/VMware/and so on or to a VPS rented from a web hosting provider.

For this deployment, we will create two Ubuntu instances with Multipass: one instance for the Notes service and the other for the user service. In each instance, there will be a MySQL instance for the corresponding database. Then we’ll use PM2 to configure these systems to start our services in the background when launched.

Because of apparent incompatibilities between Multipass and WSL2, there might be difficulties using Multipass on Windows. If you run into problems, we have a section describing what to do.

The first task is to duplicate the source code from the previous chapter. It’s suggested you create a new directory, chap10, as a sibling of the chap09 directory, and copy everything from chap09 to chap10.

To get started, let’s install Multipass, and after that we’ll start by deploying and testing the user authentication service, followed by deploying and testing Notes. We’ll also cover setup issues on Windows.

1. Installing Multipass

Multipass is an open source tool developed by Canonical. It is an extremely lightweight tool for managing VMs, specifically Ubuntu-based VMs. It is light enough to enable running a mini-sized cloud hosting system on your laptop.

With Multipass installed, you can run some of the following commands to try it out:

$ multipass launch Launched: pleased-mustang

$ multipass list

Name            State   IPv4         Image

pleased-mustang Running 192.168.64.5 Ubuntu 18.04 LTS

$ multipass exec pleased-mustang — lsb_release -a No LSB modules are available.

Distributor ID: Ubuntu Description: Ubuntu 18.04.3 LTS Release: 18.04

Codename: bionic

$ multipass shell pleased-mustang

Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-76-generic x86_64) 

… 

ubuntu@pleased-mustang:~$ 

Because we did not supply a name for the machine, Multipass created a random name. It isn’t shown in the preceding snippet, but the first command included the download and setup of a VM image. The shell command starts a login shell inside the newly created VM, where you can use tools like ps or htop to see that there is indeed a full complement of processes running already.

Since one of the first things you do with a new Ubuntu install is to update the system, let’s do so the Multipass way:

$ multipass exec pleased-mustang — sudo apt-get update

… much output

$ multipass exec pleased-mustang — sudo apt-get upgrade

… much output 

This works as expected, in that you see apt-get first update its list of available packages, and then ask you to approve downloading and installing the packages to update, after which it does so. Anyone who is familiar with Ubuntu will find this normal. The difference is doing this from the command-line environment of the host computer.

That was fun, but we have some work to do, and we’re not pleased with this mustang-based machine name Multipass saddled us with. Let’s learn how to delete Multipass instances:

$ multipass list

Name            State   IPv4         Image

pleased-mustang Running 192.168.64.5 Ubuntu 18.04 LTS

$ multipass delete pleased-mustang

$ multipass list

Name            State   IPv4 Image pleased-mustang Deleted — Not Available

$ multipass purge

$ multipass list

Name State IPv4 Image 

We can easily delete a VM image with the delete command; it is then marked as Deleted. To truly remove the VM, we must use the purge command.

We’ve learned how to create, manage, and delete VMs using Multipass. This was a lot faster than some of the alternative technologies. With VirtualBox, for example, we would have had to find and download an ISO, then boot a VirtualBox VM instance and run the Ubuntu installer, taking a lot more time.

There might be difficulties using Multipass on Windows, so let’s talk about that and how to rectify it.

1.1. Handling a failure to launch Multipass instances on Windows

The Multipass team makes their application available to on run Windows systems, but issues like the following can crop up:

PS C:\Users\david> multipass launch

launch failed: The following errors occurred:

unassuming-tailorbird: timed out waiting for response 

It goes through all the steps of setting up an instance, but in the last step, we get this message instead of success. Running multipass list might show the instance in a Running state, but no IP address has been assigned, and running multipass shell also results in a timeout.

This timeout is observed if WSL2 is installed on the computer along with Multipass. WSL2 is a lightweight Linux subsystem for Windows, that is billed as an excellent environment for running Linux commands on Windows. Running WSL2 and Multipass at the same time may result in unwanted behavior.

For the purposes of this chapter, WSL2 is not useful. This is because WSL2 does not, at this time, support installing a background service that persists after a reboot, because it does not support systemd. Remember that our goal is to learn about setting up persistent background services.

It may be necessary to disable WSL2. To do so, use the Search box in the Windows taskbar to look for the Turn Windows Features On or Off control panel. Because WSL2 is a feature rather than an application that is installed or uninstalled, it is turned off or on using this control panel. Simply scroll down to find the feature, untick the checkbox, and then reboot the computer.

Both WSL2 and Multipass use Hyper-V. This is a virtualization engine for Windows, and it also supports installing VMs in a mode similar to VirtualBox or VMware. It is easy to download an ISO for Ubuntu or any other OS and install it on Hyper-V. This results in a full OS in which to experiment with background process deployment. You may prefer to run these examples inside Hyper-V instead.

Once the virtual machine is installed most of the instructions in the rest of this chapter will work. Specifically, the install-packages.sh script will be useful for installing the Ubuntu packages required to complete the instructions, and the two configure-svc scripts are useful for “deploying” the services into /opt/notes and /opt/userauth. It is recommended to use Git inside the virtual machine to clone the repository associated with this book. Finally, the scripts in the pm2-single directory are useful for running the Notes and Users services under PM2.

Our purpose is to learn how to deploy Node.js services on a Linux system, without having to leave our laptop. For that purpose, we’ve familiarized ourselves with Multipass since it is an excellent tool for managing Ubuntu instances. We’ve also learned about alternatives such as Hyper-V or VirtualBox that also can be used for managing Linux instances.

Let’s start exploring deployment with the user authentication service.

2. Provisioning a server for the user authentication service

Since we want to have a segmented infrastructure, with the user authentication service in a walled-off area, let’s make the first attempt at building that architecture. Using Multipass we will create two server instances, svc-userauth and svc-notes. Each will contain its own MySQL instance and the corresponding Node.js-based service. In this section, we’ll set up svc-userauth, then in another section, we’ll replicate the process to set up svc-notes.

Feeling kindly to our DevOps team, who’ve requested automation for all administrative tasks, we’ll create some shell scripts to manage the server setup and configuration.

The scripts shown here handle deployment to two servers, with one server holding the authentication service and the other holding the Notes application. In the GitHub repository accompanying this book, you’ll find other scripts to handle deployment to a single server. The single server scenario might be required if you’re using a heavier- weight virtualization tool such as VirtualBox rather than Multipass.

In this section, we will create the user authentication backend server, svc-userauth, and in a later section, we will create the server for the Notes frontend, svc-notes.

Since the two server instances will be set up similarly, we might question why we’re setting up two servers. It’s because of the security model we decided on.

There are several steps involved, including a few scripts for automating Multipass operations, as follows:

  1. Create a directory named chap10/multipass for scripts related to managing Multipass instances.
  2. Then, in that directory, create a file named create-svc-userauth.sh, containing the following:

multipass launch –name svc-userauth

multipass mount ../users svc-userauth:/build-users multipass mount `pwd` svc-userauth:/build

On Windows, instead create a file named create-svc- userauth.ps1 containing the following:

multipass launch –name svc-userauth

multipass mount ../users svc-userauth:/build-users

multipass mount (get-location) svc-userauth:/build

The two are nearly the same, except for the method to compute the current directory.

The mount command in Multipass attaches a host directory into the instance at the given location. Therefore, we attach the multipass directory

as /build and users as /build-users.

The `pwd` notation is a feature of the Unix/Linux shell environment. It means to run the pwd process and capture its output, supplying it as a command-line argument to the multipass command. For Windows, we use (get-location) for the same purpose in PowerShell.

  1. Create the instance by running the script:

$ sh ./create-svc-userauth.sh 

Or, on Windows, run this:

PS C:\Path> .\create-svc-userauth.ps1 

Either one runs the commands in the scripts that will launch the instance and mount directories from the host filesystem.

  1. Create a file named install-packages.sh containing the following:

curl -sL https://deb.nodesource.com/setup_14.x | sudo -E bash

–

sudo apt-get update

sudo apt-get upgrade -y

sudo apt-get install -y nodejs build-essential mysql-server

mysql-client 

This installs Node.js 14.x and sets up other packages required to run the authentication service. This includes a MySQL server instance and the MySQL client.

A side effect of installing the mysql-server package is that it launches a running MySQL service with a default configuration. Customizing that configuration is up to you, but for our purposes here and now, the default configuration will work.

  1. Execute this script inside the instance like so:

$ multipass exec svc-userauth — sh -x /build/install- packages.sh 

The exec command, as we discussed earlier, causes a command to execute inside the container by running this command on the host system.

  1. In the users directory, edit user-server.mjs and change the following:

server.listen(process.env.PORT, process.env.REST_LISTEN ? process.env.REST_LISTEN :

‘localhost’, function() {

log(‘${server.name} listening at ${server.url}’);

});

Previously, we had specified a hardcoded ‘localhost’ here. The effect of this was that the user authentication service only accepted connections from the same computer. To implement our vision of Notes and the user authentication services running on different computers, this service must support connections from elsewhere.

This change introduces a new environment variable, REST_LISTEN, where we will declare where the server should listen for connections.

As you edit the source files, notice that the changes are immediately reflected inside the Multipass machine in the /build-users directory.

  1. Create a file called users/sequelize-mysql.yaml containing the following:

dbname: userauth

username: userauth

password: userauth

params:

host: localhost

port: 3306

dialect: mysql

This is our configuration for allowing the user service to connect with a local MySQL instance. The dbname, username, and password parameters must match the values in the configuration script shown earlier.

  1. Then, in the users/package.json file, add these entries to the scripts section:

“scripts”: {

“start”: “cross-env DEBUG=users:* PORT=5858

SEQUELIZE_CONNECT=sequelize-sqlite.yaml node ./user- server.mjs”,

The on-server script contains the runtime configuration we’ll use on the server.

  1. Next, in the users directory, run this command:

$ npm install mysql2 –save

 Since we’re now using MySQL, we must have the driver package installed.

  1. Now create a file named configure-svc-userauth.sh containing the following:

### Create the database for the UserAuthentication service

sudo mysql –user=root <<EOF

CREATE DATABASE userauth;

CREATE USER ‘userauth’@’localhost’ IDENTIFIED BY ‘userauth’;

GRANT ALL PRIVILEGES ON userauth.* TO ‘userauth’@’localhost’ WITH GRANT OPTION;

EOF

Set up the UserAuthentication service code

sudo mkdir -p /opt/userauth

sudo chmod 777 /opt/userauth

(cd /build-users; tar cf – .) | (cd /opt/userauth; tar xf -)

(

cd /opt/userauth

rm -rf node_modules package-lock.json users

-sequelize.sqlite3

npm install

)

This script is meant to execute inside the Ubuntu system managed by Multipass. The first section sets a user identity in the database. The second section copies the user authentication service code, from /build-

users to /userauth, into the instance, followed by installing the required packages.

Since the MySQL server is already running, the mysql command will access the running server to create the database, and create the userauth user. We will use this user ID to connect with the database from the user authentication service.

But, why are some files removed before copying them into the instance? The primary goal is to delete the node_modules directory; the other files are simply unneeded. The node_modules directory contains modules that were installed on your laptop, and surely your laptop has a different OS than the Ubuntu instance running on the server? Therefore, rerunning npm install on the Ubuntu server ensures the packages are installed correctly.

  1. Run the configure-svc-userauth script like so:

$ multipass exec svc-userauth — sh -x /build/configure-svc- userauth.sh

 Remember that the multipass directory in the source tree is mounted inside the instance as /build. As soon as we created this file, it showed up in the /build directory, and we can execute it inside the instance.

Several times in this book, we’ve talked about the value of explicitly declaring all dependencies and of automating everything. This demonstrates this value, because now, we can just run a couple of shell scripts and the server is configured. And we don’t have to remember how to launch the server because of the scripts section in package.json.

  1. We can now start the user authentication server, like so:

$ multipass shell svc-userauth

Welcome to Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-96-generic x86_64)

…

ubuntu@svc-userauth:~$ cd /opt/userauth/

ubuntu@svc-userauth:/opt/userauth$ npm run on-server

> user-auth-server@1.0.0 on-server /opt/userauth

> DEBUG=users:* REST_LISTEN=0.0.0.0 PORT=5858

SEQUELIZE_CONNECT=sequelize-mysql.yaml node ./user-server.mjs

users:service User-Auth-Service listening at http://0.0.0.0:5858

Notice that our notation is to use $ to represent a command typed on the host computer, and ubuntu@svc-userauth:~$ to represent a command typed inside the instance. This is meant to help you understand where the commands are to be executed.

In this case, we’ve logged into the instance, changed directory to /opt/userauth, and started the server using the corresponding npm script.

2.1. Testing the deployed user authentication service

Our next step at this point is to test the service. We created a script, cli.mjs, for that purpose. In the past, we ran this script on the same computer where the authentication service was running. But this time, we want to ensure the ability to access the service remotely.

Notice that the URL printed is http://[::]:5858. This is shorthand for listening to connections from any IP address.

On our laptop, we can see the following:

$ multipass list

Name         State   IPv4         Image

svc-userauth Running 192.168.64.8 Ubuntu 18.04 LTS 

Multipass assigned an IP address to the instance. Your IP address will likely be different.

On our laptop is a copy of the source code, including a copy of cli.mjs. This means we can run cli.mjs on our laptop, telling it to access the service on svc-userauth.

That’s because we thought ahead and added –host and –port options to cli.mjs. In theory, using those options, we can access this server anywhere on the internet. At the moment, we simply need to reach into the virtual environment on our laptop.

On your laptop, in the regular command environment rather than inside Multipass, run these commands:

$ node cli.mjs –host 192.168.64.8 –port 5858 add –password w0rd — family-name Einarsdottir –given-name Ashildr –email me@stolen.tardis

me Created {

id: ‘me’,

username: ‘me’,

provider: ‘local’,

familyName: ‘Einarsdottir’,

givenName: ‘Ashildr’,

middleName: null,

emails: [ ‘me@stolen.tardis’ ],

photos: []

}

$ node cli.mjs –host 192.168.64.8 –port 5858 add –password foooo — family-name Smith –given-name John –middle-name Snuffy –email snuffy@example.com snuffy-smith

Created {

id: ‘snuffy-smith’,

username: ‘snuffy-smith’,

provider: ‘local’,

familyName: ‘Smith’,

givenName: ‘John’,

middleName: ‘Snuffy’,

emails: [ ‘snuffy@example.com’ ],

photos: []

}

 

Make sure to specify the correct host IP address and port number.

If you remember, the script retrieves the newly created user entry and prints it out. But we need to verify this and can do so using the list-users command. But let’s do something a little different, and learn how to access the database server.

In another command window on your laptop, type these commands:

$ multipass shell svc-userauth

Welcome to Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-76-generic x86_64)

…

ubuntu@userauth:~$ mysql -u userauth -p Enter password:

Welcome to the MySQL monitor. Commands end with ;

or \g.

…

mysql> USE userauth;

mysql> SHOW tables;

 

This shows database entries for the users we created. Notice that while logged in to the Multipass instance, we can use any Ubuntu command because we have the full OS in front of us.

We have not only launched the user authentication service on an Ubuntu server, but we’ve verified that we can access that service from outside the server.

In this section, we set up the first of the two servers we want to run. We still have to create the svc-notes server.

But before we do that, we first need to discuss running scripts on Windows.

Script execution in PowerShell on Windows

In this chapter, we’ll write several shell scripts. Some of these scripts need to run on your laptop, rather than on a Ubuntu-hosted server. Some developers use Windows, and therefore we need to discuss running scripts on PowerShell.

Executing scripts on Windows is different because it uses PowerShell rather than Bash, along with a large number of other considerations. For this and the scripts that follow, make the following changes.

PowerShell script filenames must end with the .ps1 extension. For most of these scripts, all that is required is to duplicate the .sh scripts as .ps1 files, because the scripts are so simple. To execute the script, simply type .\scriptname.ps1 in the PowerShell window. In other words, on Windows, the script just shown must be named configure-svc-userauth.ps1, and is executed as .\configure-svc- userauth.ps1.

To execute the scripts, you may need to change the PowerShell execution policy:

PS C:\Users\david\chap10\authnet> Get-ExecutionPolicy Restricted

PS C:\Users\david\chap10\authnet> Set-ExecutionPolicy Unrestricted 

Obviously, there are security considerations with this change, so change the execution policy back when you’re done.

A simpler method on Windows is to simply paste these commands into a PowerShell window.

It was useful to discuss script execution on PowerShell. Let’s return to the task at hand, which is provisioning the Notes stack on Ubuntu. Since we have a functioning user authentication service, the remaining task is the Notes service.

3. Provisioning a server for the Notes service

So far, we have set up the user authentication service on Multipass. Of course, to have the full Notes application stack running, the Notes service must also be running. So let’s take care of that now.

The first server, svc-userauth, is running the user authentication service. Of course, the second server will be called svc-notes, and will run the Notes service. What we’ll do is very similar to how we set up svc-userauth.

There are several tasks in the multipass directory to prepare this second server. As we did with the svc-userauth server, here, we set up the svc-notes server by installing and configuring required Ubuntu packages, then set up the Notes application:

  1. Create a script named multipass/create-svc-notes.sh containing the following:

multipass launch –name svc-notes

multipass mount ../notes svc-notes:/build-notes

multipass mount ‘pwd’ svc-notes:/build

This is tasked with launching the Multipass instance, and is very similar to create-svc-userauth but changed to use the word notes.

For Windows, instead create a file called multipass/create-svc- notes.ps1 containing the following:

multipass launch –name svc-notes

multipass mount ../notes svc-notes:/build-notes

multipass mount (get-location) svc-notes:/build

This is the same as before, but using (get-location) this time.

  1. Create the instance by running the script as follows:

$ sh ./create-svc-notes.sh 

Or, on Windows, run the following command:

PS C:\Path> .\create-svc-notes.ps1 

Either one runs the commands in the scripts that will launch the instance and mount directories from the host filesystem.

  1. Install the required packages like so:

$ multipass exec svc-notes — sh -x /build/install-packages.sh 

This script installs Node.js, the MySQL server, and a few other required packages.

  1. Now create a file, notes/models/sequelize-mysql.yaml, containing the following:

dbname: notes

username: notes

password: notes

params:

host: localhost

port: 3306

dialect: mysql

This is the database name, username, and password credentials for the database configured previously.

  1. Because we are now using MySQL, run this command:

$ npm install mysql2 –save 

We need the MySQL driver package to use MySQL.

  1. Then, in the notes/package.json file, add this entry to the scripts section:

“on-server”: “cross-env DEBUG=notes:*

SEQUELIZE_CONNECT=models/sequelize-mysql.yaml

NOTES_MODEL=sequelize TWITTER_CALLBACK_HOST=

http://172.23.89.142:3000 USER_SERVICE_URL=

http://172.23.83.119:5858 PORT=3000 node./app.mjs”

This uses the new database configuration for the MySQL server and the IP address for the user authentication service. Make sure that the IP address matches what Multipass assigned to svc-userauth.

You’ll, of course, get the IP address in the following way:

$ multipass list

Name         State   IPv4          Image

svc-notes    Running 172.23.89.142 Ubuntu 18.04 LTS

svc-userauth Running 172.23.83.119 Ubuntu 18.04 LTS 

The on-server script will have to be updated appropriately.

  1. Duplicate multipass/configure-svc-userauth.sh to create a script named multipass/configure-svc-notes.sh, and change the final two sections to the following:

### Create the database for the UserAuthentication service

sudo mysql –user=root <<EOF

CREATE DATABASE notes;

CREATE USER ‘notes’@’localhost’ IDENTIFIED BY ‘notes’;

GRANT ALL PRIVILEGES ON notes.* TO ‘notes’@’localhost’ WITH

GRANT OPTION;

EOF

Set up the UserAuthentication service code

sudo mkdir -p /opt/notes

sudo chmod 777 /opt/notes

(cd /build-notes; tar cf – .) | (cd /opt/notes; tar xf -) (

cd /opt/notes

rm -rf node_modules package-lock.json *.sqlite3

npm install

)

This is also similar to what we did for svc-userauth. This also changes things to use the word notes where we used userauth before.

Something not explicitly covered here is ensuring the .env file you created to hold Twitter secrets is deployed to this server. We suggested ensuring this file is not committed to a source repository. That means you’ll be handling it semi-manually perhaps, or you’ll have to use some developer ingenuity to create a process for managing this file securely.

  1. Run the configure-svc-notes script like so:

$ multipass exec svc-notes– sh -x /build/configure-svc- notes.sh

Remember that the multipass directory in the source tree is mounted inside the instance as /build. As soon as we created this file, it showed up in the /build directory, and we can execute it inside the instance.

  1. We can now run the Notes service with the following command:

$ multipass shell svc-notes

Welcome to Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-96-generic x86_64) 

    • Documentation: https://help.ubuntu.com
    • Management: https://landscape.canonical.com
    • Support: https://ubuntu.com/advantage 

…

ubuntu@svc-notes:~$ cd /opt/notes/

approotdir.mjs minty node_modules package.json public theme

ubuntu@svc-notes:/opt/notes$ npm run on-server 

> notes@0.0.0 on-server /opt/notes

> cross-env DEBUG=notes:* SEQUELIZE_CONNECT=models/sequelize- yaml NOTES_MODEL=sequelize TWITTER_CALLBACK_HOST=http://172.23.89.142:3000 USER_SERVICE_URL=http://172.23.83.119:5858 PORT=3000 node./app.mjs

notes:debug Listening on port 3000 +0ms

notes:notes-store [Module] { SQNote: SQNote, default:

[Function: SequelizeNotesStore] } +0ms

notes:notes-store [Function: SequelizeNotesStore] +14ms

notes:debug Using NotesStore [object Object] +0ms

As with svc-userauth, we shell into the server, change the directory to /opt/notes, and run the on-server script. If you want Notes to be

visible on port 80, simply change the PORT environment variable. After that, the URL in the TWITTER_CALLBACK_HOST variable must contain the port number on which Notes is listening. For that to work, the on-server script needs to run as root, so therefore we will run the following:

ubuntu@svc-notes:/opt/notes$ sudo npm run on-server 

The change is to use sudo to execute the command as root.

To test this we must of course use a browser to connect with the Notes service. For that, we need to use the IP address for svc-notes, which we learned from Multipass earlier. Using that example, the URL is http://172.23.89.142:3000.

You’ll find that since we haven’t changed anything in the look-and-feel category, that our Notes application looks like it has all along. Functionally, you will be unable to log in using Twitter credentials, but you can log in using one of the local accounts we created during testing.

Once both services are running, you can use your browser to interact with the Notes

application and run it through its paces.

What we’ve done is build the second of two servers, svc-userauth and svc-notes, on which we’ll run the Notes application stack. That gives us two Ubuntu instances each of which are configured with a database and a Node.js service. We were able to manually run the authentication and Notes services together, connecting from one Ubuntu instance to the other, each working with their corresponding database. To have this as a fully deployed server, we will use PM2 in a later section.

We have learned a little about configuring Ubuntu servers, though there is an outstanding issue of running the services as background processes. Before we get to that, let’s rectify the situation with the Twitter login functionality. The issue with Twitter login is that the application is now on a different IP address, so to resolve this, we now have to add that IP address in Twitter’s management backend.

Source: Herron David (2020), Node.js Web Development: Server-side web development made easy with Node 14 using practical examples, Packt Publishing.

Leave a Reply

Your email address will not be published. Required fields are marked *