Docker
Docker is a tool for deploying and running executables in isolated and reproducible environments. This may be useful, for example, to test code in an environment identical to production.
RubyMine integrates the Docker functionality and provides assistance for creating Docker images, running Docker containers, managing Docker Compose applications, using public and private Docker registries, and much more directly from the IDE.
Getting started
Enable the Docker plugin
This functionality relies on the Docker plugin, which is bundled and enabled in RubyMine by default. If the relevant features are not available, make sure that you did not disable the plugin.
Press Ctrl+Alt+S to open the IDE settings and select .
Open the Installed tab, find the Docker plugin, and select the checkbox next to the plugin name.
Install and run Docker
For information about installing and running Docker, see the Docker documentation.
Connect to the Docker daemon
Press Ctrl+Alt+S to open the IDE settings and select .
Click
to add a Docker configuration and specify how to connect to the Docker daemon.The connection settings depend on your Docker version and operating system. For more information, see Docker connection settings.
The Connection successful message should appear at the bottom of the dialog.
Open the Services tool window ( or Alt+8), select the configured Docker connection node
and click 
, or select Connect from the context menu.
To edit the Docker connection settings, select the Docker node and click
on the toolbar, or select Edit Configuration from the context menu.You can also click
and select Docker Connection to add a Docker connection directly from the Services tool window. If you have Docker contexts configured, you can select Docker Connections from Docker Contexts to add the corresponding connections.
In the Services tool window ( or Alt+8), you can pull and push images, create and run containers, manage Docker Compose services, and so on. As with other tool windows, you can start typing the name of an image or container to highlight the matching items.
For more information, see the article about the Services tool window.
Managing images
Docker images are executable packages for running containers. Depending on your development needs, you can use Docker for the following:
Pull pre-built images from a Docker registry
For example, you can pull an image that runs a PostgreSQL server container to test how your application will interact with your production environment.
Build images locally from a Dockerfile
For example, you can build an image that runs a container with the Java Runtime Environment (JRE) of some specific version to execute your Java application inside it.
Push your images to a Docker registry
For example, if you want to demonstrate to someone how your application runs in some specific version of the JRE instead of setting up the proper environment, they can run a container from your image.
Images are distributed via the Docker registry. Docker Hub is the default public registry with all of the most common images: various Linux flavors, database management systems, web servers, runtime environments, and so on. There are other public and private Docker registries, and you can also deploy your own registry server.
Configure a Docker registry
Press Ctrl+Alt+S to open the IDE settings and select .
Click
to add a Docker registry configuration and specify how to connect to the registry. If you specify the credentials, RubyMine will automatically check the connection to the registry. The Connection successful message should appear at the bottom of the dialog.
For more information, see Docker registry settings.
Pull an image from a Docker registry
In the Services tool window ( or Alt+8), select the Images node.
Under Images Console, type the name of the image to pull. For example:
postgres:latestUse completion to select from the available suggestions of official images. Press Ctrl+Space again to see relevant images from all users.
Press Ctrl+Enter to run docker pull.
Specify the image as in the Docker CLI, for example: ubuntu:20.04.
Build an image from a Dockerfile
When you are editing a Dockerfile, RubyMine provides completion for images from the configured registries.
Open the Dockerfile from which you want to build the image.
Click
in the gutter and select to build the image.
RubyMine creates a Dockerfile run configuration that runs the docker build command.
Push an image to a Docker registry
In the Services tool window, select the image that you want to upload and click
or select Push Image from the context menu.
Select the Docker registry and specify the repository and tag (name and version of the image, for example,
my-app:v2).
Click OK to run the docker push command.
Copy image to another Docker daemon
If you have several Docker daemon connections, you can copy an image from one Docker daemon to another.
In the Services tool window, select the image that you want to copy and click
or select Copy Docker Image from the context menu.In the Copy Docker Image dialog, select the Docker daemon to which you want to copy the image and click Copy.
This first runs the docker save command to save the image from the current Docker daemon as a file, and then the docker load command to load the image from the file on the target Docker daemon.
RubyMine stores images that you pull or build locally and lists them in the Services tool window under the Images node. When you select an image, you can view its name, ID, date of last changes, size, tags, and any containers using this image, if any. You can also create a new container from the selected image, push the image, or view the layers used by the image. Click 
to see more actions: copy the image ID to the clipboard, run the docker image inspect command, or show labels applied to the image.
Images with no tags <none>:<none> can be one of the following:
Intermediate images that serve as layers for other images and do not take up any space
Dangling images that remain when you rebuild an image based on a newer version of another image. You should regularly prune dangling images to preserve disk space.
To hide untagged images from the list, click 
on the Docker toolbar, and remove the checkmark from Untagged Images.
To delete one or several images, select them in the list and click
.
Running containers
Docker containers are runtime instances of the corresponding images. RubyMine uses run configurations to execute the commands that build Docker images and run containers. There are three types of Docker run configurations:
Docker Image: Created automatically when you run a container from an existing image. You can run it from a locally existing Docker image that you either pulled or built previously.
Dockerfile: Created automatically when you run a container from a Dockerfile. This configuration builds an image from the Dockerfile, and then derives a container from this image.
Docker-compose: Created automatically when you run a multi-container Docker application from a Docker Compose file.
Run a container from an existing image
In the Services tool window, select an image and click
or select Create Container from the context menu.
In the Create Container popup, click Create….
In the Create Docker Configuration dialog that opens, you can provide a unique name for the configuration and specify a name for the container. If you leave the Container name field empty, Docker will give it a random unique name.
When you are done, click Run to launch the new configuration.
Run a container from a Dockerfile
Open the Dockerfile from which you want to run the container.
Click
in the gutter and select to run the container from this Dockerfile.
This creates and starts a run configuration with default settings, which builds an image based on the Dockerfile and then runs a container based on this image.
To create a run configuration with custom settings, click in the gutter and select New Run Configuration…. You can specify a custom tag for the built image, as well as a name for the container, and a context folder from which to read the Dockerfile. The context folder can be useful, for example, if you have some artifacts outside of the scope of your Dockerfile, which you would like to add to the file system of the image.
Docker run configurations
Create a Docker run configuration
From the main menu, select .
In the Run/Debug Configurations dialog, click
, point to Docker, and then click the desired type of run configuration.
Use this type of configuration to run a Docker container from a locally existing image that you either pulled or built previously.
Docker uses the docker run command with the following syntax:
You can set all the arguments for this command using the options of the Docker Image run configuration.
By default, the Docker Image configuration has the following options:
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, RubyMine 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 RubyMine stores run configuration settings in .idea/workspace.xml. |
Server | Select the Docker daemon connection to use for the run configuration. |
Image ID or name | Specify the identifier or the name of the Docker image from which to create the container. |
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 |
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 Move tasks in the list using |
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:
|
and 
to change the order in which to perform the tasks. Select a task and click 
to edit the task. Click Use the Modify options menu to add advanced options to the run configuration:
Randomly publish all exposed ports | Publish all exposed container ports to random free ports on the host. This is similar to using the |
Bind ports | Map specific container ports to specific ports on the host. This is similar to using the Click Lets say you already have PostgreSQL running on the host port 5432, and you want to run another instance of PostgreSQL in a container and access it from the host via port 5433. Binding the host port 5433 to port 5432 in the container is similar to setting the following command-line option: -p 5433:5432 You can set this option explicitly in the Run options field instead of configuring the Bind ports field. |
Entrypoint | Override the default This is similar to using the |
Command | Override the default This is similar to adding the command as an argument for |
Bind mounts | Mount files and directories on the host to a specific location in the container. This is similar to using the Click For example, you can mount a local PostgreSQL directory on the host (/Users/Shared/pg-data) to some directory inside the container (/var/lib/pgsql/data). Mounting volumes in this manner is similar to setting the following command-line option: -v /Users/Shared/pg-data:/var/lib/pgsql/data 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 This is similar to using the Click For example, if you want to connect to PostgreSQL with a specific username by default (instead of the operating system name of the user running the application), you can set the --env PGUSER=%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 --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 |
Show command preview | Preview the resulting command that will be used to execute the run configuration. |
in the Use this type of configuration to build an image from a Dockerfile and then derive a container from this image.
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:
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, RubyMine 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 RubyMine 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 |
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 Move tasks in the list using |
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:
|
Use the Modify options menu to add advanced options to the run configuration:
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 values for build-time variable 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 These variables must be defined in the Dockerfile with the
ARG PGTAG=latest
FROM postgres:$PGTAG
The Redefining the --build-arg PGTAG=9 |
Build options | Set any other supported For example, you can specify metadata for the built image with the |
Enable BuildKit | Use the BuildKit backend when building the images. This is similar to setting the |
Randomly publish all exposed ports | Publish all exposed container ports to random free ports on the host. This is similar to using the |
Bind ports | Map specific container ports to specific ports on the host. This is similar to using the Click Lets say you already have PostgreSQL running on the host port 5432, and you want to run another instance of PostgreSQL in a container and access it from the host via port 5433. Binding the host port 5433 to port 5432 in the container is similar to setting the following command-line option: -p 5433:5432 You can set this option explicitly in the Run options field instead of configuring the Bind ports field. |
Entrypoint | Override the default This is similar to using the |
Command | Override the default This is similar to adding the command as an argument for |
Bind mounts | Mount files and directories on the host to a specific location in the container. This is similar to using the Click For example, you can mount a local PostgreSQL directory on the host (/Users/Shared/pg-data) to some directory inside the container (/var/lib/pgsql/data). Mounting volumes in this manner is similar to setting the following command-line option: -v /Users/Shared/pg-data:/var/lib/pgsql/data 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 This is similar to using the Click For example, if you want to connect to PostgreSQL with a specific username by default (instead of the operating system name of the user running the application), you can set the --env PGUSER=%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 --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 |
Show command preview | Preview the resulting command that will be used to execute the run configuration. |
Use this type of configuration to run multi-container Docker applications.
Docker uses the docker-compose command to define, configure, and run multi-container applications. The main command that builds, creates, starts, and attaches to containers is docker-compose up.
By default, the Docker-compose configuration has the following options:
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, RubyMine 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 RubyMine stores run configuration settings in .idea/workspace.xml. |
Server | Select the Docker daemon connection to use for the run configuration. |
Compose files | Specify the compose files that define the necessary services. Docker Compose builds the configuration in the specified order, so any subsequent files override and add to the fields of the same service in previous files. This is similar to using the |
Services | Specify the services to build, create, and start. Click the Browse icon (  |
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 Move tasks in the list using |
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:
|
Use the Modify options menu to add advanced options to the run configuration:
Project name | Specify an alternate project name for Docker Compose. By default, it is the name of the current directory. This is similar to using the |
Environment variables | Specify the Docker Compose environment variables. These are used only by the Docker Compose process. They are not passed on to any of the containers. |
Environment variables file | Specify the path to a custom environment file that defines the Docker Compose environment variables. By default, Docker Compose looks for a file named .env in the project directory. This is similar to using the |
Enable BuildKit | Use the BuildKit backend when building the images. This is similar to setting the |
Remove volumes on `down` | When stopping and removing containers, also delete named volumes declared in the Docker Compose file and anonymous volumes attached to containers. This is similar to using the |
Enable compatibility mode | Convert v3 service definitions into v2 compatible parameters. This is similar to using the |
Remove images on `down` | Configure which images should be removed when stopping and removing containers. You can choose to remove all images used by any service or only images that don't have a custom tag set in the This is similar to using the |
Timeout | Set a timeout in seconds to forcefully terminate containers that won't shutdown gracefully. Docker usually tries to gracefully terminate any container with This is similar to using the |
Exit code | Return the exit code of the selected service container. Whenever a container in the selected service stops, return its exit code and stop all other containers in the service. This is similar to using the |
Override scale | Set the number of containers to start for each service. This option overrides the This is similar to using the |
Recreate dependencies | Recreate dependent containers when starting a service. This is similar to using the |
Recreate anonymous volumes | Recreate anonymous volumes instead of retrieving data from the previous containers. This is similar to using the |
Remove orphans | Remove containers for services not defined in the Docker Compose file. This is similar to using the |
Start | Configure which services to start:
|
Attach to | Configure for which containers to show output streams:
|
Recreate containers | Configure which containers to stop and replace by new ones:
|
Build | Configure which images to build before starting containers:
|
Stop Containers | Configure how to stop containers in a service. By default, Docker Compose doesn't stop other containers in a service. You have to stop them manually. However, you can choose to stop all containers if any container in a service stops. This is similar to using the |
Interacting with containers
Created containers are listed in the Services tool window. By default, the Services tool window displays all containers, including those that are not running. To hide stopped containers from the list, click in the toolbar, select Docker, and then click Stopped Containers to remove the checkbox.
When you select a container, you can view the Build Log tab that shows the deployment log produced by the corresponding Docker run configuration while creating and starting the container.
The Dashboard tab provides important information about the container. Besides its name and hash ID, it also lists the environment variables, ports, and volume bindings. You can add, edit, and remove the environment variables, ports, and volume bindings. However, these changes require you to recreate the container and do not change in the Docker run configuration that is used to create this container. This means that the changes will not persist when you run the configuration next time.
For more information, see Container dashboard.
Execute a command inside a running container
In the Services tool window, right-click the container name and then click Exec.
In the Run Command in Container popup, click Create and Run… to create and execute a new command.
Alternatively, you can select one of the commands that you ran previously.
In the Exec dialog, type the command and click OK. For example:
ls /tmpList the contents of the /tmp directory
mkdir /tmp/my-new-dirCreate the my-new-dir directory inside the /tmp directory
/bin/bashStart a
bashsession
For more information, see the docker exec command reference.
View detailed information about a running container
In the Services tool window, right-click the container name and then click Inspect.
The output is rendered as a JSON object on the Inspection tab.
For more information, see the docker inspect command reference.
View processes running in a container
In the Services tool window, right-click the container name and then click Show Processes.
The output is rendered as a JSON array on the Processes tab.
For more information, see the docker top command reference.
Attach a console to the container output
In the Services tool window, right-click the container and then click Attach.
The console is attached to the output of the ENTRYPOINT process running inside a container, and is rendered on the Attached Console tab.
For more information, see the docker attach command reference.
Docker Compose
Docker Compose is used to run multi-container applications. For example, you can run a web server, a backend database, and your application code as separate services. Each service can be scaled by adding more containers if necessary. This enables you to perform efficient development and testing in a dynamic environment, similar to production.
Run a multi-container Docker application
Define necessary services in one or several Docker Compose files.
From the main menu, select .
Click
, point to Docker and then click Docker-compose.
Specify the Docker Compose files that define services which you want to run in containers. If necessary, you can restrict the services that this configuration will start, specify environment variables, and force building of images before starting corresponding containers (that is, add the
--buildoption for the docker-compose up command).For more information about the available options, seeDocker-compose.
Click OK to save the Docker Compose run configuration, select it in the main toolbar and click
or press Shift+F10 to start the configuration.
When Docker Compose runs your multi-container application, you can use the Services tool window to control specific services and interact with containers. The containers are listed under the dedicated Compose nodes, not under the Containers node (which is only for standalone containers).
Scale a service
In the Services tool window, select the service you want to scale and click
or select Scale from the context menu.
Specify how many containers you want for this service and click OK.
Stop a running service
In the Services tool window, select the service and click
or select Stop from the context menu.
Stop all running services
In the Services tool window, select the Compose node and click
or select Stop from the context menu.
Bring your application down
In the Services tool window, select the Compose node and click
or select Down from the context menu.
This stops and removes containers along with all related networks, volumes, and images.
Open the Docker Compose file that was used to run the application
In the Services tool window, right-click the Compose node or a nested service node and then click Jump to Source in the context menu or pressF4.
The Docker-compose run configuration will identify environment files with the .env suffix if they are located in the same directory as the Docker Compose file.
Troubleshooting
If you encounter one of the following problems, try the corresponding suggested solution.
Unable to connect to Docker
Make sure that:
Docker is running.
Your Docker connection settings are correct.
If you are using Docker for Windows, enable the Expose daemon on tcp://localhost:2375 without TLS option in the General section of your Docker settings.
If you are using Docker Toolbox, make sure that Docker Machine is running and its executable is specified correctly in the Settings dialog Ctrl+Alt+S under .
Unable to use Docker Compose
Make sure that the Docker Compose executable is specified correctly in the Settings dialog Ctrl+Alt+S under .
Unable to use port bindings
Make sure that the corresponding container ports are exposed. Use the EXPOSE command in your Dockerfile.
Unable to associate existing Dockerfiles or Docker Compose files with relevant types
When you create new Dockerfiles or Docker compose files, RubyMine automatically identifies their type. If a file type is not evident from its name, you will be prompted to select the file type manually. To associate an existing file with the correct type, right-click it in the Project tool window and select Associate with File Type from the context menu.
If the Associate with File Type actions is disabled, this probably means that the filename is registered as a pattern for current file type. For example, if you have a Dockerfile with a custom name that is recognized as a text file, you cannot associate it with the Dockerfile type. To remove the file type pattern, do the following:
Press Ctrl+Alt+S to open the IDE settings and select .
Select the relevant file type (in this case: Text) and remove the pattern with the name of the file.
Click OK to apply the changes.
Now you should be able to set the correct file type using Associate with File Type in the context menu.
Limitations
The Docker plugin has certain limitations and bugs, however JetBrains is constantly working on fixes and improvements for it. You can find the list of Docker issues in our bug-tracking system and vote for the ones that affect you the most. You can also file your own bugs and feature requests.