Multiple container support for multi root workspaces

[mtsmfm]

ref: #387

Currently, multi root workspaces with remote container just allows us to open via single container.
I'd like to propose support to open container per directory.

Let's say we have a monorepo which has backend API and frontend.

monorepo/
  monorepo.code-workspace
  backend/
    .devcontainer/
      Dockerfile
      devcontainer.json
      docker-compose.yml
  frontend/
    .devcontainer/
      Dockerfile
      devcontainer.json
      docker-compose.yml

monorepo.code-workspace is like the following:

{
  "folders": [
    {
      "path": "backend"
    },
    {
      "path": "frontend"
    }
  ]
}

And when we run Open Workspace in Container, both backend container and frontend container start as defined in backend/devcontainer.json and frontend/devcontainer.json individually.

[egamma]

// fyi @Chuxel @chrmarti

[J3m5]

Any news on this feature, please?

[alegnicitrix]

I think I have another use case for this feature request. For example, I would like to have a repo which contains cross-platform code (e.g. code that is built for 3 major platforms: Windows, Linux, Mac). If a developer syncs the code on a Mac machine, it would allow building on the Mac container. If he/she syncs on a Windows machine, then it would allow building on the Windows container.. and so on.

clientrepo/
  client.code-workspace
  build-windows/
    .devcontainer/
      Dockerfile
      devcontainer.json
      docker-compose.yml
  build-linux/
    .devcontainer/
      Dockerfile
      devcontainer.json
      docker-compose.yml
  build-mac/
    .devcontainer/
      Dockerfile
      devcontainer.json
      docker-compose.yml
  src

This would also require support for Windows and Mac containers:
#445

[XBeg9]

The opensource community is moving into monorepo style for the last couple of years already, currently don't see any way to use this. How can you use VSCode Remote Code Development due to use cases described below?
if we have 20 microservices in monorepo, we can't run 20 VSCode windows (+ frontend). You should have this as a must-have feature before public release.

Thanks

[Chuxel]

@XBeg9 It's important to separate general use cases with mono repos from this specific request. Certainly monorepos are popular in certain OSS circles, but that should not be blocked by this in most cases. So, let's get a better understanding of what you are trying to do to make sure there isn't another feature request beyond this one.

To be clear, when cloned locally, you can absolutely have sub-folders in a monorepo that you open in a container and these folders can depend on other things in the broader source tree. (Even if you just use a Dockerfile, the entire git repository is mounted by default. The specific request here is to have support for creating a .code-workspace where you are working with multiple containers concurrently in the same VS Code UI instance.) You can also open a VS Code window as you need to a different container started up using the same docker-compose.yml file. See here.

In your example, would an individual developer be running 21 containers locally at once and would want to connect to all of them at the exact same time from a single VS Code window?

Remote - Containers is also released, are you referring to Codespaces?

[XBeg9]

@Chuxel thanks for the detailed answer. Yea, probably I mess around with Codespaces and Remote - Containers (release status).

The specific request here is to have support for creating a .code-workspace where you are working with multiple containers concurrently in the same VS Code UI instance.

That's exactly what I referring to, is there a way to run single VSCode UI with multiple devcontainers?
We don't need to run all 20 at once, but I want to have a debugger connected to as many as I want on the same VSCode UI instance. In monorepo, we are sharing lots of core/module packages with backend and frontend services.

[XBeg9]

@Chuxel I've seen that documentation and got so confused, in a title it says Connecting to multiple containers at once, but then in the To connect to both it requires me to open multiple windows.
If we are talking about working in monorepo style, so I am edition some core or shared modules, used by multiple services containers, should I go across multiple windows to validate my changes?

[Chuxel]

I've seen that documentation and got so confused, in a title it says Connecting to multiple containers at once, but then in the To connect to both it requires me to open multiple windows. If we are talking about working in monorepo style, so I am edition some core or shared modules, used by multiple services containers, should I go across multiple windows to validate my changes?

@XBeg9 This is referring to how one would spin up multiple Docker Compose managed containers that need to run at the same time for the application to work and develop each of them concurrently.

To recap what is possible in Remote - Containers, you can spin up a bunch of containers using the same docker-compose.yml and open individual ones with unique devcontainer.json contents (E.g. extensions) in separate VS Code windows. You can do this whenever you need to work with a given container in the set, not just right away. That's what is described in the link above. You can even have scenario specific docker-compose.yml files if needed - just use a different starting folders for the first thing you open.

