What is docker.io in relation to docker-ce and docker-ee (now called "Mirantis Kubernetes Engine")?

Previously, to install docker I would use

apt-get install docker.io

However, I have recently noticed the documentation for installing docker, and it uses docker-ce. I have tried to find the difference between the two, but have come up empty. What is docker.io in relation to docker-ce?

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.

Older versions of the Docker binary were called docker or docker-engine or docker-io

docker-io package is still the name used by Debian/Ubuntu for the docker release provided on their official repos.

docker-ce is a certified release provided directly by docker.com and can also be built from source.

Main reason for using the name docker-io on Debian/Ubuntu platform was to avoid a name conflict with docker system-tray binary.

http://manpages.ubuntu.com/manpages/precise/man1/docker.1.html

Docker has an enterprise version (EE) and a free community Edition version(CE)

Prior to installing Docker Community Edition (docker-ce from docker.com) you may need to remove older binaries.

Centos/RHL:

https://docs.docker.com/engine/installation/linux/docker-ce/centos/

sudo yum remove docker \
                  docker-client \
                  docker-client-latest \
                  docker-common \
                  docker-latest \
                  docker-latest-logrotate \
                  docker-logrotate \
                  docker-engine

Ubuntu/Debian:

https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/

$ sudo apt-get remove docker docker-engine docker.io containerd runc

Dry-run comparison on ubuntu:

$ sudo apt-get install docker.io --dry-run
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  bridge-utils cgroupfs-mount containerd pigz runc ubuntu-fan
Suggested packages:
  ifupdown aufs-tools debootstrap docker-doc rinse zfs-fuse | zfsutils
The following NEW packages will be installed:
  bridge-utils cgroupfs-mount containerd docker.io pigz runc ubuntu-fan
0 upgraded, 7 newly installed, 0 to remove and 70 not upgraded.
Inst pigz (2.4-1 Ubuntu:18.04/bionic [amd64])
Inst bridge-utils (1.5-15ubuntu1 Ubuntu:18.04/bionic [amd64])
Inst cgroupfs-mount (1.4 Ubuntu:18.04/bionic [all])
Inst runc (1.0.0~rc7+git20190403.029124da-0ubuntu1~18.04.2 Ubuntu:18.04/bionic-updates, Ubuntu:18.04/bionic-security [amd64])
Inst containerd (1.2.6-0ubuntu1~18.04.2 Ubuntu:18.04/bionic-updates, Ubuntu:18.04/bionic-security [amd64])
Inst docker.io (18.09.7-0ubuntu1~18.04.4 Ubuntu:18.04/bionic-updates, Ubuntu:18.04/bionic-security [amd64])
Inst ubuntu-fan (0.12.10 Ubuntu:18.04/bionic [all])
Conf pigz (2.4-1 Ubuntu:18.04/bionic [amd64])
Conf bridge-utils (1.5-15ubuntu1 Ubuntu:18.04/bionic [amd64])
Conf cgroupfs-mount (1.4 Ubuntu:18.04/bionic [all])
Conf runc (1.0.0~rc7+git20190403.029124da-0ubuntu1~18.04.2 Ubuntu:18.04/bionic-updates, Ubuntu:18.04/bionic-security [amd64])
Conf containerd (1.2.6-0ubuntu1~18.04.2 Ubuntu:18.04/bionic-updates, Ubuntu:18.04/bionic-security [amd64])
Conf docker.io (18.09.7-0ubuntu1~18.04.4 Ubuntu:18.04/bionic-updates, Ubuntu:18.04/bionic-security [amd64])
Conf ubuntu-fan (0.12.10 Ubuntu:18.04/bionic [all])

$ sudo apt-get install docker-ce --dry-run
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  aufs-tools cgroupfs-mount containerd.io docker-ce-cli libltdl7 pigz
The following NEW packages will be installed:
  aufs-tools cgroupfs-mount containerd.io docker-ce docker-ce-cli libltdl7 pigz
0 upgraded, 7 newly installed, 0 to remove and 70 not upgraded.
Inst pigz (2.4-1 Ubuntu:18.04/bionic [amd64])
Inst aufs-tools (1:4.9+20170918-1ubuntu1 Ubuntu:18.04/bionic [amd64])
Inst cgroupfs-mount (1.4 Ubuntu:18.04/bionic [all])
Inst containerd.io (1.2.10-3 Docker CE:bionic [amd64])
Inst docker-ce-cli (5:19.03.5~3-0~ubuntu-bionic Docker CE:bionic [amd64])
Inst docker-ce (5:19.03.5~3-0~ubuntu-bionic Docker CE:bionic [amd64])
Inst libltdl7 (2.4.6-2 Ubuntu:18.04/bionic [amd64])
Conf pigz (2.4-1 Ubuntu:18.04/bionic [amd64])
Conf aufs-tools (1:4.9+20170918-1ubuntu1 Ubuntu:18.04/bionic [amd64])
Conf cgroupfs-mount (1.4 Ubuntu:18.04/bionic [all])
Conf containerd.io (1.2.10-3 Docker CE:bionic [amd64])
Conf docker-ce-cli (5:19.03.5~3-0~ubuntu-bionic Docker CE:bionic [amd64])
Conf docker-ce (5:19.03.5~3-0~ubuntu-bionic Docker CE:bionic [amd64])
Conf libltdl7 (2.4.6-2 Ubuntu:18.04/bionic [amd64])

The docker-ce binaries will tend to be the latest versions and include docker-ce-cli.

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://[email protected] 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...