Docker
Docker enables developers to deploy applications inside containers for testing code in an environment identical to production. IntelliJ IDEA provides Docker support using the Docker plugin. The plugin is bundled and enabled by default in IntelliJ IDEA Ultimate Edition. For IntelliJ IDEA Community Edition, you need to install the Docker plugin as described in Manage plugins.
Enable Docker support
Install and run Docker.
For more information, see the Docker documentation.
Configure the Docker daemon connection settings:
In the Settings/Preferences dialog Ctrl+Alt+S, select Build, Execution, Deployment | Docker.
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 configuration.
The Connection successful message should appear at the bottom of the dialog.
note
The Path mappings table is used to map local folders to corresponding directories in the Docker virtual machine's file system. Only specified folders will be available for volume binding.
This table is not available on Linux, because when running Docker on Linux, any folder is available for volume binding.
Connect to the Docker daemon.
The configured Docker connection should appear in the Services tool window (View | Tool Windows | Services or Alt+8 ). Select the Docker 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.
The Services tool window (View | Tool Windows | Services or Alt+8) enables you to pull and push images, create and run containers, manage Docker Compose, and so on. As with other tool windows, you can start typing the name of an image or container to highlight the matching items.
![The Docker tool window, text search The Docker tool window, text search](https://resources.jetbrains.com/help/img/idea/2021.1/55_DockerFindImage.png)
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 Postgres server container to test how your application will interact with your production database.
- 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, runtimes, and so on. There are other public and private Docker registries, and you can also deploy your own registry server.
Images that you pull or build are stored locally and are listed in the Services tool window under Images. When you select an image, you can view its ID or copy it to the clipboard by clicking the button on the Properties tab.
![Docker image properties Docker image properties](https://resources.jetbrains.com/help/img/idea/2021.1/54_DockerImageID.png)
To display detailed information about an image, right-click it and select Inspect from the context menu. IntelliJ IDEA runs the docker image inspect command and prints the output to the Inspection tab.
![Docker image Inspection tab Docker image Inspection tab](https://resources.jetbrains.com/help/img/idea/2021.1/docker-image-inspect.png)
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 then click Untagged Images to remove the check mark.
To delete one or several images, select them in the list and click .
Running containers
Containers are runtime instances of corresponding images. For more information, see the docker run command reference.
IntelliJ IDEA uses run configurations (Run | Edit Configurations) to run Docker 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.
note
Any Docker run configuration can also be created manually. From the main menu, select Run | Edit Configurations. Then click
, point to Docker, and select the desired type of run configuration.
Command-line options
When running a container on the command line, the following syntax is used:
docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
All optional parameters can be specified in the corresponding Docker run configuration fields.
To open a run configuration, right-click a container and select Edit Configuration, or use the gutter icon menu in the Dockerfile, or select Run | Edit Configurations from the main menu.
![The Edit Deployment Configuration dialog with command-line options The Edit Deployment Configuration dialog with command-line options](https://resources.jetbrains.com/help/img/idea/2021.1/66_DockerContainerCLI.png)
Options are specified in the Command line options field. In the previous screenshot, the container is connected to the my-net
network and is assigned an alias my-app
.
Commands and arguments to be executed when starting the container are specified in the Entrypoint and Command fields. These fields override the corresponding ENTRYPOINT and CMD instructions in the Dockerfile. In the previous screenshot, when the container starts, it executes the docker-entrypoint.sh script with postgres
as an argument.
note
Not all
docker run
options are supported. If you would like to request support for some option, leave a comment in IDEA-181088.
The Command preview field shows the actual Docker command used for this run configuration.
You can also configure the following container settings in the run configuration:
Bind mounts
Docker can mount a file or directory from the host machine to the container using the -v
or --volume
option. You can configure this in the Docker run configuration using the Bind mounts field.
note
Make sure that the corresponding path mappings are configured in the Docker connection settings (the Path mappings table).
![The Edit Deployment Configuration dialog with bind mounts The Edit Deployment Configuration dialog with bind mounts](https://resources.jetbrains.com/help/img/idea/2021.1/69_DockerVolumeBindings.png)
Click in the Bind mounts field and add bindings by specifying 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, if you want to mount some local PostgreSQL data directory (
If you expand the Command preview field, you will see that the following line was added:
-v /Users/Shared/pg-data:/var/lib/pgsql/data
This can be used in the Command line options field instead of creating the list of volume bindings using the Bind Mounts dialog.
Bind ports
Docker can map specific ports on the host machine to ports in the container using the -p
or --publish
option. This can be used to make the container externally accessible. In the Docker run configuration, you can choose to expose all container ports to the host or use the Bind ports field to specify port mapping.
![The Edit Deployment Configuration dialog with bind ports The Edit Deployment Configuration dialog with bind ports](https://resources.jetbrains.com/help/img/idea/2021.1/71_DockerPortBindings.png)
Click in the Bind ports field and bindings by specifying 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).
If you already have PostgreSQL running on the Docker host port %5432%, you can map port %5433% on the host to %5432% inside the container as illustrated on the previous screenshot. This will make PostgreSQL running inside the container accessible via port %5433% on the host.
If you expand the Command preview field, you will see that the following line was added:
-p 5433:5432
This can be used in the Command line options field instead of creating the list of port bindings using the Port Bindings dialog.
Environment variables
Environment variables are usually set in the Dockerfile associated with the base image that you are using. There are also environment variables that Docker sets automatically for each new container. You can specify additional variables and redefine the ones that Docker sets using the -e
or --env
option. In a Docker run configuration, you can use the Environment variables field to configure environment variables.
![The Edit Deployment Configuration dialog with environment variables The Edit Deployment Configuration dialog with environment variables](https://resources.jetbrains.com/help/img/idea/2021.1/73_DockerEnvVar.png)
Click in the Environment variables field to add names and values for variables. 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 define the
PGUSER
variable as illustrated on the previous screenshot.
If you expand the Command preview field, you will see that the following line was added:
--env PGUSER=pg-admin
This can be used in the Command line options field instead of creating the list of names and values using the Environment Variables dialog. If you need to pass sensitive information (passwords, secrets, and so on) as environment variables, you can use the --env-file
option to specify a file with this information.
Build-time arguments
Docker can define build-time values for certain environment variables that do not persist in the intermediate or final images using the --build-arg
option for docker build
. These must be specified in the ARG
instruction of the Dockerfile with a default value. You can configure build-time arguments in the Docker run configuration using the Build args field.
For example, you can use build-time arguments to build the image with a specific version of PostgreSQL. To do this, add the ARG
instruction to the beginning of your Dockerfile:
ARG PGTAG=latest
FROM postgres:$PGTAG
The PGTAG
variable in this case will default to latest
if you do not redefine it as a build-time argument. So by default, this Dockerfile will produce an image with the latest available PostgreSQL version. However, you can use the Build Args field to redefine the PGTAG
variable.
![The Edit Deployment Configuration dialog with build-time arguments The Edit Deployment Configuration dialog with build-time arguments](https://resources.jetbrains.com/help/img/idea/2021.1/74_DockerBuildArgs.png)
In the previous screenshot, PGTAG
is set to 9
, which will instruct Docker to pull postgres:9
. When you deploy this run configuration, it will build an image and run the container with PostgreSQL version 9.
To check this, execute postgres --version
inside the container and see the output: it should be postgres (PostgreSQL) 9.6.6
or some later version.
If you expand the Command preview field, you will see that the following option was added to the docker build
command:
--build-arg PGTAG=9
Interacting with containers
Created containers are listed in the Services tool window. When you select a container, you can view its ID (and the ID of the corresponding image) and copy it to the clipboard using on the Properties tab. You can also specify a new name for the container and click Save to start another container with this new name from the same image.
By default, the Services tool window displays all containers, including those that are not running. To hide stopped containers from the list, click , and then click Show Stopped Containers to remove the checkbox.
If a container was created using a Docker run configuration, to view its deployment log, select it and open the Deploy log tab. To view the log messages from the container's STDOUT
and STDERR
, select it and open the Log tab. For more information, see the docker logs command reference.
You can browse the files inside a running container using the Files tab. Select any file and click to open it remotely in the editor or click
to create a copy of the file as a scratch.
note
The file browser may not work by default for containers that don't have the full
ls
package, for example, images that are based on Alpine, Photon, and BusyBox. To use it, you can add the following command in the Dockerfile:FROM alpine:3.10 RUN apk add coreutils
FROM photon:3.0 RUN echo y | tdnf remove toybox
Docker Compose
Docker Compose is used to run multi-container applications. For example, you can run a web server, 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 Run | Edit Configurations.
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
--build
option for the docker-compose up command).When the run configuration is ready, execute it.
note
To quickly create a Docker-compose run configuration and run it with default settings, right-click a Docker Compose file in the Project tool window and click Run in the context menu. You can also use gutter icons and the context menu in the Docker Compose file to control services.
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).
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.
Docker debug
To debug your application running in a Docker container, you can use the remote debug configuration:
In the main menu, select Run | Edit Configurations.
Click
and select Remote.
In the Before launch section, click
and select Launch Docker before debug.
Specify the Docker configuration you want to run and configure the preferred container port for the debugger to attach to if the default one is allocated to something else.
Check the Custom Command and modify it if necessary.
Apply all changes, remove any running containers of the application you want to debug, and then launch the remote debug configuration.
For examples, see the following tutorials:
Troubleshooting
If you encounter one of the following problems, try the corresponding suggested solution.
Limitations
The Docker integration 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.