Machine: Los certificados no se instalan correctamente, siempre se regeneran

Gracias por el resumen detallado. También he visto problemas como este antes y lo investigaré.

¿Estás en la última VirutalBox? es decir, 5.0.6?

Estaba usando la 5.0.4 que viene con la última versión de Docker Toolbox (1.8.2c). Acabo de eliminar esa versión, instalé 5.0.6 y estoy experimentando el mismo comportamiento.

Bueno, gracias.

@carolynvs Si elimina la red de solo host que tiene (puede hacer esto en la GUI de VirtualBox) y vuelve a intentarlo, ¿funciona?

Eliminé la máquina, quité el adaptador y volví a intentarlo con el mismo resultado.

Bueno, gracias. Comportamiento muy peculiar. Podría hacer una compilación de prueba que arroje más información sobre los certificados y sugerirle que lo intente si está de acuerdo.

¡Por supuesto! Estoy feliz de ayudar en todo lo que pueda.

Si solo desea hacer una rama y señalarme, puedo construirla yo mismo (: corazón: compilaciones en contenedores). De esa manera, no es necesario lanzar varias construcciones por encima de la pared si esto requiere más de un intento.

Otra cosa a considerar posiblemente al arreglar esto, algunas personas como yo escriben el contenido de docker-machine env en un archivo que obtendré para cada nueva sesión de terminal (ya que es un poco más rápido que ejecutar docker-machine env ). Si la salida de este comando contiene algo que no puede ser eval d, obviamente causará problemas.

Entonces, líneas como las siguientes causarán problemas:

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

Experimenté este problema en 0.5.0-dev , pero no lo he experimentado desde que bajé a 0.4.1 .

Experimenté exactamente el mismo comportamiento hoy con el candidato de lanzamiento.

Hola @carolynvs @blaggacao , muchas gracias por tus comentarios.

Estoy intentando reproducir / corregir este error. ¿Podría probar este PR (https://github.com/docker/machine/pull/2006) que creé para ayudar a investigar el error?

Parece que yo también estoy viendo esto. Estoy usando la última compilación master en OS X usando el controlador digitalocean , por lo que definitivamente no tiene nada que ver con el entorno. Creo que las etiquetas area/windows y area/driver-virtualbox son irrelevantes aquí :)

Hola @hairyhenderson , ¿puedes intentar construir PR # 2006 y decirme el resultado de docker-machine -D env default ?

@dgageot - lo haré cuando tenga la oportunidad.

También estoy pensando un poco más en esto y me doy cuenta de que he estado haciendo una compilación _local_ (es decir, make build en OS X, sin usar un contenedor). Una de las áreas donde go build ha comportado de manera diferente en el pasado es alrededor de los certificados (especialmente los certificados de CA raíz), por lo que esto _podría_ estar relacionado con eso ...

Pero lo reconstruiré con # 2006 y lo probaré. ¡Gracias!

@hairyhenderson Ese es un buen punto. Ejecutaré mis pruebas con una máquina acoplable de compilación cruzada

@dgageot Aquí está el resultado fallido https://gist.github.com/carolynvs/e2473d21c3376f1ebec2 de docker-machine -D env default para una máquina nueva.

Construí # 2006 y copié docker-machine.exe y docker-machine-driver-virtualbox.exe en el directorio de instalación de Docker Toolbox. Estoy usando Docker Toolbox 1.8.2c en Windows 10.

No soy lo suficientemente competente como para saber cómo construir, tal vez lo eche un vistazo esta noche, si puedo resolverlo.

@carolynvs Muchas gracias. Sigo sin entender qué está pasando, pero tus registros me ayudarán.

@carolynvs ¿Puede proporcionar el resultado 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

Descubrí que ocasionalmente obtengo adaptadores de solo host doble. Los eliminé a ambos y creé una nueva máquina. Los certificados todavía se están regenerando cuando ejecuto docker-machine env default .

