Oh Mann – Ubuntu 16.04 hat schon wieder ein neues Start-System: „systemd“ …

Ich wollte meine „Haupt-Docker-Maschine“ via docker-machine create ... „übernehmen“:

Dies hat im ersten Schritt dazu geführt, dass der Docker-Dämon neu gestartet wurde und keiner meiner Container mehr lief…

Auch mit meinem Ansible-Playbook konnte ich das nicht mehr korrigieren:

ansible-playbook -i hosts -u root ansible/docker.yml

Inzwischen weiß ich mehr:

In der Docker-Doku unter systemd findet man einige nützliche Infos:

Zentrales tool von systemd ist systemctl. z.B.

systemctl show docker

systemctl show --property=FragmentPath docker
FragmentPath=/etc/systemd/system/docker.service

/etc/systemd/system/docker.service -> Service-Einstellungen
/lib/systemd/system/docker.service -> System-Defaults

/etc/systemd/system/docker.service.d/env.conf -> zus. Einstellungen

docker-machine hat also eine docker-service in etc angelegt, was dazu führte, dass die aus lib „überschrieben“ wurde. In der neuen Datei standen in ExecStart alle Optionen von dockerd explizit – also ohne Verwendung von $DOCKER_OPTS (welche in der Variante in lib sehr wohl verwendet wurde.). D.h. die DOCKER_OPTS, die in der env.conf (erstellt von ansible) definiert wurden, kamen nicht zum Zug.

Besser wäre also (in meinem Fall) folgende Aufruf gewesen (entscheidender Teil: --engine-opt storage-driver=overlay --engine-opt icc=false --engine-opt iptables):

docker-machine create --driver generic --generic-ip-address=docker3.steinkopf.net --engine-opt storage-driver=overlay  --engine-opt icc=false --engine-opt iptables docker3

(Details zu docker-machine create).

Leider ist dann immer noch die env.conf „außer Kraft“, sodass mein Ansible-Playbook immer noch nichts ausrichten kann. Das habe ich nun von Hand korrigiert, in dem ich in die ExecStart-Zeile wieder $DOCKER_OPTS eingetragen habe. Naja, geht besser…