Machine: Сертификаты не устанавливаются должным образом, всегда обновляйте

Спасибо за подробное резюме. Я тоже видел подобные проблемы раньше, и я займусь этим.

Вы используете последнюю версию VirutalBox? т.е. 5.0.6?

Я использовал 5.0.4, который поставляется с последней версией Docker Toolbox (1.8.2c). Я только что удалил эту версию, установил 5.0.6, и у меня такое же поведение.

Хорошо спасибо.

@carolynvs Если вы удалите

Я удалил машину, снял адаптер и повторил попытку с тем же результатом.

Хорошо спасибо. Очень своеобразное поведение. Я мог бы сделать тестовую сборку, которая выводит больше информации о сертификатах, и предложить вам попробовать это, если вы согласны.

Конечно! Я рада помочь, чем могу.

Если вы хотите просто создать ветку и указать мне на нее, я могу построить ее сам (: heart: контейнерные сборки!). Таким образом, вам не нужно перебрасывать несколько построек через стену, если для этого потребуется более одной попытки.

Еще одна вещь, которую, возможно, следует учитывать при исправлении этого, некоторые люди, такие как я, фактически записывают содержимое docker-machine env в файл, который я буду использовать для каждого нового сеанса терминала (поскольку это немного быстрее, чем запуск docker-machine env ). Если вывод этой команды содержит что-то, что не может быть eval d, это, очевидно, вызовет проблемы.

Таким образом, строки, подобные приведенным ниже, вызовут проблемы:

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

У меня возникла эта проблема на 0.5.0-dev , но я не сталкивался с ней после перехода на 0.4.1 .

Сегодня я испытал точно такое же поведение с релиз-кандидатом.

Привет, @carolynvs @blaggacao , большое спасибо за ваш отзыв.

Я пытаюсь воспроизвести / исправить эту ошибку. Не могли бы вы попробовать этот PR (https://github.com/docker/machine/pull/2006), который я создал, чтобы помочь исследовать ошибку

Похоже, я тоже это вижу. Я использую последнюю сборку master в OS X с драйвером digitalocean , так что это определенно не имеет никакого отношения к среде. Я думаю, что теги area/windows и area/driver-virtualbox здесь неактуальны :)

Привет, @hairyhenderson , не могли бы вы попробовать построить PR # 2006 и сообщить мне результат для docker-machine -D env default ?

@dgageot - сделаю, когда у меня будет возможность.

Я также немного больше думаю об этом и понимаю, что делал _local_ build (т.е. make build в OS X, без использования контейнера). Одна из областей, где go build прошлом вела себя по-другому, - это сертификаты (особенно корневые сертификаты CA), так что это _might_ может быть связано с этим ... Я не знаю.

Но я перестрою с # 2006 и попробую. Спасибо!

@hairyhenderson Это хороший

@dgageot Вот неудачный вывод https://gist.github.com/carolynvs/e2473d21c3376f1ebec2 из docker-machine -D env default для совершенно новой машины.

Я построил # 2006 и скопировал docker-machine.exe и docker-machine-driver-virtualbox.exe в каталог установки Docker Toolbox. Я использую Docker Toolbox 1.8.2c в Windows 10.

Я недостаточно опытен, чтобы уметь строить, может быть, я посмотрю на это вечером, если смогу разобраться.

@carolynvs Большое спасибо. Я все еще не понимаю, что происходит, но ваши журналы мне помогут.

@carolynvs Можете ли вы предоставить вывод:

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

Я обнаружил, что иногда получаю адаптеры только для двойного хоста. Я просто удалил их обоих и создал новую машину. Сертификаты все еще восстанавливаются, когда я запускаю docker-machine env default .

Вот результат выполнения команд VBoxManage во второй раз (только с 1 хост-адаптером).

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 Пока понятия не имею.
Я добавил еще пару коммитов в PR, чтобы распечатать больше информации и попробовать что-то.
Если у вас есть время обновить полученный результат, это будет просто замечательно.

