Machine: Os certificados não são instalados corretamente, sempre regeneram

Obrigado pelo resumo detalhado. Já vi problemas como esse antes e vou analisá-los.

Você está no mais recente VirutalBox? ou seja, 5.0.6?

Eu estava usando o 5.0.4 que vem com a versão mais recente do Docker Toolbox (1.8.2c). Acabei de remover essa versão, instalei a 5.0.6 e estou tendo o mesmo comportamento.

Ok, obrigado.

@carolynvs Se você remover a rede somente host que você possui (pode fazer isso na GUI do VirtualBox) e tentar novamente, funciona?

Excluí a máquina, removi o adaptador e tentei novamente com o mesmo resultado.

Ok, obrigado. Comportamento muito peculiar. Posso fazer um teste de compilação que despeja mais informações sobre os certificados e sugerir que você tente fazer isso, se estiver de acordo.

Claro! Fico feliz em ajudar no que puder.

Se você quiser apenas fazer um branch e apontar para mim, posso construí-lo sozinho (: heart: builds em contêineres!). Dessa forma, você não precisa jogar várias construções por cima da parede se isso levar mais de uma tentativa.

Outra coisa a se considerar ao consertar isso é que algumas pessoas como eu escrevem o conteúdo de docker-machine env em um arquivo que irei fornecer para cada nova sessão de terminal (já que é um pouco mais rápido do que executar docker-machine env ). Se a saída desse comando contiver algo que não possa ser eval d, isso obviamente causará problemas.

Portanto, linhas como as seguintes causarão 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...

Eu tive esse problema em 0.5.0-dev , mas não o percebi desde o downgrade para 0.4.1 .

Eu experimentei exatamente o mesmo comportamento hoje no candidato a lançamento.

Olá @carolynvs @blaggacao , muito obrigado pelo seu feedback.

Estou tentando reproduzir / corrigir esse bug. Você poderia tentar este PR (https://github.com/docker/machine/pull/2006) que criei para ajudar a investigar o bug

Parece que também estou vendo isso. Estou usando a versão mais recente de master no OS X usando o driver digitalocean , então isso definitivamente não tem nada a ver com o ambiente. Acho que as tags area/windows e area/driver-virtualbox são irrelevantes aqui :)

Olá @hairyhenderson , você pode tentar construir PR # 2006 e me dizer o resultado de docker-machine -D env default ?

@dgageot - servirá quando eu tiver uma chance.

Também estou pensando um pouco mais sobre isso e percebendo que estou fazendo uma compilação _local_ (ou seja, make build no OS X, sem usar um contêiner). Uma das áreas em que go build se comportou de maneira diferente no passado é em torno de certificados (especialmente certificados de CA raiz), então isso _pode_ estar relacionado a isso ... Não sei.

Mas vou reconstruir com # 2006 e testá-lo. Obrigado!

@hairyhenderson Esse é um bom ponto. Vou rodar meus testes com uma máquina docker compilada cruzada

@dgageot Aqui está a saída com falha https://gist.github.com/carolynvs/e2473d21c3376f1ebec2 de docker-machine -D env default para uma máquina totalmente nova.

Eu criei o # 2006 e copiei docker-machine.exe e docker-machine-driver-virtualbox.exe para o diretório de instalação do Docker Toolbox. Estou usando o Docker Toolbox 1.8.2c no Windows 10.

Não sou proficiente o suficiente para saber como construir, talvez dê uma olhada nesta noite, se conseguir descobrir.

@carolynvs Muito obrigado. Ainda não entendo o que está acontecendo, mas seus registros vão me ajudar.

@carolynvs Você pode fornecer a saída 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

Eu descobri que ocasionalmente ainda recebo adaptadores de host duplo. Acabei de deletar os dois e criar uma nova máquina. Os certs ainda estão se regenerando quando executo docker-machine env default .

