When you run a program from the console, the program will automatically terminate when you close the console or if the computer restarts. In order to keep programs running after a shutdown you need to register it as a daemon. The term daemon comes from the idea of something that is always there working in the background. Hopefully you only have good daemons running in your background.
We want our web services to continue running as a daemon. We would also like an easy way to start and stop our services. That is what Process Manager 2 (PM2) does.
PM2 is already installed on your production server as part of the AWS AMI that you selected when you launched your server. Additionally, the deployment scripts found with the Simon projects automatically modify PM2 to register and restart your web services. That means you should not need to do anything with PM2. However, if you run into problems such as your services not running, then here are some commands that you might find useful.
You can SSH into your server and see PM2 in action by running the following command.
pm2 lsThis should print out the two services, simon and startup, that are configured to run on your web server.
You can try some of the other commands, but only if you understand what they are doing. Using them incorrectly could cause your web services to stop working.
| Command | Purpose |
|---|---|
| pm2 ls | List all of the hosted node processes |
| pm2 monit | Visual monitor |
| pm2 start index.js -n simon | Add a new process with an explicit name |
| pm2 start index.js -n startup -- 4000 | Add a new process with an explicit name and port parameter |
| pm2 stop simon | Stop a process |
| pm2 restart simon | Restart a process |
| pm2 delete simon | Delete a process from being hosted |
| pm2 delete all | Delete all processes |
| pm2 save | Save the current processes across reboot |
| pm2 restart all | Reload all of the processes |
| pm2 restart simon --update-env | Reload process and update the node version to the current environment definition |
| pm2 update | Reload pm2 |
| pm2 start env.js --watch --ignore-watch="node_modules" | Automatically reload service when index.js changes |
| pm2 describe simon | Describe detailed process information |
| pm2 startup | Displays the command to run to keep PM2 running after a reboot. |
| pm2 logs simon | Display process logs |
| pm2 env 0 | Display environment variables for process. Use pm2 ls to get the process ID |
If you want to setup another subdomain that accesses a different web service on your web server, you need to follow these steps.
- Add the rule to the Caddyfile to tell it how to direct requests for the domain.
- Create a directory and add the files for the web service.
- Configure PM2 to host the web service.
SSH into your server.
Copy the section for the startup subdomain and alter it so that it represents the desired subdomain and give it a different port number that is not currently used on your server. For example:
tacos.cs260.click {
reverse_proxy _ localhost:5000
header Cache-Control none
header -server
header Access-Control-Allow-Origin *
}This tells Caddy that when it gets a request for tacos.cs260.click it will act as a proxy for those requests and pass them on to the web service that is listening on the same machine (localhost), on port 5000. The other settings tell Caddy to return headers that disable caching, hide the fact that Caddy is the server (no reason to tell hackers anything about your server), and to allow any other origin server to make endpoint requests to this subdomain (basically disabling CORS). Depending on what your web service does you may want different settings.
Restart Caddy to cause it to load the new settings.
sudo service caddy restartNow Caddy will attempt to proxy the requests, but there is no web service listening on port 5000 and so you will get an error from Caddy if you make a request to tacos.cs260.click.
Copy the ~/services/startup directory to a directory that represents the purpose of your service. For example:
cp -r ~/services/startup ~/services/tacosIf you list the directory you should see an index.js file that is the main JavaScript file for your web service. It has the code to listen on the designated network port and respond to requests. The following is the JavaScript that causes the web service to listen on a port that is provided as an argument to the command line.
const port = process.argv.length > 2 ? process.argv[2] : 3000;
app.listen(port, () => {
console.log(`Listening on port ${port}`);
});There is also a directory named public that has static HTML/CSS/JavaScript files that your web service will respond with when requested. The index.js file enables this with the following code:
app.use(express.static('public'));You can start up the web service, listening on port 5000, using Node as follows.
node index.js 5000You can now access your web service through the browser, or curl.
curl https://tacos.cs260.clickCaddy will receive the request and map the subdomain name, tacos.cs260.click, to a request for http://localhost:5000. Your web service is listening on port 5000 and so it receives the request and responds.
Stop your web service by pressing CTRL-C in the SSH console that you used to start the service. Now your browser request for your subdomain should return an error again.
The problem with running your web service from the console with node index.js 5000, is that as soon as you close your SSH session it will terminate all processes you started in that session, including your web service. Instead you need something that is always running in the background to run your web service. This is where daemons come into play. The daemon we use to do this is called PM2.
From your SSH console session run:
pm2 lsThis will list the web services that you already have registered with PM2. To run your newly created web service under PM2, make sure you are in your service directory, and run the command similar to the following, with the service name and port substituted to your desired values:
cd ~/services/tacos
pm2 start index.js -n tacos -- 5000
pm2 saveIf you run pm2 ls again you should see your web service listed. You can now access your subdomain in the browser and see the proper response. PM2 will keep running your service even after you exit your SSH session.