ping @nathanleclaire @ dmp42 есть идеи?

Вот новый результат: https://gist.github.com/carolynvs/84cd140bcbf9b696e20f.

Сообщите мне, есть ли другой способ отладки проблемы с подключением. Я не совсем уверен, какая докер-машина обнаруживает, что заставляет ее регенерировать сертификаты, но я счастлив ковыряться в / var / lib / boot2docker на хосте или сравнивать сертификаты между окнами и хостом и т. Д., Если я знал, что искать.

@carolynvs Было бы здорово. Как вы отметили, проблема возникает в 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.

Либо сертификат неправильно скопирован на виртуальную машину.
Или виртуальная машина недоступна на порту 192.168.99.100:2376 (конфигурация сети хоста? Брандмауэр, vpn? Конфигурация сети vm?)
Или проблема в том, как мы проверяем.

Если вы экспортируете переменные env, заданные параметром docker-machine env и игнорируете ошибки, сможете ли вы подключиться к демону докера?

Я могу пинговать хост докера и подключиться к нему по ssh. Когда я игнорирую сообщения о повторном создании сертификатов из docker-machine env и устанавливаю переменные вручную, я все еще не могу подключиться к клиенту докера.

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.

Сертификаты на хосте в /var/lib/boot2docker/tls/ не совпадают с сертификатами локально в ~/.docker/machine/machines/default/ . Сертификаты в /var/lib/boot2docker/ соответствуют тому, что находится на моей локальной машине. Также сертификаты в ~/.docker/machine/certs/ соответствуют тому, что находится в ~/.docker/machine/machines/default/ .

Я предполагаю, что проблема заключается в том, что сертификаты не совпадают, что не позволяет докер-машине безопасно подключаться к демону докера, тем самым вызывая регенерацию сертификата?

Я убедился, что демон docker запущен:

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

Также вот логи от boot2docker и docker: https://gist.github.com/carolynvs/f7965455ebbceb85d4e6

: +1: Спасибо! Я чувствую, что мы приближаемся: smile:

IIRC, сертификаты в /var/lib/boot2docker/tls генерируются на стороне сервера сценарием запуска в ОС boot2docker и не используются ни для чего в текущей модели машины (они являются пережитком того, как boot2docker-cli исторически ожидал, что сертификаты будут установлены вверх).

@carolynvs @nathanleclaire Тогда я понятия не имею. Единственное различие, которое у меня есть в моих журналах, заключается в том, что я использую VBox версии 5.0.6 и более позднюю версию boot2docker.

@carolynvs Можете ли вы попробовать подключиться к демону докера с помощью curl? Мы могли бы получить лучшую обратную связь о том, что идет не так. Я думаю, что вы работаете в Windows, поэтому я действительно не знаю, как этого добиться, но вот как я сделал это в 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, вот руководство, которое я использовал, чтобы заставить его работать: http://opensolitude.com/2015/07/12/curl-docker-remote-api-os-x.html

@dgageot О, да, похоже, это проблема на моей машине (с использованием curl / openssl из Git для Windows, поэтому все команды одинаковы).

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

Я проверил все сертификаты в ~ / .docker / machine / certs с помощью vi -b path/to/cert и убедился, что у него есть окончания строки unix. Я также использовал следующую команду, чтобы проверить, может ли openssl их прочитать.

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

Я буду продолжать ковыряться с сертификатами, так как это похоже на проблему. Может быть, попробуйте его на другом компьютере и посмотрите, действительно ли это просто Windows 10.

@carolynvs Отличная работа! Я проверю это завтра утром (по парижскому времени)

Привет, @carolynvs , вы тоже пробовали эту команду на ca.pem ?

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

Можете ли вы проверить, правильно ли он начинается с -----BEGIN CERTIFICATE----- и заканчивается на -----END CERTIFICATE----- . Ничего до и после.

@carolynvs Должен признаться, я не знаю, что происходит. Вы пробовали этот пиар, который кажется отдаленно связанным.

Если вы не против подтвердить это промежуточное резюме, я могу молча потратить на это мозг:

• Сертификаты копируются, но не читаются?

Я уверен, вы уже проверили: http://stackoverflow.com/questions/20837161/openssl-pem-routinespem-read-biono-start-linepem-lib-c703expecting-truste
Ставлю для справки для других.

Я просто попробовал другую команду curl, используя --cert и --key вместо сгенерированного файла pfx, и он может подключиться.

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

При более внимательном рассмотрении вывода docker-machine env я вижу, что он экспортирует то, что я считаю неправильным путем сертификата. На моем Mac это указывает на .docker / machines / machine /а в выводе ниже он указывает на .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)"

После ручной настройки переменных среды и изменения пути к сертификату на то, что я думаю, он должен был быть, я могу подключиться к клиенту докера.

Возможно, когда докер-машина проверяет, может ли она подключиться, она использует неправильные сертификаты?

Я добавил некоторую отладочную информацию при проверке сертификатов, а затем попытался вручную подключиться, используя сначала то, что использует докер-машина, а затем то, что, по моему мнению, следует использовать.

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

Итак, я вижу 2 подозрительные вещи:

1. DOCKER_CERT_PATH использует .docker / machine / certs вместо .docker / machine / machines /
2. Проверка использует server.pem и server-key.pem вместо cert.pem и key.pem. Я не знаю, для чего нужен каждый сертификат, но это не кажется правильным.

Большое спасибо @carolynvs, который действительно должен помочь. Прежде чем я перевариваю все, что вы сообщили, можете попробовать последнюю версию https://github.com/docker/machine/pull/2006. Она должна распечатать сертификаты, используемые для проверки. Это должно помочь

Вот сертификаты, которые он использует

URL-адрес хоста = 192.168.99.102: 2376
CA CERT PATH = C: \ Users \ caro8994.docker \ machine \ certsca.pem
ПУТЬ СЕРВЕРНОГО СЕРТА = C: \ Users \ caro8994.docker \ machine \ machines \ bugtest \ server.pem
ПУТЬ К КЛЮЧУ СЕРВЕРА = C: \ Users \ caro8994.docker \ machine \ machines \ bugtest \ server-key.pem

Это из моей собственной отладочной информации, а не из PR, на создание которого уходит много времени сейчас, когда он создает все плагины. :улыбка:

Хорошо, теперь я в замешательстве, поэтому попробую подвести итоги.

Можете ли вы подтвердить, что:

• ~/.docker/machine/certs/ca.pem совпадает с ~/.docker/machine/machines/bugtest/ca.pem
• ~/.docker/machine/certs/cert.pem совпадает с ~/.docker/machine/machines/bugtest/cert.pem
• ~/.docker/machine/certs/key.pem совпадает с ~/.docker/machine/machines/bugtest/key.pem
• Вам удалось заставить docker cli добраться до сервера. Какое значение для DOCKER_CERT_PATH вы использовали тогда?
• На вашем Mac docker-machine env bugtest печатает экспорт DOCKER_CERT_PATH="~/.docker/machine" а не DOCKER_CERT_PATH="~/.docker/machine/certs"

Еще раз спасибо за поддержку!

@carolynvs FTR, только для кросс-

Простите за помойку мозгов!

• ca.pem, cert.pem и key.pm одинаковы как в ~/.docker/machine/certs и в ~/.docker/machine/machines/bugtest
• Клиент докера работал, когда я установил DOCKER_CERT_PATH на ~.docker/machine/machines/bugtest
• На моем Mac (который работает) docker-machine env устанавливает DOCKER_CERT_PATH="~/.docker/machine/machines/bugtest" . В Windows 10 (что не так) та же команда приводит к DOCKER_CERT_PATH="~/.docker/machine/certs"

Это было в моей мозговой свалке, но, возможно, я потерялся. Когда docker-machine проверяет сертификаты, он пытается подключиться к демону docker, используя server.pem и server-key.pem. Это кажется очень подозрительным.