Unfortunately, Codespaces does have some limitations around monorepos currently that prevent it from doing this, but that team knows about the issue. So, if you were trying it there, you're totally right that there's not way to do it yet (which is why I'd asked given your description). That is tracked here if you want to upvote / comment there: https://github.com/MicrosoftDocs/vscodespaces/issues/206

Now, shared libraries / modules is an interesting use case for Remote - Containers. There's a couple things here:

1. If all you need to do is run tests, you can actually spin up brand-new containers from inside the dev container using the docker-from-docker pattern. The dev container is where you write your code, but it does not have to be where it is running or deployed.
2. You can use a .code-workspace file within the same container without issue. So, if the toolchain for "shared" and each service is the same, you can create a workspace per service that includes both. (Or one big container for that matter.)

Otherwise, yes, you'd be running separate windows if neither of these two apply or would work.

[kshitijcode]

I wrote an article that might help us with multi-container and multi-root workspaces debugging simultaneously in a single VSCode Window: https://ikshitijsharma.medium.com/seamless-multi-container-multi-root-workspaces-debugging-in-vscode-devcontainers-on-steroid-54d7cff4ff77

[PavelSosin-320]

@kshitijcode I'm totally in favor of the idea. But, why I need something in addition to systemd? I need systemd to configure networks, run containers , for deployment and maintenance. The recent shift is the replacement init with systemd in OCI containers. Systemd faithfully serves me even in WSL.
OK, Microsoft is against systemd but the most popular Linux distros are installed today with systemd. It includes BalenaOS for routers, TVsets, and vacuum cleaners.

[luncht1me]

+1
Was just chatting with a friend comparing our wsl setups and this would be a nice feature for isolated dev environments within wsl.
If you could open a workspace but have multiple containers within it, it would be pretty nice for monorepo-style orchestration between containers without having to open multiple windows etc, or have an entire extra container that opens it's own containers within it to avoid too much layering.

[mikekberg]

+1 would be a very handy feature for web apps that typically have a frontend and backend dev container

[ddahan]

+1
I'm building apps with front/ and back/ and currently, my workaround is to have a single VS Code window, and use a single container which handles both the front-end (node) and back-end (python).
What I don't like about this:

• I'm using a Python official Docker image then install node by hand (a little clunky compared to use both official images)
• the devcontainer.json mixes up both Python and node config at the same place. It decreases readability.
• As soon as I need to rebuild the container, it takes more time.

[rivaros]

@Chuxel pls advise was anything done on this request since last time.

Having a multi-root workspace with following structure:

(WORKSPACE)
   project/
      .devcontainer/
   documentation/
   scripts/
   my.code-workspace <just workspace, not part of project>

why it's not possible just to right-click on project and select Dev Containers - Reopen In Container

VSCode only allows a single-folder layout when searching for .devcontainer subfolder.

I need to do curious tricks by putting my.code-workspace file into project folder and adding other folders through ../, which only brings additional warnings

p.s.: i know about https://code.visualstudio.com/remote/advancedcontainers/connect-multiple-containers and
"Run Dev Containers: Open Folder in Container..." but that does not resolve the issue.

Firstly you have to run "Run Dev Containers: Open Folder in Container..." (which opens a system file dialog to select a folder again), after that when Container View opens you can switch back only to folder view (all your workspace layout is lost)

[joehacksalot]

My team and I are finding ourselves needing support for multiple dev containers in a single project as well. I would also be very interested in progress made here.

To share our use case, our project's default devcontainer uses a docker compose file to bring up a set of support containers that serve as interfaces in place of the real services. We have a second docker compose that brings up a smaller subset, defined different url envs and whose networks are set to host mode. This second environment allows the container to run its tests against real systems that are available from this host (ie physically connected or accessible via tailscale subnet routers). Since there is no support for multiple containers, we need to manually change the compose file name being used when in the second scenario.

Earlier today, I forgot to change the file and it launched the default compose file on the host in the second environment which spun up a docker network with the same subnet as the host's main network interface and dropped the box off the internet until someone could get on the machine to remove the docker network.

[MoJo2600]

I'd like to share our current setup, which works reasonably well with multiple containers. Our application is a web application with a nodejs front and backend set up in a mono repo.

We set up a compose file in the root of our workspace. The compose file contains 3 services, the frontend, the backend and a postgres server with a testing database. The devcontainer.json references to the service in the compose file. When I do open the backend folder in vscode, it recognizes the 'devontainer' and asks if i want to reopen VScode in the container. If I say yes, VSCode will spin up the compose stack including the frontend as well. I can then open a second VSCode windows to attach to the (already running) frontend container. I can then start my backend in one window and the frontend in the other.
Under windows i then have also a shortcut to the devcontainer folder in my task bar. Even if the compose stack is not running, clicking the icon will spin up everything for me.