Machine: Die Erstellung der Maschine schlägt mit dem neuesten Docker fehl

Selbes Problem hier

docker-machine create 
    --driver=digitalocean
    --digitalocean-access-token=XXX 
    --digitalocean-size=2gb
    machinename

Gestern hat der gleiche Befehl mit Docker Version 17.05.0-ce gut funktioniert
Heute startet der Docker meiner neuen Maschine nicht (17.06.0-ce)
Ich habe es mehrmals versucht.

Ich kann das auch bestätigen:

dm create -d digitalocean \
--digitalocean-access-token XXX \
--digitalocean-size 4gb machine

Ich verwende dies als Problemumgehung:

Docker-Maschine erstellen \
--driver amazonec2 \
--engine-install-url = https://web.archive.org/web/20170623081500/https : //get.docker.com

oder
--engine-install-url = https://releases.rancher.com/install-docker/17.05.sh

Ich habe das gleiche Problem.

Docker-Version: Docker-Version 17.06.0-ce
Docker-Machine-Version: 0.12.0, Build 45c69ad

docker-machine create --driver amazonec2 --amazonec2-region eu-west-1 --amazonec2-instance-type t2.small --amazonec2-access-key XXX --amazonec2-secret-key XXX test-create-machine

29. Juni 12:26:56 ip-172-31-10-149 systemd [1]: Starten der Docker Application Container Engine ...
29. Juni 12:26:56 ip-172-31-10-149 docker [5234]: docker daemon wird unter Linux nicht unterstützt. Bitte führen Sie dockerd direkt aus

docker daemon wird unter Linux nicht unterstützt. Bitte führen Sie dockerd direkt aus

Ich konnte es mit dieser PR zum Laufen bringen
https://github.com/docker/machine/pull/4128

Kompilieren Sie einfach die Docker-Maschine mit diesem Fix und alles funktioniert wieder

@gnomus super, das ist interessant! Ich frage mich, warum es für 17.05.0-ce funktioniert hat.

@therealppa haahaha super! Ich habe mich gefragt, wie ich die alte Version dieses Skripts bekommen könnte oder ob das Live-Skript Parameter benötigt, um eine ältere Version zu installieren. web.archive.org ist mir definitiv nicht in den Sinn gekommen.

@dminkovsky Ich glaube nicht, dass es für immer funktionieren wird. Wenn Sie sich das Skript ansehen, wird die Version nirgendwo angegeben ... Trotzdem funktioniert es gerade.

@therealppa @dminkovsky Eine längerfristige Lösung besteht darin, die Zeile 457 des Skripts von zu ändern

$sh_c 'apt-get install -y -q docker-ce'

zu

$sh_c "apt-get install -y -q docker-ce=17.05.0~ce-0~$lsb_dist-$dist_version"

Hoffentlich wird die feste Version von Docker-Maschine bald veröffentlicht.

gleiche für mich
Wir sorgen dafür, dass "dockerd" anstelle von "docker daemon" in der Datei /etc/systemd/system/docker.service.d/10-machine.conf verwendet wird

@ fabio-barile was ist mit dem --storage-driver aufs arg? Meins würde nicht anfangen, wenn ich das nicht auch loswerden würde.

@dminkovsky Ich hatte das gleiche Problem auf einer Autoscaling-CI mit Gitlab, bekam das aufs Problem + Dockerd Problem, musste es mit der Angabe von Overlay im Speichertreiber lösen.

Neben dem Problem mit dem Speichertreiber werden auch Überprüfungsfehler für von gitlab-running (9.3.0) erstellte Zertifikate angezeigt. @ JustEra bist du auf das gleiche Problem

http: TLS handshake error from ...:
 tls:
  failed to verify client's certificate: x509:
   certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "unknown")

ERROR: Error creating machine:
 Error checking the host:
  Error checking and/or regenerating the certs:
   There was an error validating certificates for host "...":
    remote error: tls: bad certificate  driver=amazonec2 name=...

Dieses Problem mit dem Speichertreiber wurde für mich behoben (habe diesen Parameter gerade entfernt; NUR für systemd). Bewerben Sie sich oben auf https://github.com/docker/machine/pull/4128 und erstellen Sie

