How do you choose between the docker-ce repository packages, the get.docker.com script and Docker Desktop when provisioning build hosts?

### The three channels, and what each is actually for **1. Docker's package repository (`docker-ce`).** You add Docker's apt or dnf repository and its signing key, then install the engine as ordinary packages. The current set is five: `docker-ce` (the daemon), `docker-ce-cli` (the client), `containerd.io`, `docker-buildx-plugin` and `docker-compose-plugin`. This is the only channel that gives you the two properties a fleet needs: you can install a **named version** rather than "whatever is newest today", and you can hold it so an unrelated `apt upgrade` does not move the engine underneath a running workload. ``` VER=$(apt-cache madison docker-ce | awk 'NR==1{print $3}') sudo apt-get install -y docker-ce="$VER" docker-ce-cli="$VER" \ containerd.io docker-buildx-plugin docker-compose-plugin sudo apt-mark hold docker-ce docker-ce-cli ``` The reason to pin both `docker-ce` and `docker-ce-cli` to the same string is the skew problem: they are separate packages and nothing stops a host from acquiring a newer client than daemon. **2. The convenience script at get.docker.com.** `curl -fsSL https://get.docker.com -o get-docker.sh && sudo sh get-docker.sh` detects the distribution, configures the same repository, and installs the latest release. It is genuinely useful — for a scratch VM, a lab box, a five-minute reproduction. Docker's own documentation says it is **not recommended for production**, and the reasons are worth being able to list: it requires piping a remote script into a root shell; it always installs the latest version with no way to pick one; it may enable prerelease channels if you ask it to; it does not integrate with whatever configuration management already owns the host; and it can behave surprisingly on a machine that already has some Docker packages installed. If you need unattended installs at scale, the honest answer is "configuration management driving the repository packages", not "the script in a loop". **3. Docker Desktop.** Desktop is a developer workstation product for macOS, Windows and Linux desktops. It bundles a GUI, its own Linux virtual machine, and a licence that requires a paid subscription for organisations above Docker's published size threshold. It is the right answer for "how do developers get an engine on their laptop" and the wrong answer for "how does a build host get an engine". Confusing the two is a common interview stumble. **4. The distribution's own package.** Debian and Ubuntu ship `docker.io`, Fedora ships a `moby-engine`. These are packaged by the distro rather than by Docker: usually older, tied to the distro release cycle, and carried by the distro's security updates. They are a legitimate choice for a conservative estate that wants one update mechanism for everything, and a poor one if you need a recent BuildKit or a feature from a recent release. Mixing them with Docker's own repository on the same host is where conflicts come from — pick one source per host. ### The fleet question underneath Suppose 41 CI build hosts compile a Go CLI into a `scratch` image. What you care about is not which command installs Docker but whether all 41 hosts have the **same** engine, and whether that engine changes only when you decide it does. That reframes the choice completely: - **Reproducibility.** Named version plus hold, applied by configuration management, so a host rebuilt in six months lands on the version you chose rather than the one that shipped this morning. - **Uniformity.** Skew between hosts is what generates the "works on 37 of 41 agents" tickets. One source, one version, upgraded as a batch. - **Upgrade path.** Engine upgrades restart dockerd. Plan them as a maintenance action — drain the agent, upgrade, put it back — not as a side effect of unattended-upgrades running at 03:00. - **Provenance.** The repository is signed; verifying the key is part of the install and part of what you can show an auditor. A `curl | sh` install has a much weaker story. ### How to answer the question in an interview State the decision rule first, then the reasons: **repository packages with an explicit version for anything long-lived; the convenience script only for disposable hosts; Desktop only for workstations, with the licence caveat named.** Then show that you know the failure modes — drifting engine versions across a fleet, CLI and daemon packages moving independently, an unattended upgrade restarting the daemon mid-build, and a host that has both the distro package and Docker's own repository half-installed. Those are the things that actually cost time, and naming them is what distinguishes an operator's answer from a recital of install commands.