Can no longer start docker desktop from a remote powershell session

Docker Desktop
,
1

We have implemented AzureDevOps testing pipelines that test the deployment of our software, including the deployment of development environments. This is executed on an Azure VM using a remote powershell session.

On our previously installed version of Docker Desktop, 4.22, I was able able to start docker desktop on a remote powershell session by simply running the Docker Desktop executable and wait for it to startup.

We have now upgraded to version 4.37 and it no longer works correctly. The docker processes are starting, but attempts to query docker locks up.

For example, if you wait a few minutes and enter:

docker info

to get information on the status of docker, that command seems to lock up indefinitely. I had a test pipeline waiting for an hour until the pipeline locked up. I have replicated on a remote powershell session.

In version 4.37 I was excited to note the addition of new beta docker commands to automate the start/stop of docker desktop documented here:

However their is a note on “docker dekstop start” command that SSH is not supported. Its unclear if similar issues apply to winrm.

The docker desktop cli commands can act inconsistent when it gets in this strange state. “docker desktop status” will say docker is stopped. But complain that its already running if you use “docker desktop start” to start it. A bunch of docker processses are running.

You can login to a windows normally, run "docker desktop start " in that session, and use the docker info succesfully in a remote powershell session (effectively a seperate login to the same account)

With the addition of the new beta docker desktop cli commands its unclear if this is a supported use case or not. I can see it being yes or no. I’m trying to work out the appropiate strategy. Wait for the issue to get fixed, assuming it is one, or try to find an alternative.

A lot of ground. Any thoughts?

5

I see you also created an issue on GitHub

It was a good idea, but it seems you don’t have replies yet.

Unfortunately I can’t really answer, but I if it is for a pipeline, do you really need a desktop that was made for development?

You also mentioned WSL on GitHub, but it is not clear what you actually use it for. If you have WSL2, that can only run Linux contaiers, but then why using a Windows host? You could run a Linux VM without Windows and use Docker CE or at least install Docker CE in a WSL distribution.

You also mentioned an Ubuntu distro on GitHub and that you installed Docker Desktop on it. Did you really install Docker Desktop on a WSL2 linux distribution or installed it on Windows using the WSL2 backend? If you just used the WSL2 backend, why do you mention the Ubuntu distribution?

If you used WSL integration in Docker Desktop (installed on Windows) I heard that these beta commands didn’t work from the WSL2 distribution (I don’t know if it was a bug or just how it was implemented), but I’m really not sure why would that be necessary when it can be executed on the host. Normal Docker commands work from a WSL2 distribution, but first you need to start Docker Desktop and docker desktop start would start that.

6

Thank you for your reply.

To set the context we have a software platform with around 30 microservices spread across more code repos than I can count! We develop on windows using a varieity of platforms including Service Fabric, Azure and Kubernetes. All new work is on docker and we are moving our services across but its a multi-year process.

We are specifically talking about our development environments.Themselves very large and non-trivial and a involve a great deal of code just to set them up. When it got up to a man month to setup a dev environment we started automating it. And they are Waayyyy more complicated now.

Docker desktop is hosted on Windows because we develop on windows and it seemed the obvious at the time.The pipelines are specifically testing the creation of a development environment, not the deployment of a production system.

We use WSL2 to run our services in Linux on our development environment. Those docker services are part of a much larger environment using a wide variety of tooling.

To be clear on the docker parts of the development environment:

  • Install WSL2 + Ubuntu distro
  • Install docker desktop on windows
  • Set docker desktop to run docker services on WSL2.

Ah I confirmed that the “docker desktop start” commands work with everything installed in the above configuration if you log into a desktop as a user normally. They don’t work if you log into an WINRM session using the same user.

The scripts all work perfectly if I login to a desktop and run them from a conventional powershell session.They don’t work if I use a remote powershell session using the same user due to the issue reported.

7

Sorry, I had too many things recently, but I’m back for now.

You mean Docker Desktop is deployed automatically and the pipeline also tests if it was installed correctly?

It would indeed be great if you could start Docker Desktop remotely in that case. If the docker desktop start feature was made for people who want to run scripts locally, being able to run it through SSH or WinRM was probably not that important. Unfortunately I can’t tell you why it doesn’t work as I rarely even turn my Windows laptop on, but you should probably share your use case on GitHub

If they say it is not a bug, but it is just not supported, then if it is possible to implement it, it could be added to the Roadmap

8

Again thanks for your reply rimelek.

More the pipelines test the deployment and tear down of services onto docker desktop. Along with a lot more stuff. Because the intent is for a development environment we want to test it as close as possible.

Ah I’ve noticed that docker desktop pops up a new security based, once off warning dialogs when you start deploying services. So it might be blocked because of that dialog.

I’ve put up a bug, bit its still in triage. someone else has run into the same issue. Whether its a supported use-case, feature still in Beta, or not supported is an interesting question.