Aqui está a saída dos comandos VBoxManage pela segunda vez (com apenas 1 adaptador 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 Não tenho ideia até agora.
Eu empurrei mais alguns commits no PR para imprimir mais informações e tentar coisas.
Se você tiver tempo para atualizar o resultado obtido, seria ótimo.

ping @nathanleclaire @ dmp42 alguma ideia?

Aqui está a nova saída: https://gist.github.com/carolynvs/84cd140bcbf9b696e20f.

Avise-me se houver outra maneira de depurar o problema de conexão. Não tenho certeza de qual docker-machine está detectando que está causando a regeneração dos certs, mas estou feliz em dar uma olhada em / var / lib / boot2docker no host ou comparar certs entre o Windows e o host, etc se eu soubesse o que procurar.

@carolynvs Isso seria incrível. Como você apontou, o problema surge em 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 certificado não foi copiado corretamente para a VM.
Ou a vm não está acessível na porta 192.168.99.100:2376 (configuração de rede host? Firewall, vpn? Configuração de rede vm?)
Ou há um problema na forma como verificamos.

Se você exportar as variáveis ​​env fornecidas por docker-machine env e ignorar os erros, você consegue se conectar ao daemon do docker?

Posso executar ping no host docker e ssh nele. Quando ignoro as mensagens sobre a regeneração de certificados de docker-machine env e defino as variáveis ​​manualmente, ainda não consigo me conectar com o cliente 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.

Os certs no host em /var/lib/boot2docker/tls/ não correspondem aos locais em ~/.docker/machine/machines/default/ . Os certs em /var/lib/boot2docker/ correspondem ao que está em minha máquina local. Além disso, os certs em ~/.docker/machine/certs/ correspondem ao que está em ~/.docker/machine/machines/default/ .

Estou supondo que o problema está nos certificados não correspondentes, o que impede a docker-machine de se conectar com segurança ao daemon do docker, acionando assim um cert regen?

Eu verifiquei se o daemon do docker está em execução:

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

Também aqui estão os registros de boot2docker e docker: https://gist.github.com/carolynvs/f7965455ebbceb85d4e6

: +1: Obrigado! Sinto que estamos nos aproximando: sorria:

IIRC, os certificados em /var/lib/boot2docker/tls são gerados no lado do servidor por um script de inicialização no sistema operacional boot2docker e não são usados ​​para nada no modelo de máquina atual (eles são uma relíquia de como boot2docker-cli historicamente esperava que os certificados fossem definidos pra cima).

@carolynvs @nathanleclaire Não tenho ideia então. A única diferença que tenho em meus logs é que estou usando o VBox versão 5.0.6 e um boot2docker mais recente.

@carolynvs Você pode tentar se conectar ao docker daemon usando curl? Podemos obter um feedback melhor sobre o que está errado. Eu acho que você está no Windows, então eu realmente não sei como fazer isso, mas aqui está como fiz no 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, aqui está o tutorial que usei para fazer funcionar: http://opensolitude.com/2015/07/12/curl-docker-remote-api-os-x.html

@dgageot Ooh, sim, isso parece ser um problema na minha máquina (usando curl / openssl do Git para Windows para que todos os comandos sejam iguais).

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

Eu verifiquei todos os certificados em ~ / .docker / machine / certs usando vi -b path/to/cert e verifiquei que ele tem terminações de linha unix. Também usei o seguinte comando para tentar verificar se o openssl conseguia lê-los.

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

Vou continuar bisbilhotando com certs, pois esse parece ser o problema. Talvez experimente em outra máquina e veja se é apenas uma coisa do Windows 10.

@carolynvs Bom trabalho! Vou verificar isso amanhã de manhã (hora de Paris)

Olá @carolynvs , você tentou este comando em ca.pem também?

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

Você pode verificar se ele começa corretamente com -----BEGIN CERTIFICATE----- e termina com -----END CERTIFICATE----- . Nada antes e depois.

@carolynvs Devo admitir que não sei o que está acontecendo. Você já tentou este PR que parece vagamente relacionado.

Se você não se importa em confirmar este resumo intermediário, então posso silenciosamente dedicar meu cérebro a isso:

• Os certificados são copiados, mas não podem ser lidos?

Tenho certeza de que você já verificou: http://stackoverflow.com/questions/20837161/openssl-pem-routinespem-read-biono-start-linepem-lib-c703expecting-truste
Eu o coloquei como referência para os outros.

Acabei de tentar um comando curl diferente usando --cert e --key em vez do arquivo pfx gerado e ele pode se conectar.

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

Olhando mais de perto a saída de docker-machine env , vejo que ele está exportando o que considero um caminho de certificado inválido. No meu mac, isso aponta para .docker / machines / machine /enquanto na saída abaixo, ele aponta para .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)"

Depois de definir manualmente as variáveis ​​de ambiente, alterando o caminho do certificado para o que acho que deveria ser, posso me conectar com o cliente docker.

