Machine: Les certificats ne s'installent pas correctement, se régénèrent toujours

Merci pour le résumé détaillé. J'ai déjà vu des problèmes comme celui-ci auparavant et je vais m'en occuper.

Êtes-vous sur la dernière VirutalBox ? c'est-à-dire 5.0.6 ?

J'utilisais le 5.0.4 qui est livré avec la dernière version de Docker Toolbox (1.8.2c). Je viens de supprimer cette version, d'installer la 5.0.6 et je rencontre le même comportement.

D'accord merci.

@carolynvs Si vous supprimez le seul réseau hôte que vous possédez (vous pouvez le faire dans l'interface graphique de VirtualBox) et réessayez, cela fonctionne-t-il ?

J'ai supprimé la machine, retiré l'adaptateur et réessayé avec le même résultat.

D'accord merci. Comportement très particulier. Je pourrais faire une version de test qui vide plus d'informations sur les certificats et vous suggère d'essayer cela si vous êtes d'accord.

Bien sûr! Je suis heureux d'aider comme je peux.

Si vous voulez juste créer une branche et me pointer dessus, je peux la construire moi-même (:heart: builds conteneurisés !). De cette façon, vous n'avez pas besoin de lancer plusieurs constructions par-dessus le mur si cela prend plus d'une tentative.

Une autre chose à considérer peut-être lors de la résolution de cela, certaines personnes comme moi écrivent en fait le contenu de docker-machine env dans un fichier que je vais sourcer pour chaque nouvelle session de terminal (car c'est un peu plus rapide que d'exécuter docker-machine env ). Si la sortie de cette commande contient quelque chose qui ne peut pas être eval d, cela va évidemment poser des problèmes.

Ainsi, des lignes comme celles-ci causeront des problèmes :

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

J'ai rencontré ce problème sur 0.5.0-dev , mais je ne l'ai plus rencontré depuis la rétrogradation à 0.4.1 .

J'ai vécu exactement le même comportement aujourd'hui sur la release candidate.

Salut @carolynvs @blaggacao , merci beaucoup pour vos commentaires.

J'essaye de reproduire/réparer ce bug. Pourriez-vous essayer ce PR (https://github.com/docker/machine/pull/2006) que j'ai créé pour aider à enquêter sur le bogue

On dirait que je vois ça aussi. J'utilise la dernière version de master sur OS X en utilisant le pilote digitalocean , donc cela n'a rien à voir avec l'environnement. Je pense que les balises area/windows et area/driver-virtualbox sont pas pertinentes ici :)

Salut @hairyhenderson , pouvez-vous essayer de compiler PR #2006 et me dire le résultat pour docker-machine -D env default ?

@dgageot - fera l'affaire quand j'en

J'y réfléchis aussi un peu plus et je me rends compte que j'ai fait un build _local_ (c'est- make build dire go build s'est comporté différemment dans le passé concerne les certificats (en particulier les certificats de l'autorité de certification racine), donc cela _pourrait_ être lié à cela ... Je ne sais pas.

Mais je vais reconstruire avec #2006 et l'essayer. Merci!

@hairyhenderson C'est un bon point. Je vais faire mes tests avec une docker-machine cross-compilée

@dgageot Voici la sortie échouée https://gist.github.com/carolynvs/e2473d21c3376f1ebec2 de docker-machine -D env default pour une toute nouvelle machine.

J'ai construit #2006 et copié docker-machine.exe et docker-machine-driver-virtualbox.exe dans le répertoire d'installation de Docker Toolbox. J'utilise Docker Toolbox 1.8.2c sous Windows 10.

Je ne suis pas assez doué pour savoir construire, peut-être que j'y jetterai un œil ce soir, si j'y arrive.

@carolynvs Merci beaucoup. Je ne comprends toujours pas ce qui se passe mais vos logs vont m'aider.

@carolynvs Pouvez-vous fournir la sortie de :

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

J'ai constaté que je reçois encore occasionnellement des adaptateurs double hôte uniquement. Je viens de les supprimer tous les deux et de créer une nouvelle machine. Les certificats se régénèrent toujours lorsque j'exécute docker-machine env default .

Voici la sortie des commandes VBoxManage la deuxième fois (avec seulement 1 adaptateur hôte).

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 Je
J'ai poussé quelques commits supplémentaires sur le PR pour imprimer plus d'informations et essayer des choses.
Si vous avez le temps de mettre à jour la sortie que vous obtenez, ce serait tout simplement génial.

ping @nathanleclaire @dmp42 une idée ?

Voici la nouvelle sortie : https://gist.github.com/carolynvs/84cd140bcbf9b696e20f.

Faites-moi savoir s'il existe une autre façon de déboguer le problème de connexion. Je ne suis pas tout à fait sûr de ce que docker-machine détecte qui provoque la régénération des certificats, mais je suis heureux de fouiller dans /var/lib/boot2docker sur l'hôte ou de comparer les certificats entre Windows et l'hôte, etc. chercher.

@carolynvs Ce serait génial. Comme vous l'avez souligné, le problème se pose dans 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.

Soit les certificats ne sont pas correctement copiés sur la machine virtuelle.
Ou la machine virtuelle n'est pas accessible sur le port 192.168.99.100:2376 (configuration réseau hôte ? pare-feu, vpn ? configuration réseau vm ?)
Ou il y a un problème dans la façon dont nous vérifions.

Si vous exportez les variables d'environnement données par docker-machine env et ignorez les erreurs, êtes-vous en mesure de vous connecter au démon docker ?

Je peux envoyer un ping à l'hôte docker et y accéder en ssh. Lorsque j'ignore les messages concernant la régénération des certificats de docker-machine env et que je définis les variables manuellement, je ne parviens toujours pas à me connecter au client docker.

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.

Les certificats sur l'hôte dans /var/lib/boot2docker/tls/ ne correspondent ~/.docker/machine/machines/default/ . Les certificats dans /var/lib/boot2docker/ correspondent à ce qui se trouve sur ma machine locale. De plus, les certificats dans ~/.docker/machine/certs/ correspondent à ce qui est dans ~/.docker/machine/machines/default/ .

Je suppose que le problème réside dans le fait que les certificats ne correspondent pas, ce qui empêche docker-machine de se connecter en toute sécurité au démon docker, déclenchant ainsi une régénération de certificat?

J'ai vérifié que le démon docker est en cours d'exécution :

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

Voici également les journaux de boot2docker et docker : https://gist.github.com/carolynvs/f7965455ebbceb85d4e6

:+1: Merci ! Je sens qu'on se rapproche :sourire:

IIRC, les certificats dans /var/lib/boot2docker/tls sont générés côté serveur par un script de démarrage dans le système d'exploitation boot2docker et ne sont utilisés pour rien dans le modèle de machine actuel (ils sont une relique de la façon dont boot2docker-cli s'attendait historiquement à ce que les certificats soient définis en haut).

@carolynvs @nathanleclaire Je

@carolynvs Pouvez-vous essayer de vous connecter au démon docker à l'aide de curl ? Nous pourrions avoir un meilleur retour sur ce qui ne va pas. Je pense que vous êtes sur windows, donc je ne sais pas vraiment comment y parvenir mais voici comment je l'ai fait sur OSX :

$ 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, voici le tutoriel que j'ai utilisé pour le faire fonctionner : http://opensolitude.com/2015/07/12/curl-docker-remote-api-os-x.html

@dgageot Ooh, oui, cela semble être un problème sur ma machine (en utilisant curl/openssl de Git pour Windows donc toutes les commandes sont les mêmes).

$ 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?)

J'ai vérifié tous les certificats dans ~/.docker/machine/certs à l'aide de vi -b path/to/cert et j'ai vérifié qu'il y avait des fins de ligne unix. J'ai également utilisé la commande suivante pour essayer de vérifier si openssl était capable de les lire.

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

Je vais continuer à fouiller avec les certificats, car cela semble être le problème. Essayez peut-être sur une autre machine et voyez s'il ne s'agit que de Windows 10.

@carolynvs Excellent travail ! Je vérifierai ça demain matin (heure de Paris)

Salut @carolynvs , avez-vous aussi essayé cette commande sur ca.pem ?

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

Pouvez-vous vérifier qu'il commence correctement par -----BEGIN CERTIFICATE----- et se termine par -----END CERTIFICATE----- . Rien avant et après.

@carolynvs Je dois admettre que je ne sais pas ce qui se passe. Avez-vous essayé ce PR qui semble vaguement lié.

Si cela ne vous dérange pas de confirmer ce résumé intermédiaire, je peux donc passer mon cerveau en silence à ce sujet :

• Les certificats sont copiés, mais ne peuvent pas être lus ?

Je suis sûr que vous avez déjà vérifié : http://stackoverflow.com/questions/20837161/openssl-pem-routinespem-read-biono-start-linepem-lib-c703expecting-truste
Je le mets en référence pour les autres.

Je viens d'essayer une commande curl différente en utilisant --cert et --key au lieu du fichier pfx généré et il est capable de se connecter.

$ 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"}

En regardant de plus près la sortie de docker-machine env je vois qu'il exporte ce que je pense être un mauvais chemin de certification. Sur mon mac, cela pointe vers .docker/machines/machine/tandis que dans la sortie ci-dessous, il pointe vers .docker/machine/certs.

$ 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)"

