Do not "Bind" docker "To" containerd.

relates to docker/for-linux#678

When using the BindTo directive, Docker is permanently stopped by systemd
when containerd is temporarily killed and restarted;

Using `Requires` achieves mostly the same, but defines a weaker dependency;

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Requires=

> Requires=
>
> .. If this unit gets activated, the units listed will be activated as well.
> If one of the other units fails to activate, and an ordering dependency
> After= on the failing unit is set, this unit will not be started. Besides,
> with or without specifying After=, this unit will be stopped if one of the
> other units is explicitly stopped.

We may want to look into using `Wants=` instead of `Requires=`, because
that allows docker to continue running if containerd is restarted, quoting
the systemd documentation:

> Often, it is a better choice to use Wants= instead of Requires= in order
> to achieve a system that is more robust when dealing with failing services.

Given that docker will likely still fail if the containerd socket is not
present, startup will fail if containerd is not running, but if containerd
is restarted, the docker daemon may be able to try reconnecting.

Signed-off-by: Sebastiaan van Stijn <[email protected]>

Author: mihao

systemd/docker.service

@@ -1,10 +1,9 @@
 [Unit]
 Description=Docker Application Container Engine
 Documentation=https://docs.docker.com
-BindsTo=containerd.service
 After=network-online.target firewalld.service containerd.service multi-user.target
 Wants=network-online.target
-Requires=docker.socket
+Requires=docker.socket containerd.service
 
 [Service]
 Type=notify