Talvez quando a docker-machine está testando se pode se conectar, ela está usando os certificados errados?

Eu adicionei algumas informações de depuração ao validar certificados e, em seguida, tentei conectar manualmente usando primeiro o que a docker-machine está usando e depois o que acho que deveria ser usado.

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

Portanto, vejo 2 coisas suspeitas:

1. DOCKER_CERT_PATH está usando .docker / machine / certs em vez de .docker / machine / machines /
2. Validar está usando server.pem e server-key.pem em vez de cert.pem e key.pem. Não sei para que serve cada certificado, mas não parece certo.

Muito obrigado @carolynvs, isso deve realmente ajudar. Antes de eu digerir tudo que você relatou, você pode tentar a versão mais recente de https://github.com/docker/machine/pull/2006. Ela deve imprimir os certificados que estão sendo usados ​​para validação. Isso deve ajudar

Aqui estão os certificados que ele está usando

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

Isso vem das minhas próprias informações de depuração, não do PR, que leva muito tempo para construir agora que está construindo todos os plug-ins. :sorriso:

OK, agora estou confuso, então tentarei recapitular.

Você pode confirmar que:

• ~/.docker/machine/certs/ca.pem é o mesmo que ~/.docker/machine/machines/bugtest/ca.pem
• ~/.docker/machine/certs/cert.pem é o mesmo que ~/.docker/machine/machines/bugtest/cert.pem
• ~/.docker/machine/certs/key.pem é o mesmo que ~/.docker/machine/machines/bugtest/key.pem
• Você conseguiu fazer docker cli chegar ao servidor. Qual valor de DOCKER_CERT_PATH você usou então?
• No seu mac, docker-machine env bugtest imprime exporta DOCKER_CERT_PATH="~/.docker/machine" e não DOCKER_CERT_PATH="~/.docker/machine/certs"

Mais uma vez obrigado pelo apoio!

@carolynvs FTR, cross-building apenas docker-machine, apenas para windows deve ser muito mais rápido: TARGET_ARCH = amd64 TARGET_OS = windows make build-x-machine

Desculpe pelo despejo de cérebro!

• ca.pem, cert.pem e key.pm são iguais em ~/.docker/machine/certs e ~/.docker/machine/machines/bugtest
• O cliente do docker funcionou quando eu defini DOCKER_CERT_PATH como ~.docker/machine/machines/bugtest
• No meu mac (que funciona) docker-machine env sets DOCKER_CERT_PATH="~/.docker/machine/machines/bugtest" . No Windows 10 (que não), o mesmo comando resulta em DOCKER_CERT_PATH="~/.docker/machine/certs"

Isso estava no meu cérebro, mas pode ter se perdido. Quando docker-machine está validando os certificados, ela está tentando se conectar ao docker daemon usando server.pem e server-key.pem. Isso parece super suspeito.

OK. Vamos chamar @nathanleclaire e @ehazlett para o resgate. Acho que você acertou em cheio, mas agora sou muito novo no projeto para entender por que temos tantos certificados duplicados e por que não usamos os certos.

Obrigado pela dica de construção!

Abaixo está a saída relevante da última compilação do PR # 2006 e aqui está a saída completa: 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

Desculpe pelo barulho fechado / reaberto. Eu me atrapalhei

Oi vey. @carolynvs @dgageot vocês todos são campeões por continuar a perseguir este aqui. Acho que a suspeita de Carolyn está correta: se DOCKER_CERT_PATH não estiver sendo configurado corretamente, a comunicação com o daemon não funcionará corretamente. Parece que pode ser um problema com caminhos que introduzi inadvertidamente nas alterações de libmachine . Vou continuar investigando isso e vasculhando suas descobertas até agora.

A porta de entrada para o culpado pode ser esta linha, então?
https://github.com/docker/machine/blob/8aa1572e0dcd75762a7627e1056ef104317f44b9/libmachine/persist/filestore.go#L155

@blaggacao Definitivamente, fortemente no reino da possibilidade - esse código tende a ser um pouco frágil e foi problemático no passado.

Eu não entendo como isso pode ser diferente no Windows e Mac OS, embora como @carolynvs confirmou.
Para mim, ele constrói claramente o caminho .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 em silêncio.

@blaggacao claramente, não tenho o mesmo comportamento que @carolynvs no mac. Portanto, há algo suspeito.

Sim, os certificados são copiados para o diretório daquela máquina durante o bit de provisionamento.

