Question

Deploying a React app using pm2 and serve in App Platform

Posted September 9, 2021 104 views
DeploymentReactDigitalOcean App Platform

Hi, I am trying to setup PM2 to run a React app I am deploying using the App Platform. The purpose is to have PM2 to automatically restart the app in case it crashes. However I am not able to properly configure the app.yaml to make it work. An example of the app.yaml that I have is:

services:
  - name: app
    build_command: npm install pm2 serve -g && npm run build
    environment_slug: node-js
    github:
      branch: main
      deploy_on_push: true
      repo: repo/app
    http_port: 8080
    instance_count: 1
    instance_size_slug: professional-xs
    routes:
      - path: /
    run_command: pm2-runtime serve build 8080 --spa
    source_dir: /

With these settings, the app deploys, but when I try to access it using the app URL, I get a page that shows the file directory. Also I get two PM2 looping errors after the build:

PM2 error: Error caught while calling pidusage
PM2 error: Error: ESPIPE: invalid seek, read

Probably I am not using a proper run command. Also, should I be using pm2 or pm2-runtime?

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
Submit an Answer
1 answer

👋 @mateusAxolotl

This is occurring because pidusage uses an underlying SYSCALL which is not available on App Platform, this is part of our underlying sandbox technology called gVisor. Here’s a thread of users who’ve run into this on gVisor based services, like App Platform and Google Cloud Run.

The good news is that for monitoring your app and restarting it on crashes is already a built-in feature of App Platform. Running node app.js should be all you need.

In addition, we recently released alerts and notifications which support getting alerts on restart counts. Here’s a youtube video talking all about this feature.

Hope this helps!

  • 👋 @crashoverride

    Thanks for the quick reply!

    That makes sense, it wasn’t clear to me that auto restart on crash was already built-in. I wanted to implement an auto-restart because we ran into an issue another day in which the app wasn’t running (there was a screen with an Error 500 message), so I did a new manual build and since then we’ve experienced no downtime. But as logs do not persist in App Platform components by default, I cannot tell what went wrong in that event.

    Does the auto restart work on a service level or on a container level?

    Can you point out to a reference on how to implement log persistence for components in the App Platform?

    • We will recreate the container in two scenarios, if the main run process stops (causing the container to stop), and if the healthcheck starts failing.

      The default healthcheck is a very simple TCP check. It sounds like your app might be better suited to an HTTP healthcheck. This will do check to see if the app URL is returning 200 OK’s. Here’s some docs further cutomization can be made in the app spec.

      Runtime logs are not persisted longterm. We are working hard on a feature to allow for external logging which should be available in the near future.

      • Thanks again @crashoverride .

        I’ve check the docs, but the HTTP healthcheck functionality is not clear to me. Can you clarify the health_checksettings in the app spec service settings? As I understand, if I set a http_path endpoint, the built-in healthcheck will happen over HTTP automatically? Or do I still need to setup an additional service/worker to check the status on the http_path endpoint? And if I want to perform a healthcheck in the main app URL, should I still set a custom endpoint (something like /healthcheck) or should I just use “/” as a value for http_path?