Command-line Arguments for /Applications/Docker.app/Contents/MacOS/Docker

[rfay]

Expected behavior

Docker for Mac 18.09.* [edit 2019-02-03]

Could you please let me know the allowed command-line arguments for /Applications/Docker.app/Contents/MacOS/Docker? I know that these sort-of work:

/Applications/Docker.app/Contents/MacOS/Docker --unattended
/Applications/Docker.app/Contents/MacOS/Docker --quit-after-install --unattended

but only because I happened to find a reference to them in #882 (comment)

Currently I can sudo run /Applications/Docker.app/Contents/MacOS/Docker --unattended
in a headless environment, but only with sudo, and really want to know how to do it to set up docker for a normal user. (For testing on CircleCI)

Actual behavior

Information

• Full output of the diagnostics from "Diagnose & Feedback" in the menu
• A reproducible case if this is a bug, Dockerfiles FTW
• Page URL if this is a docs issue or the name of a man page

Steps to reproduce the behavior

1. ...
2. ...

[docker-robott]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

[GabLeRoux]

I just learned about the --unattended parameter a bit like you and was curious if I could run Docker for mac on Travis, but that's not possible due to Incompatible CPU:

+brew cask install docker
==> Satisfying dependencies
==> Downloading https://download.docker.com/mac/stable/23751/Docker.dmg
==> Verifying checksum for Cask docker
==> Installing Cask docker
==> Moving App 'Docker.app' to '/Applications/Docker.app'.
🍺  docker was successfully installed!
+docker system info
+sudo /Applications/Docker.app/Contents/MacOS/Docker --unattended
+sleep 1
Settings: >>> New settings saved <<<
Settings: linuxDaemonConfigCreationDate : 2018-07-26 15:40:23 +0000
Settings: <<< New settings saved >>>
CrashReport: stderr redirected to /var/root/Library/Group Containers/group.com.docker/DockerAppStderr.txt
FeaturesStateLoader: featuresState saved
AppDelegate: Application version: 18.03.0-ce-mac60 (23751)
AppDelegate: Channel: stable
AppDelegate: Administrator user: true
OSX Version: Version 10.13.3 (Build 17D47)
Terminator: Incompatible CPU detected.
We are sorry, but your hardware is incompatible with Docker for Mac.
Docker requires a processor with virtualization capabilities and hypervisor support.
To learn more about this issue see:
[https://docs.docker.com/docker-for-mac/troubleshoot](https://docs.docker.com/docker-for-mac/troubleshoot/#incompatible-cpu-detected)

[rfay]

/remove-lifecycle stale

[rfay]

/lifecycle frozen

[rfay]

For the basic question of "How to install docker-for-mac from the command line" this currently works:

brew cask install docker
sudo /Applications/Docker.app/Contents/MacOS/Docker --quit-after-install --unattended
nohup /Applications/Docker.app/Contents/MacOS/Docker --unattended &

https://github.com/drud/ddev/blob/fe1b8ddbfeb322e4966b31c5654362f6a0b022be/.circleci/macos_circle_vm_setup.sh#L11-L13

[rfay]

Unfortunately, this ceases working in Docker Desktop for Mac 2.1.0.0 (docker v19.03.1). Now you get the error message:

DockerApplication: Docker.app starting for root
Terminator: Running Docker Desktop as root is dangerous. Please run it as a regular user.

Which breaks our CI :( For now, I can download earlier version, but Docker folk... please tell us how to do an unattended installation!

[rfay]

/remove-lifecycle frozen

[rfay]

/iifecycle frozen

[apolishch]

Any plans to get this addressed? I'm still being hit with this in CI

[msmoljan]

Fixing this would be extremely helpful for our CI workflow too.

Currently I'm using this workaround from @rfay as a temporary fix:
https://github.com/drud/ddev/pull/1748/files#diff-19288f650af2dabdf1dcc5b354d1f245

[docker-robott]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

[cweagans]

/remove-lifecycle stale

[cweagans]

/lifecycle frozen

[rfay]

Thanks for fixing that @cweagans - Would love to hear from the docker team on this simple issue, thanks! https://twitter.com/randyfay/status/1230757005792432128

[FranDepascuali]

I wrote about setting up docker headless in this post, it may be of help:
https://deep-thought.netlify.com/posts/using-docker-fastlane

[telamonian]

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.plist

and 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 --unattended

was so, so much better. Can we please get this back?

[telamonian]

I think a lot of people need this in order to get their CI test suites to pass. The use case is for when you need to run a docker that exposes a service (such as a local S3 server) to the test code.

@satrapu seems to have also gone through similar issues with docker+mac+azure. Some useful info:

https://crossprogramming.com/2019/12/27/use-docker-when-running-integration-tests-with-azure-pipelines.html#self-managed-docker-containers
https://github.com/satrapu/aspnet-core-logging/blob/8176a9569da56934f83e01b37648d58300198d1e/Build/start-docker-on-macOS.sh

[armenzg]

@myitcv Use 61 instead of 59. It seems that the dynamically generated com.docker.vmnetd.plist changes overtime. (In reference to @telamonian code snippet in here)

Anyone know where that 61 comes from?
Or anyone know how to brew install --cask docker with a specific version? (By doing so, I can stick to a specific Docker version and hopefully the plist does not change).

-	<string>59</string>
+ 	<string>61</string>

[jasoncodes]

It looks like you can get the vmnetd version number from Contents/Info.plist:

$ defaults read /Applications/Docker.app/Contents/Info.plist VmnetdVersion
61

[armenzg]

You would think they have some intention of fixing this.
I think I'm throwing the towel and I'm going to find some other alternative to running containers on Docker.

This is the latest UI prompt and I don't know how to bypass it:

[MaceWindu]

oh well, we already disabled our macos pipelines due to unbearable slowlyness. Probably it is time to remove them completely and just forget about them

[gwynne]

The following script seems to work on a macos-11 runner:

brew install --cask docker
sudo /Applications/Docker.app/Contents/MacOS/Docker --unattended --install-privileged-components
open -a /Applications/Docker.app --args --unattended --accept-license
while ! /Applications/Docker.app/Contents/Resources/bin/docker info &>/dev/null; do sleep 1; done

No manual copying of Docker's resources or plist hackery needed; Homebrew even takes care of the quarantine xattr automatically now. As far as I can tell, --install-privileged-components and --accept-license were added to support exactly this kind of automation (though some documentation thereof would be really great). It took almost 10 minutes to run, but that's the only caveat.

(Note: The Docker version installed by Homebrew was 4.1.0,69386)

[armenzg]

I've verified that @gwynne 's fix works on Github's macos-11 runners.

[knksmith57]

@gwynne's work around is awesome and we can confirm it is working for us on macOS 11.16.1 w/ Docker Desktop 4.1.0 🚀 (huge thanks for that! 🙏 )

note: after a system reboot, the license accept didn't "stick" and the re-launched Docker.app prompted for license acceptance. I'm guessing if one always opened Docker.app with the --unattended and --accept-license flags that this would continue to Just Work™️, but note that launching with this workaround doesn't appear to permanently dismiss the prompt.

[joffrey-bion]

@gwynne's solution did work for me as well, although indeed it took 9m49s to run 😭
The previous script I was using took about 1m30s, but well at least this new one works.

Every independent developer needs to do this on Github Actions, which is a bit ridiculous...
Why not just allow them to preinstall the software?

[armenzg]

I filed it here in case you want to up-vote it.

[MaceWindu]

@armenzg , that's a wrong place to request it as it's blocked on Docker side by their EULA:
actions/runner-images#4399 (comment)
actions/runner-images#2150 (comment)

[armenzg]

Thanks @MaceWindu !

[sparty02]

the above comment worked great, but I happened to have HOMEBREW_CASK_OPTS="--appdir=~/Applications", so the app directory where the docker cask gets installed is a bit different. In that respect, I updated the script a bit to lookup the appdir.

#!/usr/bin/env bash

brew install --cask docker
docker_app_path=$(brew list --cask docker | grep '==> App' -A1 | tail -n 1 | awk '{ print $1 }')
docker_app_path="${docker_app_path/#\~/$HOME}"

sudo "$docker_app_path"/Contents/MacOS/Docker --unattended --install-privileged-components
open -a "$docker_app_path" --args --unattended --accept-license
while ! "$docker_app_path"/Contents/Resources/bin/docker info &>/dev/null; do sleep 1; done

[stephen-turner]

This is mostly fixed in Docker Desktop 4.7.0. Let's move the discussion to docker/roadmap#80.

[rfay]

@stephen-turner installation is fixed. I don't see anything in the docs about how to start Docker Desktop from the command line. Am I just missing something? This issue is largely about being able to start/stop Docker Desktop. DDEV's tests would be far more stable if I could stop and start Docker Desktop before every test run.

[stephen-turner]

You're right, we don't have that part yet, that's docker/roadmap#172.

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked