WebStorm 2024.1 Help

Dockerfile run configuration

Use this type of configuration to build an image from a Dockerfile and then derive a container from this image.

Dockerfile run configuration dialog

Docker uses the docker build command to build an image from a Dockerfile, and then the docker run command to start a container from it.

By default, the Dockerfile configuration has the following options:

Item

Description

Name

Specify a name for the run configuration to quickly identify it among others when editing or running.

Allow multiple instances

Allow running multiple instances of this run configuration in parallel.

By default, it is disabled, and when you start this configuration while another instance is still running, WebStorm suggests stopping the running instance and starting another one. This is helpful when a run configuration consumes a lot of resources and there is no good reason to run multiple instances.

Store as project file

Save the file with the run configuration settings to share it with other team members. The default location is .idea/runConfigurations. However, if you do not want to share the .idea directory, you can save the configuration to any other directory within the project.

By default, it is disabled, and WebStorm stores run configuration settings in .idea/workspace.xml.

Server

Select the Docker daemon connection to use for the run configuration.

Dockerfile

Specify the name and location of the Dockerfile used to build the image.

Image tag

Specify an optional name and tag for the built image.

This can be helpful for referring to the image in the future. If you leave the field blank, the image will have only a random unique identifier.

Container name

Specify an optional name for the container. If empty, Docker will generate a random name for the container.

This is similar to using the --name option with the docker run command.

Before launch

Specify a list of tasks to perform before starting the run configuration. For example, run another configuration, build the necessary artifacts, run some external tool or a web browser, and so on.

Click the Add button or press Alt+Insert to add one of the available tasks.

Move tasks in the list using the Up button and the Down button to change the order in which to perform the tasks. Select a task and click the Edit button to edit the task. Click the Remove button to remove the selected task from the list.

Show this page

Show the run configuration settings before actually starting it.

Activate tool window

Depending on the type of configuration, open the Run, Debug, or Services tool window when you start this run configuration. If this option is disabled, you can open the tool window manually:

  • View | Tool Windows | Run or Alt+4

  • View | Tool Windows | Debug or Alt+5

  • View | Tool Windows | Services or Alt+8

Use the Modify options menu to add advanced options to the run configuration:

Item

Description

Context folder

Specify a local directory that the daemon will use during the build process. All host paths in the Dockerfile will be processed relative to this directory. By default, if you leave it blank, Docker uses the same directory where the Dockerfile is located.

Build args

Specify the values for build-time variables that can be accessed like regular environment variables during the build process but do not persist in the intermediate or final images.

This is similar to using the --build-args option with the docker build command.

These variables must be defined in the Dockerfile with the ARG instruction. For example, you can define a variable for the version of the base image that you are going to use:

ARG WSNODETAG=latest FROM node:$WSNODETAG

The WSNODETAG variable in this case will default to latest and the Dockerfile will produce an image with the latest available version of Node.js, unless you redefine it as a build-time argument. If you set, WSNODETAG=8, Docker will pull node:8 instead, which will run a container with Node.js version 8.

Redefining the WSNODETAG argument is similar to setting the following command-line option:

--build-arg WSNODETAG=8

You can provide several arguments separated by spaces.

Build options

Set supported docker build options.

For example, you can specify metadata for the built image with the --label option.

Enable BuildKit

Use the BuildKit backend when building the images.

This is similar to setting the DOCKER_BUILDKIT=1 environment variable when invoking the docker build command.

Randomly publish all exposed ports

Publish all exposed container ports to random free ports on the host.

This is similar to using the -P or --publish-all option on the command line.

Bind ports

Map specific container ports to specific ports on the host.

This is similar to using the -p or --publish option on the command line.

Click Browse in the Bind ports field and specify which ports on the host should be mapped to which ports in the container. You can also provide a specific host IP from which the port should be accessible (for example, you can set it to 127.0.0.1 to make it accessible only locally, or set it to 0.0.0.0 to open it for all computers in your network).

Lets say you already have Node.js running on the host port 3001, and you want to run another instance of Node.js in a container and access it from the host via port 3000. Binding the host port 3000 to port 3001 in the container is similar to setting the following command-line option:

-p 3000:3001

You can set this option explicitly in the Run options field instead of configuring the Bind ports field.

Entrypoint

Override the default ENTRYPOINT of the image.

This is similar to using the --entrypoint option on the command line.

Command

Override the default CMD of the image.

This is similar to adding the command as an argument for docker run.

Bind mounts

Mount files and directories on the host to a specific location in the container.

This is similar to using the -v or --volume option on the command line.

Click Browse in the Bind mounts field and specify the host directory and the corresponding path in the container where it should be mounted. Select Read only if you want to disable writing to the container volume.

For example, you can mount a local Node.js directory on the host (/Users/jetbrains/WS/node_docker/web) to some directory inside the container (usr/src/app). Mounting volumes in this manner is similar to setting the following command-line option:

-v /Users/jetbrains/WS/node_docker/web:usr/src/app

You can set this option explicitly in the Run options field instead of configuring the Bind mounts field.

Environment variables

Specify environment variables. There are environment variables associated with the base image that you are using as defined by the ENV instruction in the Dockerfile. There are also environment variables that Docker sets automatically for each new container. Use this field to override any of the variables or specify additional ones.

This is similar to using the -e or --env option on the command line.

Click Browse in the Environment variables field to add names and values for variables.

For example, if you want to suppress colors in REPL, set the NODE_DISABLE_COLORS = 1 variable. This is similar to setting the following command-line option:

--env NODE_DISABLE_COLORS=%env-var-value

You can set this option explicitly in the Run options field instead of configuring the Environment variables field.

Run options

Set any other supported docker run options.

For example, to connect the container to the my-net network and set the my-app alias for it, specify the following:

--network my-net --network-alias my-app

Attach to container

Attach to the container's standard input, output, and error streams.

This is similar to using the -a or --attach option on the command line.

Show command preview

Preview the resulting command that will be used to execute the run configuration.

Last modified: 11 February 2024