Run /
Override command or entrypoint
Your deployments will specify either a command (CMD
) or an entrypoint (ENTRYPOINT
) instruction to identify the executable to run in your built image. Commands or entrypoints will be defined either in your Dockerfile, generated by the buildpack, or defined by a Procfile (for buildpack builds). In many cases you will not need to change these settings from the default.
Overriding the command or entrypoint in an individual service or job allows you to run a built image without updating the Dockerfile or re-building it, or affecting any other deployments of the image. This allows you to run different services or jobs from the same repository, for example if you have a repository containing microservices or need to run a migration.
You can configure the Docker runtime mode when creating a deployment (combined service, deployment service, or job) to override the default command and/or entrypoint at runtime. You can set the Docker runtime mode for existing services and jobs from the CMD override page.
If your Dockerfile defines an ENTRYPOINT instruction , the entrypoint instruction and parameters will be processed first, then any CMD instruction and parameters. The executed command in this case is a concatenation of the entrypoint and command instructions: [...(entrypoint ?? []), ...(cmd ?? [])]
.
You can override the default command from the CMD override page in your job or service by selecting custom command
as the Docker runtime mode.
Enter the new command and save changes to restart your containers with the new command. To use the default command again, select default configuration
as the runtime mode and save changes to restart your deployment. Jobs will run with the new configuration after it is set.
CMD override format
The Docker CMD instruction is run in exec
form on Northflank, where the executable and parameters are given as elements in an array:
CMD ["executable", "parameter1", "parameter2"]
To enter your command, type it into the CMD Override field and it will be automatically formatted. You must include an executable as the first argument in the command. You can check how your command has been parsed before continuing.
As Northflank uses the exec
form by default, you must explicitly invoke a shell (e.g. /bin/sh -c
) if you want to execute a shell command for a Docker image.
Command | Parsed command | Effect |
---|---|---|
/bin/sh -c /start.sh | CMD ["/bin/sh", "-c", "/start.sh"] | Executes a shell to run start.sh |
node server/index.js mode=test | CMD ["node", "server/index.js", "mode=test"] | Runs server/index.js in Node with the parameter mode=test . |
You can override the default entrypoint from the CMD override page in your job or service by selecting custom command
as the Docker runtime mode.
Enter the new entrypoint and save changes to restart your containers with the new entrypoint. To use the default entrypoint again, select default configuration
as the runtime mode and save changes to restart your deployment. Jobs will run with the new configuration after it is set.
The buildpack builder will attempt to identify all processes and their associated commands in your repository, and will define them in the built image, with the web
process as default. You can check a default process has been set in the build logs.
You can also manually define processes and their commands in a Procfile .
If you want to run a non-default process you can specify this process using the entrypoint override.
If your built image does not define a default process then the entrypoint of the generated image will be /cnb/lifecycle/launcher
. In this case you must set a command override to one of the non-default processes, otherwise the container will not start properly. The launcher will attempt to run any command with a bash shell. To execute a command without a shell, prefix the command with --
(e.g. -- /cnb/process/non-default
).
Build a repository using a Dockerfile
Configure your application build process using a Dockerfile.
Build a repository using Buildpacks
Build your application automatically using Buildpack stacks.
Inject secrets
Set build arguments and inject runtime variables into running deployments.
Create groups of secrets
Create and manage groups of secrets that can be inherited throughout an entire project or by specific services and jobs.