Aquí está el resultado de los comandos de VBoxManage la segunda vez (con solo 1 adaptador de host).

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 No tengo ni idea hasta ahora.
Presioné un par de confirmaciones más en las relaciones públicas para imprimir más información y probar cosas.
Si tiene tiempo para actualizar la salida que obtiene, sería genial.

ping @nathanleclaire @ dmp42 ¿ alguna idea?

Aquí está la nueva salida: https://gist.github.com/carolynvs/84cd140bcbf9b696e20f.

Avíseme si hay otra forma de depurar el problema de conexión. No estoy muy seguro de qué docker-machine está detectando que está causando que se regeneren los certificados, pero estoy feliz de hurgar en / var / lib / boot2docker en el host o comparar certificados entre Windows y el host, etc., si supiera qué buscar.

@carolynvs Eso sería genial. Como señaló, el problema surge en 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.

O el certificado no se ha copiado correctamente en la máquina virtual.
O no se puede acceder a la máquina virtual en el puerto 192.168.99.100:2376 (¿configuración de red de host? ¿Firewall, vpn? ¿Configuración de red de vm?)
O hay un problema en la forma en que verificamos.

Si exporta las variables env dadas por docker-machine env e ignora los errores, ¿puede conectarse al demonio de la ventana acoplable?

Puedo hacer ping al host de la ventana acoplable y ssh en él. Cuando ignoro los mensajes sobre la regeneración de certificados de docker-machine env y configuro las variables manualmente, sigo sin poder conectarme con el cliente de 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.

Los certificados del host en /var/lib/boot2docker/tls/ no coinciden con los de ~/.docker/machine/machines/default/ localmente. Los certificados en /var/lib/boot2docker/ coinciden con lo que está en mi máquina local. Además, los certificados en ~/.docker/machine/certs/ coinciden con lo que está en ~/.docker/machine/machines/default/ .

Supongo que el problema radica en que los certificados no coinciden, lo que evita que la máquina acoplable se conecte de forma segura al demonio de la ventana acoplable, lo que desencadena una regeneración de certificados.

He verificado que el demonio de la ventana acoplable se está ejecutando:

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

También aquí están los registros de boot2docker y docker: https://gist.github.com/carolynvs/f7965455ebbceb85d4e6

: +1: ¡Gracias! Siento que nos estamos acercando: sonríe:

IIRC, los certificados en /var/lib/boot2docker/tls se generan en el lado del servidor mediante un script de inicio en el sistema operativo boot2docker y no se usan para nada en el modelo de máquina actual (son una reliquia de cómo boot2docker-cli históricamente esperaba que se configuraran los certificados arriba).

@carolynvs @nathanleclaire No tengo ni idea entonces. La única diferencia que tengo en mis registros es que estoy usando VBox versión 5.0.6 y un boot2docker más reciente.

@carolynvs ¿Puedes intentar conectarte al demonio de la

$ 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, aquí está el tutorial que utilicé para hacerlo funcionar: http://opensolitude.com/2015/07/12/curl-docker-remote-api-os-x.html

@dgageot Ooh, sí, esto parece ser un problema en mi máquina (usando curl / openssl de Git para Windows para que todos los comandos sean iguales).

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

Revisé todos los certificados en ~ / .docker / machine / certs usando vi -b path/to/cert y verifiqué que tiene terminaciones de línea Unix. También utilicé el siguiente comando para intentar verificar si openssl pudo leerlos.

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

Seguiré hurgando con los certificados, ya que este parece ser el problema. Puede probarlo en otra máquina y ver si es solo una cosa de Windows 10.

@carolynvs ¡

Hola @carolynvs , ¿has probado este comando en ca.pem también?

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

¿Puede comprobar que comienza correctamente con -----BEGIN CERTIFICATE----- y termina con -----END CERTIFICATE----- ? Nada antes y después.

@carolynvs Debo admitir que no sé qué está pasando. ¿Has probado este PR que parece vagamente relacionado?

Si no le importa confirmar este resumen intermedio, puedo gastar mi cerebro en silencio en esto:

• ¿Se copian los certificados, pero no se pueden leer?

