Machine: Zertifikate werden nicht richtig installiert, immer neu generiert

Danke für die ausführliche Zusammenfassung. Ich habe solche Probleme auch schon gesehen und werde mich damit befassen.

Sind Sie auf der neuesten VirutalBox? dh 5.0.6?

Ich habe 5.0.4 verwendet, das mit der neuesten Version von Docker Toolbox (1.8.2c) geliefert wird. Ich habe gerade diese Version entfernt, 5.0.6 installiert und erlebe das gleiche Verhalten.

OK danke.

@carolynvs Wenn Sie das Host-only-Netzwerk entfernen, das Sie haben (kann dies in der VirtualBox-GUI tun) und es erneut versuchen, funktioniert es?

Ich habe die Maschine gelöscht, den Adapter entfernt und es erneut mit dem gleichen Ergebnis versucht.

OK danke. Sehr eigenartiges Verhalten. Ich könnte einen Test-Build erstellen, der weitere Informationen zu den Zertifikaten ausgibt, und schlage vor, dass Sie dies versuchen, wenn Sie damit einverstanden sind.

Natürlich! Ich helfe gerne, soweit ich kann.

Wenn Sie nur einen Zweig erstellen und mich darauf hinweisen möchten, kann ich ihn selbst erstellen (:heart: containerized builds!). Auf diese Weise müssen Sie nicht mehrere Builds über die Mauer werfen, wenn dies mehr als einen Versuch erfordert.

Eine andere Sache, die möglicherweise bei der Behebung dieses Problems berücksichtigt werden muss, ist, dass einige Leute wie ich tatsächlich den Inhalt von docker-machine env in eine Datei schreiben, die ich für jede neue Terminalsitzung beziehe (da es etwas schneller ist, als docker-machine env ). Wenn die Ausgabe dieses Befehls etwas enthält, das nicht eval d sein kann, wird dies offensichtlich Probleme verursachen.

Zeilen wie die folgenden verursachen also Probleme:

Invalid certs detected; regenerating for 192.168.99.100:2376
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...

Dieses Problem trat bei 0.5.0-dev , aber seit dem Downgrade auf 0.4.1 es nicht mehr aufgetreten.

Genau das gleiche Verhalten habe ich heute beim Release Candidate erlebt.

Hallo @carolynvs @blaggacao , vielen Dank für dein Feedback.

Ich versuche, diesen Fehler zu reproduzieren/zu beheben. Könnten Sie diese PR (https://github.com/docker/machine/pull/2006) ausprobieren, die ich erstellt habe, um den Fehler zu untersuchen?

Sieht so aus, als würde ich das auch sehen. Ich verwende den neuesten master Build unter OS X mit dem digitalocean Treiber, also hat dies definitiv nichts mit der Umgebung zu tun. Ich denke, die Tags area/windows und area/driver-virtualbox sind hier irrelevant :)

Hallo @hairyhenderson , kannst du PR #2006 erstellen und mir die Ausgabe für docker-machine -D env default mitteilen?

@dgageot - werde ich bei Gelegenheit tun.

Ich denke auch ein bisschen mehr darüber nach und stelle fest, dass ich einen _lokalen_ Build gemacht habe (dh make build unter OS X, ohne einen Container zu verwenden). Einer der Bereiche, in denen sich go build in der Vergangenheit anders verhalten hat, sind Zertifikate (insbesondere Root-CA-Zertifikate), also könnte dies damit zusammenhängen... Ich weiß nicht.

Aber ich werde mit #2006 umbauen und ausprobieren. Vielen Dank!

@hairyhenderson Das ist ein guter Punkt. Ich werde meine Tests mit einer kreuzkompilierten Docker-Maschine durchführen

@dgageot Hier ist die fehlgeschlagene Ausgabe https://gist.github.com/carolynvs/e2473d21c3376f1ebec2 von docker-machine -D env default für eine brandneue Maschine.

Ich habe #2006 erstellt und docker-machine.exe und docker-machine-driver-virtualbox.exe in das Installationsverzeichnis der Docker Toolbox kopiert. Ich verwende Docker Toolbox 1.8.2c unter Windows 10.

Ich kenne mich nicht so gut mit dem Bauen aus, vielleicht schaue ich mir das noch heute Abend an, wenn ich es hinbekomme.

@carolynvs Vielen Dank. Ich verstehe immer noch nicht, was los ist, aber Ihre Protokolle werden mir helfen.

@carolynvs Können Sie die Ausgabe bereitstellen von:

VBoxManage list hostonlyifs
VBoxManage list dhcpservers

C:\Program Files\Oracle\VirtualBox>VBoxManage list hostonlyifs
Name:            VirtualBox Host-Only Ethernet Adapter
GUID:            3729f60a-d9c3-4daa-96ca-7ce7bae4ddcc
DHCP:            Disabled
IPAddress:       192.168.56.1
NetworkMask:     255.255.255.0
IPV6Address:     fe80:0000:0000:0000:9d6d:4449:fce1:e1cb
IPV6NetworkMaskPrefixLength: 64
HardwareAddress: 0a:00:27:00:00:00
MediumType:      Ethernet
Status:          Up
VBoxNetworkName: HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter

Name:            VirtualBox Host-Only Ethernet Adapter #2
GUID:            99076a32-c9e5-4930-895a-a35ee45c2542
DHCP:            Disabled
IPAddress:       192.168.99.1
NetworkMask:     255.255.255.0
IPV6Address:     fe80:0000:0000:0000:118b:39e1:36b9:a336
IPV6NetworkMaskPrefixLength: 64
HardwareAddress: 0a:00:27:00:00:00
MediumType:      Ethernet
Status:          Up
VBoxNetworkName: HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter #2


C:\Program Files\Oracle\VirtualBox>VBoxManage list dhcpservers
NetworkName:    HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter
IP:             192.168.56.100
NetworkMask:    255.255.255.0
lowerIPAddress: 192.168.56.101
upperIPAddress: 192.168.56.254
Enabled:        Yes

NetworkName:    HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter #2
IP:             192.168.99.6
NetworkMask:    255.255.255.0
lowerIPAddress: 192.168.99.100
upperIPAddress: 192.168.99.254
Enabled:        Yes

Ich habe festgestellt, dass ich immer noch gelegentlich Double-Host-Only-Adapter bekomme. Ich habe gerade beide gelöscht und eine neue Maschine erstellt. Die Zertifikate werden immer noch regeneriert, wenn ich docker-machine env default ausführe.

Hier ist die Ausgabe der VBoxManage-Befehle beim zweiten Mal (mit nur 1 Host-Adapter).

C:\Program Files\Oracle\VirtualBox>VBoxManage list hostonlyifs
Name:            VirtualBox Host-Only Ethernet Adapter
GUID:            2883b47a-862d-454e-9db7-42c3789585eb
DHCP:            Disabled
IPAddress:       192.168.99.1
NetworkMask:     255.255.255.0
IPV6Address:     fe80:0000:0000:0000:90ff:fd25:e5f0:8c92
IPV6NetworkMaskPrefixLength: 64
HardwareAddress: 0a:00:27:00:00:00
MediumType:      Ethernet
Status:          Up
VBoxNetworkName: HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter


C:\Program Files\Oracle\VirtualBox>VBoxManage list dhcpservers
NetworkName:    HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter
IP:             192.168.99.6
NetworkMask:    255.255.255.0
lowerIPAddress: 192.168.99.100
upperIPAddress: 192.168.99.254
Enabled:        Yes