ОК. Давайте позвоним на помощь @nathanleclaire и @ehazlett . Думаю, вы справились, но сейчас я слишком новичок в этом проекте, чтобы понять, почему у нас так много дублированных сертификатов и почему мы не используем правильные.

Спасибо за совет по сборке!

Ниже приведены соответствующие результаты последней сборки PR # 2006, а вот полный результат: 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

Приносим извинения за шум закрытия / открытия. Я возился

Ой, вэй. @carolynvs @dgageot, вы все чемпионы, продолжив преследовать этого. Я думаю, что подозрения Кэролайн верны: если DOCKER_CERT_PATH не устанавливается правильно, то связь с демоном не будет работать должным образом. Похоже, это может быть проблема с путями, которые я случайно ввел в изменениях libmachine . Я продолжу исследовать это и пока буду копаться в ваших выводах.

Может ли тогда выходом к виновному быть эта линия?
https://github.com/docker/machine/blob/8aa1572e0dcd75762a7627e1056ef104317f44b9/libmachine/persist/filestore.go#L155

@blaggacao Определенно сильно в области возможности - этот код имеет тенденцию быть немного хрупким и был проблематичным в прошлом.

Я не понимаю, как это может отличаться в Windows и Mac OS, хотя, как подтвердил @carolynvs .
Для меня он явно .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

молчит.

@blaggacao ясно, у меня нет такого же поведения, как у @carolynvs на Mac. Так что есть что-то подозрительное.

Да, сертификаты копируются в каталог этой машины во время бита подготовки.

@dgageot Приносим извинения за недоразумение. На моем Mac установлен docker-machine 0.4.1. Я запускаю только PR-сборку на своей машине с Windows, так как я тестировал исправления там, поскольку они объединены в мастер.

Я могу сделать сборку и снова запустить ее на своем Mac прямо сейчас.

Резюмирую:

• различия не показывают разницы между /machine/certs и /machine/machines/certs
• Я не могу воспроизвести обходной путь carlynvs для решения проблемы.

При установке DOCKER_CERT_PATH вручную в Windows (в bash) следует использовать пути в стиле UNIX. Например, export DOCKER_CERT_PATH="~./docker/machine/machines/oca" .

Я могу подтвердить, что на моей (шаткой) машине сертификаты совпадают между / machine / certs и / machine / machines / certs.

Я могу подтвердить, скопировав вручную, поскольку scp не работает:

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

второй и третий различаются между /machines/oca и oca:~/.docker

Какие пути в виртуальной машине вы используете для сертификатов @blaggacao ?

Я просто понял, что это не тот ...

Я проверил по ~/.docker Еще раз проверю по /var/lib/boot2docker

Я могу определенно подтвердить, что

• сертификаты в /machines/oca и oca:/var/lib/boot2docker/ одинаковы
  (Я использую dos2unix на всех трех полях ca.pem , server.pem , sever-key.pem на oca )

Я также получаю эту ошибку тайм-аута: https://github.com/docker/machine/blob/6a5219b879db52698ccb2b7e0aafd516b34df839/libmachine/provision/boot2docker.go#L193
каждый раз, когда я запускаю env либо с флагом --native-ssh либо нет

Да, @blaggacao также похоже, что IP-адрес хоста, назначенный виртуальной машине, недоступен на вашем компьютере. Сможете ли вы ping $(docker-machine ip vmname) ?

нет, тоже не работает ... "Истекло время ожидания запроса"

docker-machine ssh vmname хотя работает

Да, ssh проходит через localhost . Но похоже, что вы не можете связаться с назначенным хостом только с IP-адресом виртуальной машины, поэтому я не ожидал, что env будет работать правильно. Вы используете какой-либо VPN или прокси?

нет, я бы знал, просто дважды проверил диспетчер задач ... ОБНОВЛЕНИЕ обнаружило один, закрытие

Закрытие ничего не меняет, но это уже другая проблема, я думаю ...

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

приводит меня к

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

Поскольку я ничего не понимаю: https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/libmachine/cert/cert.go#L22