Estoy seguro de que ya revisaste: http://stackoverflow.com/questions/20837161/openssl-pem-routinespem-read-biono-start-linepem-lib-c703expecting-truste
Lo pongo como referencia para otros.

Acabo de probar un comando curl diferente usando --cert y --key en lugar del archivo pfx generado y puede conectarse.

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

Mirando más de cerca la salida de docker-machine env , veo que está exportando lo que creo que es una ruta de certificación incorrecta. En mi mac, esto apunta a .docker / machines / machine /mientras que en la salida a continuación, apunta a .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)"

Después de configurar manualmente las variables de entorno, cambiar la ruta del certificado a lo que creo que debería haber sido, puedo conectarme con el cliente de Docker.

¿Quizás cuando docker-machine está probando si puede conectarse, está usando los certificados incorrectos?

Agregué información de depuración al validar los certificados y luego intenté conectarme manualmente usando primero lo que está usando la máquina acoplable y luego lo que creo que debería usarse.

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

Entonces veo 2 cosas sospechosas:

1. DOCKER_CERT_PATH usa .docker / machine / certs en lugar de .docker / machine / machines /
2. Validar está usando server.pem y server-key.pem en lugar de cert.pem y key.pem. No sé para qué sirve cada certificado, pero eso no parece correcto.

Muchas gracias @carolynvs que realmente debería ayudar. Antes de digerir todo lo que informó, ¿puede probar la última versión de https://github.com/docker/machine/pull/2006? Debería imprimir los certificados que se utilizan para la validación. Eso debería ayudar

Aquí están los certificados que está usando

URL DEL HOST = 192.168.99.102: 2376
RUTA DE CA CERT = C: \ Users \ caro8994.docker \ machine \ certsca.pem
SERVER CERT PATH = C: \ Users \ caro8994.docker \ machine \ machines \ bugtest \ server.pem
RUTA DE LA CLAVE DEL SERVIDOR = C: \ Users \ caro8994.docker \ machine \ machines \ bugtest \ server-key.pem

Eso es de mi propia información de depuración, no del PR, que lleva mucho tiempo compilar ahora que está compilando todos los complementos. :sonrisa:

Bien, ahora estoy confundido, así que intentaré un resumen.

¿Puede confirmar que:

• ~/.docker/machine/certs/ca.pem es lo mismo que ~/.docker/machine/machines/bugtest/ca.pem
• ~/.docker/machine/certs/cert.pem es lo mismo que ~/.docker/machine/machines/bugtest/cert.pem
• ~/.docker/machine/certs/key.pem es lo mismo que ~/.docker/machine/machines/bugtest/key.pem
• Lograste que docker cli llegara al servidor. ¿Qué valor de DOCKER_CERT_PATH usó entonces?
• En su mac, docker-machine env bugtest impresiones exportan DOCKER_CERT_PATH="~/.docker/machine" y no DOCKER_CERT_PATH="~/.docker/machine/certs"

¡Gracias de nuevo por el apoyo!

@carolynvs FTR, docker-machine de construcción cruzada, solo para Windows debería ser mucho más rápido: TARGET_ARCH = amd64 TARGET_OS = windows make build-x-machine

¡Perdón por la descarga de cerebros!

• ca.pem, cert.pem y key.pm son iguales en ~/.docker/machine/certs y ~/.docker/machine/machines/bugtest
• El cliente de Docker funcionó cuando configuré DOCKER_CERT_PATH en ~.docker/machine/machines/bugtest
• En mi mac (que funciona) docker-machine env establece DOCKER_CERT_PATH="~/.docker/machine/machines/bugtest" . En Windows 10 (que no lo hace), el mismo comando da como resultado DOCKER_CERT_PATH="~/.docker/machine/certs"

Esto estaba en mi volcado de cerebro, pero es posible que se haya perdido. Cuando docker-machine está validando los certificados, está intentando conectarse al demonio de la ventana acoplable usando server.pem y server-key.pem. Esto parece muy sospechoso.

