Now that the Notes application is fairly complete, it's time to think about how to deploy it to a real server. We've created a minimal implementation of the collaborative note concept that works fairly well. To get input and advice from others, Notes needs to escape our laptop and live on a real server. Therefore, the goal of this chapter to look at a couple of deployment methods for Node.js applications.
In this chapter, we will cover the following topics:
- Traditional LSB-compliant Node.js deployment
- Using PM2 to improve reliability
- Deployment to a Virtual Private Server provider
- Microservice deployment with Docker (we have four distinct services to deploy)
- Deployment to a Docker hosting provider
The first task is to duplicate the source code from the previous chapter. It's suggested to create a new directory, chap10, as a sibling of the chap09 directory and copy everything from chap09 to chap10.
Before we get into deploying the
Notes application, we need to review its architecture. We put together several pieces in the last several chapters without giving ourselves the chance to step back a few feet and gather some perspective on the results. To deploy the Notes application, we must understand what we're planning to do:
It's been our goal to segment the services into two groups. The user authentication server should be the more secure portion of the system so that we can earn the trust of our users. On our laptop, we weren't able to create the envisioned protective wall around that service, but we're about to implement such protection.
One strategy to enhance security is to expose as few ports as possible to the outside. That reduces the avenues miscreants can probe for vulnerabilities, thus simplifying our work in hardening the application against security bugs. With the Notes application, we have exactly one port to expose, the HTTP service through which users access the application. The other ports, the two for MySQL servers and the user authentication service port, should be hidden from public view.
Internally, the Notes application needs to access both the Notes database and the User Authentication service. That service, in turn, needs to access the User Authentication database. As currently envisaged, no service outside the Notes application requires access to either database or the authentication service.
Implementation of this segmentation requires either two or three subnets, depending on the lengths you wish to go. The first subnet, FrontNet, contains the Notes application and its database. The second subnet, AuthNet, contains the authentication service and its database. The subnets must be configured to limit the hosts that can access that subnet. It's this subnet configuration that creates the security wall that will let us breathe a little easier because miscreants will have a much harder time doing any damage.
But if the authentication service and Notes application are on different subnets, they will be unable to talk to each other. One could create a third subnet, NotesAuthConnector maybe, so that those services can talk to each other. Or one could do as shown here and allow the authentication service to connect to both FrontNet and AuthNet.
That picture is the desired end result of the chapter. First, we need to get our feet wet with traditional deployment methodologies.