FAQ about Dev Containers

After a dev container is created, the following volumes and properties appear in Docker:

• jb_devcontainer_cache_xxx: this is a cached volume that contains all backend cashes in the root/cached/jetbrains folder.

• jb_devcontainers_shared_volume: the process of copying an IDE backend takes a certain amount of time. However, this process is done only once during the first dev container creation, and everything is copied into this volume. Then, this volume is shared among multiple containers, and we don't need to repeat the downloading process. If we create a dev container using another IDE or a different IDE version, we copy it into the same Docker volume. All backends are stored in one volume, making it easy to manage.

  For example, remove unnecessary backends through the Manage backends dialog.

• jb-devcontainer-features-xxx: if you use features in your devcontainer.json file then all features are placed into such images.

  Currently, the unnecessary images should be deleted manually.

• jb_devcontainer_sources_xxx: if we use git clone then all sources are cloned into this volume using helper container (based on alpine/git image).

Add to Help | Diagnostic Tools | Debug Log Settings the following strings:

com.intellij.platform.ijent:all

com.intellij.clouds.docker.gateway.ijent:all

Run the following command:

docker --host <ssh> build <git-url>:<context-dir>

Check the following example:

docker --host ssh://jetbrains@MUNIT-234:22 build
            git@git.jetbrains.team/devcont/DevCont_test_cases.git:.devcontainer

We create a helper container based on the small alpine/git image, which contains some of the required tools or libraries, for example git or the SSH client. We need that to clone the repository that can be absent in the image used for a dev container creation.

If we already have all the sources locally, there is no need to use such a complicated and slow method like Docker via SSH.

Let's say you connected to your remote project using the SSH connection. Then you added a devcontainer.json and tried to create a dev container via Create Dev Container and Mount sources on the remote machine.

Currently, we don't support such scenario and you can't create a dev container from the running backend-client connection. If you have the corresponding gutter option in your remote project, please add your vote or comment to the corresponding issue.

As a workaround, you can follow a procedure in the Docker section.

The local Docker collects the correct context and clones only the needed files into a dev container instead of the entire repository, which can be quite large.

In more detail, Docker should have the correct context with all the needed files for building a docker-compose. These files can reside in different locations (folders, modules, and so on). If we clone all possible files beforehand, and collect the context on the remote machine, it would take a lot of time because repositories can be extensive. Note that we had this implementation before and users had many complains about its performance. Currently, the implementation works differently - we collect the correct context using the local Docker and clone only the needed files into the remote machine. Therefore, the local Docker CLI is required.

note

When it comes to the Docker plugin, it's important to note that running a Dockerfile and a docker-compose file doesn't work without locally installed Docker via SSH Docker connection (Image run configuration works fine). In the case of development containers via SSH, nothing functions without the local Docker installation.