está bien. Llamemos a @nathanleclaire y @ehazlett al rescate. Creo que lo acertó, pero ahora soy demasiado nuevo en el proyecto para entender por qué tenemos tantos certificados duplicados y por qué no usamos los correctos.

¡Gracias por el consejo de construcción!

A continuación se muestra el resultado relevante de la última compilación de PR # 2006 y aquí está el resultado completo: 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

Perdón por el ruido cerrado / reabierto. Yo torpe

Oi vey. @carolynvs @dgageot todos ustedes son campeones por seguir persiguiendo a este. Creo que la sospecha de Carolyn es correcta: si DOCKER_CERT_PATH no se configura correctamente, la comunicación con el demonio no funcionará correctamente. Parece que puede ser un problema con las rutas que introduje inadvertidamente en los cambios de libmachine . Continuaré investigando esto y hurgando en sus hallazgos hasta ahora.

Entonces, ¿puede ser esta línea la puerta de entrada al culpable?
https://github.com/docker/machine/blob/8aa1572e0dcd75762a7627e1056ef104317f44b9/libmachine/persist/filestore.go#L155

@blaggacao Definitivamente fuertemente en el ámbito de la posibilidad: ese código tiende a ser un poco frágil y ha sido problemático en el pasado.

No entiendo cómo esto puede ser diferente en Windows y Mac OS , aunque como confirmó
Para mí, claramente construye la ruta .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

permanece en silencio.

@blaggacao claramente, no tengo el mismo comportamiento que @carolynvs en mac. Entonces hay algo sospechoso.

Sí, los certificados se copian en el directorio de esa máquina durante el bit de aprovisionamiento.

@dgageot Disculpas por la confusión. Mi mac está ejecutando docker-machine 0.4.1. Solo estoy ejecutando la compilación de relaciones públicas en mi máquina con Windows, ya que he estado probando las correcciones allí a medida que se fusionan en el maestro.

Puedo hacer una compilación y ejecutar de nuevo en mi Mac ahora mismo.

Resumo:

• diffs no muestran la diferencia entre /machine/certs y /machine/machines/certs
• No puedo reproducir la solución alternativa de Carlynv para resolver el problema.

Al configurar manualmente DOCKER_CERT_PATH en Windows (en bash), debe usar rutas de estilo UNIX. Por ejemplo, export DOCKER_CERT_PATH="~./docker/machine/machines/oca" .

Puedo confirmar que en mi máquina (inestable) los certificados coinciden entre / machine / certs y / machine / machines / certs.

Puedo confirmar, copiando manualmente, que scp no funciona:

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

el segundo y el tercero difieren entre /machines/oca y oca:~/.docker

¿Qué rutas en la máquina virtual está utilizando para los certificados @blaggacao ?

Me acabo de dar cuenta de que era el equivocado ...

Comprobé con ~/.docker Volveré a comprobar con /var/lib/boot2docker

Definitivamente puedo confirmar que

• los certificados en /machines/oca y oca:/var/lib/boot2docker/ son los mismos
  (Ejecuto dos2unix en los 3 campos ca.pem , server.pem , sever-key.pem en oca )

También recibo este error de tiempo de espera: https://github.com/docker/machine/blob/6a5219b879db52698ccb2b7e0aafd516b34df839/libmachine/provision/boot2docker.go#L193
cada vez que ejecuto env con la bandera --native-ssh o no

Sí, @blaggacao también parece que la única IP de host asignada a la VM no es accesible en su computadora. ¿Puedes ping $(docker-machine ip vmname) ?

no, tampoco funciona ... "Se agotó el tiempo de espera de la solicitud"

docker-machine ssh vmname aunque funciona

Sí, ssh pasa por localhost . Pero parece que no puede comunicarse con el host asignado solo con la IP de la VM, por lo que no esperaría que env funcione correctamente. ¿Estás usando alguna VPN o proxy?

no, que yo sepa, simplemente verifiqué dos veces el administrador de tareas ... ACTUALIZACIÓN detectó uno, cerrando

