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

Question

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 I have come up empty. What is docker.io in relation to docker-ce?

Mockingbird

@zerkms I was confused because the official docker website has no mention of docker.io. Is it depreciated? – Mockingbird

docker.io package is maintained by ubuntu developers. Ubuntu developers are not affiliated with the "official docker website". So the fact the docker website does not refer to it means basically nothing. – Dalessio

@zerkmsIs docker.io up to date though? – Mockingbird

Check and see? packages.ubuntu.com/… – Dalessio

This now totally works again! – Pennyworth

Answer 1

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

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

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

The main reason for using the name docker-io on Debian/Ubuntu platform was to avoid a name conflict with the 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/Red Hat Linux (RHL):

Install Docker Engine on CentOS

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

Ubuntu/Debian:

Install Docker Engine on 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

Output:

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])

Second command:

sudo apt-get install docker-ce --dry-run

Output:

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.

Southwest

@Ivolmar Thank you very much, so it would be silly to use docker.io over one of the newer ones then? – Mockingbird

@WillParzybok Correct. Depending on your version of Debian or Ubuntu you should be able to install new CE version and remove older version binaries – Southwest

I wish I have seen your comment beforeI I installed docker.io.. :-) – Lasagne

In Ubuntu 19.04, the docker.io version is slightly ahead of docker-ce (18.09.5 v. 18.06.3). Vendor releases and ppas are typically ahead of Ubuntu's releases. Comments appreciated about whether the advice to use ce over io still applies. – Stanfield

2019-May-21 confused ... what to use on Ubuntu 18.04? apt-get install docker.io looks so much more comfortable than doing the 10 steps or more to install docker-ce :( – Harald

Just did apt install docker.io and got Docker version 18.09.2, build 6247962 ... so what's the deal with docker-ce? I take what Ubuntu gives me. – Harald

I have 19.04 Ubuntu, install docker.io. Client: Version: 18.09.5 API version: 1.39 Go version: go1.10.4 Git commit: e8ff056 Built: Fri Apr 12 00:34:27 2019 OS/Arch: linux/amd64 Experimental: false Server: Engine: Version: 18.09.5 API version: 1.39 (minimum version 1.12) Go version: go1.10.4 Git commit: e8ff056 Built: Fri Apr 12 00:27:37 2019 OS/Arch: linux/amd64 Experimental: false Is't norm variant? – Nathanielnathanil

@TsetNoitamotua : Suppose docker releases a brand new major version of docker (version 20). If you are on Ubuntu 19.04 you now have the following options. FIRST: Wait till the successor of ubuntu 19.04 is released. Probably the docker.io package will then be upgraded to v20 of docker. SECOND: Check if v20 of docker is available in the Ubuntu 19.04 backports repo. THIRD: Use the docker-ce package (based on docker v20) for Ubuntu 19.04 provided by Docker Inc. So at the time of writing this comment it does not really matter if you use the docker.io or docker-ce packages ;-) – Stonechat

Answer 2

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 right away, while for docker-ce you have to attach an external repository from docker.com beforehand.

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 Go 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.

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.

Hellfire

found this answer after docker-ce in 2 of my nodes stuck while another node with docker.io survived while apt upgrade. – Oscine

This makes me cosidering to favorite Debian's/Ubuntu's docker.io package. More over it is just one apt install away while for docker-ce I always have to go to Docker docs to look up the installation steps. – Harald

You might want to mention the security implications of using docker.io - you will not receive security patches as soon as it goes out of maintenance again, and even as long as it is not you rely on the maintainers correctly backporting every security patch. – Darken

One advantage of docker-ce is that you get a certified release, you get docker team's promise that the package will work with the bundled dependencies. Presumably, there's less finger-pointing if you have a problem. Do the debian maintainers of docker.io certify that docker runs on the most current version of all the dependent packages? Have the docker team done a good enough job of packaging their tests that any other team can certify a release? There's no "best" solution here, just a balance of risks, and you have to choose which risks matter more to you. – Grouchy

@Grouchy I agree, it's a tradeoff. Just don't forget to switch to docker.io in your production systems that have no development activity if and when Docker Inc. goes down the drain or stops making regular(!) updates to docker-ce for some other reason. Debian has a solid reputation in this respect: Even if docker.io should stop getting updates once again, the many libraries still will. – Hellfire

Was linked to this from a GitHub ticket and wanted to point out how Debian packages for go work. Regardless of the packaging methodology, go aims to produce a single binary with few (or no) dynamically linked libraries. Debian go libraries are typically packages that contain go source code, that is compiled into the go binary. So the bulk of the code in docker-io is still built into a single binary artifact. (Put another way, the debian method aims to avoid the "go get" step by turning your GOPATH into debian packages of source code). – Optime

I'm confused about the dependency concerns. Since docker itself is written in Go, isn't Debian doing a build to a single binary, same as the Docker packages? – Gand

@Gand Good point. I have not looked at how the Debian build is structured specifically. But if docker.io were just the same structure as docker-ce, I guess it would have existed as an up-to-date version throughout and not had the lagging-behind that it had for some time. – Hellfire

Some good evidence that at least Ubuntu is now very fast to publish newer versions: Docker 24.0.5 was released on 2023-07-17, Ubuntu was notified on 2023-08-07, had the package ready on 2023-08-17, then backported to 22.04 on 2023-08-23. That's about a month from upstream to an LTS release! – Sloganeer

Answer 3

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: stand-alone 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.

Gand

Answer 4

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 Red Hat 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...

Franco