diff --git a/libmachine/provision/systemd.go b/libmachine/provision/systemd.go
index 90d02603..05d63bb5 100644
--- a/libmachine/provision/systemd.go
+++ b/libmachine/provision/systemd.go
@@ -53,7 +53,7 @@ func (p *SystemdProvisioner) GenerateDockerOptions(dockerPort int) (*DockerOptio

        engineConfigTmpl := `[Service]
 ExecStart=
-ExecStart=/usr/bin/` + arg + ` -H tcp://0.0.0.0:{{.DockerPort}} -H unix:///var/run/docker.sock --storage-driver {{.EngineOptions.StorageDriver}} --tlsverify --tlscacert {{.AuthOptions.CaCertRemotePath}} --tlscert {{.AuthOptions.ServerCertRemotePath}} --tlskey {{.AuthOptions.ServerKeyRemotePath}} {{ range .EngineOptions.Labels }}--label {{.}} {{ end }}{{ range .EngineOptions.InsecureRegistry }}--insecure-registry {{.}} {{ end }}{{ range .EngineOptions.RegistryMirror }}--registry-mirror {{.}} {{ end }}{{ range .EngineOptions.ArbitraryFlags }}--{{.}} {{ end }}
+ExecStart=/usr/bin/` + arg + ` -H tcp://0.0.0.0:{{.DockerPort}} -H unix:///var/run/docker.sock --tlsverify --tlscacert {{.AuthOptions.CaCertRemotePath}} --tlscert {{.AuthOptions.ServerCertRemotePath}} --tlskey {{.AuthOptions.ServerKeyRemotePath}} {{ range .EngineOptions.Labels }}--label {{.}} {{ end }}{{ range .EngineOptions.InsecureRegistry }}--insecure-registry {{.}} {{ end }}{{ range .EngineOptions.RegistryMirror }}--registry-mirror {{.}} {{ end }}{{ range .EngineOptions.ArbitraryFlags }}--{{.}} {{ end }}

Für alle, die eine bestimmte ältere Version wünschen, pflegen wir (Rancher) leicht modifizierte get.docker.com-Skripte, um jedes zu installieren:

http://rancher.com/docs/rancher/v1.6/en/hosts/#supported -docker-version

@ fabio-barile oben ist völlig richtig. Wie 'Testen' solche Dinge emittieren lässt, kann ich mir nicht vorstellen.

Weitere Informationen finden Sie hier: https://github.com/docker/for-linux/issues/11#issuecomment -312143765

@ vincent99 ... mag immer den Sound von euch und danke.

+1
Ich schaue jeden Tag nach einer neuen Docker-Maschine-Version ... Dieser Fehler bringt mich um :-)

Im Moment füge ich /etc/systemd/system/docker.service.d/20-machine.conf hinzu, wodurch 10-machine.conf mit der richtigen Befehlszeile überschrieben wird. Auf diese Weise wird ein weiterer Docker-Machine-Befehl, der ihn normalerweise unterbrechen würde, nicht ausgeführt. Je länger es dauert, bis dies in der Veröffentlichung behoben ist, desto mehr Arbeit habe ich natürlich, um alles zurückzusetzen!

Vielen Dank für die großartige Aufschlüsselung der Details zu diesem Problem. Wir untersuchen es, um herauszufinden, was schief gelaufen ist.

im Zusammenhang mit https://github.com/docker/for-linux/issues/11#issuecomment -312143765

Dies hängt also nicht mit dem Installationsskript bei get.docker.com , sondern damit, dass der Versionsvergleich nicht richtig funktioniert und 17.06.0-ce der erste ist, der docker daemon offiziell ablehnt, deshalb sind wir es Fehler sehen.

Diese PR (Docker / Maschine Nr. 4128) scheint dieses Problem zu beheben, und ich werde bis zum späten Nachmittag eine PR haben, die Tests für die anderen Vergleichsfunktionen hinzufügt, damit wir nicht wieder auf so etwas stoßen.

@seemethere Hört sich gut an, danke. Möchte von dem Test hören.

Der Unterschied bei einem der PRs erschien mir etwas seltsam, aber ich denke, ihr werdet sich darum gekümmert haben.

Die Version 0.12.1 behebt diesen Fehler. Vielen Dank an alle für Ihre Geduld und Ihre Hilfe.

@ shin- danke für die schnelle Lösung! Ich freue mich darauf, es zu benutzen.

@ shin- Dieser Patch behebt den Teil docker daemon -> dockerd , aber Docker startet aufgrund immer noch nicht auf dem Computer

dockerd[6407]: Error starting daemon: error initializing graphdriver: driver not supported

@ shin- Ich konnte das Problem mit dem Speichertreiber umgehen, indem ich --engine-storage-driver=overlay hinzufügte (https://github.com/docker/machine/issues/3895#issuecomment-270934728). Hier ist meine ganze docker-machine -Aufforderung.

docker-machine -D create \
    --driver google \
    --google-project $project \
    --google-zone $zone \
    --google-machine-type $type \
    --google-disk-size $size \
    --google-preemptible \
    --engine-storage-driver=overlay \
    $name

Ohne --engine-storage-driver=overlay scheitert es immer noch mit

dockerd[6407]: Error starting daemon: error initializing graphdriver: driver not supported

wie zuvor und wie in # 3895

Haben Sie das Protokoll gesehen, das erklärt, warum es abgestürzt ist?

Am Freitag, den 7. Juli 2017 um 9:39 Uhr, Seweryn Zeman [email protected]
schrieb:

@ shin- https://github.com/shin- Leider hat 0.12.1 dies nicht behoben
für mich.

$ docker -v
Docker Version 17.06.0-ce, Build 02c1d87
$ docker-machine -v
Docker-Maschine Version 0.12.1, Build c8b17e8

Ich erstelle eine amazonec2-Maschine mit --amazonec2-region = eu-central-1
das schafft ein ami-fe408091 für mich.

Die Ausgabe von Docker-Maschine erstellen ist:

Vorab-Erstellungsprüfungen ausführen ...
Maschine erstellen ...
(test-dm) Instanz wird gestartet ...
Das Warten auf den Betrieb der Maschine kann einige Minuten dauern ...
Betriebssystem der erstellten Instanz erkennen ...
Warten auf die Verfügbarkeit von SSH ...
Den Provisioner erkennen ...
Bereitstellung mit Ubuntu (systemd) ...
Docker installieren ...
Kopieren von Zertifikaten in das lokale Maschinenverzeichnis ...
Kopieren von Zertifikaten auf den Remote-Computer ...
Festlegen der Docker-Konfiguration auf dem Remote-Daemon ...
Fehler beim Erstellen der Maschine: Fehler beim Ausführen der Bereitstellung: ssh-Befehlsfehler:
Befehl: sudo systemctl -f Docker starten
err: Status beenden 1
Ausgabe: Job für docker.service fehlgeschlagen, da der Steuerungsprozess mit Fehlercode beendet wurde. Weitere Informationen finden Sie unter "systemctl status docker.service" und "journalctl -xe".

Die Ausgabe der gestarteten Maschine ist:

$ systemctl status docker.service
● docker.service - Docker Application Container Engine
Geladen: geladen (/lib/systemd/system/docker.service; aktiviert; Hersteller-Voreinstellung: aktiviert)
Drop-In: /etc/systemd/system/docker.service.d
└─10-machine.conf
Aktiv: inaktiv (tot) (Ergebnis: Exit-Code) seit Fr 2017-07-07 13:34:47 UTC; Vor 36s
Dokumente: https://docs.docker.com
Prozess: 5522 ExecStart = / usr / bin / dockerd -H tcp: //0.0.0.0 : 2376 -H unix: ///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacer
Haupt-PID: 5522 (Code = beendet, Status = 1 / FEHLER)

07. Juli 13:34:46 test-dm systemd [1]: docker.service: Gerät in ausgefallenen Zustand versetzt.
07. Juli 13:34:46 test-dm systemd [1]: docker.service: Fehler mit Ergebnis 'Exit-Code'.
07. Juli 13:34:47 test-dm systemd [1]: docker.service: Service-Wartezeit abgelaufen, Neustart geplant.
07. Juli 13:34:47 test-dm systemd [1]: Docker Application Container Engine gestoppt.
07. Juli 13:34:47 test-dm systemd [1]: docker.service: Startanforderung zu schnell wiederholt.
07. Juli 13:34:47 test-dm systemd [1]: Docker Application Container Engine konnte nicht gestartet werden.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/docker/machine/issues/4156#issuecomment-313683311 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AANWZXHODzL3Lumb5NqlmXwnSi3VZBBkks5sLjUlgaJpZM4OIt7R
.

@dminkovsky Danke für die overlay2 da es sich stattdessen um eine neueste Version des Treibers handelt.

Wissen Sie, ob es auch eine Problemumgehung für docker-machine rm {instance-name} ? Ich erhalte eine Fehlermeldung in Bezug auf EOF und es verbleiben Reste von Schlüsselpaaren in der AWS-Cloud, die mich daran hindern, die Instanz neu zu erstellen.

Entschuldigung, ich habe meine Nachricht entfernt, nachdem ich hart debuggt habe und festgestellt habe, dass dies tatsächlich auf das zurückzuführen ist, was @dminkovsky geschrieben hat:

Ohne --engine-storage-driver=overlay schlägt es immer noch fehl
dockerd[6407]: Error starting daemon: error initializing graphdriver: driver not supported
wie zuvor und wie in # 3895

Haben wir ein Problem für diesen einen speziellen Fall der Verwendung von AUFS-Engine-Speicher?

@ Cadavre

Haben wir ein Problem für diesen einen speziellen Fall der Verwendung von AUFS-Engine-Speicher?

Ich habe https://github.com/docker/machine/issues/3895 gesehen, das offen ist und auf das Sie auch verwiesen haben.

Interessanterweise sehe ich diesen Fehler nicht mehr. Ich bekomme --storage-driver overlay

@ Drujensen

Ich habe mich für overlay2 entschieden, da es sich stattdessen um eine neueste Version des Treibers handelt.

Oh cool, danke, das wusste ich nicht.

Wissen Sie, ob es auch eine Problemumgehung für Docker-Maschine rm {Instanzname} gibt?

Ich bin mir nicht sicher, ob ich diesen Fehler nicht hatte. Ich verwende docker-machine rm -f wenn der Computer beendet wurde und nicht reagiert. Mit -f docker-machine rm die VM und die zugehörigen Festplatten, auch wenn sie die Box nicht erreichen können.

@dminkovsky Kannst du dafür eine neue Ausgabe erstellen? Es hat nichts mit dem Problem dockerd / docker daemon tun, daher sollten wir es auch separat behandeln. Und bitte geben Sie auch an, welches Betriebssystem Sie bereitstellen :)

@ shin- ich bin alles gut. Docker-Maschine arbeitet gerade 100% für mich. Beziehen Sie sich auf das Overlay2-Ding?

Mein anderes Problem beim Entfernen von Maschinen wurde in Pr # 4187 behoben. Danke.

@dminkovsky Entschuldigung - ja, die, die Sie hier erwähnen

@shin - Nachdem das Problem unter https://github.com/docker/machine/issues/4168 aufgetreten war , habe ich versucht, meinen Staging-Server neu zu erstellen, und es wurden einige Probleme mit docker-machine create festgestellt, die gemeldet wurden in mehreren aktuellen Tickets:

• https://github.com/docker/machine/issues/4156
• https://github.com/docker/machine/issues/4166
• https://github.com/docker/machine/issues/4189
• https://github.com/docker/machine/issues/4197
• https://github.com/docker/machine/issues/4198

Sind diese alle verwandt? Verfolgen Sie diese hier? Ich kann bestätigen, dass dieses Problem noch heute auftritt.

@ shin- docker-machine v0.12.1 weist immer noch das gleiche Problem auf

Ich bekomme immer noch das gleiche Problem mit Version 0.12.1.

Bitte aktualisieren Sie auf die neueste Version von github:
https://github.com/docker/machine/releases/tag/v0.12.2

@eamontaaffe @ajwah @costa

Danke @dminkovsky Ich habe diesen Fehler auch heute auf 0.12.2 bekommen !!! Scheint, als würde die Datei 10-machine.conf während des Updates nicht überschrieben

Bitte!

Ich gebe "Overlay" in der Befehlszeilenoption für die Speicher-Engine und seitdem an
die meine Maschinen booten.

ср, 2 авг. 2017 г. 12:05, Denis [email protected] :

Vielen Dank an @dminkovsky https://github.com/dminkovsky Ich habe das bekommen
Fehler auf 0.12.2 auch heute !!! Scheint, als ob die Datei 10-machine.conf dies nicht tut
werden während des Updates überschrieben

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/docker/machine/issues/4156#issuecomment-319719085 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AANWZSYqy1uGhWeXozx35OnFhPRSb144ks5sUJ5YgaJpZM4OIt7R
.

Wenn Sie Systeme mit Kernel> 4.4 verwenden, empfehle ich die Verwendung von overlay2 .

Ich konnte die Maschine nicht dazu bringen, overlay2 und den Anwendungsfall dafür zu verwenden
Zum Glück war nur Gebäude / CD

ср, 2 авг. 2017 г. 12:36, Seweryn Zeman [email protected] :

Wenn Sie Systeme mit Kernel> 4.4 verwenden, empfehle ich die Verwendung von Overlay2.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/docker/machine/issues/4156#issuecomment-319727847 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AANWZXLGHjLvfOOAgmBWV0zOEBDZBdSVks5sUKWBgaJpZM4OIt7R
.

Diesen Fehler wird auch auf 0.12.2 angezeigt :-(

das noch geöffnet!

Ich sehe dieses Problem immer noch mit docker-machine 0.12.2 . Ich bin vorwärts gegangen, indem ich Docker auf dem bereitgestellten Computer deinstalliert habe ( sudo apt purge docker-ce && sudo apt autoremove ) und habe das richtige Rancher-Installationsskript für meine Version verwendet, wie oben aufgeführt.

Aus irgendeinem Grund kann Docker immer noch nicht gestartet werden, aber ein Neustart des Computers löst das Problem.

Kann bestätigen, immer noch den gleichen Fehler

@jhartma Ich denke, ein Upgrade auf die neueste Version (Linux-Image) ist notwendig und funktioniert

@kassanmoor scheint, dass mein AMI es unter AWS nicht unterstützt hat, ich habe es mit dem Standard funktionieren lassen