Deployment and Process Monitoring for a Healthy Application

We are building a new and shiny Fastify API and want to expose it on the internet to gather feedback before our official launch. When we look online, there are plenty of options… but what should we use? After that, we will then need to figure out how to monitor the health of our server (because we always monitor our applications, right?).

In this chapter, we will unpack the basics of a monolith deployment, using Docker, MongoDB, and Fly.io. We will also review the key Node.js metrics, how to extract them from our application with Prometheus, and then how to easily consult them on Grafana.

This is the learning path we will cover in this chapter:

• Testing our Docker image for deployment
• Hosting our DB on MongoDB Atlas
• Choosing a cloud provider
• Deploying to Fly.io
• Setting up continuous deployment
• Collecting application process data

Technical requirements

As mentioned in the previous chapters, you will need the following:

• A working Node.js 18 installation
• A text editor to try the example code
• Docker
• An HTTP client to test out code, such as cURL or Postman
• A GitHub account

All the snippets in this chapter are on GitHub at https://github.com/PacktPublishing/Accelerating-Server-Side-Development-with-Fastify/tree/main/Chapter%2010.

Testing our Docker image with a local deployment

In Chapter 6, we set up our application for usage with Docker. This is a critical step for our TODO List application. Now, it’s time to test the image with Docker Compose to verify that everything is working as expected.

Let’s recap our DockerFile, with a minor modification:

FROM node:18-alpine as builder
WORKDIR /build
COPY package.json ./
COPY package-lock.json ./
ARG NPM_TOKEN
ENV NPM_TOKEN $NPM_TOKEN
RUN npm ci --only=production --ignore-scripts
FROM node:18-alpine
RUN apk update && apk add --no-cache dumb-init
ENV HOME=/home/app
ENV APP_HOME=$HOME/node/
ENV NODE_ENV=production
WORKDIR $APP_HOME
COPY --chown=node:node . $APP_HOME
COPY --chown=node:node --from=builder /build $APP_HOME
USER node
EXPOSE 3000
ENTRYPOINT ["dumb-init"]
CMD ["./node_modules/.bin/fastify", "start", "-a", "0.0.0.0", "-l", "info", "--options", "...

Hosting our DB on MongoDB Atlas

As we write this, the simplest way to provision a MongoDB cluster is to use MongoDB Atlas, which will allow 512 MB of storage for free. To employ this, please follow the MongoDB Atlas setup tutorial – while we include the screenshot for this process here, the process might vary.

The first step is to sign up to MongoDB Atlas at http://mongodb.com. After you have completed the signup and email verification process, you can select the tier in which you want your new database to be created. We will select the Shared option, which is the free tier. After we have selected our tier, we now choose where we want our MongoDB instance to be located. Choose a location that’s near to you!

Now, it’s time to add the security mechanism for our database. Make sure you are in the Quickstart tab below SECURITY, as shown in Figure 10.1. For this book, select the Username and Password authentication method.

Figure 10...

Choosing a cloud provider

Most people who start using a new technology wonder what cloud provider would provide the best experience to deploy their applications. In this book, we are not considering any solution that would be too much effort given the little space available.

Here is a list of providers that are worthwhile checking out:

• Heroku – it started supporting Node.js in 2011 and it’s by far one of the most mature and stable products.
• Google Cloud Run – it’s based on Knative (https://knative.dev/) and the Kubernetes stack.
• AWS Lambda – it’s the original “serverless” runtime, enabling the executions of “functions” that can scale elastically. Every function only processes one request at a time: while this makes it easy to scale and operate, I/O heavy applications are at a disadvantage. AWS Lambda is based on Firecracker (https://firecracker-microvm.github.io/).
• Vercel – it’...

Deploying to Fly.io

Fly.io’s main interface is a command-line tool called flyctl, which we can install with the following:

• iwr https://fly.io/install.ps1 -useb | iex on Windows PowerShell
• curl -L https://fly.io/install.sh | sh on Linux and macOS
• You can also use brew install flyctl on macOS too

Signing up with Fly.io is easy: issue the flyctl auth signup command. We recommend connecting your GitHub account, as you will need it later.

We can now deploy to Fly.io by executing flyctl launch in our current working directory (make sure there are no fly.toml files) and answering the following questions:

$ flyctl launch
Creating app in /path/to/Chapter 10
Scanning source code
Detected a Dockerfile app
? App Name (leave blank to use an auto-generated name):
? Select organization: Matteo Collina (personal)
? Select region: fra (Frankfurt, Germany)
Created app shy-fog-346 in organization personal
Wrote config file fly.toml
? Would you like to setup a Postgresql...

Setting up continuous deployment

We are setting up a continuous deployment system so that every commit pushed to the main branch of your GitHub repository is automatically deployed to Fly.io.

Automating your project with GitHub Actions

We recommend automating your development process with the use of GitHub Actions. They can be used to automatically run your automated tests, deploy your project, and even synchronize your issues with your other management software. Read more at https://docs.github.com/en/actions.

First, let’s create a repository on GitHub, clone it locally, and push our code there! To upload our code to GitHub, we run git clone, git add, git commit, and git push in our terminal.

Using Git and GitHub

If you are not familiar with Git and GitHub, we recommend you to follow the GitImmersion tutorial at https://gitimmersion.com/, as well as https://docs.github.com/en/get-started/quickstart/create-a-repo, to create the repository on GitHub, clone it,...

Collecting application process data

Excerpt from the talk “My Node.js process is on fire”

“At 10am on Black Friday, your phone rings: the new JS application you deployed came under too much load, and the site has gone down! Your employer is losing sales opportunities... your employer is losing money! But you don’t lose your cool. You log in to your cloud provider and tweak your autoscaling settings. Now the deployment can handle the load spike but with four times the number of servers, which is four times the cost. The next day, you try to analyze what happened and begin to optimize your application to prepare for future load spikes.”

The full talk was delivered by Matteo Collina at JSConf Asia 2018 and is available at https://www.youtube.com/watch?v=G9Vkpe55Gu8.

The main reason we want to collect metrics of our running Node.js process is to be able to diagnose and debug problems hours, days, or even weeks after they happened. The flow of...

Summary

In this chapter, we have deployed our Fastify application to Fly.io with the database hosted in MongoDB Atlas. Then, we added monitoring with the Prometheus instance hosted by Fly.io. Finally, we connected Prometheus with Grafana Cloud.

In the next chapter, we will cover how to set up logging in our Fastify application to produce readable, inspectable, and useful logs.