единственные оставшиеся кандидаты:
https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/libmachine/cert/cert.go#L198 -L205

Это похоже на связь между обеими проблемами. Можете ли вы истолковать мою мысль?

Удаленное копание: https://github.com/leo-stone/fix-go-1.5-tls-issue/blob/master/main.go

Я больше не доверял своей среде Windows, поэтому я начал заново и перестроил Windows, а затем поставил # 2006.

В файле docker.log я вижу эту ошибку

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

поэтому я проверил даты сертификата

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

Может быть проблема в том, что сертификат датирован будущим? Это объясняет, почему изначально мои команды curl не работали, но через несколько часов они заработали.

то же самое:

$ 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

Это примерно через 5 часов в моем часовом поясе (Богота / Америка) Ну, но там указано GMT (UTC). Богота - это UTC-5

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

Обновление: FIX

Как указано здесь: https://github.com/docker/docker/issues/11534#issuecomment -89405874

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

дал мне другую ошибку (шаг за шагом :)

Думаю, все, остальное - мой виртуальный бокс.

Я собираюсь поужинать и вернуться через 5 часов, когда я подозреваю, что мой сертификат будет действителен, и все будет работать. :улыбка:

Плохие новости, я должен делать это при каждом перезапуске виртуальной машины.

: smile: Думаю, вы попали в первопричину! Спасибо!

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

@carolynvs исправление, которое я опубликовал, сработало для вас?

Я просто хотел подтвердить, что после 5 часов ожидания, пока сертификат не будет действителен, env docker-machine работает. Не знаю, почему я получаю сертификаты, которые датированы будущим, но, возможно, мне следует обновить проблему, чтобы отразить настоящую основную причину, которую мы знаем.

В моем случае проблема заключалась не в сертификатах, а в настройке времени на boot2docker ... Как я вижу в вашем профиле github, вы из Чикаго, это тот же часовой пояс, что и Богота, возможно, boot2docker неправильно настроен в наших часовых поясах ...

После синхронизации времени с помощью обходного пути я все еще получаю ту же ошибку (срок действия сертификата истек или еще не действителен) при использовании этих сертификатов для подключения к моему хосту докеров.

На моем Mac это то, что я вижу после создания нового ящика и проверки его времени.

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

Вот те же команды на новом хосте в 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

Дата показывает мое местное время, но я думаю, что это UTC, и я не знаю, как обновить его, чтобы он соответствовал hwclock. Я пробовал вручную изменить дату, но есть что-то в busybox или virtualbox, что немедленно отменяет любое изменение.

Это рабочее состояние на вчерашний день после применения обходного пути:

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

здесь date соответствует моему местному времени, выраженному в UTC.

несколько подсказок для моих симтопмов: https://forums.virtualbox.org/viewtopic.php?f=3&t=60558#p281836

time замораживается, через 10 минут: docker<strong i="18">@oca</strong>:~$ time BusyBox v1.23.1 (2015-02-22 15:53:49 UTC) multi-call binary.

поскольку date показывает правильную дату в моем случае, я предполагаю, что в моем случае фиксированная дата временного решения и, следовательно, проблема.

cc @tianon @SvenDowideit PTAL в приведенном выше RE: проблемы с датой и временем boot2docker ^^

Некоторый код, который я обнаружил, может способствовать проблеме с отметкой времени:

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

Но раньше он всегда работал нормально.

@carolynvs @blaggacao Вы все еще сталкивались с этими проблемами?

Для меня это работает после указанного обходного пути. Это, в свою очередь, указывает на то, что какой-то параметр времени boot2docker установлен неправильно. Обычно это происходит только в течение ограниченного периода времени сразу после создания машины. (Наверное, только в некоторых часовых поясах).

Это снова будет означать, что метки времени сертификатов будут правильными.

Я снова наткнулся на это сразу после перезапуска компьютера на моем rc, но после обновления до 5.0, похоже, все работает. Возможно, мы могли бы закрыть это сейчас. В любом случае, как только я замечаю странное поведение, я открываю его заново.

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

У меня тоже есть эта проблема. Не закрывайте это.

@damontic Это похоже на другой вопрос, нежели обсуждаемый здесь.

Я пытаюсь настроить рой на DigitalOcean, и у меня такая же ошибка.

Файл init-do.sh, который создает хранилище KV, мастер роя и узел:

 # 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

Журнал / ошибка, которую я получаю

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

Перед запуском я обновился до Machine 0.5.1.

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

Я могу перейти в контекст машины "consul", но не в "demo0" или "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 Если инициализация не удалась, созданные экземпляры будут «недействительными». Попробуйте удалить их и начать заново с нуля.

@nathanleclaire Я только что удалил машины (достаточно ли «docker-machine rm consul demo0 demo1» или мне следует вручную удалить некоторые другие вещи?) и перезапустить с установочным файлом, и у меня возникла та же проблема с сертификатами (при создании в DigitalOcean). Странно то, что с машиной 'consul' проблем нет, а только с роями (demo0, demo1).

Однако при создании роя на VirtualBox (5.0.10) он работает нормально.

я вижу это при использовании драйвера aws

Я провел несколько тестов (на самом деле много), после удаления виртуальной машины и воссоздания их (с роем) у меня все еще есть та же проблема.

Теперь у меня возникла эта проблема после обновления с версии 1.8 до 1.9.1 с помощью панели инструментов Docker в 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

Со мной это тоже периодически происходит. Докер v1.9.1

Та же проблема и с лазурным драйвером. Каждый раз, когда я создаю новую лазурную машину, она выдает ошибку:

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

После запуска docker-machine regenerate-certs проверки сертификатов работают нормально.

В docker-machine v0.5.5 проблем нет, и создание хоста docker работает нормально:

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 Вы версии 0.6.0?

Ага, начиная с 0.5.5. Я тестировал это с 0.5.6 и 0.6.0.

то же самое для меня на 0.6.0 с драйвером aws (постоянно) на Mac 10.10.5. Не происходит с драйвером виртуального бокса.

исправлено после изменения --engine-opt="cluster-advertise=eth1:2376" на --engine-opt="cluster-advertise=eth0:2376" с помощью docker-machine 0.6.0 (docker-machine 0.5.4 по-прежнему не работает)

Я думаю, что я борюсь с той же проблемой на своей машине. Я использую ubuntu 14.04
докер-машина версии 0.5.5, сборка 02c4254
Запуск хоста на RHEL 7.1
Версия сервера: 1.10.2-cs1-rc3

Пробовал все, что предлагалось со временем на машинах, вот результат, который я получаю от 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: // $ (ip-адрес докер-машины $ NODE_NAME): 2376 / версия

• Имя хоста НЕ найдено в кеше DNS
• Пробуем 16.85.3.140 ...
• Подключен к 16.85.3.140 (16.85.3.140) порт 2376 (# 0)
• успешно установить местоположения проверки сертификата:
• Файл CA: /home/eraigosa/.docker/machine/certs/ca.pem
  CApath: / etc / ssl / certs
• SSLv3, рукопожатие TLS, привет клиенту (1):
• SSLv3, рукопожатие TLS, привет серверу (2):
• SSLv3, рукопожатие TLS, CERT (11):
• SSLv3, рукопожатие TLS, обмен серверными ключами (12):
• SSLv3, рукопожатие TLS, запрос CERT (13):
• SSLv3, рукопожатие TLS, сервер завершен (14):
• SSLv3, рукопожатие TLS, CERT (11):
• SSLv3, рукопожатие TLS, обмен клиентскими ключами (16):
• SSLv3, рукопожатие TLS, проверка CERT (15):
• SSLv3, шифр смены TLS, привет клиенту (1):
• SSLv3, рукопожатие TLS, завершено (20):
• SSLv3, предупреждение TLS, привет серверу (2):
• ошибка: 14094412 : подпрограммы SSL sslv3 неверный сертификат
• Закрытие соединения 0
  curl: (35) ошибка: 14094412 : подпрограммы SSL sslv3 неверный сертификат

@nathanleclaire Я нашел культа! prltoolsd из boot2docker постоянно неправильно устанавливает дату / часовой пояс.

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

После остановки prltoolsd и сброса даты все мои команды докер-машины работают должным образом, и мои сертификаты не восстанавливаются.

Я до сих пор не знаю, почему часовой пояс установлен на UTC, а время на местное время после создания новой машины, так что это просто обходной путь, а не исправление.

Приятно @carolynvs ! Мы будем работать над тем, чтобы исправить это в boot2docker.

@tianon @ legal90 К вашему сведению ^^

@carolynvs Вау: страшно:. Это выглядит действительно странно, потому что процесс prltoolsd не должен запускаться ни в одной другой системе виртуализации, кроме Parallels Desktop. Демон запустится, только если /usr/bin/prlvmcheck вернет 0 код выхода, что означает, что мы находимся в виртуальной машине Parallels.

Вы воспроизводили эту проблему на виртуальной машине Virtualbox? Какую версию Boot2Docker вы используете?

Ps Также, если мы предположим, что prltoolsd - единственная причина, то версия Docker Machine не должна иметь смысла. Однако другие комментарии выше ( ссылка ) говорят о том, что проблема возникает только в Machine 0.5.5+.

@ legal90 В этом больше смысла. Моя среда немного шаткая, но раньше она работала нормально:

1. Я использую Mac под управлением Parallels.
2. Внутри Parallels я запускаю Windows, затем устанавливаю последнюю версию Docker Toolbox. Я делаю это, потому что пишу документацию и руководства для Docker, и мне нужно ориентироваться на пользователей Mac, Linux и Windows.

Это объясняет, почему prltoolsd пытается управлять часами моего докер-хоста. Должно быть, он улавливает вложенность в Parallels. Это также объясняет, почему системные часы установлены на местное время, но думают, что это UTC?

Это основная проблема, которая заставила меня открыть эту ошибку. Я создаю новую докерную машину в 10:00 по центральноевропейскому времени (-6). Системные часы ( date ) на новом компьютере считают, что сейчас 10:00 по всемирному координированному времени, поэтому отметки времени на сертификатах относятся к «будущему». hwclock сообщает точное время.

Посмотрев на файл Dockerfile boot2docker, я заметил, что он устанавливает /etc/timezone на UTC и _должен_ также установить /etc/localtime на UTC.

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

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

Но на моем хосте док-машины пакет tzdata не установлен, поэтому /usr/share/zoneinfo не существует, как и /etc/localtime . Я создал свой собственный boot2docker из последнего файла Docker, чтобы убедиться, что я не использую старый iso. Интересно, не влияет ли отсутствие файла /etc/localtime на проблему неправильного времени?

@carolynvs А, теперь я понял.

Это объясняет, почему prltoolsd пытается управлять часами моего хоста докера. Должно быть, он улавливает вложенность в Parallels.

Да, это корень проблемы. prltoolsd запускается на виртуальной машине Virtualbox, вложенной в виртуальную машину Parallels. Я воспроизвел это и сообщил ответственным лицам в Parallels. Я дам вам знать, как только исправлю.

Это также объясняет, почему системные часы установлены на местное время, но думают, что это UTC?

Что ж, это сложно сделать, но это известная проблема Parallels Desktop (и его гостевых инструментов). Изначально об этом сообщалось здесь: https://github.com/Parallels/vagrant-parallels/issues/186.
Это было исправлено в PD 11 с помощью дополнительной опции для утилиты prlctl , но это не помогает в вашем редком случае, потому что вы фактически используете виртуальную машину Virtualbox в Windows.

Извините, но единственное решение, которое я могу вам предложить на данный момент, - это предотвратить запуск prltoolsd на вашей виртуальной машине при загрузке. Если вы используете собственную сборку Boot2Docker ISO, вы можете удалить строки, связанные с https://github.com/boot2docker/boot2docker/blob/master/rootfs/rootfs/bootscript.sh#L101

Спасибо за дополнительную информацию о том, как работает prltoolsd! Я сделаю так, как вы предлагаете, и сделаю индивидуальный ISO-образ для своей установки. :пиво:

Я бы закрыл эту проблему, так как это решит мою проблему, но оставлю это на ваше усмотрение, поскольку другие люди, похоже, сталкиваются с ней (хотя, вероятно, по другим причинам!).

Я думаю, мы можем рассматривать его как эффективно решенный; мы можем повторно открыть его, если будут обнаружены какие-либо новые проблемы.

Спасибо всем за ваш вклад в составление отчетов и упорядочение этой невероятно длинной проблемы!

Я использую DockerToolbox 1.10.3 в Windows. Он работал нормально, пока я не перезапустился, и теперь у меня такая же проблема. Я также не очень хорошо знаком с Docker, так что может кто-нибудь сказать мне, что это за исправление?

@mtrtm docker-machine regenerate-certs -f не работает?

Да, docker-machineгенерировать-сертификаты -f делает. Также кажется, что это происходит каждый раз, когда я запускаю Docker Quickstart Terminal.

+1
Я использую докер в основном на сервере Redhat, и все работает нормально. Я не специалист, но знаю, что делаю. Однако в Windows с виртуальным боксом каждый раз, когда виртуальная машина докера перезагружается, мне нужно регенерировать сертификаты. Я нахожусь на панели инструментов 1.11.1

+1

Macbook конца 2009 г.
Intel Core 2 Duo 2,26 ГГц
Mac OS Sierra 10.12
Docker Tollbox 1.2.1
VirtualBox 5.0.26

$ docker-machine ls
ИМЯ АКТИВНЫЙ ДРАЙВЕР СОСТОЯНИЕ URL ОШИБКИ SWARM DOCKER
vbox-test - virtualbox Выполняется tcp: //192.168.99.100 : 2376 Неизвестно Невозможно запросить версию докера: Получить https://192.168.99.100 : 2376 / v1.15 / version: x509: срок действия сертификата истек или он еще не действителен

$ docker-machine env vbox-test
Ошибка проверки соединения TLS: проверка ошибок и / или повторное создание сертификатов: произошла ошибка при проверке сертификатов для хоста «192.168.99.100:2376»: x509: срок действия сертификата истек или он еще не действителен
Вы можете попытаться восстановить их, используя «docker-machine regenerate-certs [name]».
Имейте в виду, что это вызовет перезапуск демона Docker, который остановит запуск контейнеров.

$ docker-machine восстановить сертификаты vbox-test
Восстановить сертификаты машины TLS? Предупреждение: это необратимо. (г / п): г
Восстановление сертификатов TLS
Ожидание доступности SSH ...
Обнаружение инициатора ...
Копирование сертификатов в каталог локального компьютера ...
Копирование сертификатов на удаленную машину ...
Настройка конфигурации Docker на удаленном демоне ...

$ docker-machine env vbox-test
Ошибка проверки соединения TLS: проверка ошибок и / или повторное создание сертификатов: произошла ошибка при проверке сертификатов для хоста «192.168.99.100:2376»: x509: срок действия сертификата истек или он еще не действителен
Вы можете попытаться восстановить их, используя «docker-machineгенерировать-сертификаты [имя]».
Имейте в виду, что это вызовет перезапуск демона Docker, который остановит запуск контейнеров.

У меня это было при установке по умолчанию Docker Tookit (установленного в Windows 10 Home), загруженного 2016-10-30. Ошибка исчезла после запуска:

docker-machine regenerate-certs

Возникла эта проблема в macOS. docker-machine env жалуется:

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

Повторное создание сертификатов (даже с -f ) не помогает. docker-machine ssh docker1 date показывает правильную дату и время.

Любые идеи?

@paddor Восстановление сертификатов, вкл. клиентские сертификаты ( docker-machine regenerate-certs -f --client-certs ) исправили это для меня.