@dgageot Desculpas pela confusão. Meu mac está executando docker-machine 0.4.1. Só estou executando o PR build na minha máquina Windows, pois venho testando as correções lá à medida que são mescladas no master.

Posso fazer uma compilação e executar novamente no meu mac agora.

Eu retomo:

• diffs não estão mostrando diferença entre /machine/certs e /machine/machines/certs
• Não consigo reproduzir a solução alternativa de Carlynv para resolver o problema.

Ao definir manualmente DOCKER_CERT_PATH no Windows (no bash), você deve usar caminhos de estilo UNIX. Por exemplo, export DOCKER_CERT_PATH="~./docker/machine/machines/oca" .

Posso confirmar que na minha máquina (instável) os certificados correspondem entre / machine / certs e / machine / machines / certs.

Posso confirmar, por cópia manual, pois o scp não 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

o segundo e o terceiro diferem entre /machines/oca e oca:~/.docker

Quais caminhos na VM você está usando para os certs @blaggacao ?

Acabei de perceber que era o errado ...

Eu chequei ~/.docker Vou verificar novamente /var/lib/boot2docker

Eu posso definitivamente confirmar isso

• os certs em /machines/oca e oca:/var/lib/boot2docker/ são os mesmos
  (Corro dos2unix em todos os 3 campos ca.pem , server.pem , sever-key.pem em oca )

Além disso, recebo este erro de tempo limite: https://github.com/docker/machine/blob/6a5219b879db52698ccb2b7e0aafd516b34df839/libmachine/provision/boot2docker.go#L193
toda vez que corro env com a bandeira --native-ssh ou não

Sim, @blaggacao também parece que o único IP do host atribuído à VM não está acessível em seu computador. Você pode ping $(docker-machine ip vmname) ?

não, também não funciona ... "Solicitação expirada"

docker-machine ssh vmname funciona embora

Sim, ssh passa por localhost . Mas parece que você não pode contatar o host atribuído apenas com o IP da VM, então eu não esperaria que env funcionasse corretamente. Você está usando VPN ou proxy?

não, que eu saiba, apenas verifiquei novamente o gerenciador de tarefas ... UPDATE detectou um, fechando

Fechar não muda nada, mas esse é outro problema, eu acho ...

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

me leva a

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

Como não recebo: https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/libmachine/cert/cert.go#L22

os únicos candidatos restantes são:
https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/libmachine/cert/cert.go#L198 -L205

Isso cheira a uma conexão entre os dois problemas. Você pode interpretar minha linha de pensamento?

Escavação remota: https://github.com/leo-stone/fix-go-1.5-tls-issue/blob/master/main.go

Eu não confiava mais no meu ambiente Windows, então recomecei, reconstruí o Windows e coloquei no # 2006.

No arquivo docker.log, vejo este erro

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

então eu verifiquei as datas do certificado

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

O problema pode ser que o certificado tem uma data futura? Isso explicaria por que originalmente meus comandos curl não funcionaram, mas algumas horas depois eles funcionaram.

mesmo aqui:

$ 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

Isso é em cerca de 5 horas no meu fuso horário (Bogotá / Américas) Bem, mas diz GMT (UTC). Bogotá é UTC-5

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

Atualização: FIX

Conforme declarado aqui: https://github.com/docker/docker/issues/11534#issuecomment -89405874

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

gerou um erro diferente (um passo de cada vez :)

Acho que é isso, o resto é minha caixa virtual.

Vou jantar e voltar em 5 horas, quando suspeito que meu certificado será válido e tudo funcionará. :sorriso:

Más notícias, tenho que fazer isso a cada reinicialização do VM.

: smile: Acho que você atingiu a causa raiz! Obrigado!

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

@carolynvs a correção que postei funcionou para você?

Eu só queria confirmar que depois de esperar 5 horas até que o certificado fosse válido, o ambiente docker-machine funciona. Não tenho ideia de por que estou recebendo certificados que são datados no futuro, mas talvez deva atualizar o problema para refletir a causa raiz real agora que sabemos.

No meu caso, não o certs era o problema, mas a configuração de tempo no boot2docker ... Como posso ver no seu perfil do github, você é de Chicago, é um fuso horário semelhante a Bogotá, talvez o boot2docker esteja configurado incorretamente em nossos fusos horários ...

Depois de sincronizar o tempo usando sua solução alternativa, ainda recebo o mesmo erro (o certificado expirou ou ainda não é válido) ao usar esses certificados para me conectar ao meu host docker.