El cierre no cambia nada, pero este es otro tema, creo ...

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

me lleva a

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

Como no obtengo ninguno de: https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/libmachine/cert/cert.go#L22

los únicos candidatos restantes son:
https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/libmachine/cert/cert.go#L198 -L205

Esto huele a una conexión entre ambos problemas. ¿Puedes interpretar mi línea de pensamiento?

Excavación remota: https://github.com/leo-stone/fix-go-1.5-tls-issue/blob/master/main.go

Ya no confiaba en mi entorno de Windows, así que comencé de nuevo y reconstruí Windows y luego puse el # 2006.

En el archivo docker.log veo este error

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

así que verifiqué las fechas del certificado

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

¿Podría el problema ser que el certificado tiene fecha futura? Eso explicaría por qué originalmente mis comandos curl no funcionaron, pero unas horas más tarde lo hicieron.

aquí igual:

$ 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

Eso es en aproximadamente 5 horas en mi zona horaria (Bogotá / Américas) Bueno, pero dice GMT (UTC). Bogotá es UTC-5

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

Actualización: FIX

Como se indica aquí: https://github.com/docker/docker/issues/11534#issuecomment -89405874

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

me produjo un error diferente (un paso a la vez :)

Creo que esto es todo, el resto es mi caja virtual.

Voy a cenar y volver en 5 horas cuando sospeche que mi certificado será válido y todo funcionará. :sonrisa:

Malas noticias, tengo que hacer esto cada vez que reinicie la máquina virtual.

: smile: ¡Supongo que has llegado a la raíz! ¡Gracias!

: aplaudir :: aplaudir :: aplaudir :: aplaudir :: aplaudir :: aplaudir :: aplaudir:

@carolynvs, ¿la solución que

Solo quería confirmar que después de esperar 5 horas hasta que el certificado fuera válido, el env de la máquina acoplable funciona. No tengo ni idea de por qué obtengo certificados con fecha futura, pero tal vez debería actualizar el problema para reflejar la causa raíz real ahora que lo sabemos.

En mi caso, no los certificados fueron el problema, sino la configuración de tiempo en boot2docker ... Como puedo ver en su perfil de github, usted es de Chicago, esa es una zona horaria similar a Bogotá, tal vez el boot2docker se configura incorrectamente en nuestras zonas horarias ...

Después de sincronizar la hora con su solución alternativa, sigo recibiendo el mismo error (el certificado ha caducado o aún no es válido) cuando utilizo esos certificados para conectarme a mi host de la ventana acoplable.

En mi mac, esto es lo que veo después de hacer una nueva caja y verificar su hora.

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

Aquí están los mismos comandos en un nuevo host en 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 fecha muestra mi hora local, pero cree que es UTC y no sé cómo actualizarla para que coincida con hwclock. Intenté cambiar la fecha manualmente, pero hay algo acerca de busybox o virtualbox que deshace inmediatamente cualquier cambio.

Este es el estado de funcionamiento a partir de ayer después de aplicar la solución alternativa:

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

aquí, date corresponde a mi hora local expresada en UTC

algunos consejos para mis symtopms: https://forums.virtualbox.org/viewtopic.php?f=3&t=60558#p281836

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

como date muestra la fecha correcta en mi caso, asumo la fecha fija de la solución en mi caso y, por lo tanto, el problema.

cc @tianon @SvenDowideit PTAL en el anterior RE: problemas de fecha / hora de boot2docker ^^

Algún código que encontré podría estar contribuyendo al problema de la marca de tiempo:

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

Pero siempre ha funcionado bien antes.

@carolynvs @blaggacao ¿

Para mí, está funcionando después de la solución alternativa a la que se hace referencia. Esto, a su vez, indica que algunos parámetros de tiempo de boot2docker no estaban configurados correctamente. Por lo general, esto ocurriría solo durante un período de tiempo limitado justo después de la creación de la máquina. (Probablemente solo en algunas zonas horarias).

De nuevo, esto significaría que las marcas de tiempo de los certificados serían correctas.

