Tell us about your request
There are many situations, but most especially CI test runners, where Docker Desktop needs to be installed unattended. With current versions, that's either impossible or very, very sketchy.
It used to be possible on macOS using the technique in https://github.com/docker/for-mac/issues/2359, but as explained in https://github.com/docker/for-mac/issues/2359#issuecomment-516945781 it was somewhat randomly blocked by an error check on root installs in 2.1.0.0
Which service(s) is this request for?
Docker Desktop for Mac and Docker Desktop for WIndows. macOS is the place I would immediately use it.
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
As above, in a CI environment Docker Desktop needs to be installed... by a script.
Are you currently working around the issue?
Currently using pre-2.1.0.0 version of Docker Desktop for Mac
Additional context
While I'd prefer a great solution (explicit, supported unattended install technique), I'm modestly sure that you could just remove the blocker error check, "Running Docker Desktop as root is dangerous. Please run it as a regular user"
+1 to this feature request, many times over. The lack of an automated install is a serious pain point for using Docker as part of a CI pipeline. This issue should also be fairly easy for the Docker team to fix, while at the same time being basically impossible to work around in a robust way from the outside. As I said in the older issue thread:
Here's a way to get a working copy of the latest Docker Desktop app for Mac installed from the command line:
#!/usr/bin/env bash # refs: # https://github.com/MicrosoftDocs/vsts-docs/issues/3784 # https://forums.docker.com/t/docker-for-mac-unattended-installation/27112 brew cask install docker # allow the app to run without confirmation xattr -d -r com.apple.quarantine /Applications/Docker.app # preemptively do docker.app's setup to avoid any gui prompts sudo /bin/cp /Applications/Docker.app/Contents/Library/LaunchServices/com.docker.vmnetd /Library/PrivilegedHelperTools sudo /bin/cp /Applications/Docker.app/Contents/Resources/com.docker.vmnetd.plist /Library/LaunchDaemons/ sudo /bin/chmod 544 /Library/PrivilegedHelperTools/com.docker.vmnetd sudo /bin/chmod 644 /Library/LaunchDaemons/com.docker.vmnetd.plist sudo /bin/launchctl load /Library/LaunchDaemons/com.docker.vmnetd.plistand then you can run the app and wait for it to install/set up with this script:
#!/usr/bin/env bash # refs: # https://stackoverflow.com/a/35979292/425458 [[ $(uname) == 'Darwin' ]] || { echo "This function only runs on macOS." >&2; exit 2; } echo "-- Starting Docker.app, if necessary..." open -g -a Docker.app || exit # Wait for the server to start up, if applicable. i=0 while ! docker system info &>/dev/null; do (( i++ == 0 )) && printf %s '-- Waiting for Docker to finish starting up...' || printf '.' sleep 1 done (( i )) && printf '\n' echo "-- Docker is ready."This is what I needed to do in order to get Docker running during my Mac CI tests (on Azure Pipelines).
My install hack above is completely ridiculous, and there should be a better way. The old way with the cute command line arguments:
/Applications/Docker.app/Contents/MacOS/Docker --quit-after-install --unattendedwas so, so much better. Can we please get this back?
You now need a slightly updated version of the above filthy hack in order to successfully install the very latest docker desktop for mac: https://github.com/docker/for-mac/issues/2359#issuecomment-853420567
After updating docker to version 3.4.0, the command open -g -a Docker.app began to request privileged access: Docker Desktop needs privileged access to install its networking components and links to the Docker apps.
@telamonian, did you find a way to get around this?
Most helpful comment
+1 to this feature request, many times over. The lack of an automated install is a serious pain point for using Docker as part of a CI pipeline. This issue should also be fairly easy for the Docker team to fix, while at the same time being basically impossible to work around in a robust way from the outside. As I said in the older issue thread: