2 min read docker, provisioning

Adding an autostart daemon to get.docker.com

A feature I worked on for Docker's official install script running the one-liner now leaves you with a running daemon, and a new --no-autostart flag is the opt-out for flows that need the old behaviour.

For years, the standard Docker install one-liner

curl -fsSL https://get.docker.com | sh

left you with Docker installed but not running. The first thing almost everyone did next was the same pair of commands:

sudo systemctl start docker
sudo systemctl enable docker

docker/docker-install#518 (merged today) flips that default. The install script now finishes with the daemon running and enabled, and there’s a new --no-autostart flag for the cases where you really do want the old behaviour. This closes #124, which had been open asking for exactly this for a while.

What changes

Default:

sudo sh install.sh
# Installs Docker, starts the daemon, enables it on boot.

Opt-out:

sudo sh install.sh --no-autostart
# Installs Docker. Daemon is not started, not enabled.

You can also see what the script will do without running it:

sudo sh install.sh --dry-run
# Prints every command the script would run, including the
# new start/enable calls.

Init-system detection

The install script supports more than just systemd hosts, so the autostart code does runtime detection:

  • systemd (most modern distros): systemctl start docker && systemctl enable docker.
  • Traditional init: service docker start, then either chkconfig docker on on RHEL-family hosts or update-rc.d docker defaults on Debian-family hosts.

Both branches show up in --dry-run output, so you can confirm the right one was picked before letting the script touch the system.

When --no-autostart is the right choice

The use case for opting out is image bakery — Packer, Ansible, container-image base layers, anything that bakes Docker into an image rather than installing it on a live host. There are two reasons you don’t want the daemon coming up during the bake:

  1. A dockerd process eating CPU and memory during the image build is wasted work.
  2. Starting the daemon at bake time creates content under /var/lib/docker that then gets frozen into the image and breaks first boot on any machine that comes up from it.

Before #518, image-bakery flows got the right default by accident, and interactive users paid the tax. After it, interactive users get the obvious behaviour and bake flows add one flag.

Backward compatibility

The visible surface of the install is unchanged — it still succeeds, the same packages are installed, and CI that pipes into sh keeps working. The only thing that’s different is the post-install service state. If you have CI that asserts systemctl is-active docker after a fresh get.docker.com run and currently passes by accident, it now passes on purpose. If you have CI that asserts the daemon is not running, add --no-autostart to your install command and you’re back where you were.