@carolynvs Ich habe noch keine Ahnung.
Ich habe noch ein paar Commits auf die PR geschoben, um mehr Informationen zu drucken und Dinge auszuprobieren.
Wenn Sie Zeit haben, die Ausgabe zu aktualisieren, die Sie erhalten, wäre das einfach großartig.

ping @nathanleclaire @dmp42 eine Idee?

Hier ist die neue Ausgabe: https://gist.github.com/carolynvs/84cd140bcbf9b696e20f.

Lassen Sie mich wissen, ob es eine andere Möglichkeit gibt, das Verbindungsproblem zu beheben. Ich bin mir nicht ganz sicher, welche Docker-Maschine erkennt, die dazu führt, dass die Zertifikate neu generiert werden, aber ich freue mich, in /var/lib/boot2docker auf dem Host herumzustöbern oder Zertifikate zwischen Windows und dem Host zu vergleichen usw zu suchen.

@carolynvs Das wäre cert.go :

Certs are not valid: read tcp 192.168.99.1:49755->192.168.99.100:2376: wsarecv: An established connection was aborted by the software in your host machine.

Entweder werden die Zertifikate nicht richtig auf die VM kopiert.
Oder die VM ist auf Port 192.168.99.100:2376 nicht erreichbar (Host-Netzwerkkonfiguration? Firewall, VPN? VM-Netzwerkkonfiguration?)
Oder es gibt ein Problem bei der Art und Weise, wie wir prüfen.

Wenn Sie die durch docker-machine env angegebenen env-Variablen exportieren und die Fehler ignorieren, können Sie dann eine Verbindung zum Docker-Daemon herstellen?

Ich kann den Docker-Host anpingen und per SSH hineingehen. Wenn ich die Meldungen zum Regenerieren von Zertifikaten von docker-machine env ignoriere und die Variablen manuell setze, kann ich mich immer noch nicht mit dem Docker-Client verbinden.

An error occurred trying to connect: Get https://192.168.99.101:2376/v1.20/containers/json: WSARecv tcp 192.168.99.1:50072: An established connection was aborted by the software in your host machine.

Die Zertifikate auf dem Host in /var/lib/boot2docker/tls/ stimmen nicht mit denen lokal in ~/.docker/machine/machines/default/ überein. Die Zertifikate in /var/lib/boot2docker/ stimmen mit dem überein, was sich auf meinem lokalen Computer befindet. Auch die certs in ~/.docker/machine/certs/ Streichhölzer , was in ist ~/.docker/machine/machines/default/ .

Ich vermute, dass das Problem darin liegt, dass die Zertifikate nicht übereinstimmen, was verhindert, dass sich die Docker-Maschine sicher mit dem Docker-Daemon verbindet und so eine Zertifikatsregenerierung auslöst?

Ich habe überprüft, ob der Docker-Daemon ausgeführt wird:

docker<strong i="18">@default2</strong>:/var/log$ ps aux | grep docker
root      2439  0.1  1.9 122904 19872 ?        Sl   13:23   0:00 /usr/local/bin/docker daemon -D -g /var/lib/docker -H unix:// -H tcp://0.0.0.0:2376 --label provider=virtualbox --tlsverify --tlscacert=/var/lib/boot2docker/ca.pem --tlscert=/var/lib/boot2docker/server.pem --tlskey=/var/lib/boot2docker/server-key.pem -s aufs

Hier sind auch die Logs von boot2docker und docker: https://gist.github.com/carolynvs/f7965455ebbceb85d4e6

:+1: Danke! Ich habe das Gefühl, wir kommen uns näher :smile:

IIRC, die Zertifikate in /var/lib/boot2docker/tls werden serverseitig von einem Startskript im boot2docker-Betriebssystem generiert und im aktuellen Maschinenmodell für nichts verwendet (sie sind ein Relikt davon, wie boot2docker-cli historisch erwartet hatte, dass die Zertifikate gesetzt werden oben).

@carolynvs @nathanleclaire Da habe ich keine Ahnung. Der einzige Unterschied, den ich in meinen Protokollen habe, ist, dass ich VBox Version 5.0.6 und einen neueren boot2docker verwende.

@carolynvs Können Sie versuchen, sich mit curl mit dem Docker-Daemon zu verbinden? Wir könnten ein besseres Feedback bekommen, was schief läuft. Ich denke, Sie verwenden Windows, also weiß ich nicht wirklich, wie ich das erreichen soll, aber so habe ich es unter OSX gemacht:

$ openssl pkcs12 -export -in ~/.docker/machine/certs/cert.pem -inkey ~/.docker/machine/certs/key.pem -out ~/.docker/machine/certs/cert.pfx -password pass:supersecret
$ curl -v --cacert ~/.docker/machine/machines/default/ca.pem --cert ~/.docker/machine/certs/cert.pfx --pass supersecret https://192.168.99.100:2376/version