Après avoir défini manuellement les variables d'environnement, changé le chemin du certificat en ce que je pense qu'il aurait dû être, je peux me connecter au client docker.

Peut-être que lorsque docker-machine teste s'il peut se connecter, il utilise les mauvais certificats?

J'ai ajouté des informations de débogage lors de la validation des certificats, puis j'ai essayé de me connecter manuellement en utilisant d'abord ce que docker-machine utilise, puis ce que je pense devrait être utilisé.

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"}

Je vois donc 2 choses suspectes :

1. DOCKER_CERT_PATH utilise .docker/machine/certs au lieu de .docker/machine/machines/
2. Validate utilise server.pem et server-key.pem au lieu de cert.pem et key.pem. Je ne sais pas à quoi sert chaque certificat, mais cela ne semble pas correct.

Merci beaucoup @carolynvs qui devrait vraiment aider. Avant de digérer tout ce que vous avez signalé, pouvez-vous essayer la dernière version de https://github.com/docker/machine/pull/2006 Il devrait imprimer les certificats utilisés pour la validation. ça devrait aider

Voici les certificats qu'il utilise

URL HTE=192.168.99.102:2376
CA CERT PATH=C:\Users\caro8994.docker\machine\certsca.pem
CHEMIN DU SERVEUR CERT=C:\Users\caro8994.docker\machine\machines\bugtest\server.pem
CHEMIN DE LA CLÉ DU SERVEUR=C:\Users\caro8994.docker\machine\machines\bugtest\server-key.pem

