Run command should allow specifying ports that need to be published

[lostintangent]

The Docker: Run command that this extension adds to VS Code doesn't provide a way to specify which (if any) ports within the container should be exposed to the host. This makes it hard to use this command for many containers, and therefore, requires you to drop down to using the terminal directly. This isn't a big deal, but since the Docker: Add docker files to workspace command asks which port to expose, it would seemingly make sense for the Docker: Run command to provide a similar experience, for publishing ports at runtime.

[kr428]

+1. This is definitely missing so far.

[chrisdias]

I ran into this too, but there are potentially many questions to ask. You need to know which port to expose, which port you want it exposed on, and if there are multiple ports exposed in the image, then you have to do it multiple times. You could argue the "add files to workspace" command does not support exposing multiple ports.

As result, I didn't do this and figured the easiest thing to do as a user was use a docker-compose.yml file instead, which can do all of the port mappings for you.

That said, if there are good ideas on how to ask the questions, I'm happy to do the work.

[MicahZoltu]

As a short-term iterative step, perhaps provide a mechanism for having a VSCode setting that allows you to specify the specifics of Docker Run? This way each project can setup Docker Run to be appropriate for that project by using a .vscode/settings.json file, and the default can remain docker run <image-name>.

[lostintangent]

@MicahZoltu That's a great idea. As another potential solution, we also just merged a PR that enhances this command, so that it detects the ports that the selected image exposes, and automatically publishes them on the host machine (by adding the appropriate "-p" args to "docker run").

This behavior solves the primary scenario I had in mind when I initially opened this issue, but I'd love to get your thoughts on this and discuss any further customizations we might need to add in to enable additional scenarios/requirements.

[MicahZoltu]

Does it publish the port to a dynamic port (like -p 80) or does it publish to a matching port on the host (-p 80:80)? Both have their caveats, but both likely address the issue for the most common case as well.

One advantage of allowing for a setting that defines how docker run behaves on a per-project basis is that it allows for more than just port binding. For example, if your project needs to map environment variables (e.g., user secrets) over this could be done via project settings as well. For example, docker run -e MY_SECRET would map MY_SECRET environment variable on the host to MY_SECRET environment variable in the container and this may be required for the container to function properly.

[chrisdias]

The other way to do all of this is to just use Docker Compose Up/Down on the docker_compose.yml file where you can configure ports, environment variables, and volume mappings. It is effectively a settings file and we don't get into the situation where the extension is asking a bunch of questions.

[MicahZoltu]

docker_compose.yml will definitely solve a large set of problems. However, if I am developing a project that already uses docker-compose for something else then I'll still need a way to configure VSCode to use a different docker-compose file. This is definitely an easier UI than trying to solve for ports + environment variables + etc., but it does mean an entire file just to have 2 (port) numbers in it.

As a general rule, I try to avoid solutions that involve requiring users to put yet-another-file into the root of their project. I am currently working on a project that has 13 files in its root, none of which are actually source code, along with 5 folders full of even more files that are just project/build management. This means I currently have more files doing project/build management than I do actual source files (it is a small "toy" project). There is already a .vscode folder, so I would prefer to keep anything necessary to get VSCode to work constrained to that folder. Perhaps a docker-compose.yml in that folder would be "first choice" when running docker-compose up?

[chrisdias]

You could put a compose file in the .vscode folder and when you run the Docker Compose Up/Down commands you'll see that file as an option for which compose file to use. It seems that this would be better than adding settings in the extension that mirror what is in a compose file.

Maybe it would make sense to have a setting that is something like defaultComposeFile and if that is present, we don't list all the compose files in the workspace, we just Up/Down that one. One less prompt is always goodness. Thoughts?

[MicahZoltu]

Is everyone with Docker guaranteed to have docker-compose? I know it has always come with the installs I have done, but I don't know if that is always the case?

Can you (in one command) do an interactive docker-compose? docker build ... && docker run --rm -it ... is (for some projects) the way I use docker, can that be reproduced with docker-compose?

I would say the defaultComposeFile would be default selection, but you should still be able to pick? Perhaps a second setting for alwaysUseDefaultComposeFile that if true would skip the prompt entirely? If you just had the latter setting it would skip the prompt and always use whatever the system default was (presumably the one in root)?

[chrisdias]

From the Docker docs:

Docker for Mac, Docker for Windows, and Docker Toolbox include Docker Compose, so most Mac and Windows users do not need to install Docker Compose separately.

So it looks like compose is not on Linux by default.

[DanWahlin]

Ran into this today as well. For scenarios where we need to start a single container (before using compose for example), it'd definitely be nice to have a prompt come up where we could specify the external:internal port.

I'm normally using compose especially when multiple containers are involved, but when I'm initially trying out a custom image it'd be great to be able to specify the port when using the extension. Of course....I can always type it. :-)

[PrashanthCorp]

@DanWahlin Are you still running into this issue?

[DanWahlin]

Yeah - it looks like it. For example, if I right-click on nginx and select the Run option it defaults to 80:80 for the ports. I'm not seeing any prompt so there's no way to override the external:internal ports it uses without typing out the docker run command -p command.

[bwateratmsft]

Since this is covered by #1321 I'm going to resolve this as a dupe of that one.