*   Trying 192.168.99.100...
* Connected to 192.168.99.100 (192.168.99.100) port 2376 (#0)
* WARNING: SSL: Certificate type not set, assuming PKCS#12 format.
* Client certificate: dgageot
* WARNING: using IP address, SNI is being disabled by the OS.
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: default
* Server certificate: dgageot
> GET /version HTTP/1.1
> Host: 192.168.99.100:2376
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Server: Docker/1.8.3 (linux)
< Date: Tue, 20 Oct 2015 14:47:14 GMT
< Content-Length: 192
<
{"Version":"1.8.3","ApiVersion":"1.20","GitCommit":"f4bf5c7","GoVersion":"go1.4.2","Os":"linux","Arch":"amd64","KernelVersion":"4.1.10-boot2docker","BuildTime":"Mon Oct 12 18:01:15 UTC 2015"}
* Connection #0 to host 192.168.99.100 left intact

FTR, hier ist das Tutorial, mit dem ich es zum Laufen gebracht habe: http://opensolitude.com/2015/07/12/curl-docker-remote-api-os-x.html

@dgageot Ooh, ja, dies scheint ein Problem auf meinem Computer zu sein (mit curl/openssl von Git für Windows, damit alle Befehle gleich sind).

$ openssl pkcs12 -export -in ~/.docker/machine/certs/cert.pem -inkey ~/.docker/machine/certs/key.pem -out ~/.docker/machine/certs/cert.pfx -password pass:supersecret
Loading 'screen' into random state - done

caro8994<strong i="7">@CAROLYNVANS87E4</strong> MINGW64 ~
$ docker-machine ip default
192.168.99.100

caro8994<strong i="8">@CAROLYNVANS87E4</strong> MINGW64 ~
$ curl -v --cacert ~/.docker/machine/machines/default/ca.pem --cert ~/.docker/machine/certs/cert.pfx --pass supersecret https://192.168.99.100:2376/version
* timeout on name lookup is not supported
*   Trying 192.168.99.100...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to 192.168.99.100 (192.168.99.100) port 2376 (#0)
* ALPN, offering http/1.1
* could not load PEM client certificate, OpenSSL error error:0906D06C:PEM routines:PEM_read_bio:no start line, (no key found, wrong pass phrase, or wrong file format?)
* Closing connection 0
curl: (58) could not load PEM client certificate, OpenSSL error error:0906D06C:PEM routines:PEM_read_bio:no start line, (no key found, wrong pass phrase, or wrong file format?)

Ich habe alle Zertifikate in ~/.docker/machine/certs mit vi -b path/to/cert überprüft und überprüft, ob es Unix-Zeilenenden hat. Ich habe auch den folgenden Befehl verwendet, um zu überprüfen, ob openssl sie lesen konnte.

$ openssl x509 -in .docker/machine/certs/cert.pem -inform PEM -text -noout

Ich werde weiter mit Zertifikaten herumstöbern, da dies das Problem zu sein scheint. Probieren Sie es vielleicht auf einem anderen Computer aus und sehen Sie, ob es nur eine Windows 10-Sache ist.

@carolynvs Tolle Arbeit! Ich prüfe das morgen früh (Pariser Zeit)

Hallo @carolynvs , hast du diesen Befehl auch auf ca.pem ausprobiert?

openssl x509 -in ~/.docker/machine/machines/default/ca.pem -inform PEM -text -noout

Können Sie überprüfen, ob es richtig mit -----BEGIN CERTIFICATE----- beginnt und mit -----END CERTIFICATE----- endet. Vorher und nachher nichts.

@carolynvs Ich muss zugeben, dass ich nicht weiß, was los ist. Haben Sie diese PR ausprobiert, die vage verwandt zu sein scheint.

Wenn es Ihnen nichts ausmacht, diese Zwischenzusammenfassung zu bestätigen, kann ich mir im Stillen Gedanken darüber machen:

• Zertifikate werden kopiert, können aber nicht gelesen werden?

Ich bin sicher, Sie haben bereits nachgesehen: http://stackoverflow.com/questions/20837161/openssl-pem-routinespem-read-biono-start-linepem-lib-c703expecting-truste
Ich habe es als Referenz für andere verwendet.

Ich habe gerade einen anderen curl-Befehl mit --cert und --key anstelle der generierten pfx-Datei ausprobiert und er kann eine Verbindung herstellen.

$ curl --cacert ~/.docker/machine/machines/bugtest/ca.pem --cert ~/.docker/machine/machines/bugtest/cert.pem --key ~/.docker/machine/machines/bugtest/key.pem https://$(docker-machine ip bugtest):2376/version
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   192  100   192    0     0   1761      0 --:--:-- --:--:-- --:--:--  1761{"Version":"1.8.3","ApiVersion":"1.20","GitCommit":"f4bf5c7","GoVersion":"go1.4.2","Os":"linux","Arch":"amd64","KernelVersion":"4.1.10-boot2docker","BuildTime":"Mon Oct 12 18:01:15 UTC 2015"}

Wenn ich mir die Ausgabe von docker-machine env genauer ansehe, sehe ich, dass ein meiner Meinung nach fehlerhafter Zertifikatpfad exportiert wird. Auf meinem Mac zeigt dies auf .docker/machines/machine/während es in der Ausgabe unten auf .docker/machine/certs zeigt.

$ docker-machine env bugtest
Certs are not valid: remote error: bad certificate
Invalid certs detected; regenerating for 192.168.99.102:2376
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.102:2376"
export DOCKER_CERT_PATH="C:\Users\caro8994\.docker\machine\certs"
export DOCKER_MACHINE_NAME="bugtest"
# Run this command to configure your shell:
# eval "$(C:\Program Files\Docker Toolbox\docker-machine.exe env bugtest)"

Nachdem ich die Umgebungsvariablen manuell festgelegt und den Zertifikatspfad auf das geändert habe, was meiner Meinung nach hätte sein sollen, kann ich eine Verbindung mit dem Docker-Client herstellen.

Vielleicht verwendet Docker-Maschine die falschen Zertifikate, wenn sie testet, ob sie eine Verbindung herstellen kann?

Ich habe beim Validieren von Zertifikaten einige Debug-Informationen hinzugefügt und dann versucht, eine manuelle Verbindung herzustellen, indem zuerst der Docker-Computer verwendet wird, und dann das, was meiner Meinung nach verwendet werden sollte.

caro8994<strong i="16">@CAROLYNVANS87E4</strong> MINGW64 ~
$ docker-machine env bugtest
HOST URL=192.168.99.102:2376
CA CERT PATH=C:\Users\caro8994\.docker\machine\certs\ca.pem
SERVER CERT PATH=C:\Users\caro8994\.docker\machine\machines\bugtest\server.pem
SERVER KEY PATH=C:\Users\caro8994\.docker\machine\machines\bugtest\server-key.pem
Certs are not valid: read tcp 192.168.99.1:50658->192.168.99.102:2376: wsarecv: An established connection was aborted by the software in your host machine.
Invalid certs detected; regenerating for 192.168.99.102:2376
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.102:2376"
export DOCKER_CERT_PATH="C:\Users\caro8994\.docker\machine\certs"
export DOCKER_MACHINE_NAME="bugtest"
# Run this command to configure your shell:
# eval "$(C:\Program Files\Docker Toolbox\docker-machine.exe env bugtest)"

caro8994<strong i="17">@CAROLYNVANS87E4</strong> MINGW64 ~
$ curl --cacert ~/.docker/machine/certs/ca.pem --cert ~/.docker/machine/machines/bugtest/server.pem --key ~/.docker/machine/machines/bugtest/server-key.pem https://$(docker-machine ip bugtest):2376/version
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (35) error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate

caro8994<strong i="18">@CAROLYNVANS87E4</strong> MINGW64 ~
$ curl --cacert ~/.docker/machine/certs/ca.pem --cert ~/.docker/machine/machines/bugtest/cert.pem --key ~/.docker/machine/machines/bugtest/key.pem https://$(docker-machine ip bugtest):2376/version
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   192  100   192    0     0    472      0 --:--:-- --:--:-- --:--:--   472{"Version":"1.8.3","ApiVersion":"1.20","GitCommit":"f4bf5c7","GoVersion":"go1.4.2","Os":"linux", "Arch":"amd64","KernelVersion":"4.1.10-boot2docker","BuildTime":"Mon Oct 12 18:01:15 UTC 2015"}

Also ich sehe 2 verdächtige Dinge:

1. DOCKER_CERT_PATH verwendet .docker/machine/certs anstelle von .docker/machine/machines/
2. Validate verwendet server.pem und server-key.pem anstelle von cert.pem und key.pem. Ich weiß nicht, wofür jedes Zertifikat ist, aber das scheint nicht richtig zu sein.

Vielen Dank @carolynvs , das sollte wirklich helfen. Bevor ich alles verdaue, was Sie gemeldet haben, können Sie die neueste Version von https://github.com/docker/machine/pull/2006 ausprobieren. Sie sollte die für die Validierung verwendeten Zertifikate drucken. Das sollte helfen

Hier sind die verwendeten Zertifikate

HOST-URL=192.168.99.102:2376
CA CERT PATH=C:\Users\caro8994.docker\machine\certsca.pem
SERVER CERT PATH=C:\Users\caro8994.docker\machine\machines\bugtest\server.pem
SERVERSCHLÜSSELPFAD=C:\Users\caro8994.docker\machine\machines\bugtest\server-key.pem

Das ist von meinen eigenen Debug-Informationen, nicht der PR, deren Erstellung lange dauert, da alle Plugins erstellt werden. :Lächeln:

OK, jetzt bin ich verwirrt, also versuche ich es einfach noch einmal.

Können Sie das bestätigen:

• ~/.docker/machine/certs/ca.pem ist dasselbe wie ~/.docker/machine/machines/bugtest/ca.pem
• ~/.docker/machine/certs/cert.pem ist dasselbe wie ~/.docker/machine/machines/bugtest/cert.pem
• ~/.docker/machine/certs/key.pem ist dasselbe wie ~/.docker/machine/machines/bugtest/key.pem
• Sie haben es geschafft, dass docker cli den Server erreicht. Welchen Wert für DOCKER_CERT_PATH hast du dann verwendet?
• Auf Ihrem Mac druckt docker-machine env bugtest Export von DOCKER_CERT_PATH="~/.docker/machine" und nicht DOCKER_CERT_PATH="~/.docker/machine/certs"

Danke nochmal für die Unterstützung!

@carolynvs FTR, Cross-Building nur Docker-Maschine, nur für Windows sollte viel schneller sein: TARGET_ARCH=amd64 TARGET_OS=windows make build-x-machine

Sorry für den Hirndump!

• ca.pem, cert.pem und key.pm sind in ~/.docker/machine/certs und ~/.docker/machine/machines/bugtest
• Der Docker-Client hat funktioniert, als ich DOCKER_CERT_PATH auf ~.docker/machine/machines/bugtest
• Auf meinem Mac (der funktioniert) legt DOCKER_CERT_PATH="~/.docker/machine/machines/bugtest" docker-machine env DOCKER_CERT_PATH="~/.docker/machine/machines/bugtest" . Unter Windows 10 (was nicht der Fall ist) führt derselbe Befehl zu DOCKER_CERT_PATH="~/.docker/machine/certs"

Das war in meinem Hirndump, ist aber vielleicht verloren gegangen. Wenn docker-machine die Zertifikate validiert, versucht sie, sich mit server.pem und server-key.pem mit dem Docker-Daemon zu verbinden. Das sieht super fischig aus.

OK. Rufen wir @nathanleclaire und @ehazlett zur Rettung. Ich denke, Sie haben es geschafft, aber jetzt bin ich zu neu im Projekt, um zu verstehen, warum wir so viele duplizierte Zertifikate haben und warum wir nicht die richtigen verwenden.

Danke für den Bautipp!

Unten ist die relevante Ausgabe des neuesten Builds von PR #2006 und hier die vollständige Ausgabe: https://gist.github.com/carolynvs/8b7034c26fe3a764c537

Reading CA certificate from C:\Users\caro8994\.docker\machine\certs\ca.pem
Reading server certificate from C:\Users\caro8994\.docker\machine\machines\bugtest\server.pem
Reading server key from C:\Users\caro8994\.docker\machine\machines\bugtest\server-key.pem

Entschuldigung für das geschlossene/wieder geöffnete Geräusch. ich habe gefummelt

Oi vey. @carolynvs @dgageot ihr seid alle champs dafür, dass ihr diesen weiter jagt. Ich denke, Carolyns Verdacht ist richtig: Wenn DOCKER_CERT_PATH nicht richtig gesetzt wird, funktioniert die Kommunikation mit dem Daemon nicht richtig. Es hört sich so an, als ob es ein Problem mit Pfaden sein könnte, die ich versehentlich in den libmachine Änderungen eingeführt habe. Ich werde das weiter untersuchen und in Ihren bisherigen Erkenntnissen herumstöbern.

Kann also diese Linie das Tor zum Täter sein?
https://github.com/docker/machine/blob/8aa1572e0dcd75762a7627e1056ef104317f44b9/libmachine/persist/filestore.go#L155

@blaggacao Definitiv stark im Bereich des Möglichen - dieser Code ist tendenziell etwas spröde und war in der Vergangenheit problematisch.

Ich verstehe nicht, wie dies unter Windows und Mac OS unterschiedlich sein kann, obwohl
Für mich konstruiert es eindeutig den Pfad .docker\machine\certs .

diff .docker/machine/certs/ca.pem .docker/machine/machines/oca/ca.pem
diff .docker/machine/certs/cert.pem .docker/machine/machines/oca/cert.pem
diff .docker/machine/certs/key.pem .docker/machine/machines/oca/key.pem

bleibt stumm.

@blaggacao eindeutig, ich habe nicht das gleiche Verhalten wie @carolynvs auf dem Mac. Es ist also etwas faul.

Ja, die Zertifikate werden während des Bereitstellungsbits in das Verzeichnis dieser Maschine kopiert.

@dgageot Entschuldigung für die Verwirrung. Auf meinem Mac läuft docker-machine 0.4.1. Ich führe den PR-Build nur auf meinem Windows-Rechner aus, da ich dort Fixes getestet habe, die mit dem Master zusammengeführt werden.

Ich kann jetzt einen Build erstellen und auf meinem Mac erneut ausführen.

Ich fasse zusammen:

• diffs zeigen keinen Unterschied zwischen /machine/certs und /machine/machines/certs
• Ich kann carlynvs Workaround nicht reproduzieren, um das Problem zu lösen.

Wenn Sie DOCKER_CERT_PATH unter Windows (in der bash) manuell festlegen, sollten Sie Pfade im UNIX-Stil verwenden. Beispiel: export DOCKER_CERT_PATH="~./docker/machine/machines/oca" .

Ich kann bestätigen, dass auf meinem (wackligen) Computer die Zertifikate zwischen /machine/certs und /machine/machines/certs übereinstimmen.

Ich kann durch manuelles Kopieren bestätigen, da scp nicht funktioniert:

diff ca.pem.local       ca.pem.vm       FALSE
diff server.pem.local   server.pem.vm   TRUE
diff key.pam.local      key.pem.vm      TRUE

die zweite und dritte unterscheiden sich zwischen /machines/oca und oca:~/.docker

Welche Pfade in der VM verwenden Sie für die Zertifikate @blaggacao ?

Mir ist gerade aufgefallen, dass es der falsche war...

Ich habe gegen ~/.docker gecheckt Ich werde noch einmal gegen /var/lib/boot2docker prüfen

Das kann ich auf jeden Fall bestätigen

• die Zertifikate in /machines/oca und oca:/var/lib/boot2docker/ sind gleich
  ( Ich führe dos2unix auf allen 3 Feldern aus ca.pem , server.pem , sever-key.pem auf oca )

Ich bekomme zusätzlich diesen Timeout-Fehler: https://github.com/docker/machine/blob/6a5219b879db52698ccb2b7e0aafd516b34df839/libmachine/provision/boot2docker.go#L193
Jedes Mal, wenn ich env ausführe, entweder mit dem --native-ssh Flag oder nicht

Ja, @blaggacao sieht auch so aus, als ob die der VM zugewiesene Host-only-IP auf Ihrem Computer nicht erreichbar ist. Kannst du ping $(docker-machine ip vmname) ?

nein, funktioniert auch nicht... "Zeitüberschreitung der Anforderung"

docker-machine ssh vmname funktioniert aber

Ja, ssh geht durch localhost . Aber es scheint, dass Sie die zugewiesene Host-only-VM-IP nicht kontaktieren können, daher würde ich nicht erwarten, dass env ordnungsgemäß funktioniert. Verwenden Sie ein VPN oder einen Proxy?

nicht, dass ich es wüsste, habe nur den Task-Manager überprüft ... UPDATE hat einen gefunden, wird geschlossen

Das Schließen ändert nichts, aber das ist ein anderes Problem, denke ich...

https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/commands/config.go#L88

führt mich zu

https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/libmachine/cert/cert.go#L177

Da ich keine bekomme von: https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/libmachine/cert/cert.go#L22

die einzigen verbleibenden Kandidaten sind:
https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/libmachine/cert/cert.go#L198 -L205

Das riecht nach einem Zusammenhang zwischen beiden Problemen. Können Sie meinen Gedankengang interpretieren?

Graben aus der Ferne: https://github.com/leo-stone/fix-go-1.5-tls-issue/blob/master/main.go

Ich traute meiner Windows-Umgebung nicht mehr, also fing ich von vorne an und baute Windows neu auf und legte dann #2006 auf.

In der docker.log-Datei sehe ich diesen Fehler

2015/10/21 17:06:23 http: TLS handshake error from 192.168.99.1:50386: tls: failed to verify client's certificate: x509: certificate has expired or is not yet valid

Also habe ich die Daten des Zertifikats überprüft

$ openssl x509 -in server.pem -noout -dates
notBefore=Oct 21 22:00:00 2015 GMT
notAfter=Oct  5 22:00:00 2018 GMT

Könnte das Problem sein, dass das Zertifikat in die Zukunft datiert ist? Das würde erklären, warum meine Curl-Befehle ursprünglich nicht funktionierten, aber ein paar Stunden später funktionierten sie.

hier gilt das gleiche:

$ openssl x509 -in .docker/machine/machines/oca/server.pem -noout -dates
notBefore=Oct 21 22:00:00 2015 GMT
notAfter=Oct  5 22:00:00 2018 GMT

Das ist in ungefähr 5 Stunden in meiner Zeitzone (Bogota/Americas) Nun, aber dort steht GMT (UTC). Bogota ist UTC-5

docker<strong i="5">@oca</strong>:~$ time
BusyBox v1.23.1 (2015-02-22 15:53:49 UTC) multi-call binary.

Update: FIX

Wie hier angegeben: https://github.com/docker/docker/issues/11534#issuecomment -89405874

docker-machine ssh vmname
sudo ntpclient -s -h pool.ntp.org

hat mir einen anderen Fehler ergeben (einen Schritt nach dem anderen :)

Ich denke, das ist es, der Rest ist meine Virtualbox.

Ich werde zu Abend essen und in 5 Stunden wieder nachschauen, wenn ich vermute, dass mein Zertifikat gültig ist und alles funktioniert. :Lächeln:

Schlechte Nachrichten, ich muss dies bei jedem VM-Neustart tun.

:smile: Ich schätze, du hast die Ursache getroffen! Vielen Dank!

: klatschen:: klatschen:: klatschen:: klatschen:: klatschen:: klatschen:: klatschen:

@carolynvs hat der Fix, den ich gepostet habe, für Sie funktioniert?

Ich wollte nur bestätigen, dass docker-machine env funktioniert, nachdem ich 5 Stunden gewartet hatte, bis das Zertifikat gültig war. Keine Ahnung, warum ich Zertifikate erhalte, die in die Zukunft datiert sind, aber vielleicht sollte das Problem aktualisiert werden, um die wahre Ursache widerzuspiegeln, die wir jetzt kennen.

In meinem Fall waren nicht die Zertifikate das Problem, sondern die Zeiteinstellung auf boot2docker... Wie ich auf deinem Github-Profil sehen kann, bist du aus Chicago, das ist eine ähnliche Zeitzone wie Bogota, vielleicht wird der boot2docker in unseren Zeitzonen falsch eingerichtet ...

Nach der Synchronisierung der Uhrzeit mit Ihrer Problemumgehung erhalte ich immer noch den gleichen Fehler (Zertifikat ist abgelaufen oder noch nicht gültig), wenn ich diese Zertifikate zum Herstellen einer Verbindung mit meinem Docker-Host verwende.

Auf meinem Mac sehe ich dies, nachdem ich eine neue Box erstellt und ihre Zeit überprüft habe.

docker<strong i="7">@bugtest</strong>:~$ time
BusyBox v1.23.1 (2015-02-22 15:53:49 UTC) multi-call binary.

docker<strong i="8">@bugtest</strong>:~$ hwclock
Thu Oct 22 15:54:29 2015  0.000000 seconds

docker<strong i="9">@bugtest</strong>:~$ date
Thu Oct 22 15:54:06 UTC 2015

docker<strong i="10">@bugtest</strong>:~$ openssl x509 -in /var/lib/boot2docker/server.pem -noout -dates
notBefore=Oct 22 15:48:00 2015 GMT
notAfter=Oct  6 15:48:00 2018 GMT

Hier sind die gleichen Befehle auf einem neuen Host unter Windows:

docker<strong i="14">@bugtest</strong>:~$ time
BusyBox v1.23.1 (2015-02-22 15:53:49 UTC) multi-call binary.

docker<strong i="15">@bugtest</strong>:~$ hwclock
Thu Oct 22 15:58:56 2015  0.000000 seconds

docker<strong i="16">@bugtest</strong>:~$ date
Thu Oct 22 10:58:58 UTC 2015

docker<strong i="17">@bugtest</strong>:~$ openssl x509 -in /var/lib/boot2docker/server.pem -noout -dates
notBefore=Oct 22 15:45:00 2015 GMT
notAfter=Oct  6 15:45:00 2018 GMT

Das Datum zeigt meine Ortszeit an, glaubt aber, dass es UTC ist und ich weiß nicht, wie ich es aktualisieren kann, damit es mit der hwclock übereinstimmt. Ich habe versucht, das Datum manuell zu ändern, aber entweder bei busybox oder virtualbox gibt es etwas, das jede Änderung sofort rückgängig macht.

Dies ist seit gestern der Arbeitsstatus, nachdem die Problemumgehung angewendet wurde:

docker<strong i="6">@oca</strong>:~$ time
BusyBox v1.23.1 (2015-02-22 15:53:49 UTC) multi-call binary.
docker<strong i="7">@oca</strong>:~$ hwclock
Thu Oct 22 10:10:46 2015  0.000000 seconds
docker<strong i="8">@oca</strong>:~$ date
Thu Oct 22 16:28:19 UTC 2015
docker<strong i="9">@oca</strong>:~$
docker<strong i="10">@oca</strong>:~$ openssl x509 -in /var/lib/boot2docker/server.pem -noout -dates
notBefore=Oct 21 22:32:00 2015 GMT
notAfter=Oct  5 22:32:00 2018 GMT

hier entspricht date meiner Ortszeit in UTC

einige Hinweise zu meinen Symptomen: https://forums.virtualbox.org/viewtopic.php?f=3&t=60558#p281836

time ist eingefroren, nach 10 Minuten: docker<strong i="18">@oca</strong>:~$ time BusyBox v1.23.1 (2015-02-22 15:53:49 UTC) multi-call binary.

da date in meinem Fall das korrekte Datum anzeigt, gehe ich davon aus, dass das Problemumgehungs-Festdatum in meinem Fall und damit das Problem ist.

cc @tianon @SvenDowideit PTAL im obigen RE: boot2docker Zeit-/Datumsprobleme ^^

Ein Code, den ich gefunden habe, trägt möglicherweise zum Zeitstempelproblem bei:

https://github.com/docker/machine/blob/master/libmachine/cert/cert.go#L53 -L56

Aber vorher hat es immer gut funktioniert.

@carolynvs @blaggacao Sind diese Probleme immer noch

Bei mir funktioniert es nach dem referenzierten Workaround. Dies wiederum weist darauf hin, dass einige Boot2Docker-Zeitparameter nicht richtig eingestellt sind. Typischerweise würde es dann nur während eines begrenzten Zeitrahmens direkt nach der Maschinenerstellung auftreten. (Wahrscheinlich nur in einigen Zeitzonen).

Dies wiederum würde bedeuten, dass die Zeitstempel der Zertifikate korrekt sind.

Ich bin gerade wieder darüber gestolpert, nachdem ich den PC auf meinem RC neu gestartet habe, aber nach dem Update auf 5.0 scheint alles zu funktionieren. Wir könnten dies wahrscheinlich vorerst schließen. Wie auch immer, sobald ich ein seltsames Verhalten bemerke, würde ich es wieder öffnen.

https://gist.github.com/damontic/bd60b6a18cacf635dc9c

Ich habe dieses Problem auch. Schließen Sie es nicht.

@damontic Das sieht nach einem anderen Problem aus als das hier besprochene.

Ich versuche, einen Schwarm auf DigitalOcean einzurichten, und ich habe den gleichen Fehler.

init-do.sh-Datei, die einen KV-Speicher, einen Schwarm-Master und einen Knoten erstellt:

 # KV Store
docker-machine create \
--driver digitalocean \
--digitalocean-access-token ${TOKEN} \
--digitalocean-region "lon1" \
--digitalocean-size "1gb" \
consul
eval "$(docker-machine env consul)"
docker run -d -p "8500:8500" -h "consul" progrium/consul -server -bootstrap

sleep 5

# Swarm master
docker-machine create \
--driver digitalocean \
--digitalocean-access-token ${TOKEN} \
--digitalocean-region "lon1" \
--digitalocean-size "1gb" \
--swarm --swarm-image="swarm" --swarm-master \
--swarm-discovery="consul://$(docker-machine ip consul):8500" \
--engine-opt="cluster-store=consul://$(docker-machine ip consul):8500" \
--engine-opt="cluster-advertise=eth1:2376" \
demo0

sleep 5

# Swarm node
docker-machine create \
--driver digitalocean \
--digitalocean-access-token ${TOKEN} \
--digitalocean-region "lon1" \
--digitalocean-size "1gb" \
--swarm --swarm-image="swarm:1.0.0-rc2" \
--swarm-discovery="consul://$(docker-machine ip consul):8500" \
--engine-opt="cluster-store=consul://$(docker-machine ip consul):8500" \
--engine-opt="cluster-advertise=eth1:2376" \
demo1

Das Protokoll / der Fehler, den ich bekomme

$> ./init-do.sh
Running pre-create checks...
Creating machine...
(consul) OUT | Creating SSH key...
(consul) OUT | Creating Digital Ocean droplet...
(consul) OUT | Waiting for IP address to be assigned to the Droplet... 
Waiting for machine to be running, this may take a few minutes... 
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Detecting the provisioner...
Provisioning created instance...
Copying certs to the local machine directory... 
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
To see how to connect Docker to this machine, run: docker-machine env consul
Unable to find image 'progrium/consul:latest' locally
latest: Pulling from progrium/consul
3b4d28ce80e4: Pull complete
...
d9125e9e799b: Pull complete
Digest: sha256:8cc8023462905929df9a79ff67ee435a36848ce7a10f18d6d0faba9306b97274
Status: Downloaded newer image for progrium/consul:latest
ab964fd70394d34f8d1de5c76246490b5857adaffbc1c02235bdc53663c33b37
Running pre-create checks...
Creating machine...
(demo0) OUT | Creating SSH key...
(demo0) OUT | Creating Digital Ocean droplet...
(demo0) OUT | Waiting for IP address to be assigned to the Droplet...
Waiting for machine to be running, this may take a few minutes... 
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Detecting the provisioner...
Provisioning created instance...
Copying certs to the local machine directory... 
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Error creating machine: Error running provisioning: Unable to verify the Docker daemon is listening:        Maximum number of retries (5) exceeded
Running pre-create checks...
Creating machine...
(demo1) OUT | Creating SSH key...
(demo1) OUT | Creating Digital Ocean droplet...
(demo1) OUT | Waiting for IP address to be assigned to the Droplet...  
Waiting for machine to be running, this may take a few minutes...
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Detecting the provisioner...
Provisioning created instance...
Error creating machine: Error running provisioning: Something went wrong running an SSH command!
command : sudo apt-get update
err     : exit status 100
output  : Ign http://mirrors.digitalocean.com trusty InRelease
Get:1 http://mirrors.digitalocean.com trusty-updates InRelease [64.4 kB]
Hit http://mirrors.digitalocean.com trusty Release.gpg
Hit http://mirrors.digitalocean.com trusty Release
Get:2 http://mirrors.digitalocean.com trusty-updates/main Sources [244 kB]
Get:3 http://mirrors.digitalocean.com trusty-updates/universe Sources [144 kB]
Get:4 http://mirrors.digitalocean.com trusty-updates/main amd64 Packages [652 kB]
Get:5 http://mirrors.digitalocean.com trusty-updates/universe amd64 Packages [331 kB] 
Get:6 http://mirrors.digitalocean.com trusty-updates/main i386 Packages [631 kB]
Get:7 http://mirrors.digitalocean.com trusty-updates/universe i386 Packages [332 kB]
Get:8 http://mirrors.digitalocean.com trusty-updates/main Translation-en [319 kB]
Get:9 http://security.ubuntu.com trusty-security InRelease [64.4 kB]
Get:10 http://mirrors.digitalocean.com trusty-updates/universe Translation-en [173 kB]
Hit http://mirrors.digitalocean.com trusty/main Sources
Hit http://mirrors.digitalocean.com trusty/universe Sources
Hit http://mirrors.digitalocean.com trusty/main amd64 Packages
Hit http://mirrors.digitalocean.com trusty/universe amd64 Packages
Hit http://mirrors.digitalocean.com trusty/main i386 Packages
Hit http://mirrors.digitalocean.com trusty/universe i386 Packages
Hit http://mirrors.digitalocean.com trusty/main Translation-en
Hit http://mirrors.digitalocean.com trusty/universe Translation-en
Ign http://mirrors.digitalocean.com trusty/main Translation-en_US
Ign http://mirrors.digitalocean.com trusty/universe Translation-en_US
Get:11 http://security.ubuntu.com trusty-security/main Sources [99.2 kB]
Get:12 http://security.ubuntu.com trusty-security/universe Sources [32.5 kB]
Get:13 http://security.ubuntu.com trusty-security/main amd64 Packages [370 kB]
Get:14 http://security.ubuntu.com trusty-security/universe amd64 Packages [122 kB]
Get:15 http://security.ubuntu.com trusty-security/main i386 Packages [350 kB]
Get:16 http://security.ubuntu.com trusty-security/universe i386 Packages [123 kB]   
Get:17 http://security.ubuntu.com trusty-security/main Translation-en [200 kB]
Get:18 http://security.ubuntu.com trusty-security/universe Translation-en [69.6 kB]
Fetched 4,323 kB in 4s (925 kB/s) 
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/trusty-security/universe/i18n/Translation-en    Hash Sum mismatch

E: Some index files failed to download. They have been ignored, or old ones used instead.

Bevor ich dies ausgeführt habe, habe ich auf Machine 0.5.1 aktualisiert

$ docker-machine -v
docker-machine version 0.5.1 (7e8e38e)

Ich kann zum Kontext der Maschine "consul" wechseln, aber nicht zu "demo0" oder "demo1"

$ docker-machine env consul
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://178.62.93.196:2376"
export DOCKER_CERT_PATH="/Users/luc/.docker/machine/machines/consul"
export DOCKER_MACHINE_NAME="consul"
# Run this command to configure your shell:
# eval "$(/usr/local/bin/docker-machine env consul)"

$ docker-machine env    demo0
Error running connection boilerplate: Error checking and/or regenerating the certs: There was an error   validating certificates for host "46.101.74.179:2376": dial tcp 46.101.74.179:2376: getsockopt: connection  refused
You can attempt to regenerate them using 'docker-machine regenerate-certs name'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

$ docker-machine env demo1
Error running connection boilerplate: Error checking and/or regenerating the certs: There was an error  validating certificates for host "46.101.17.195:2376": open   /Users/luc/.docker/machine/machines/demo1/server.pem: no such file or directory
You can attempt to regenerate them using 'docker-machine regenerate-certs name'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

@lucj Wenn die Bereitstellung fehlschlägt, sind die erstellten Instanzen "ungültig". Versuchen Sie, sie zu entfernen und von vorne zu beginnen.

@nathanleclaire Ich habe gerade die Maschinen gelöscht (ist 'docker-machine rm consul demo0 demo1' genug oder sollte ich andere Dinge manuell löschen?) und mit der Setup-Datei erneut ausführen, und ich habe das gleiche Zertifikatsproblem (beim Erstellen auf DigitalOcean). Seltsam ist, dass es mit der 'Konsul'-Maschine kein Problem gibt, sondern nur mit den Schwarm-Maschinen (demo0, demo1).

Beim Erstellen des Schwarms auf VirtualBox (5.0.10) funktioniert es jedoch einwandfrei.

Ich sehe dies, wenn ich den AWS-Treiber verwende

Ich habe mehrere Tests durchgeführt (eigentlich viele), nachdem ich die VM gelöscht und neu erstellt habe (mit einem Schwarm) habe ich immer noch das gleiche Problem.

Ich habe dieses Problem jetzt nach dem Upgrade von Version 1.8 auf 1.9.1 mit der Docker-Toolbox unter MacOSX 10.10.5

Error running connection boilerplate: Error checking and/or regenerating the certs: There was an error validating certificates for host "192.168.99.100:2376": dial tcp 192.168.99.100:2376: getsockopt: connection refused
You can attempt to regenerate them using 'docker-machine regenerate-certs name'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

command failed; 1

Das passiert mir auch regelmäßig. Docker v1.9.1

Gleiches Problem hier mit Azure-Treiber. Jedes Mal, wenn ich eine neue Azure-Maschine erstelle, schlägt sie mit dem folgenden Fehler fehl:

Error creating machine: Error checking the host: Error checking and/or regenerating the certs: There was an error validating certificates for host "testcargo2-prefapp-in.cloudapp.net:2376": tls: DialWithDialer timed out
You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'

Nach dem Ausführen von docker-machine regenerate-certs funktioniert die Zertifikatsvalidierung einwandfrei.

In docker-machine v0.5.5 gibt es kein Problem und das Erstellen eines Docker-Hosts funktioniert einwandfrei:

Running pre-create checks...
Creating machine...
(testcargo3-prefapp-in) Creating Azure machine...
Waiting for machine to be running, this may take a few minutes...
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Detecting the provisioner...
Provisioning with ubuntu(upstart)...
Installing Docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect Docker to this machine, run: docker-machine env 

@alambike Sie haben dieses Problem mit 0.6.0?

Ja, ab 0.5.5. Ich habe dies mit 0.5.6 und 0.6.0 getestet.

das gleiche für mich auf 0.6.0 mit aws-Treiber (ständig) auf mac 10.10.5. Nicht passiert mit virtuellem Box-Treiber.

behoben, nachdem --engine-opt="cluster-advertise=eth1:2376" in --engine-opt="cluster-advertise=eth0:2376" mit docker-machine 0.6.0 geändert wurde (docker-machine 0.5.4 schlägt immer noch fehl)

Ich glaube, ich habe das gleiche Problem auf meiner Maschine. Ich verwende Ubuntu 14.04
Docker-Maschine Version 0.5.5, Build 02c4254
Ausführen des Hosts auf RHEL 7.1
Serverversion: 1.10.2-cs1-rc3

Habe alles versucht, was mit der Zeit auf den Maschinen vorgeschlagen wurde, hier ist die Ausgabe, die ich von curl bekomme get

curl -v --cacert ~/.docker/machine/certs/ca.pem --cert ~/.docker/machine/machines/$NODE_NAME/cert.pem --key ~/.docker/machine/machines/$NODE_NAME /key.pem https://$(Docker-Rechner-IP $NODE_NAME):2376/version

• Hostname wurde NICHT im DNS-Cache gefunden
• 16.85.3.140 versuchen...
• Verbunden mit 16.85.3.140 (16.85.3.140) Port 2376 (#0)
• Zertifikatsüberprüfungsstandorte erfolgreich festgelegt:
• CAfile: /home/eraigosa/.docker/machine/certs/ca.pem
  CApath: /etc/ssl/certs
• SSLv3, TLS-Handshake, Client hallo (1):
• SSLv3, TLS-Handshake, Server hallo (2):
• SSLv3, TLS-Handshake, CERT (11):
• SSLv3, TLS-Handshake, Serverschlüsselaustausch (12):
• SSLv3, TLS-Handshake, CERT anfordern (13):
• SSLv3, TLS-Handshake, Server fertig (14):
• SSLv3, TLS-Handshake, CERT (11):
• SSLv3, TLS-Handshake, Client-Schlüsselaustausch (16):
• SSLv3, TLS-Handshake, CERT-Verifizierung (15):
• SSLv3, TLS-Chiffre ändern, Client hallo (1):
• SSLv3, TLS-Handshake, Fertig (20):
• SSLv3, TLS-Warnung, Server hallo (2):
• error:14094412 :SSL- Routinen:SSL3_READ_BYTES :sslv3-Warnung fehlerhaftes Zertifikat
• Verbindung schließen 0
  curl: (35) error:14094412 :SSL- Routinen:SSL3_READ_BYTES :sslv3-Warnung fehlerhaftes Zertifikat

@nathanleclaire Ich habe den Kultprinzen gefunden! prltoolsd von boot2docker stellt mein Datum/Zeitzone ständig falsch ein.

$ date
<the current local time with the timezone set to UTC>

$ date -s '<the correct time in UTC>'
<prints the correct time>

$ date
<the date/time is now broken again>

$ /usr/local/etc/init.d/prltoolsd stop

$ date -s '<the correct time in UTC>'
<prints the correct time>

$ date
<prints the correct time and stays put>

Nach dem Stoppen von prltoolsd und dem Zurücksetzen des Datums funktionieren alle meine Docker-Computer-Befehle wie erwartet und meine Zertifikate werden nicht neu generiert.

Ich weiß immer noch nicht, warum die Zeitzone auf UTC und die Zeit auf Ortszeit eingestellt ist, nachdem eine neue Maschine erstellt wurde. Dies ist also nur ein Workaround, kein Fix.

Schön @carolynvs ! Wir werden daran arbeiten zu sehen, ob wir dies in boot2docker beheben können.

@tianon @legal90 Zur Info ^^

@carolynvs Wow :ängstlich: . Es sieht wirklich seltsam aus, denn der prltoolsd Prozess sollte auf keinem anderen Virtualisierungssystem außer Parallels Desktop gestartet werden. Der Daemon startet nur, wenn /usr/bin/prlvmcheck 0 Exit-Code zurückgibt, was bedeutet, dass wir uns in Parallels VM befinden.

Haben Sie dieses Problem auf der Virtualbox-VM reproduziert? Welche Boot2Docker-Version verwendest du?

Ps Auch wenn wir davon ausgehen, dass prltoolsd der einzige Grund ist, dann sollte die Docker Machine-Version keinen Sinn machen. Andere Kommentare oben ( Link ) weisen jedoch darauf hin, dass das Problem nur in Maschine 0.5.5+ auftritt

@legal90 Das macht mehr Sinn. Meine Umgebung ist ein bisschen wackelig, aber früher hat es gut funktioniert:

1. Ich verwende einen Mac mit Parallels.
2. Innerhalb von Parallels führe ich Windows aus, dann die neueste Docker-Toolbox-Installation. Ich tue dies, weil ich Dokumentationen und Tutorials für Docker schreibe und auf Mac-, Linux- und Windows-Benutzer abzielen muss.

Dies erklärt, warum prltoolsd versucht, meine Docker-Host-Uhr zu verwalten. Es muss die Verschachtelung in Parallels aufnehmen. Erklärt das auch, warum die Systemuhr auf die Ortszeit eingestellt ist, sie aber für UTC hält?

Das ist das Grundproblem, das mich veranlasst hat, diesen Fehler zu öffnen. Ich erstelle um 10 Uhr CST (-6) eine neue Docker-Maschine. Die Systemuhr ( date ) auf dem neuen Computer geht davon aus, dass es 10 Uhr UTC ist, daher sind die Zeitstempel auf den Zertifikaten "in der Zukunft". hwclock meldet die richtige Uhrzeit.

Als ich mir das boot2docker Dockerfile ansah, bemerkte ich, dass es /etc/timezone auf UTC setzt und _sollte_ auch /etc/localtime auf UTC gesetzt haben.

siehe https://github.com/boot2docker/boot2docker/blob/master/Dockerfile#L311

RUN echo 'UTC' > $ROOTFS/etc/timezone \
    && cp -L /usr/share/zoneinfo/UTC $ROOTFS/etc/localtime

Aber auf meinem Docker-Rechner-Host ist das tzdata-Paket nicht installiert, also existiert weder /usr/share/zoneinfo noch /etc/localtime . Ich habe meinen eigenen boot2docker aus dem neuesten Dockerfile erstellt, nur um zu überprüfen, ob ich keine alte ISO verwende. Ich frage mich, ob das Fehlen der /etc/localtime Datei zu dem Problem mit der falschen Zeit beiträgt.

@carolynvs Ah, jetzt habe ich es verstanden.

Dies erklärt, warum prltoolsd versucht, meine Docker-Host-Uhr zu verwalten. Es muss die Verschachtelung in Parallels aufnehmen.

Ja, das ist die Wurzel des Problems. prltoolsd in Virtualbox VM ausgeführt, die in Parallels VM verschachtelt ist. Ich habe dies reproduziert und den Verantwortlichen bei Parallels gemeldet. Ich melde mich sobald es behoben ist.

Erklärt das auch, warum die Systemuhr auf die Ortszeit eingestellt ist, sie aber für UTC hält?

Nun, es ist schwer, sich darauf festzulegen, aber es ist ein bekanntes Problem von Parallels Desktop (und seinen Gasttools). Es wurde ursprünglich hier gemeldet: https://github.com/Parallels/vagrant-parallels/issues/186.
Es wurde in PD 11 durch eine zusätzliche Option für das Dienstprogramm prlctl umgangen, aber es hilft in Ihrem seltenen Fall nicht, da Sie Virtualbox VM tatsächlich unter Windows ausführen.

Es tut mir leid, aber die einzige Lösung, die ich Ihnen im Moment vorschlagen kann, besteht darin, zu verhindern, dass prltoolsd in Ihrer VM beim Booten ausgeführt wird. Wenn Sie einen benutzerdefinierten Boot2Docker-ISO-Build verwenden, können Sie parallelsbezogene Zeilen aus Dockerfile entfernen und die ISO neu erstellen. Oder kommentieren Sie diese Zeile aus: https://github.com/boot2docker/boot2docker/blob/master/rootfs/rootfs/bootscript.sh#L101

Vielen Dank für die zusätzlichen Informationen zur Funktionsweise von prltoolsd! Ich werde tun, was Sie vorschlagen und eine benutzerdefinierte ISO für mein Setup erstellen. :Bier:

Ich würde dieses Problem schließen, da dies mein Problem behebt, aber ich überlasse das Ihnen, da andere Leute darauf zu stoßen scheinen (wenn auch wahrscheinlich aus anderen Gründen!).

Ich denke, wir können es als effektiv gelöst behandeln; Wir können wieder öffnen, wenn neue Probleme entdeckt werden.

Vielen Dank an alle für Ihre Beiträge zur Berichterstattung und Prüfung dieser episch langen Ausgabe!

Ich verwende DockerToolbox 1.10.3 unter Windows. Bis zum Neustart funktionierte es einwandfrei und jetzt habe ich das gleiche Problem. Ich kenne Docker auch nicht so gut, kann mir jemand sagen, was die Lösung ist?

@mtrtm Funktioniert docker-machine regenerate-certs -f nicht?

Ja, docker-machine regenerate-certs -f tut dies. Es scheint auch jedes Mal zu tun, wenn ich Docker Quickstart Terminal starte

+1
Ich verwende Docker hauptsächlich auf einem Redhat-Server und alles funktioniert einwandfrei. Ich bin kein Experte, aber ich weiß was ich tue. Unter Windows mit Virtualbox muss ich jedoch jedes Mal, wenn die Docker-VM neu gestartet wird, Zertifikate neu generieren. Ich bin auf Toolbox 1.11.1

+1

Macbook Ende 2009
2,26 GHz Intel Core 2 Duo
Mac OS Sierra 10.12
Docker Tollbox 1.2.1
VirtualBox 5.0.26

$ docker-machine ls
NAME AKTIVER FAHRERSTATUS URL SWARM DOCKER ERRORS
vbox-test - virtualbox Ausführen von tcp://192.168.99.100 :2376 Unbekannt Docker-Version kann nicht abgefragt werden: https://192.168.99.100 abrufen:2376/v1.15/version: x509: Zertifikat ist abgelaufen oder noch nicht gültig

$ docker-machine env vbox-test
Fehler beim Prüfen der TLS-Verbindung: Fehler beim Prüfen und/oder Neugenerieren der Zertifikate: Es gab einen Fehler beim Validieren von Zertifikaten für Host "192.168.99.100:2376": x509: Zertifikat ist abgelaufen oder noch nicht gültig
Sie können versuchen, sie mit 'docker-machine regenerate-certs [name]' neu zu generieren.
Beachten Sie, dass dies einen Neustart des Docker-Daemons auslöst, der die Ausführung von Containern beendet.

$ docker-machine regenerate-certs vbox-test
TLS-Maschinenzertifikate neu generieren? Achtung: Dies ist irreversibel. (j/n): ja
TLS-Zertifikate neu generieren
Warten auf die Verfügbarkeit von SSH...
Anbieter wird erkannt...
Zertifikate werden in das Verzeichnis des lokalen Computers kopiert...
Zertifikate werden auf den Remote-Rechner kopiert...
Docker-Konfiguration auf dem Remote-Daemon einstellen...

$ docker-machine env vbox-test
Fehler beim Prüfen der TLS-Verbindung: Fehler beim Prüfen und/oder Neugenerieren der Zertifikate: Es gab einen Fehler beim Validieren von Zertifikaten für Host "192.168.99.100:2376": x509: Zertifikat ist abgelaufen oder noch nicht gültig
Sie können versuchen, sie mit 'docker-machine regenerate-certs [name]' neu zu generieren.
Beachten Sie, dass dies einen Neustart des Docker-Daemons auslöst, der die Ausführung von Containern beendet.

Ich hatte dies bei der Standardinstallation des Docker Tookit (installiert auf Windows 10 Home) 2016-10-30 heruntergeladen. Der Fehler war nach dem Ausführen weg:

docker-machine regenerate-certs

Habe dieses Problem unter macOS. docker-machine env beschwert sich:

$ docker-machine env docker1
Error checking TLS connection: Error checking and/or regenerating the certs: There was an error validating certificates for host "192.168.99.100:2376": x509: certificate has expired or is not yet valid
You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'.
Be advised that this will trigger a Docker daemon restart which might stop running containers.

Das erneute Generieren der Zertifikate (auch mit -f ) hilft nicht. docker-machine ssh docker1 date zeigt das richtige Datum und die richtige Uhrzeit an.

Irgendwelche Ideen?

@paddor Regenerieren der Zertifikate inkl. Clientzertifikate ( docker-machine regenerate-certs -f --client-certs ) haben es für mich behoben.