No meu mac, é isso que vejo depois de fazer uma nova caixa e verificar a 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

Aqui estão os mesmos comandos em um novo host no 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

A data está mostrando minha hora local, mas pensa que é UTC e não sei como atualizá-la para coincidir com o hwclock. Tentei alterar a data manualmente, mas há algo no busybox ou no virtualbox que desfaz imediatamente qualquer alteração.

Este é o estado de funcionamento de ontem, após a aplicação da solução 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

aqui, date corresponde ao meu horário local expresso em UTC

algumas dicas para meus symtopms: https://forums.virtualbox.org/viewtopic.php?f=3&t=60558#p281836

time está congelado, após 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 está mostrando a data correta no meu caso, presumo que a solução alternativa foi a data fixada no meu caso e, portanto, o problema.

cc @tianon @SvenDowideit PTAL no RE acima: problemas de data / hora do boot2docker ^^

Alguns códigos que encontrei podem estar contribuindo para o problema de carimbo de data / hora:

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

Mas sempre funcionou bem antes.

@carolynvs @blaggacao Você ainda se

Para mim, está funcionando após a solução alternativa mencionada. Isso, por sua vez, indica que algum parâmetro de tempo do boot2docker não foi definido corretamente. Normalmente, isso ocorreria apenas durante um período de tempo limitado, logo após a criação da máquina. (Provavelmente apenas em alguns fusos horários).

Novamente, isso significaria que os carimbos de data / hora certs estariam corretos.

Eu tropecei nisso novamente agora após reiniciar o pc no meu rc, mas após a atualização para 5.0 tudo parece funcionar. Provavelmente poderíamos fechar isso por enquanto. De qualquer forma, assim que eu perceber um comportamento estranho, eu o reabriria.

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

Eu tenho esse problema tambem. Não feche.

@damontic Isso parece um assunto diferente do que está sendo discutido aqui.

Estou tentando configurar um swarm no DigitalOcean e tenho o mesmo erro.

Arquivo init-do.sh que cria um armazenamento KV, um mestre de enxame e um nó:

 # 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

O log / erro que recebo

$> ./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 executar isso, eu atualizei para a Máquina 0.5.1

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

Posso passar para o contexto da máquina "cônsul", mas não para "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 Se o provisionamento falhar, as instâncias criadas serão "inválidas". Experimente removê-los e começar do zero.

@nathanleclaire Acabei de excluir as máquinas ('docker-machine rm consul demo0 demo1' é suficiente ou devo excluir manualmente algumas outras coisas?) e executei novamente com o arquivo de configuração e tive o mesmo problema certs (ao criar no DigitalOcean). O estranho é que não há problema com a máquina 'cônsul', mas apenas com as do enxame (demo0, demo1).

Ao criar o enxame no VirtualBox (5.0.10), ele está funcionando bem.

estou vendo isso ao usar o driver aws

Já fiz vários testes (muitos na verdade), depois de ter deletado a VM e recriado (com um swarm) ainda tenho o mesmo problema.

Agora tenho esse problema depois de atualizar da versão 1.8 para 1.9.1 usando a caixa de ferramentas do docker no 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

Isso também está acontecendo comigo periodicamente. Docker v1.9.1

O mesmo problema aqui com o driver azure. Cada vez que criamos uma nova máquina azul, ela falha com o erro:

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

Depois de executar docker-machine regenerate-certs as validações certs funcionam bem.

No docker-machine v0.5.5 não há problema, e a criação de um host docker funciona bem:

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 Você está tendo esse problema com a versão 0.6.0?

Sim, de 0,5,5 em diante. Eu testei isso com 0.5.6 e 0.6.0.

mesmo para mim em 0.6.0 com driver aws (constantemente) no mac 10.10.5. Não acontecendo com o driver de caixa virtual.

corrigido após alterar --engine-opt="cluster-advertise=eth1:2376" para --engine-opt="cluster-advertise=eth0:2376" usando docker-machine 0.6.0 (docker-machine 0.5.4 ainda falha)

Acho que estou lutando contra o mesmo problema na minha máquina. Estou usando o ubuntu 14.04
docker-machine versão 0.5.5, build 02c4254
Host em execução no RHEL 7.1
Versão do servidor: 1.10.2-cs1-rc3

Tentei tudo sugerido com o tempo nas máquinas, aqui está o resultado que recebo do 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 / versão

