GoLand 2024.1 Help

FAQ about Dev Containers

I see various volumes and properties in Docker after I created a dev container. What does each of them do?

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).

How do I add more log information when creating a dev container?

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

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

How do I understand that my SSH connection was successful for creating a remote dev container using -ssh git clone?

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

Why is the alpine/git image pulled during dev container creation?

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.

Why don't you use the Create Dev Container and Mount Sources option for the SSH Docker connections?

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

Is it possible to create a Dev Container inside an open remote project?

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.

Why do I need to have Docker installed locally to create a dev container remotely by SSH?

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.

Last modified: 17 April 2024