Be wary of docker-ce

The accepted answer is under-complex.

docker-ce is provided by docker.com, docker.io is provided by Debian.

On the surface, this means you can install docker.io rightaway, while for docker-ce you have to attach an external repository from docker.com beforehands.

More importantly, however, although both packages provide properly released versions of Docker, they have a very different internal structure:

• docker.io does it the Debian (or Ubuntu) way: Each external dependency is a separate package that can and will be updated independently.
• docker-ce does it the Golang way: All dependencies are pulled into the source tree before the build and the whole thing forms one single package afterwards. So you always update docker with all its dependencies at once.

The problem with the latter approach is that it goes against much of what Debian/Ubuntu are trying to do.

If everybody did it the way docker-ce does...

...you would have 174 versions of many libraries on your system, which not only consume a lot of memory, they also make it essentially impossible to decide whether you have that version 7.6.5 of library XYZ with that horrible security vulnerability somewhere among them.
Let alone close that vulnerability (or all 109 instances of it you have).

Worse, one of the 174 versions is likely to be version 5.4.3 of XYZ as of three years ago, which had another, very different, but just as gaping security vulnerability that the world has long since forgotten about but that will still exist happily on your system.

Some remarks:

• Many web pages call docker.io "outdated". That is because it was unmaintained for about a year. As of August 2019, this is no longer the case.
• I learned all this today here and will now switch from using docker-ce to using docker.io -- and presumably never go back again.
• There is a reason why the Debian/Ubuntu packaging system is so complicated. A good reason.

Edit: As BobHy points out in a comment, the docker-ce approach also has an advantage: It is less likely to have compatibility issues with library XYZ. You have to trade off your risks.

docker.io

This is provided by the Linux distribution. They are compiling the upstream docker engine themselves, and adding some distribution specific code, mainly to the startup scripts. This name was picked because docker was already taken by an unrelated project. In addition, Debian currently has a few other related packages:

• docker-doc: Documentation that is packaged separately.
• rootlesskit: For running the docker engine without the root user.
• docker-compose: This is a nice to have since Docker Inc was packaging compose, but that is changing with the version 2 of compose that is written in Go and included directly in the docker CLI.
• docker-registry: Standalone packaging of a registry server, though it's not clear of the use case since almost everyone runs this as a container from the registry:2 image.
• credential helpers: There are several packages for these, and can be useful if you authenticate to a cloud vendor for your registry.

docker-ce

This is the Community Edition, aka the OSS release from Docker Inc. This is what most people think of when they install docker on Linux. In addition, the following are currently available on the docker repos:

• docker-ce-cli: You can install only the command line without the engine, and use this for remotely accessing docker engines on other hosts.
• docker-ce-rootless-extras: There's been a lot of effort to enable rootless support in recent releases of docker, so you can run the engine as your user instead of as root.
• docker-scan-plugin: This is a vulnerability scanner you can use for your images.

Instructions for installing docker-ce are available from Docker's website.

docker-ee

This is the Enterprise Edition, and part of Docker Inc. that was sold off to Mirantis. There were (I haven't followed it closely since the split) a few extra features compiled into this version, but the main two reasons for installing this version was vendor support (paid) and using it as the base for other commercial offerings like the UCP and DTR, which were the UI's on top of Swarm/Kubernetes and a registry server. Unless you've been working with Mirantis sales and have a license key, I don't think there's any reason to install this version.

Choosing between docker.io and docker-ce

The main decision is whether to install the OSS version of docker from your Linux distribution or directly from Docker Inc. A few points to consider:

• Documentation on https://docs.docker.com will be focused towards docker-ce.
• Support for issues from Docker Inc. will want you to have installed their version. That's only fair if you're a developer that packages the product, that you'd only want to support your own packaging.
• Patches and new releases will be available from docker-ce before docker.io. This may be important for time sensitive security issues.
• Installing docker-ce requires adding another repository to your sources.list, which is one more vendor to trust, and one more list of packages to update with every patch.
• If you only want the CLI so you can access docker on remote machines (e.g. DOCKER_HOST=ssh://you@example.com docker ps), you'll want to use the docker-ce-cli package.

For me, if you are setting up a dedicated machine for running containers, go with docker-ce. While if you only run an occasional container, don't follow what Docker Inc. is doing upstream, and use the machine for a lot of other tasks, using docker.io can simplify your workflows.

Docker Enterprise is now Mirantis Kubernetes Engine:

The other answers were written before Docker sold their enterprise assets to Mirantis. And there were big changes stemming from that acquisition...

If you now visit the link for "Enterprise Edition"- https://docs.docker.com/ee/ - you'll find oogatz. That's because "Docker Enterprise" is now "Mirantis Kubernetes Engine"

Swarm's Future:

With the uptake of Kubernetes and Mirantis buying Docker's Enterprise assets, the future of swarm was in doubt. However, the future of swarm container orchestration appears to be more certain now as it's a headline feature in Mirantis Kubernetes Engine v3.5 according to this blog post which states:

"...customers have spoken — and many of them are completely satisfied using Swarm instead of Kubernetes for container orchestration. With that in mind, we’re excited to announce Swarm-only mode: a new Mirantis Kubernetes Engine configuration option that dedicates the platform exclusively to Swarm orchestration and Docker containers."

So for enterprise planning purposes, it looks like swarm has a future in a Kubernetes world.

But that's not all the changes from Mirantis...

Docker CE Now Developed (mostly) By Third Party:

Effective with the v20.10 release on 20201209, Docker CE is now the product of TWO separate Github Projects:

• docker/cli (still managed by Docker)
• moby/moby (managed by a third party)

So going forward from v20.10, The Moby Project will now do the grunt work of developing Docker CE while Mirantis pursues monetizing Mirantis Kubernetes Engine. Don't whinge: Mirantis is a business after all and they have to make a profit; no surprises there.

The docker-cli portion of Docker CE however is still being developed by Docker. Obviously the docker-cli bit is interesting and they've kept that bit in-house...

Conclusion:

After IBM bought Red Hat and CentOS was killed-off, I imagine there are similar concerns by organizations reliant on Docker containerization about the future of Docker CE post Mirantis acquisition. It appears the Moby Project could take over were Mirantis to pull their (5) developers. But it would ultimately lead to a fork in Docker and development taking divergent paths.

Red Hat employed the CentOs Project folks (you weren't aware?), so they were always beholden to follow the direction RH gave them. I don't know whether Docker employs or otherwise pay the remaining 22/27 Moby devs. There could be further material changes in the future for the Docker landscape given the commercial pressures Mirantis is under to make Docker a profitable acquisition which makes planning commercial decisions on the current landscape challenging...