Open folder in container starts all compose services

[mattschutt]

First, thanks for all these updates. Great stuff!

Details: OS: Windows 10 1809 VSCode: 1.34.0-insider

While working with the new updates and trying to integrate it into my existing compose file, it seems like running the 'Open folder in container' command starts all docker-compose services and I don't see where it's using the service name I provide in the .devcontainer/devcontainer.json.

My docker compose file has 3 services, develop, debug, and lint.

Here is the .devcontainer/devcontainer.json file I'm currently working with:

{
    "name": "test",
    "dockerComposeFile": "../docker-compose.yml",
    "service": "develop",
    "workspaceFolder": "/home/app",
    "shutdownAction": "stopCompose",
    "extensions": []
}

When I attempt to open the folder in the container, I get a popup error about ports being used that are already bound:

When checking out the console, I see the command it was attempting to run:

Run: docker-compose --project-name test -f c:\Dev\test\docker-compose.yml up -d

I can see it attempting to start all the services:

Starting test_develop_1 ... done
Starting test_debug_1   ... error
Starting test_lint_1    ... done

Debug is failing because it's binding to ports already bound in the develop service. I was expecting it to just start the develop service since that was what I had defined in the devcontainer.json file.

Am I missing something?

Thanks

[Chuxel]

@mcmatthew Transferred this to the vscode-remote-release repository since this is about the product's behavior rather than a specific dev container definition.

Thanks for your question! Here's the situation:

• Right now the service in devcontainer.json tells VS Code which container to attach to rather than what to spin up.
• If VS Code detects that the container is already running, it connects to it.
• If it is not started, docker-compose up is run since developers typically want a set of related containers spun up from what we have seen.

So, if you just want that container, you can actually start it from the command line and open VS Code and it will connect.

Would that meet your need? What is your workflow like here? Depending on what you need to do, I could see a feature request here, but would be great to understand the workflow so we can make sure we've got it accommodated well.

[mattschutt]

@Chuxel Just for my own clarification, the "service" key in the devcontainer.json file is only utilized to grab what container is utilized for the service? If so, I think that could be called out more specifically in the documentation. With that understanding, I could see that at least meeting my own needs by launching and attaching separately.

However, it is my opinion that your 3rd bullet:

If it is not started, docker-compose up is run since developers typically want a set of related containers spun up from what we have seen

might be more appropriate if it was this:

If it is not started, docker-compose up "service" is run. If developers want to utilize multiple services in their development environment, they can utilize docker-compose's depends_on.

Personally, I have not ever used a blank docker-compose up without specifying a service. I always tend to have multiple development services.

The use case I'm presenting is a cross-ecosystem developer (OS X and Windows, specifically). The more I learn and utilize Docker and docker-compose it has become a key role in creating a cross-system development environment. VSCode and it's project-specific settings and capabilities has greatly improved that experience.

I was excited by the new changes because it seemed like I could just fire up the IDE and it would start my service and boom everything is up and going which saves some clicks and I would now have all of my extensions running inside the container which gets me linting (finally!) in the IDE. I couldn't get rubocop to run without creating the lint service prior (or frankly any other linter required local dependencies that I don't want to manage separately)

I was already utilizing docker-compose to start the service, open ports, connect debuggers, etc. This new vscode-remote feature really just integrates that more into the IDE, which is great!

[Chuxel]

Just for my own clarification, the "service" key in the devcontainer.json file is only utilized to grab what container is utilized for the service? If so, I think that could be called out more specifically in the documentation. With that understanding, I could see that at least meeting my own needs by launching and attaching separately.

Correct. That's good feedback - I can take the to-do to make that clearer.

might be more appropriate if it was this:

If it is not started, docker-compose up "service" is run.

Yeah given your description of your workflow, that makes total sense. Specifying the service should also bring up any linked containers... just not others in the yml file.

@chrmarti Anything jump to mind that passing the service from devcontainer.json to docker-compose up would cause issues for? Seems like a worthy addition as an option - I think the question would be which is the default.

[chrmarti]

Not sure what the best default would be, our assumption so far was that you usually want to work with the entire set of containers.

[mattschutt]

As someone who is doing more and more on Windows due to working with teams that come from win32 development and have Windows devices and are adopting more and more linux based development, we utilize docker-compose services to perform a lot of the duties that are normally run locally on devices. Ultimately it comes down to moving away from requiring local dependencies and putting all production and development dependencies inside the container and utilize those from the IDE.

Think about a Rails application -- I'd have a service to start it up in development, non-prod, prod. I'd have a service to run a debugger (this could be the same as the dev service, I guess). Then there's services to run commands: bundle, db:migrate, lint (hopefully this is now in the IDE as previously mentioned), spec, etc, etc etc.

I do not claim to understand everyone's use case, but to me, a default 'docker-compose up' and spinning up all these services doesn't make much sense.

Just my two cents. :) Thanks for listening, though.

[lbssousa]

As I've mentioned in https://github.com/microsoft/vscode/issues/73997, for Laradock-based projects, you do need to specify which services to start up with docker-compose (e.g. docker-compose up -d nginx postgres), so it would be very valuable for this use case if I can specify in devcontainer.json which services should be started with docker-compose up.

[ManfredLange]

As I've mentioned in microsoft/vscode#73997, for Laradock-based projects, you do need to specify which services to start up with docker-compose (e.g. docker-compose up -d nginx postgres), so it would be very valuable for this use case if I can specify in devcontainer.json which services should be started with docker-compose up.

Yes, the same way as we can specify multiple docker-compose files in an array, it'd be great if there was an option in devcontainer.json to specify which services to run up in addition and separately to specifying which container to connect to.

[marco-m]

Hello, an alternative approach would be:

1. leave the current behavior as-is: start everything by default, "service" is the service to connect to
2. support also for docker-compose the existing attribute "runargs", to be passed to docker-compose

For example,

    "runargs": ["foo"],

would call docker-compose foo, and foo would be the service to start.

Note that runargs supports a list, which is needed to allow to start more than one service but not all of them:

    "runargs": ["foo", "bar"],

would start services foo and bar.

[chrmarti]

We could use "upArgs", but that wouldn't allow us to simply stop the same services on shutdown.

We could add a "runServices" (trying to avoid being as unspecific as the existing "service") property listing the services that should be started initially and stopped on shutdown. All being the default when this property is not set.

[marco-m]

@chrmarti thanks! I had a a look at https://github.com/microsoft/vscode/commit/00d53e96861523c96789c5242ffe78101acfe1fb. What I am missing is this: that commit only adds to a JSON configuration file. Where is that configuration change picked up in the code? Thanks

[chrmarti]

@marco-m The actual code is not open source, so there is a second commit implementing the new option. (See our FAQ for the details on the license.)

[marco-m]

@chrmarti ahhh! That's explain it :-) Thanks!