Automatically start Docker service with --no-autostart disable option

[gajeshbhat]

Summary

This PR makes the Docker daemon start automatically after installation by default, with a --no-autostart opt-out flag. This addresses issue #124 and aligns with the current design philosophy of get.docker.com.

Problem

Users need an option to automatically start the Docker daemon after installation, as service management differs between distributions. Currently, users must manually run sudo systemctl start docker and sudo systemctl enable docker after installation.

Solution

The script now automatically starts and enables the Docker daemon by default:

• Daemon starts automatically after installation
• Use --no-autostart flag to skip daemon start
• Automatically detects systemd vs traditional init systems
• Uses appropriate commands for each distribution:
  • systemdsystemctl start docker && systemctl enable docker
  • Traditional: service docker start && chkconfig docker on (or update-rc.d)
• Dry-run: Shows exactly what commands will be executed

Usage

# Install Docker (daemon starts automatically)
sudo sh install.sh

# Install Docker without starting daemon
sudo sh install.sh --no-autostart

# See what would happen (dry-run)
sudo sh install.sh --dry-run

[gajeshbhat]

@thaJeztah Can you kindly take a look ? Do you think the feature would be useful?

[thaJeztah]

Oh! This one dropped off my list; I think we actually had a conversation internally to consider making this the default so that rpm and deb packages installed using the convenience script (get.docker.com) would always result in a running daemon.

The current script tried to align with the general conventions / expectations of rpm packages (which don't start services after installation), but as the get.docker.com script is considered a more "opinionated" way to install the docker packages, and meant for convenience (not production scenarios), we could consider doing this by default.

I had to dig back the discussion related to it, but I think it was when we made this change in the docs, which also was changed to automatically start the daemon;

• engine: minor improvements to rpm-based installation instructions docs#21380

We could add an option to not start it if we decide to make that change (--disable-start or --install-only or something along those lines)

@vvoland WDYT?

[gajeshbhat]

Oh! This one dropped off my list; I think we actually had a conversation internally to consider making this the default so that rpm and deb packages installed using the convenience script (get.docker.com) would always result in a running daemon.

The current script tried to align with the general conventions / expectations of rpm packages (which don't start services after installation), but as the get.docker.com script is considered a more "opinionated" way to install the docker packages, and meant for convenience (not production scenarios), we could consider doing this by default.

I had to dig back the discussion related to it, but I think it was when we made this change in the docs, which also was changed to automatically start the daemon;

• engine: minor improvements to rpm-based installation instructions docs#21380

We could add an option to not start it if we decide to make that change (--disable-start or --install-only or something along those lines)

@vvoland WDYT?

Thanks for adding more context. I don't have a strong opinion on whether this feature should be default/non-default. I would personally like a --autostart option so that the default behaviour is as currently expected, ensuring that people who don't use this option/not aware of the update are not surprised if they have an automation script(s) that pulls the latest version of this script.

[vvoland]

Yeah something like --no-autostart would also be fine.

[thaJeztah]

Heh, yeah, for context; the get.docker.com script has had many debates over the years; it's generally "bad practice" to just curl | sudo sh a script; it's risky, and even more so if the script involves trying to detect what commands to run; potentially changing system settings that were already set; it's the reason it prints a warning if it discovers that docker is already installed, because this may mean it's installed through other means, with different configs. So it's much better to install things "manualy" (which could mean a customised variants of the steps, but targeted at the distro you're using)

That said; it's it sure is REALLY convenient to use, so the script is unlikely to go away; we consider it an opinionated way to configure things, which may involve things like this (automatically start), and with the proper warnings in place ("know what you're opting into when using the script") both in the script, the "dry run" option to check what you're about to run, and warnings in our docs, I think that's perfectly fine to do.

[gajeshbhat]

Heh, yeah, for context; the get.docker.com script has had many debates over the years; it's generally "bad practice" to just curl | sudo sh a script; it's risky, and even more so if the script involves trying to detect what commands to run; potentially changing system settings that were already set; it's the reason it prints a warning if it discovers that docker is already installed, because this may mean it's installed through other means, with different configs. So it's much better to install things "manualy" (which could mean a customised variants of the steps, but targeted at the distro you're using)

That said; it's it sure is REALLY convenient to use, so the script is unlikely to go away; we consider it an opinionated way to configure things, which may involve things like this (automatically start), and with the proper warnings in place ("know what you're opting into when using the script") both in the script, the "dry run" option to check what you're about to run, and warnings in our docs, I think that's perfectly fine to do.

I have refactored it to make autostart the default behaviour with a --no-autostart opt-out flag. CC: @vvoland

[vvoland]

Thanks, looks good to me. One last thing though - please change the new echos to output to stderr ❤️

[gajeshbhat]

Thanks, looks good to me. One last thing, though - please change the new echos to output to stderr ❤️

Thank you for the review @vvoland. I have updated the suggested changes and pushed the commit. Please let me know if you have any questions. Cheers.

[vvoland]

Oh, could you please rebase the PR on top of the latest master (after #530 was merged)?

The test in the CI pipeline wasn't being ran correctly before, so the script wasn't even ran for this PR 🙈

[gajeshbhat]

@vvoland rebased and pushed. Please let me know if you have any questions. Cheers.

[vvoland]

Looks like it fails in a container environment: https://github.com/docker/docker-install/actions/runs/18424536661/job/52594868483?pr=518

Also, can you please rebase so it doesn't actually include the merge commits? ❤️

[gajeshbhat]

Looks like it fails in a container environment: https://github.com/docker/docker-install/actions/runs/18424536661/job/52594868483?pr=518

Also, can you please rebase so it doesn't actually include the merge commits? ❤️

@vvoland Did a clean rebase and fixed errors from CI earlier. Can you please approve the PR workflow runs so that I can check to make sure my release and fix went as expected? Thanks again for the feedback. Cheers.

[gajeshbhat]

@vvoland Any update on this PR?

[vvoland]

Sorry, this one went off my radar!

Approved the workflows

[gajeshbhat]

@vvoland sorry for the delayed reply. I have made some fixes and pushed a commit, Can you kindly approve the workflow so that I can test my changes. I did test them locally but would be good to test it on the Pipeline. Please let me know if you have any questions. Cheers.

[gajeshbhat]

@vvoland Can you please approve the workflow ? I made fixes after the last failure.

[vvoland]

Sorry for missing! Approved

[vvoland]

LGTM. @thaJeztah PTAL

[thaJeztah]

Left some comments / thoughts; I gave it a quick go to look what it looked like with my suggestions, and opened a PR against your branch; if you merge that PR, the changes should show up in this PR, and we can review / discuss those changes;

• simplify service start gajeshbhat/docker-install#1

[gajeshbhat]

Left some comments / thoughts; I gave it a quick go to look what it looked like with my suggestions, and opened a PR against your branch; if you merge that PR, the changes should show up in this PR, and we can review / discuss those changes;

• simplify service start gajeshbhat/docker-install#1

Let's run the CI check and see if this works. Thanks for the detailed review. Cheers.

[thaJeztah]

LGTM, thank you!

but would like another review from @vvoland as I made some of the last changes 😅

[gajeshbhat]

Thank you both @vvoland @thaJeztah . It was fun collaborting on this PR. My understanding of docker has definitly improved after this.Looking forward to contributing more in the future. Cheers.