Docker example wraps the next CLI with yarn in CMD and will not receive process signals (e.g. from Kubernetes)

[stefee]

What example does this report relate to?

with-docker

What version of Next.js are you using?

latest

What version of Node.js are you using?

N/A

What browser are you using?

N/A

What operating system are you using?

N/A

How are you deploying your application?

Docker

Describe the Bug

The with-docker example and Deployment with Docker Image docs use similar Dockerfile example.

The Dockerfile has CMD as yarn start

CMD ["yarn", "start"]

This means that yarn will be used as default entrypoint executable when running the container.

As a result if a container manager such as Kubernetes sends process signals (SIGTERM/SIGINT) to the container created from this Dockerfile, the yarn process will receive these signals and expected to handle them correctly. There is no guarantee that yarn will forward these signals correctly to the child process (in this case, next CLI).

Without receiving the process signals from the Docker manager, next CLI is unable to respond appropriately to the context in which it is run - for example, to wait for in-flight HTTP requests to be fulfilled before exiting.

Also, we should consider that users will copy this example and use it with npm - which also has no guarantee to forward process signals to the child process from start or run-script.

A user might also decide to use next CLI initially and then change to use a custom Node.js server inside their Docker container (e.g. by changing their start script in package.json to use node index.js instead of next start). In this case, they might not realise that the node process is not able to receive signals from the container manager.

These are some of the reasons why it is recommended by Node.js Docker WG and Snyk that you do not use npm or yarn script as the entrypoint for a container.

Expected Behavior

Docker example could use the following instead:

ENV PORT 3000

CMD ["node_modules/.bin/next", "start"]

Sidenote:

The deployment guide could also mention that if you are using a custom Node.js server in Docker, then the node process will not handle SIGTERM and SIGINT signals sent via the container by default when it is run as container entrypoint [source], and recommend using docker run --init flag, using a small init binary like tini as the entrypoint instead, or handling process signals in code using process.on or a package like terminus or lightship.

To Reproduce

$ cd examples/with-docker
$ yarn  # There is no yarn.lock in the repo, we must generate it first
$ docker build . --tag=next-with-docker
$ docker run -p 3000:3000 next-with-docker

# Expected: "ready - started server on 0.0.0.0:3000, url: http://localhost:3000"

$ docker kill --signal="SIGINT" <container name>  # OR --signal="SIGTERM"

# Expected: server will stop gracefully

Note: the above should be the same whether using yarn, npm, next CLI or a custom Node.js server.

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.