Cela vient de mes propres informations de débogage, pas du PR qui prend beaucoup de temps à construire maintenant qu'il construit tous les plugins. :le sourire:

OK, maintenant je suis confus, alors je vais juste essayer un récapitulatif.

Pouvez-vous confirmer que :

• ~/.docker/machine/certs/ca.pem est le même que ~/.docker/machine/machines/bugtest/ca.pem
• ~/.docker/machine/certs/cert.pem est le même que ~/.docker/machine/machines/bugtest/cert.pem
• ~/.docker/machine/certs/key.pem est le même que ~/.docker/machine/machines/bugtest/key.pem
• Vous avez réussi à faire en sorte que docker cli atteigne le serveur. Quelle valeur pour DOCKER_CERT_PATH avez-vous utilisé alors ?
• Sur votre mac, les docker-machine env bugtest prints exportent DOCKER_CERT_PATH="~/.docker/machine" et non DOCKER_CERT_PATH="~/.docker/machine/certs"

Merci encore pour le soutien !

@carolynvs FTR, docker-machine cross-building uniquement, uniquement pour Windows devrait être beaucoup plus rapide : TARGET_ARCH=amd64 TARGET_OS=windows make build-x-machine

Désolé pour le vidage du cerveau !

• ca.pem, cert.pem et key.pm sont les mêmes dans ~/.docker/machine/certs et ~/.docker/machine/machines/bugtest
• Le client docker a fonctionné lorsque j'ai défini DOCKER_CERT_PATH sur ~.docker/machine/machines/bugtest
• Sur mon mac (qui fonctionne) docker-machine env définit DOCKER_CERT_PATH="~/.docker/machine/machines/bugtest" . Sous Windows 10 (ce qui n'est pas le cas), la même commande génère DOCKER_CERT_PATH="~/.docker/machine/certs"

C'était dans mon vidage du cerveau mais s'est peut-être perdu. Lorsque docker-machine valide les certificats, il tente de se connecter au démon docker à l'aide de server.pem et server-key.pem. Cela semble super louche.

D'ACCORD. Appelons @nathanleclaire et @ehazlett à la rescousse. Je pense que vous l'avez compris, mais maintenant, je suis trop nouveau dans le projet pour comprendre pourquoi nous avons autant de certificats en double et pourquoi nous n'utilisons pas les bons.

Merci pour l'astuce de construction !

Vous trouverez ci-dessous la sortie pertinente de la dernière version de PR #2006 et voici la sortie complète : 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

Désolé pour le bruit de fermeture/réouverture. j'ai tâtonné

Oi vey. @carolynvs @dgageot vous êtes tous des champions pour continuer à chasser celui-ci. Je pense que les soupçons de Carolyn sont corrects : si le DOCKER_CERT_PATH n'est pas défini correctement, la communication avec le démon ne fonctionnera pas correctement. Il semble que cela puisse être un problème avec les chemins que j'ai introduits par inadvertance dans les modifications libmachine . Je vais continuer à enquêter sur cela et à fouiller dans vos découvertes jusqu'à présent.

La passerelle vers le coupable peut-elle être cette ligne, alors ?
https://github.com/docker/machine/blob/8aa1572e0dcd75762a7627e1056ef104317f44b9/libmachine/persist/filestore.go#L155

@blaggacao Certainement fortement dans le domaine du possible - ce code a tendance à être un peu cassant et a été problématique dans le passé.

Je ne comprends pas en quoi cela peut être différent sur Windows et Mac OS, bien que @carolynvs l'ait confirmé.
Pour moi, cela construit clairement le chemin .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

reste silencieux.

@blaggacao clairement, je n'ai pas le même comportement que @carolynvs sur mac. Il y a donc quelque chose de louche.

Oui, les certificats sont copiés dans le répertoire de cette machine pendant le bit de provisionnement.

@dgageot Désolé pour la confusion. Mon mac exécute docker-machine 0.4.1. J'exécute uniquement la version PR sur ma machine Windows car j'y ai testé des correctifs au fur et à mesure qu'ils sont fusionnés dans le maître.

Je peux faire une compilation et réexécuter sur mon mac maintenant.

je reprends :

• les différences n'affichent pas la différence entre /machine/certs et /machine/machines/certs
• Je ne peux pas reproduire la solution de contournement de carlynvs pour résoudre le problème.

Lorsque vous définissez manuellement DOCKER_CERT_PATH sur Windows (dans bash), vous devez utiliser des chemins de style UNIX. Par exemple, export DOCKER_CERT_PATH="~./docker/machine/machines/oca" .

Je peux confirmer que sur ma machine (maladroite), les certs correspondent entre /machine/certs et /machine/machines/certs.

Je peux confirmer, par copie manuelle, que scp ne fonctionne pas :

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

les deuxième et troisième diffèrent entre /machines/oca et oca:~/.docker

Quels chemins dans la VM utilisez-vous pour les certs @blaggacao ?

Je viens de me rendre compte que c'était la mauvaise...

J'ai vérifié par rapport à ~/.docker Je vérifierai à nouveau par rapport à /var/lib/boot2docker

Je peux définitivement le confirmer

• les certificats dans /machines/oca et oca:/var/lib/boot2docker/ sont les mêmes
  ( Je cours dos2unix sur les 3 champs ca.pem , server.pem , sever-key.pem sur oca )

J'obtiens également cette erreur de délai d'attente : https://github.com/docker/machine/blob/6a5219b879db52698ccb2b7e0aafd516b34df839/libmachine/provision/boot2docker.go#L193
à chaque fois que je lance env avec le drapeau --native-ssh ou non

Oui, @blaggacao, il semble également que l'adresse IP de l'hôte uniquement attribuée à la machine virtuelle ne soit pas accessible sur votre ordinateur. Pouvez-vous ping $(docker-machine ip vmname) ?

non, ne fonctionne pas non plus... "Demande expirée"

docker-machine ssh vmname fonctionne cependant

Oui, ssh passe par localhost . Mais il semble que vous ne puissiez pas contacter l'hôte attribué uniquement l'IP de la VM, donc je ne m'attendrais pas à ce que env fonctionne correctement. Utilisez-vous un VPN ou un proxy ?

pas, que je serais au courant, juste revérifié le gestionnaire de tâches ... UPDATE en a détecté un, fermeture

La fermeture ne change rien, mais c'est un autre problème, je pense...

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

m'amène à

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

Comme je ne reçois rien de : https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/libmachine/cert/cert.go#L22

les seuls candidats restants sont :
https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/libmachine/cert/cert.go#L198 -L205

Cela sent comme un lien entre les deux problèmes. Pouvez-vous interpréter ma ligne de pensée?

Creusement à distance : https://github.com/leo-stone/fix-go-1.5-tls-issue/blob/master/main.go

Je ne faisais plus confiance à mon environnement Windows, j'ai donc recommencé et reconstruit Windows puis mis le #2006.

Dans le fichier docker.log je vois cette erreur

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

donc j'ai vérifié les dates du cert

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

Le problème pourrait-il être que le certificat est daté du futur ? Cela expliquerait pourquoi à l'origine mes commandes curl ne fonctionnaient pas, mais quelques heures plus tard, elles fonctionnaient.

pareil ici:

$ 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

C'est dans environ 5 heures dans mon fuseau horaire (Bogota/Amériques) Eh bien, mais il est indiqué GMT (UTC). Bogota est UTC-5

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

Mise à jour : CORRECTIF

Comme indiqué ici : https://github.com/docker/docker/issues/11534#issuecomment -89405874

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

m'a donné une erreur différente (une étape à la fois :)

Je pense que c'est ça, le reste est ma virtualbox.

Je vais dîner et vérifier dans 5 heures quand je soupçonne que mon certificat sera valide et que tout fonctionnera. :le sourire:

Mauvaise nouvelle, je dois le faire à chaque redémarrage de la machine virtuelle.

:smile: Je suppose que vous touchez la cause racine ! Merci!

: clap:: clap :: clap :: clap :: clap :: clap :: clap:

@carolynvs est-ce que le correctif que j'ai publié a fonctionné pour vous ?

Je voulais juste confirmer qu'après avoir attendu 5 heures jusqu'à ce que le certificat soit valide, docker-machine env fonctionne. Aucune idée de la raison pour laquelle je reçois des certificats datés du futur, mais je devrais peut-être mettre à jour le problème pour refléter la véritable cause première maintenant que nous le savons.

Dans mon cas, ce n'était pas les certificats, mais le réglage de l'heure sur boot2docker... Comme je peux le voir sur votre profil github, vous êtes de Chicago, c'est un fuseau horaire similaire à celui de Bogota, peut-être que boot2docker est mal configuré dans nos fuseaux horaires ...

Après avoir synchronisé l'heure à l'aide de votre solution de contournement, je reçois toujours la même erreur (le certificat a expiré ou n'est pas encore valide) lors de l'utilisation de ces certificats pour me connecter à mon hôte docker.

Sur mon mac, voici ce que je vois après avoir créé une nouvelle boîte et vérifié son heure.

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

Voici les mêmes commandes sur un nouvel hôte sous 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

La date indique mon heure locale mais pense que c'est UTC et je ne sais pas comment la mettre à jour pour qu'elle corresponde à l'horloge. J'ai essayé de changer manuellement la date, mais il y a quelque chose à propos de busybox ou de virtualbox qui annule immédiatement tout changement.

C'est l'état de fonctionnement depuis hier après avoir appliqué la solution de contournement :

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

ici, date correspond à mon heure locale exprimée en UTC

quelques conseils pour mes symtopms : https://forums.virtualbox.org/viewtopic.php?f=3&t=60558#p281836

time est gelé, après 10 min : docker<strong i="18">@oca</strong>:~$ time BusyBox v1.23.1 (2015-02-22 15:53:49 UTC) multi-call binary.

comme date affiche la date correcte dans mon cas, je suppose que la solution de contournement date fixe dans mon cas et donc le problème.

cc @tianon @SvenDowideit PTAL au RE ci-dessus: problèmes d'heure/date boot2docker ^^

Certains codes que j'ai trouvés pourraient contribuer au problème d'horodatage :

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

Mais ça a toujours bien fonctionné avant.

@carolynvs @blaggacao Avez-vous toujours rencontré ces problèmes ?

Pour moi, cela fonctionne après la solution de contournement référencée. Ceci, à son tour, indique que certains paramètres de temps boot2docker n'ont pas été définis correctement. En règle générale, cela ne se produirait que pendant une période de temps limitée juste après la création de la machine. (Probablement seulement dans certains fuseaux horaires).

Encore une fois, cela signifierait que les horodatages certs seraient corrects.

Je suis tombé sur cela à nouveau juste après avoir redémarré le PC sur mon rc, mais après la mise à jour vers 5.0, tout semble fonctionner. Nous pourrions probablement fermer cela pour le moment. Quoi qu'il en soit, dès que je remarque un comportement étrange, je le rouvre.

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

J'ai aussi ce problème. Ne le fermez pas.

@damontic Cela ressemble à un problème différent de celui discuté ici.

J'essaie de configurer un essaim sur DigitalOcean et j'ai la même erreur.

init-do.sh qui crée un magasin KV, un maître swarm et un nœud :

 # 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

Le journal / l'erreur que je reçois

$> ./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.

Avant de l'exécuter, j'ai mis à jour vers Machine 0.5.1

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

Je peux passer au contexte de la machine "consul" mais pas au "demo0" ou "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 Si le provisionnement échoue, les instances créées seront "invalides". Essayez de les supprimer et de recommencer à zéro.

@nathanleclaire Je viens de supprimer les machines (est-ce que 'docker-machine rm consul demo0 demo1' suffit ou dois-je supprimer manuellement d'autres éléments ?) Chose étrange, il n'y a pas de problème avec la machine 'consul', mais seulement avec les swarm (demo0, demo1).

Lors de la création de l'essaim sur VirtualBox (5.0.10), cela fonctionne bien.

je vois cela lors de l'utilisation du pilote aws

J'ai fait plusieurs tests (beaucoup en fait), après avoir supprimé les VM et les avoir recréées (avec un essaim) j'ai toujours le même problème.

J'ai maintenant ce problème après la mise à niveau de la version 1.8 à 1.9.1 à l'aide de la boîte à outils Docker sur 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

Cela m'arrive aussi périodiquement. Docker v1.9.1

Même problème ici avec le pilote azur. Chaque fois que nous créons une nouvelle machine Azure, elle échoue avec l'erreur :

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

Après avoir exécuté docker-machine regenerate-certs les validations de certificats fonctionnent correctement.

Dans docker-machine v0.5.5 il n'y a pas de problème, et la création d'un hôte docker fonctionne bien :

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 Vous rencontrez ce problème avec la 0.6.0 ?

Oui, à partir de 0.5.5. J'ai testé cela avec 0.5.6 et 0.6.0.

idem pour moi sur 0.6.0 avec pilote aws (en permanence) sur mac 10.10.5. Cela ne se produit pas avec le pilote de boîte virtuelle.

corrigé après avoir changé --engine-opt="cluster-advertise=eth1:2376" en --engine-opt="cluster-advertise=eth0:2376" utilisant docker-machine 0.6.0 (docker-machine 0.5.4 échoue toujours)

Je pense que je suis confronté au même problème sur ma machine. J'utilise Ubuntu 14.04
docker-machine version 0.5.5, build 02c4254
Exécution de l'hôte sur RHEL 7.1
Version du serveur : 1.10.2-cs1-rc3

J'ai essayé tout ce qui est suggéré avec le temps sur les machines, voici la sortie que je reçois de curl

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-machine ip $NODE_NAME):2376/version

• Le nom d'hôte n'a PAS été trouvé dans le cache DNS
• Essayer le 16.85.3.140...
• Connecté au 16.85.3.140 (16.85.3.140) port 2376 (#0)
• placer avec succès le certificat vérifier les emplacements :
• Fichier CA : /home/eraigosa/.docker/machine/certs/ca.pem
  CApath : /etc/ssl/certs
• SSLv3, poignée de main TLS, bonjour client (1) :
• SSLv3, poignée de main TLS, bonjour du serveur (2) :
• SSLv3, négociation TLS, CERT (11) :
• SSLv3, poignée de main TLS, échange de clé de serveur (12) :
• SSLv3, négociation TLS, demande CERT (13) :
• SSLv3, négociation TLS, serveur terminé (14) :
• SSLv3, négociation TLS, CERT (11) :
• SSLv3, poignée de main TLS, échange de clé client (16) :
• SSLv3, négociation TLS, vérification CERT (15) :
• SSLv3, chiffrement de changement TLS, bonjour client (1) :
• SSLv3, établissement de liaison TLS, terminé (20) :
• SSLv3, alerte TLS, bonjour serveur (2) :
• erreur : 14094412 : routines SSL
• Connexion de fermeture 0
  curl : (35) erreur : 14094412 : routines SSL

@nathanleclaire j'ai trouvé le cultprit ! prltoolsd de boot2docker définit constamment ma date/fuseau horaire de manière incorrecte.

$ 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>

Après avoir arrêté prltoolsd et réinitialisé la date, toutes mes commandes docker-machine fonctionnent comme prévu et mes certificats ne se régénèrent pas.

Je ne sais toujours pas pourquoi le fuseau horaire est défini sur UTC et l'heure locale après la création d'une nouvelle machine, il ne s'agit donc que d'une solution de contournement, pas d'un correctif.

Belle @carolynvs ! Nous allons travailler pour voir si nous pouvons résoudre ce problème dans boot2docker.

@tianon @legal90 Pour info ^^

@carolynvs Wow :effrayant: . Cela semble vraiment étrange, car le processus prltoolsd ne devrait pas démarrer sur un autre système de virtualisation à l'exception de Parallels Desktop. Le démon ne démarrera que si /usr/bin/prlvmcheck renvoie 0 exit-code, ce qui signifie que nous sommes dans Parallels VM.

Avez-vous reproduit ce problème sur Virtualbox VM ? Quelle version de Boot2Docker utilisez-vous ?

Ps De plus, si nous supposons que prltoolsd est la seule raison, alors la version de Docker Machine ne devrait pas avoir de sens. Cependant, d'autres commentaires ci-dessus ( lien ) indiquent que le problème n'apparaît que dans Machine 0.5.5+

@legal90 Cela a plus de sens. Mon environnement est un peu bancal, mais il fonctionnait très bien auparavant :

1. Je suis sur un Mac exécutant Parallels.
2. Dans Parallels, j'exécute Windows, puis la dernière installation de la boîte à outils Docker. Je le fais parce que j'écris de la documentation et des tutoriels pour Docker et que je dois cibler les utilisateurs Mac, Linux et Windows.

Cela explique pourquoi prltoolsd tente de gérer l'horloge de mon hôte Docker. Il doit être en train d'être imbriqué dans Parallels. Cela explique-t-il également pourquoi l'horloge système est réglée sur l'heure locale mais pense que c'est UTC ?

C'est la racine du problème qui m'a amené à ouvrir ce bogue. Je crée une nouvelle machine docker à 10h00 CST (-6). L'horloge système ( date ) sur la nouvelle machine pense qu'il est 10 heures UTC, donc les horodatages sur les certificats sont "dans le futur". hwclock indique l'heure correcte.

En regardant le fichier Docker de boot2docker, j'ai remarqué qu'il définissait /etc/timezone sur UTC et _devrait_ avoir également défini /etc/localtime sur UTC.

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

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

Mais sur mon hôte de machine docker, le package tzdata n'est pas installé, donc /usr/share/zoneinfo n'existe pas et /etc/localtime . J'ai construit mon propre boot2docker à partir du dernier Dockerfile juste pour vérifier que je n'utilise pas une ancienne iso. Je me demande si l'absence du fichier /etc/localtime contribue au problème de temps incorrect ?

@carolynvs Ah, maintenant je l'ai.

Cela explique pourquoi prltoolsd tente de gérer l'horloge de mon hôte docker. Il doit être en train d'être imbriqué dans Parallels.

Oui, c'est la racine du problème. prltoolsd s'exécute dans la VM Virtualbox imbriquée dans la VM Parallels. J'ai reproduit ceci et signalé aux personnes responsables de Parallels. Je vous tiens au courant dès que c'est réparé.

Cela explique-t-il également pourquoi l'horloge système est réglée sur l'heure locale mais pense que c'est UTC ?

Eh bien, c'est difficile à valider mais c'est un problème connu de Parallels Desktop (et de ses outils invités). Il a été initialement signalé ici : https://github.com/Parallels/vagrant-parallels/issues/186.
Cela a été contourné dans PD 11 par une option supplémentaire pour l'utilitaire prlctl , mais cela n'aide pas dans votre cas rare, car vous exécutez en fait Virtualbox VM sous Windows.

Je suis désolé, mais la seule solution que je peux vous suggérer pour le moment est d'empêcher prltoolsd de s'exécuter dans votre VM au démarrage. Si vous utilisez une version ISO Boot2Docker personnalisée, vous pouvez supprimer les lignes liées aux parallèles de Dockerfile et reconstruire l'ISO. Ou commentez cette ligne : https://github.com/boot2docker/boot2docker/blob/master/rootfs/rootfs/bootscript.sh#L101

Merci pour les informations supplémentaires sur le fonctionnement de prltoolsd ! Je ferai comme vous le suggérez et créerai une iso personnalisée pour ma configuration. :Bière:

Je fermerais ce problème, car cela résout mon problème, mais je vous laisse le soin de le faire car d'autres personnes semblent le résoudre (bien que probablement pour des raisons différentes !).

Je pense que nous pouvons le traiter comme résolu efficacement ; nous pouvons rouvrir si de nouveaux problèmes sont découverts.

Merci à tous pour vos contributions au rapport et au tri de ce problème épique !

J'utilise DockerToolbox 1.10.3 sous Windows. Cela fonctionnait bien jusqu'à ce que je redémarre, et j'ai maintenant le même problème. Je ne connais pas non plus Docker, alors quelqu'un peut-il me dire quel est le correctif ?

@mtrtm Est- docker-machine regenerate-certs -f ne fonctionne pas ?

Oui, docker-machine regenerate-certs -f le fait. Il semble également le faire chaque fois que je démarre Docker Quickstart Terminal

+1
J'utilise docker principalement sur un serveur Redhat et tout fonctionne très bien. Je ne suis pas un expert mais je sais ce que je fais. Sous Windows avec virtualbox, cependant, chaque fois que la machine virtuelle docker redémarre, je dois régénérer les certificats. Je suis sur toolbox 1.11.1

+1

Macbook fin 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
NOM ACTIVE DRIVER ÉTAT URL SWARM ERREURS DOCKER
Vbox test - virtualbox Exécution tcp: //192.168.99.100 : 2376 Inconnu Impossible de version requête docker: Get https://192.168.99.100 : 2376 / v1.15 / Version: X509: certificat a expiré ou est pas encore valide

$ docker-machine env vbox-test
Erreur lors de la vérification de la connexion TLS : erreur lors de la vérification et/ou de la régénération des certificats : une erreur s'est produite lors de la validation des certificats pour l'hôte « 192.168.99.100:2376 » : x509 : le certificat a expiré ou n'est pas encore valide
Vous pouvez essayer de les régénérer en utilisant 'docker-machine regenerate-certs [nom]'.
Sachez que cela déclenchera un redémarrage du démon Docker qui arrêtera l'exécution des conteneurs.

$ docker-machine regenerate-certs vbox-test
Régénérer les certificats de machine TLS ? Attention : ceci est irréversible. (o/n): oui
Régénérer les certificats TLS
En attente de la disponibilité de SSH...
Détection du fournisseur...
Copie des certificats dans le répertoire de la machine locale...
Copie des certificats sur la machine distante...
Paramétrage de la configuration Docker sur le démon distant...

$ docker-machine env vbox-test
Erreur lors de la vérification de la connexion TLS : erreur lors de la vérification et/ou de la régénération des certificats : une erreur s'est produite lors de la validation des certificats pour l'hôte « 192.168.99.100:2376 » : x509 : le certificat a expiré ou n'est pas encore valide
Vous pouvez essayer de les régénérer en utilisant 'docker-machine regenerate-certs [nom]'.
Sachez que cela déclenchera un redémarrage du démon Docker qui arrêtera l'exécution des conteneurs.

J'avais ceci sur l'installation par défaut de Docker Tookit (installé sur Windows 10 Home) téléchargé le 30/10/2016. L'erreur a disparu après l'exécution :

docker-machine regenerate-certs

Avoir ce problème sur macOS. docker-machine env plaint :

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

Régénérer les certificats (même avec -f ) n'aide pas. docker-machine ssh docker1 date affiche la date et l'heure correctes.

Des idées?

@paddor Régénérer les certificats incl. les certificats clients ( docker-machine regenerate-certs -f --client-certs ) l'ont corrigé pour moi.