Me tropecé con esto nuevamente justo ahora después de reiniciar la PC en mi rc, pero después de la actualización a 5.0, todo parece funcionar. Probablemente podríamos cerrar esto por ahora. De todos modos, tan pronto como note un comportamiento extraño, lo reabriría.

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

Tengo este problema también. No lo cierres.

@damontic Parece un tema diferente al que se está discutiendo aquí.

Estoy tratando de configurar un enjambre en DigitalOcean y tengo el mismo error.

init-do.sh archivo que crea una tienda KV, un maestro de enjambre y un nodo:

 # 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

El registro / error que obtengo

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

Antes de ejecutar esto, actualicé a la máquina 0.5.1

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

Puedo pasar al contexto de la máquina "cónsul" pero no a "demo0" o "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 el aprovisionamiento falla, las instancias creadas serán "inválidas". Intente eliminarlos y comenzar de nuevo desde cero.

@nathanleclaire Acabo de eliminar las máquinas (¿es suficiente con 'docker-machine rm consul demo0 demo1' o debo eliminar manualmente algunas otras cosas?) y volver a ejecutar con el archivo de configuración y obtuve el mismo problema de certificados (al crear en DigitalOcean). Lo extraño es que no hay problema con la máquina 'cónsul', sino solo con las de enjambre (demo0, demo1).

Sin embargo, al crear el enjambre en VirtualBox (5.0.10), funciona bien.

Veo esto cuando uso el controlador AWS

He hecho varias pruebas (muchas en realidad), después de haber eliminado la VM y volver a crearlas (con un enjambre) sigo teniendo el mismo problema.

Ahora tengo este problema después de actualizar de la versión 1.8 a 1.9.1 usando la caja de herramientas de la ventana acoplable en 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

Esto también me está sucediendo periódicamente. Docker v1.9.1

El mismo problema aquí con el controlador azul. Cada vez que creo una nueva máquina azul, falla con el error:

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

Después de ejecutar docker-machine regenerate-certs las validaciones de certificados funcionan bien.

En docker-machine v0.5.5 no hay problema, y ​​la creación de un host de docker funciona 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 ¿Estás

Sí, desde 0.5.5 en adelante. He probado esto con 0.5.6 y 0.6.0.

lo mismo para mí en 0.6.0 con el controlador aws (constantemente) en mac 10.10.5. No sucede con el controlador de caja virtual.

corregido después de cambiar --engine-opt="cluster-advertise=eth1:2376" a --engine-opt="cluster-advertise=eth0:2376" usando docker-machine 0.6.0 (docker-machine 0.5.4 aún falla)

Creo que estoy luchando contra el mismo problema en mi máquina. Estoy usando ubuntu 14.04
docker-machine versión 0.5.5, compilación 02c4254
Ejecución de host en RHEL 7.1
Versión del servidor: 1.10.2-cs1-rc3

Probé todo lo sugerido con el tiempo en las máquinas, aquí está la salida que obtengo 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 / versión

