Compose shell access to sibling containers

[slominskir]

Select Topic Area

Question

Body

When using codespaces with a Docker Compose file referenced in the devcontainer.json how do you access a shell on sibling containers? On a local workstation you can use "docker exec". Is there no built-in support for this? For example in order to view a log file in a database that is included in a sibling container.

Maybe docker must be installed manually in the devcontainer (docker-in-docker?) If using a project without an explicit devcontainer I noticed the default devcontainer already has docker installed and can run docker-in-docker. Is this the preferred approach?

[8b1tz]

When using codespaces with a Docker Compose file referenced in the devcontainer.json, accessing a shell on sibling containers can be achieved through a few different methods.

One approach is to use the docker exec command directly within the codespace terminal. This allows you to execute commands within a running container. For example, to access a shell in a sibling container, you could run:

docker exec -it <sibling_container_id> /bin/bash

Replace <sibling_container_id> with the ID or name of the sibling container you want to access.

Alternatively, if your Docker Compose setup includes services that you need to interact with frequently, you might consider configuring additional services directly within your devcontainer.json file. This allows you to define dependencies and configurations specific to your development environment. You can include additional Docker Compose services in the dockerComposeFile or dockerComposeFile services section of the devcontainer.json file. This approach can streamline development and provide easy access to sibling containers from within the codespace.

As for the installation of Docker within the devcontainer, it depends on your project's requirements and preferences. If your project relies heavily on Docker, installing Docker within the devcontainer (docker-in-docker) can be a viable approach. This allows you to manage and interact with containers directly within the codespace environment. However, keep in mind that running Docker within Docker introduces some complexities and potential performance overhead.

If your project does not explicitly require Docker, relying on the default devcontainer, which already has Docker installed and can run docker-in-docker, may be a convenient option. This allows you to leverage Docker capabilities without the need for manual installation or configuration. Evaluate your project's specific needs and consider the trade-offs associated with each approach to determine the best fit for your development workflow.

[slominskir]

It sounds like "no" to built-in support in codespaces interface and "yes" to you must install docker inside the dev container, though default devcontainer has it already installed. It isn't clear if it's functioning in sibling mode (bind mounted /var/run/docker.sock) or true docker-in-docker. Either way, it doesn't appear Docker fully supports this: https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/. This appears to be a major obstacle for codespaces.

Generally the whole point of dev container is to provide a pre-built image containing the specific tools to build the project, which means the default container generally isn't going to cut it. So it sounds like the onus is the dev to ensure docker is installed on their custom image. Worth mentioning using the open source "podman exec" doesn't appear to work, at least on my ubuntu devcontainer. Also, using docker/docker-cli blows up in IntelliJ, where I'm testing locally. So setting up docker-in-docker may require some fiddling, and may be environment specific (what works on github devcontainer may not work elsewhere).

[slominskir]

Seems like it may be safest to use Microsoft's own image when working with compose in codespaces so that you can use the "feature" of either:

• https://github.com/devcontainers/features/tree/main/src/docker-in-docker (docker in docker / isolated, default?)
• https://github.com/devcontainers/features/tree/main/src/docker-outside-of-docker (docker outside of docker, bind mounted /var/run/docker.sock sibling containers)

There is a lot going on under the hood that is likely tricky to re-create in your own custom image.

the devcontainer.json would look like:

 {
 "image": "mcr.microsoft.com/devcontainers/universal:2",
 "features": {
     "ghcr.io/devcontainers/features/docker-in-docker:2": {}
 }
}

[slominskir]

Since installing features at runtime is not optimal a pre-built Docker image is best. It's not immediately obvious how to navigate the devcontainer + codespaces APIs on top of the Docker APIs to accomplish this so I'm just relying on a direct Docker build. Here is an example for anyone else trying to figure this out:

https://github.com/JeffersonLab/java-devcontainer/blob/9696143e7b50aecc8a4c36062b538659dfeb8bfd/Dockerfile

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