/probes_module_nodejs

A ready to use livenessprobe and readinessprobe for your application.

Primary LanguageJavaScriptGNU General Public License v3.0GPL-3.0

Digipolis Probes

This package includes a livenessprobe and a readinessprobe.

  • A livenessprobe checks if the app is still active. If it's not, the pod/container will be restarterd.
  • A readinessprobe checks if the app is ready to process requests. If the readinessprobe fails, no requests will be sent to this pod/container.

This package exposes two endpoints:

  • /status/alive for the livenessprobe.
  • /status/ready for the readinessprobe.

After including this package in your project you'll need to configure it in appconfig. Here is a small how-to.

Installation

npm i @digipolis/probes

Configuration

This package will work without any configuration but it is best practice to add some.

Param Description
alive (optional) Array with alive check functions
ready (optional) Array with ready check functions

Example

const probes = require('@digipolis/probes');

function customReadyCheck() {
  const ready = true;

  return new Promise((resolve, reject) => {
    if(!ready) {
      return reject({status: 400, message: 'Uh oh! This app is not ready.'});
    }

    return resolve();
  })
}

const config = {
  hooks: {
    ready: [
      customReadyCheck
    ]
  }
};

app.use(probes(config));

Error object

When there's an error (app is not alive/ready) you'll reject with an object.

Key Value
status (number) The status code you want to respond with. Should not be 200.
message (string A human readable message that will appear in the logs and your browser

If you omit a status a 500 will be used.

Example

  return reject({status: 400, message: 'Uh oh! This app is not ready.'});

If your app is in good shape and ready to handle traffic you resolve the promise. return resolve();

Tests

run npm t

Authors

See the list of contributors who participated in this project.

Contributing

Pull requests are always welcome, however keep the following things in mind:

  • New features (both breaking and non-breaking) should always be discussed with the repo's owner. If possible, please open an issue first to discuss what you would like to change.
  • Fork this repo and issue your fix or new feature via a pull request.
  • Please make sure to update tests as appropriate. Also check possible linting errors and update the CHANGELOG if applicable.

Support

Jan-Bart Vervoort (jan-bart.vervoort@digipolis.be)