Arbitrary command line options in the optional settings of image RUN dialog window

[ktzsolt]

Tell us about your request It would be nice to be able to add arbitrary command line options in the optional settings when clicking the image RUN button, currently only --name, -p, -v are supported.

Arguments could be passed in key/value pairs: key: --entrypoint value: /bin/bash key: --cpus value: 2 etc

One could add any options with a + icon. Option sets could be saved for later usage.

Which service(s) is this request for? Docker Desktop (for Windows)

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? ENTRYPOINT and CMD would be the most important option to set, so one could override it to /bin/bash to get into the container for debugging, that is I do a lot of times from CLI.

Are you currently working around the issue? Yes, using the CLI

Additional context

[ktzsolt]

I see in 4.15.0 (93002) there is support for adding environment variables, that is good start. If arbitrary command line options is not doable as in my first comment or if it would be to vague for the end user then you could just have a block for all the command line options so besides container name, ports, volumes, environment variables there could be a block for entrypoint, cmd, network and so on.

[stephanierifai]

Thanks for the feedback @ktzsolt, and glad environment variables is a good start for you. Are you looking to be able to run any run command the same way you run in the cli? Would something like this mockup help you or are you looking for something else?

Feel free to drop me a line at steph.rifai@docker.com if you want to discuss more!

[ktzsolt]

Hi @stephanierifai !

Not really what I was thinking of. This wouldn't help too much, I could just write the same command in the command line so the DD UI would not be helpful.

What I would like to have is the ability to set ENTRYPOINT and CMD in the optional settings at least thus overriding the setting that is in the image.

This would be helpful to debug images/containers with overwriting the entrypont/cmd to not start the actual service that is in the image and is failing and crashing the container but to start something different, for example a tail -f /dev/null would start the container and make it run indefinitely but not doing anything, not crashing so one could exec into it to get a terminal and start debugging.

See this picture:

Also other optional docker run parameters would be helpful, for example to set the cpu count etc, but entrypoint/cmd would be the most useful, so I could use the Docker Desktop UI to easily start a image/container for debugging like I described.

[davidknaack]

@stephanierifai @nunocoracao If I may, I'd like to add to this as it is a problem I also have with Docker Desktop.

When I run an image I always add various arguments. I need to document these options somewhere for when I need to reference them or start the container(s) again.

Currently I do this by creating a bash script with either the run or docker-compose command I am using (and usually some comments describing what it's for and why I configured it the way I did). I store that script file (maybe and docker-compose manifest) in a directory (which is also a git repo) with a bunch of other files containing the commands needed to launch my various containers. The data associated with the container (running or stopped) in docker isn't sufficient, IMO, because it is harder to access and more volatile (if I prune unused stuff I can lose information that I don't have stored elsewhere).

What I want from Docker Desktop is a way to handle those commands in a more 'first class entity' kind of way. Right now in the Docker Desktop UI I can go to a container, click the ellipses button and 'copy run command', then paste it somewhere to view/edit the values, but I can't easily use them in Docker Desktop. When I do want to use them to start a container, the inputs are hidden in the 'Optional' section of the 'Run' dialog, which appears to only support a few common option, and provides no input for arbitrary options.

I feel like the UI needs a launcher tab where I can keep run commands, and (or maybe just) docker-compose files where I can launch containers and see associated containers (if you are familiar with Terraform, something a bit like the terraform state file, some stored info that gives me the value of the run command or docker-compose at the time the container was launched, and the id of the container if it is still around). In the images list I'd rather have an 'add launcher' (or whatever) button instead of the 'Run' button, because I never want to just run an image, I always want to add some persistent configuration and some notes about what the container is for.

[ktzsolt]

Hi @davidknaack !

I think what you described is gitops and state/drift management for Docker Desktop that I think is an order of magnitude bigger work than just adding ability to add arbitrary command line arguments to the UI start container section (or at least ability to override ENTRYPOINT and CMD).

Also I think DD is for local development only, to run containers by the developer on the developer's local machine (laptop/desktop) so this gitops-like feature would be overkill. Containers on the local dev machine should be 100% expendable and ephemeral. You just store the docker-compose.yaml in git and rebuild/start your project fresh from it every day. There is already a feature rich VSCode extension (by Microsoft) for managing docker-compose and other stuff on your docker installation, you might want to check it out: https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-docker

But this is just my opinionated opinion :)

[davidknaack]

@ktzsolt Hi!

You may be reading too much into my comparison to TF state. What I was trying to describe is just a simple way to link a run command to an existing container, and maybe a bit of context about how it was started. No devops-y flavor, that's way too much.

I don't know what Docker Desktop wants to be, or how others use it, but for my use cases the rudimentary image run capability is unnecessarily limiting and the tool would benefit from providing some kind of memory for the run arguments the user has specified.

Many of my (local household network) containers are not ephemeral, they run most of the time (my media server and local gitlab instance for example), and it would be nice if I could manage them more completely with a relatively simple tool like DD instead of either the command line or a large-scale devops tool.

To be clear I'm not really asking for anything here, I just wanted to add a bit of user context that might be useful to consider if/when someone enhances the existing run command interface. I'm adding the features I want with my own extension.

[robross0606]

I am constantly frustrated that I need to use the command line to run a container if I want to change the entrypoint to gain shell access. This is a common pattern (at least for me) if I need to explore a container from a shell, debug an issue or even see if a command exists in a baseline container. Docker Desktop offers direct terminal access to the running container, but no way right now to launch a container with an alternate entrpoint like "/bin/sh" if that isn't the default entrypoint. Very frustrating and seems like low-hanging fruit to add to the Run dialog.