Building custom runtime services

To get started with custom runtimes, gcloud beta provides a helper function to generate the required Dockerfile and app.yaml:

gcloud beta app gen-config --custom

This command will analyze the current directory to determine the type of application. For example, when run in a directory with a package.json file, gcloud will provide an app.yaml and Dockerfile for building a Node.js application. This command will generate a basic app.yaml and the following Dockerfile:

FROM gcr.io/google_appengine/nodejs
COPY . /app/
...
RUN npm install --unsafe-perm || \
  ((if [ -f npm-debug.log ]; then \
      cat npm-debug.log; \
    fi) && false)
CMD npm start

Note that this generated Dockerfile is provided as a convenience, but any valid Dockerfile can be used. When developing a service to be run in a custom runtime, there are a few design considerations that should be made:

• Listen on port 8080: App Engine expects that services will handle requests on port 8080. To maintain portability, this value also is available at runtime as the PORT environment variable.
• Provide health checks at /_ah/health: App Engine regularly polls this endpoint to check that an instance is in a healthy state. While this behavior can be disabled from within the application's configuration file (enable_health_check: False), doing so is generally a bad idea. Response codes 502, 503, and 504 indicate that a service is unhealthy. Note that in this context, a 404 is considered healthy, meaning the default response for most web frameworks will pass the health check.
• Gracefully shut down on SIGTERM: App Engine attempts to send all instances a SIGTERM (stop) signal 30 seconds before actual termination. Services should leverage this time to gracefully terminate any open requests and end processes. The SIGTERM and 30-second grace period are delivered on a best effort basis, so they should not be depended on.