• El nombre de host NO se encontró en la caché de DNS
• Intentando 16.85.3.140 ...
• Conectado a 16.85.3.140 (16.85.3.140) puerto 2376 (# 0)
• establecer correctamente las ubicaciones de verificación de certificados:
• CAfile: /home/eraigosa/.docker/machine/certs/ca.pem
  CApath: / etc / ssl / certs
• SSLv3, protocolo de enlace TLS, saludo del cliente (1):
• SSLv3, protocolo de enlace TLS, saludo del servidor (2):
• SSLv3, protocolo de enlace TLS, CERT (11):
• SSLv3, protocolo de enlace TLS, intercambio de claves de servidor (12):
• SSLv3, protocolo de enlace TLS, solicitud de CERT (13):
• SSLv3, protocolo de enlace TLS, servidor terminado (14):
• SSLv3, protocolo de enlace TLS, CERT (11):
• SSLv3, protocolo de enlace TLS, intercambio de claves de cliente (16):
• SSLv3, protocolo de enlace TLS, verificación CERT (15):
• SSLv3, cifrado de cambio de TLS, saludo del cliente (1):
• SSLv3, protocolo de enlace TLS, terminado (20):
• SSLv3, alerta TLS, saludo del servidor (2):
• error: 14094412 : rutinas SSL
• Cerrar conexión 0
  curl: (35) error: 14094412 : rutinas SSL

@nathanleclaire ¡ He encontrado el cultprit! prltoolsd de boot2docker constantemente configura incorrectamente mi fecha / zona horaria.

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

Después de detener prltoolsd y restablecer la fecha, todos los comandos de mi docker-machine funcionan como se esperaba y mis certificados no se regeneran.

Todavía no sé por qué la zona horaria está configurada en UTC y la hora de ubicación después de hacer una nueva máquina, por lo que esto es solo una solución, no una solución.

¡ Bien @carolynvs ! Trabajaremos para ver si podemos solucionar esto en boot2docker.

@tianon @ legal90 FYI ^^

@carolynvs Wow: temeroso:. Parece realmente extraño, porque el proceso prltoolsd no debería iniciarse en ningún otro sistema de virtualización excepto Parallels Desktop. El demonio se iniciará solo si /usr/bin/prlvmcheck devuelve 0 código de salida, lo que significa que estamos en Parallels VM.

¿Ha reproducido este problema en Virtualbox VM? ¿Qué versión de Boot2Docker estás usando?

Ps Además, si asumimos que prltoolsd es la única razón, entonces la versión de Docker Machine no debería tener sentido. Sin embargo, otros comentarios anteriores ( enlace ) indican que el problema aparece solo en Machine 0.5.5+

@ legal90 Eso tiene más sentido. Mi entorno es un poco inestable, pero solía funcionar bien:

1. Estoy en una Mac con Parallels.
2. Dentro de Parallels ejecuto Windows, luego la última instalación de la caja de herramientas de la ventana acoplable. Hago esto porque escribo documentación y tutoriales para Docker, y necesito apuntar a usuarios de Mac, Linux y Windows.

Esto explica por qué prltoolsd está intentando administrar el reloj de mi host de la ventana acoplable. Debe retomar el hecho de estar anidado dentro de Parallels. ¿Eso también explica por qué el reloj del sistema está configurado en la hora local pero cree que es UTC?

Ese es el problema de raíz que me hizo abrir este error. Creo una nueva máquina acoplable a las 10 AM CST (-6). El reloj del sistema ( date ) en la nueva máquina cree que son las 10 AM UTC, por lo que las marcas de tiempo en los certificados están "en el futuro". hwclock informa la hora correcta.

Mirando el boot2docker Dockerfile, noté que está configurando /etc/timezone a UTC y _should_ haber configurado /etc/localtime a UTC también.

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

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

Pero en el host de mi máquina docker, el paquete tzdata no está instalado, por lo que /usr/share/zoneinfo no existe y tampoco /etc/localtime . He creado mi propio boot2docker a partir del último Dockerfile solo para verificar que no estoy usando una iso antigua. Me pregunto si perder el archivo /etc/localtime está contribuyendo al problema de la hora incorrecta.

@carolynvs Ah, ahora lo tengo.

Esto explica por qué prltoolsd está intentando administrar el reloj de mi host de la ventana acoplable. Debe retomar el hecho de estar anidado dentro de Parallels.

Sí, esa es la raíz del problema. prltoolsd ejecuta en Virtualbox VM anidada en Parallels VM. He reproducido esto y he informado a las personas responsables de Parallels. Te lo haré saber tan pronto como esté arreglado.

¿Eso también explica por qué el reloj del sistema está configurado en la hora local pero cree que es UTC?

Bueno, es difícil de confirmar, pero es un problema conocido de Parallels Desktop (y sus herramientas de invitado). Originalmente se informó aquí: https://github.com/Parallels/vagrant-parallels/issues/186.
Se solucionó en PD 11 mediante una opción adicional para la utilidad prlctl , pero no ayuda en su raro caso, porque en realidad está ejecutando Virtualbox VM en Windows.

Lo siento, pero la única solución que puedo sugerirle en este momento es evitar que prltoolsd ejecute en su VM en el arranque. Si usa una compilación ISO Boot2Docker personalizada, puede eliminar las líneas relacionadas con los paralelos de Dockerfile y reconstruir la ISO. O comente esta línea: https://github.com/boot2docker/boot2docker/blob/master/rootfs/rootfs/bootscript.sh#L101

¡Gracias por la información adicional sobre cómo funciona prltoolsd! Haré lo que sugiera y crearé una iso personalizada para mi configuración. :cerveza:

Cerraría este problema, ya que esto soluciona mi problema, pero lo dejo a usted ya que parece que otras personas lo están atacando (¡aunque probablemente por diferentes razones!).

Creo que podemos tratarlo como efectivamente resuelto; podemos volver a abrir si se descubren problemas nuevos.

¡Gracias a todos por sus contribuciones para informar y clasificar este número épicamente largo!

Estoy usando DockerToolbox 1.10.3 en Windows. Funcionaba bien hasta que reinicié y ahora tengo el mismo problema. Tampoco estoy tan familiarizado con Docker, entonces, ¿alguien puede decirme cuál es la solución?

@mtrtm ¿ docker-machine regenerate-certs -f no funciona?

Sí, docker-machine regenerate-certs -f lo hace. También parece hacerlo cada vez que inicio Docker Quickstart Terminal

+1
Estoy usando Docker principalmente en un servidor Redhat y todo funciona bien. No soy un experto pero sé lo que hago. En Windows con virtualbox, sin embargo, cada vez que se reinicia la máquina virtual docker, necesito regenerar-certs. Estoy en la caja de herramientas 1.11.1

+1

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

$ docker-machine ls
NOMBRE CONDUCTOR ACTIVO ESTADO URL ERRORES DE SWARM DOCKER
vbox-test - virtualbox Running tcp: //192.168.99.100 : 2376 Desconocido No se puede consultar la versión de la https://192.168.99.100 : 2376 / v1.15 / version: x509: el certificado ha caducado o aún no es válido

$ docker-machine env vbox-test
Error al verificar la conexión TLS: Error al verificar y / o regenerar los certificados: Hubo un error al validar los certificados para el host "192.168.99.100:2376": x509: el certificado ha caducado o aún no es válido
Puede intentar regenerarlos usando 'docker-machine regenerate-certs [nombre]'.
Tenga en cuenta que esto activará un reinicio del demonio de Docker que dejará de ejecutar contenedores.

$ docker-machine regenerate-certs vbox-test
¿Regenerar certificados de máquina TLS? Advertencia: esto es irreversible. (s / n): s
Regeneración de certificados TLS
Esperando que SSH esté disponible ...
Detectando el aprovisionador ...
Copiando certificados al directorio de la máquina local ...
Copiando certificados a la máquina remota ...
Estableciendo la configuración de Docker en el demonio remoto ...

$ docker-machine env vbox-prueba
Error al verificar la conexión TLS: Error al verificar y / o regenerar los certificados: Hubo un error al validar los certificados para el host "192.168.99.100:2376": x509: el certificado ha caducado o aún no es válido
Puede intentar regenerarlos usando 'docker-machine regenerate-certs [nombre]'.
Tenga en cuenta que esto activará un reinicio del demonio de Docker que dejará de ejecutar contenedores.

Tenía esto en la instalación predeterminada de Docker Tookit (instalado en Windows 10 Home) descargado 2016-10-30. El error desapareció después de ejecutar:

docker-machine regenerate-certs

Tener este problema en macOS. docker-machine env queja:

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

Regenerar los certificados (incluso con -f ) no ayuda. docker-machine ssh docker1 date muestra la fecha y hora correctas.

¿Algunas ideas?

@paddor Regenerando los certificados incl. los certificados de cliente ( docker-machine regenerate-certs -f --client-certs ) me lo arreglaron.