• O nome do host NÃO foi encontrado no cache DNS
• Tentando 16.85.3.140 ...
• Conectado a 16.85.3.140 (16.85.3.140) porta 2376 (# 0)
• definir com êxito os locais de verificação de certificado:
• CAfile: /home/eraigosa/.docker/machine/certs/ca.pem
  CApath: / etc / ssl / certs
• SSLv3, handshake TLS, Olá do cliente (1):
• SSLv3, handshake TLS, servidor hello (2):
• SSLv3, handshake TLS, CERT (11):
• SSLv3, handshake TLS, troca de chave de servidor (12):
• SSLv3, handshake TLS, Solicitar CERT (13):
• SSLv3, handshake TLS, servidor concluído (14):
• SSLv3, handshake TLS, CERT (11):
• SSLv3, handshake TLS, troca de chave de cliente (16):
• SSLv3, handshake TLS, verificação CERT (15):
• SSLv3, cifra de alteração de TLS, Olá do cliente (1):
• SSLv3, handshake TLS, concluído (20):
• SSLv3, alerta TLS, servidor Olá (2):
• erro: 14094412 : Rotinas SSL
• Fechando conexão 0
  curl: (35) erro: 14094412 : Rotinas SSL

@nathanleclaire eu encontrei o cultprit! prltoolsd do boot2docker está constantemente configurando minha data / fuso horário incorretamente.

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

Depois de parar prltoolsd e redefinir a data, todos os meus comandos docker-machine funcionam como esperado e meus certificados não são regenerados.

Ainda não sei por que o fuso horário está definido como UTC e a hora local após fazer uma nova máquina, então esta é apenas uma solução alternativa, não uma correção.

Legal @carolynvs ! Vamos trabalhar para ver se podemos consertar isso no boot2docker.

@tianon @ legal90 FYI ^^

@carolynvs Uau: medo:. Parece muito estranho, porque prltoolsd processo não deve iniciar em nenhum outro sistema de virtualização, exceto Parallels Desktop. O daemon iniciará apenas se /usr/bin/prlvmcheck retornar 0 código de saída, o que significa que estamos no Parallels VM.

Você reproduziu este problema no Virtualbox VM? Qual versão do Boot2Docker você está usando?

Ps Além disso, se assumirmos que prltoolsd é o único motivo, a versão da máquina Docker não deve fazer sentido. No entanto, outros comentários acima ( link ) informam que o problema aparece apenas na Máquina 0.5.5+

@ legal90 Isso faz mais sentido. Meu ambiente é um pouco instável, mas costumava funcionar bem:

1. Estou em um Mac rodando o Parallels.
2. Dentro do Parallels, executo o Windows e, em seguida, a instalação mais recente da caixa de ferramentas do docker. Faço isso porque escrevo documentação e tutoriais para o Docker e preciso direcionar os usuários do Mac, Linux e Windows.

Isso explica por que prltoolsd está tentando gerenciar meu relógio do host docker. Deve estar começando a ser aninhado dentro do Parallels. Isso também explica por que o relógio do sistema está definido para a hora local, mas pensa que é UTC?

Essa é a raiz do problema que me levou a abrir esse bug. Crio uma nova máquina docker às 10h CST (-6). O relógio do sistema ( date ) na nova máquina pensa que são 10h00 UTC, então os carimbos de data / hora nos certificados estão "no futuro". hwclock relata a hora correta.

Olhando para o boot2docker Dockerfile, percebi que ele está definindo /etc/timezone como UTC e _should_ definiu /etc/localtime também como UTC.

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

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

Mas no host da minha máquina docker, o pacote tzdata não está instalado, então /usr/share/zoneinfo não existe e nem /etc/localtime . Eu construí meu próprio boot2docker a partir do Dockerfile mais recente apenas para verificar se não estou usando um iso antigo. Será que perder o arquivo /etc/localtime está contribuindo para o problema de hora incorreta?

@carolynvs Ah, agora entendi.

Isso explica por que prltoolsd está tentando gerenciar meu relógio do host docker. Deve estar começando a ser aninhado dentro do Parallels.

Sim, essa é a raiz do problema. prltoolsd é executado no Virtualbox VM aninhado no Parallels VM. Eu reproduzi isso e relatei às pessoas responsáveis ​​na Parallels. Avisarei você assim que for corrigido.

Isso também explica por que o relógio do sistema está definido para a hora local, mas pensa que é UTC?

Bem, é difícil de comprometer, mas é um problema conhecido do Parallels Desktop (e suas ferramentas de convidado). Ele foi relatado originalmente aqui: https://github.com/Parallels/vagrant-parallels/issues/186.
Foi contornado no PD 11 pela opção adicional para o utilitário prlctl , mas não ajuda em seu caso raro, porque você está realmente executando o Virtualbox VM no Windows.

Sinto muito, mas a única solução que posso sugerir no momento é evitar que prltoolsd seja executado em sua VM durante a inicialização. Se você usar um build ISO Boot2Docker personalizado, poderá remover linhas relacionadas a paralelos do Dockerfile e reconstruir o ISO. Ou comente esta linha: https://github.com/boot2docker/boot2docker/blob/master/rootfs/rootfs/bootscript.sh#L101

Obrigado pela informação extra sobre como funciona o prltoolsd! Vou fazer o que você sugere e fazer uma iso personalizada para minha configuração. :Cerveja:

Eu encerraria esse problema, pois isso corrige meu problema, mas deixarei isso com você, pois outras pessoas parecem estar acertando-o (embora provavelmente por razões diferentes!).

Acho que podemos tratá-lo como efetivamente resolvido; podemos reabrir se novos problemas forem descobertos.

Obrigado a todos por suas contribuições em relatar e fazer a triagem desta questão épica!

Estou usando o DockerToolbox 1.10.3 no Windows. Ele estava funcionando bem até que reiniciei e agora estou tendo o mesmo problema. Também não estou familiarizado com o Docker, então alguém pode me dizer qual é a solução?

@mtrtm docker-machine regenerate-certs -f não funciona?

Sim, docker-machine regenerate-certs -f faz. Ele também parece funcionar sempre que eu inicio o Docker Quickstart Terminal

+1
Estou usando o docker principalmente em um servidor Redhat e tudo funciona bem. Não sou um especialista, mas sei o que estou fazendo. No Windows com o virtualbox, no entanto, sempre que o docker VM é reiniciado, preciso regenerar-certs. Estou na caixa de ferramentas 1.11.1

+1

Macbook final 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
NOME DO MOTORISTA ATIVO DO ESTADO URL ERROS DO SWARM DOCKER
vbox-test - virtualbox Executando tcp: //192.168.99.100 : 2376 Desconhecido Não é possível consultar a versão do docker: Obtenha https://192.168.99.100 : 2376 / v1.15 / versão: x509: o certificado expirou ou ainda não é válido

$ docker-machine env vbox-test
Erro ao verificar a conexão TLS: Erro ao verificar e / ou regenerar os certificados: Ocorreu um erro ao validar certificados para o host "192.168.99.100:2376": x509: o certificado expirou ou ainda não é válido
Você pode tentar regenerá-los usando 'docker-machine regenerate-certs [nome]'.
Esteja ciente de que isso acionará uma reinicialização do daemon do Docker, que interromperá a execução de contêineres.

$ docker-machine regenerate-certs vbox-test
Regenerar certificados de máquina TLS? Aviso: isso é irreversível. (s / n): s
Gerando novamente certificados TLS
Esperando que o SSH esteja disponível ...
Detectando o provisionador ...
Copiando certificados para o diretório da máquina local ...
Copiando certificados para a máquina remota ...
Definindo a configuração do Docker no daemon remoto ...

$ docker-machine env vbox-test
Erro ao verificar a conexão TLS: Erro ao verificar e / ou regenerar os certificados: Ocorreu um erro ao validar certificados para o host "192.168.99.100:2376": x509: o certificado expirou ou ainda não é válido
Você pode tentar regenerá-los usando 'docker-machine regenerate-certs [nome]'.
Esteja ciente de que isso irá disparar uma reinicialização do daemon do Docker, que interromperá a execução de contêineres.

Eu tinha isso na instalação padrão do Docker Tookit (instalado no Windows 10 Home) baixado 2016-10-30. O erro desapareceu após a execução:

docker-machine regenerate-certs

Tendo esse problema no macOS. docker-machine env reclama:

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

Gerar novamente os certificados (mesmo com -f ) não ajuda. docker-machine ssh docker1 date mostra a data e a hora corretas.

Alguma ideia?

@paddor Gerando novamente os certificados incl. certificados de cliente ( docker-machine regenerate-certs -f --client-certs ) consertaram para mim.