Machine: لا يتم تثبيت الشهادات بشكل صحيح ، يتم تجديدها دائمًا

شكرا على الملخص التفصيلي. لقد رأيت مثل هذه القضايا من قبل أيضًا وسأبحث فيها.

هل أنت على أحدث إصدار من VirutalBox؟ أي 5.0.6؟

كنت أستخدم 5.0.4 الذي يأتي مع أحدث إصدار من Docker Toolbox (1.8.2c). لقد قمت للتو بإزالة هذا الإصدار ، وتثبيته 5.0.6 وأواجه نفس السلوك.

حسنا، شكرا.

carolynvs إذا قمت بإزالة الشبكة المضيفة فقط التي لديك (يمكنك القيام بذلك في VirtualBox GUI) وحاول مرة أخرى ، فهل تعمل؟

لقد حذفت الجهاز وأزلت المحول وحاولت مرة أخرى بنفس النتيجة.

حسنا، شكرا. سلوك غريب جدا. قد أقوم بإجراء اختبار يقوم بتفريغ مزيد من المعلومات حول الشهادات ويقترح عليك تجربة ذلك إذا كنت موافقًا.

بالتاكيد! يسعدني تقديم المساعدة ولكن يمكنني ذلك.

إذا كنت تريد فقط إنشاء فرع وتوجيهي إليه ، فيمكنني بناءه بنفسي (: القلب: إنشاءات في حاويات!). بهذه الطريقة لن تحتاج إلى رمي العديد من البنيات على الحائط إذا استغرق ذلك أكثر من محاولة.

شيء آخر يجب مراعاته أثناء إصلاح هذا الأمر ، يقوم بعض الأشخاص مثلي بالفعل بكتابة محتويات 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 .

لقد واجهت نفس السلوك بالضبط اليوم على مرشح الإصدار.

مرحباcarolynvsblaggacao، شكرا جزيلا لملاحظاتك.

أحاول إعادة إنتاج / إصلاح هذا الخطأ. هل يمكنك تجربة العلاقات العامة هذه (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_ (على سبيل المثال 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 هل يمكنك توفير ناتج:

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 في المرة الثانية (مع محول مضيف واحد فقط).

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 ليس لدي أي فكرة حتى الآن.
لقد دفعت بضع التزامات أخرى على العلاقات العامة لطباعة المزيد من المعلومات وتجربة الأشياء.
إذا كان لديك الوقت لتحديث الناتج الذي تحصل عليه ، فسيكون ذلك رائعًا.

بينغ nathanleclaire @ dmp42 أي فكرة؟

إليك الإخراج الجديد: https://gist.github.com/carolynvs/84cd140bcbf9b696e20f.

اسمحوا لي أن أعرف ما إذا كانت هناك طريقة أخرى للشروع في تصحيح مشكلة الاتصال. لست متأكدًا تمامًا مما تكتشفه آلة الإرساء والتي تسبب في إعادة إنشاء الشهادات ولكن يسعدني أن أتجول في / var / lib / boot2docker على المضيف أو مقارنة الشهادات بين Windows والمضيف ، وما إلى ذلك إذا كنت أعرف ما للبحث عن.

تضمين التغريدة كما أشرت ، تظهر المشكلة في 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 (Host network config؟ firewall، vpn؟ vm network config؟)
أو أن هناك مشكلة في طريقة التحقق.

إذا قمت بتصدير متغيرات env التي قدمها docker-machine env وتجاهلت الأخطاء ، فهل يمكنك الاتصال ببرنامج Docker daemon؟

يمكنني تنفيذ الأمر ping على مضيف عامل التحميل وإدخاله فيه. عندما أتجاهل الرسائل المتعلقة بإعادة إنشاء الشهادات من 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 daemon:

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: شكرا! أشعر أننا نقترب: ابتسم:

IIRC ، يتم إنشاء الشهادات الموجودة في /var/lib/boot2docker/tls من جانب الخادم بواسطة برنامج نصي لبدء التشغيل في نظام التشغيل boot2docker ولا يتم استخدامها لأي شيء في نموذج الجهاز الحالي (إنها بقايا لكيفية توقع boot2docker-cli تاريخيًا أن يتم تعيين الشهادات فوق).

تضمين التغريدة carolynvsnathanleclaire ليس لدي فكرة بعد ذلك. الاختلاف الوحيد الذي أملكه في سجلاتي هو أنني أستخدم VBox الإصدار 5.0.6 وأحدث boot2docker.

carolynvs هل يمكنك محاولة الاتصال

$ 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 ، هذا هو البرنامج التعليمي الذي استخدمته لإنجاحه :

dgageot Ooh ، نعم يبدو أن هذه مشكلة على جهازي (باستخدام 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 ، هل جربت هذا الأمر على 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"}

لذلك أرى شيئين مريبين:

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

هذا من معلومات تصحيح الأخطاء الخاصة بي ، وليس العلاقات العامة التي تستغرق وقتًا طويلاً لإنشائها الآن بعد أن قامت ببناء جميع المكونات الإضافية. :ابتسامة:

حسنًا ، أنا الآن مرتبك ، لذلك سأحاول فقط الملخص

هل يمكنك تأكيد ما يلي:

• ~/.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"

كان هذا في تفريغ عقلي ولكن ربما ضاع. عندما يقوم عامل الإرساء بالتحقق من صحة الشهادات ، فإنه يحاول الاتصال بخادم عامل الإرساء باستخدام 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

آسف للضوضاء المغلقة / المعاد فتحها. لقد تخبطت

أوي فاي. carolynvsdgageot لكم جميعا الأبطال للاستمرار في مطاردة هذا واحد لأسفل. أعتقد أن شك كارولين صحيح: إذا لم يتم ضبط DOCKER_CERT_PATH بشكل صحيح ، فلن يعمل التواصل مع البرنامج الخفي بشكل صحيح. يبدو أنها قد تكون مشكلة في المسارات التي أدخلتها عن غير قصد في التغييرات libmachine . سأستمر في التحقيق في هذا الأمر والبحث في النتائج التي توصلت إليها حتى الآن.

فهل يكون المدخل إلى الجاني هذا الخط إذن؟
https://github.com/docker/machine/blob/8aa1572e0dcd75762a7627e1056ef104317f44b9/libmachine/persist/filestore.go#L155

blaggacao بالتأكيد بقوة في عالم الاحتمالات - يميل هذا الرمز إلى أن يكون هشًا بعض الشيء وكان يمثل مشكلة في الماضي.

لا أفهم كيف يمكن أن يكون هذا مختلفًا على نظامي التشغيل windows و mac os ، على الرغم من تأكيد
بالنسبة لي ، من الواضح أنه يبني المسار .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 على

نعم ، يتم نسخ الشهادات إلى دليل هذا الجهاز أثناء بت التزويد.

dgageot نعتذر عن الارتباك. يعمل جهاز Mac الخاص بي على تشغيل Docker-machine 0.4.1. أنا فقط أقوم بتشغيل إصدار العلاقات العامة على جهاز Windows الخاص بي لأنني كنت أختبر الإصلاحات هناك حيث تم دمجها في النظام الرئيسي.

يمكنني إنشاء وتشغيل مرة أخرى على جهاز Mac الخاص بي الآن.

أستأنف:

• فرق لا تظهر الفرق بين /machine/certs و /machine/machines/certs
• لا يمكنني إعادة إنتاج حل carlynvs لحل المشكلة.

عند ضبط DOCKER_CERT_PATH يدويًا على النوافذ (في bash) ، يجب عليك استخدام مسارات نمط UNIX. على سبيل المثال ، export DOCKER_CERT_PATH="~./docker/machine/machines/oca" .

أستطيع أن أؤكد أن الشهادات على جهازي (متزعزع) تتطابق بين / الجهاز / الشهادات و / الجهاز / الآلات / الشهادات.

يمكنني التأكيد ، عن طريق النسخ اليدوي ، لأن 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

ما هي المسارات في الجهاز الظاهري التي تستخدمها للحصول على certsblaggacao ؟

لقد أدركت للتو أنه كان الخطأ ...

لقد تحققت من ~/.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 يبدو أيضًا أن المضيف الوحيد الذي تم تعيينه لـ VM لا يمكن الوصول إليه على جهاز الكمبيوتر الخاص بك. هل يمكنك ping $(docker-machine ip vmname) ؟

كلا ، لا يعمل أيضًا ... "انتهت مهلة الطلب"

docker-machine ssh vmname بالرغم من ذلك

نعم ، يمر ssh عبر localhost . ولكن يبدو أنه لا يمكنك الاتصال بالمضيف المعين فقط VM IP ، لذلك لا أتوقع أن يعمل env بشكل صحيح. هل تستخدم أي VPN أو وكيل؟

لا ، سأكون على علم بذلك ، فقط قمت بفحص مدير المهام مرتين ... اكتشفت UPDATE واحدًا ، وأغلق

الإغلاق لا يغير شيئًا ، لكن هذه مسألة أخرى ، على ما أعتقد ...

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 ساعات عندما أظن أن سيرتي ستكون صالحة وسيعمل كل شيء. :ابتسامة:

أخبار سيئة ، يجب أن أفعل هذا عند إعادة تشغيل جهاز vm

: ابتسامة: أعتقد أنك ضربت السبب الجذري! شكرا!

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

carolynvs هل الإصلاح الذي نشرته يعمل من أجلك؟

أردت فقط أن أؤكد أنه بعد الانتظار لمدة 5 ساعات حتى تصبح الشهادة صالحة ، تعمل بيئة عامل الإرساء. لا يوجد دليل على سبب حصولي على شهادات مؤرخة في المستقبل ولكن ربما يجب تحديث المشكلة لتعكس السبب الجذري الحقيقي الذي نعرفه الآن.

في حالتي ، لم تكن الشهادات هي المشكلة ، ولكن ضبط الوقت على 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 يتوافق مع التوقيت المحلي المُعبّر عنه بالتوقيت العالمي المنسق

بعض التلميحات حول Symtopms الخاصة بي: 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 tianonSvenDowideit PTAL في RE أعلاه: مشاكل وقت / تاريخ boot2docker ^^

قد تكون بعض التعليمات البرمجية التي وجدتها تساهم في مشكلة الطابع الزمني:

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

لكنها كانت تعمل دائمًا بشكل جيد من قبل.

carolynvs blaggacao هل ما

بالنسبة لي ، إنه يعمل بعد الحل البديل المشار إليه. وهذا بدوره يشير إلى أن بعض معلمات وقت boot2docker لم يتم تعيينها بشكل صحيح. عادةً ما يحدث ذلك فقط خلال إطار زمني محدود بعد إنشاء الجهاز مباشرةً. (ربما فقط في بعض المناطق الزمنية).

هذا مرة أخرى ، يعني أن الطوابع الزمنية للشهادات ستكون صحيحة.

لقد تعثرت في هذا مرة أخرى الآن فقط بعد إعادة تشغيل الكمبيوتر على جهاز التحكم عن بعد الخاص بي ، ولكن بعد التحديث إلى 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)

يمكنني الانتقال إلى سياق "قنصل" الجهاز ولكن ليس إلى "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). الغريب أنه لا توجد مشكلة في آلة "القنصل" ، ولكن فقط مع السرب (demo0 ، demo1).

عند إنشاء السرب على VirtualBox (5.0.10) ، فإنه يعمل بشكل جيد.

أرى هذا عند استخدام برنامج التشغيل AWS

لقد أجريت العديد من الاختبارات (كثيرًا في الواقع) ، بعد حذف VM وإعادة إنشائها (باستخدام سرب) ما زلت أعاني من نفس المشكلة.

لدي الآن هذه المشكلة بعد الترقية من الإصدار 1.8 إلى 1.9.1 باستخدام Docker Toolbox على 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

هذا يحدث لي بشكل دوري أيضًا. Docker v1.9.1

نفس المشكلة هنا مع اللازوردية سائق. في كل مرة أقوم فيها بإنشاء آلة جديدة من نوع azure ، فإنها تفشل بسبب الخطأ:

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 ، لا توجد مشكلة ، وإنشاء مضيف عامل الإرساء يعمل بشكل جيد:

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" باستخدام آلة الإرساء 0.6.0 (ما زال فشل آلة الرصيف 0.5.4)

أعتقد أنني أواجه نفس المشكلة على جهازي. أنا أستخدم ubuntu 14.04
إصدار آلة الإرساء 0.5.5 ، الإصدار 02c4254
تشغيل المضيف على RHEL 7.1
إصدار الخادم: 1.10.2-cs1-rc3.0

جربت كل ما هو مقترح مع مرور الوقت على الأجهزة ، إليك الإخراج الذي أحصل عليه من curl

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

• لم يتم العثور على اسم المضيف في ذاكرة التخزين المؤقت لنظام أسماء النطاقات
• جاري محاولة 16.85.3.140 ...
• متصل 16.85.3.140 (16.85.3.140) المنفذ 2376 (# 0)
• تم تعيين مواقع التحقق من الشهادة بنجاح:
• الملف: /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
• إغلاق الاتصال 0
  curl: (35) خطأ: 14094412 : إجراءات SSL

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 وإعادة ضبط التاريخ ، تعمل جميع أوامر جهاز الإرساء كما هو متوقع ولا يتم إعادة إنشاء شهاداتي.

ما زلت لا أعرف سبب ضبط المنطقة الزمنية على التوقيت العالمي المنسق والوقت على التوقيت المحلي بعد صنع آلة جديدة ، لذلك هذا مجرد حل بديل وليس إصلاحًا.

تضمين التغريدة سنعمل على معرفة ما إذا كان بإمكاننا إصلاح هذا في boot2docker.

تضمين التغريدة

@ carolynvs نجاح باهر: خائف prltoolsd يجب ألا تبدأ في أي نظام ظاهري آخر باستثناء Parallels Desktop. سيبدأ البرنامج الخفي فقط إذا قام /usr/bin/prlvmcheck بإرجاع 0 كود خروج ، مما يعني أننا في Parallels VM.

هل قمت بإعادة إنتاج هذه المشكلة على Virtualbox VM؟ ما هو إصدار Boot2Docker الذي تستخدمه؟

ملاحظة أيضًا ، إذا افترضنا أن prltoolsd هو السبب الوحيد ، فلا يجب أن يكون إصدار Docker Machine منطقيًا. ومع ذلك ، تشير التعليقات الأخرى أعلاه ( الرابط ) إلى أن المشكلة تظهر فقط في Machine 0.5.5+

@ legal90 هذا منطقي أكثر. بيئتي متزعزعة بعض الشيء ، لكنها كانت تعمل بشكل جيد:

1. أنا على جهاز Mac يعمل بنظام Parallels.
2. داخل Parallels ، أقوم بتشغيل Windows ، ثم أحدث تثبيت لمربع أدوات docker. أفعل ذلك لأنني أكتب الوثائق والبرامج التعليمية لـ Docker ، وأحتاج إلى استهداف مستخدمي Mac و Linux و Windows.

هذا ما يفسر سبب محاولة prltoolsd إدارة ساعة مضيف عامل الإرساء. يجب أن تكون متداخلة داخل Parallels. هل يفسر ذلك أيضًا سبب ضبط ساعة النظام على التوقيت المحلي ولكن يعتقد أنه التوقيت العالمي المنسق (UTC)؟

هذه هي المشكلة الجذرية التي تسببت في فتح هذا الخطأ. أقوم بإنشاء آلة إرساء جديدة في الساعة 10 صباحًا بتوقيت وسط أمريكا (-6). تعتقد ساعة النظام ( date ) على الجهاز الجديد أنها 10 صباحًا بالتوقيت العالمي المنسق ، وبالتالي فإن الطوابع الزمنية على الشهادات "في المستقبل". يُعلن hwclock عن الوقت الصحيح.

بالنظر إلى boot2docker Dockerfile ، لاحظت أنه يقوم بتعيين /etc/timezone إلى UTC و _should_ قد قام بتعيين /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 الخاص بي من Dockerfile الأحدث فقط للتحقق من أنني لا أستخدم ISO قديمًا. أتساءل عما إذا كان فقدان ملف /etc/localtime يساهم في مشكلة الوقت غير الصحيحة؟

@ carolynvs آه ، الآن حصلت عليه.

هذا يفسر سبب محاولة prltoolsd إدارة ساعة مضيف عامل الإرساء. يجب أن تكون متداخلة داخل Parallels.

نعم ، هذا هو أصل المشكلة. prltoolsd يعمل في Virtualbox VM متداخل في Parallels VM. لقد أعدت إنتاج هذا وأبلغت الأشخاص المسؤولين في Parallels. سأخبرك بمجرد إصلاحه.

هل يفسر ذلك أيضًا سبب ضبط ساعة النظام على التوقيت المحلي ولكن يعتقد أنه التوقيت العالمي المنسق (UTC)؟

حسنًا ، من الصعب الالتزام ولكنها مشكلة معروفة في Parallels Desktop (وأدوات الضيف). تم الإبلاغ عنها في الأصل هنا: https://github.com/Parallels/vagrant-parallels/issues/186.
تم العمل عليه في PD 11 بخيار إضافي لأداة مساعدة prlctl ، لكنه لا يساعد في حالتك النادرة ، لأنك تقوم بالفعل بتشغيل Virtualbox VM على Windows.

أنا آسف ، ولكن الحل الوحيد الذي يمكنني اقتراحه عليك في الوقت الحالي هو منع prltoolsd من العمل في جهاز VM الخاص بك في التمهيد. إذا كنت تستخدم إصدار Boot2Docker ISO مخصصًا ، فيمكنك إزالة الخطوط ذات الصلة بالتوازيات من Dockerfile وإعادة إنشاء ملف 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 ؟

نعم ، يعمل عامل الإرساء-آلة التجديد-الشهادات -f. يبدو أيضًا أنه يفعل ذلك في كل مرة أبدأ فيها تشغيل Docker Quickstart Terminal

+1
أنا أستخدم عامل الإرساء بشكل أساسي على خادم Redhat وكل شيء يعمل بشكل جيد. أنا لست خبيرا ولكني أعرف ما أفعله. على نظام Windows مع Virtualbox ، في كل مرة يتم فيها إعادة تشغيل Docker VM ، أحتاج إلى إعادة إنشاء الشهادات. أنا في toolbox 1.11.1

+1

Macbook أواخر عام 2009
2،26 جيجاهرتز Intel Core 2 Duo
نظام التشغيل Mac OS Sierra 10.12.2
Docker Tollbox 1.2.1.1 تحديث
برنامج VirtualBox 5.0.26

آلة الإرساء $ ls
الاسم النشط لعنوان URL لولاية السائق النشط أخطاء SWARM DOCKER
vbox-test - virtualbox قيد التشغيل tcp: //192.168.99.100 : 2376 غير معروف غير قادر على الاستعلام عن إصدار عامل الإرساء: احصل على https://192.168.99.100 : 2376 / v1.15 / الإصدار: x509: انتهت صلاحية الشهادة أو لم تعد صالحة بعد

$ docker-machine env vbox-test
خطأ في التحقق من اتصال TLS: التحقق من الخطأ و / أو إعادة إنشاء الشهادات: حدث خطأ أثناء التحقق من صحة الشهادات للمضيف "192.168.99.100:2376": x509: انتهت صلاحية الشهادة أو لم تعد صالحة بعد
يمكنك محاولة إعادة إنشائها باستخدام "docker-machine regenerate-certs [name]".
يرجى العلم أن هذا سيؤدي إلى إعادة تشغيل برنامج Docker daemon والذي سيؤدي إلى إيقاف تشغيل الحاويات.

$ docker-machine regenerate-certs vbox-test
هل تريد إعادة إنشاء شهادات جهاز TLS؟ تحذير: هذا لا رجوع فيه. (ص / ن): ذ
تجديد شهادات TLS
في انتظار توفر SSH ...
جاري الكشف عن الموفر ...
جاري نسخ الشهادات إلى دليل الجهاز المحلي ...
جاري نسخ الشهادات إلى الآلة البعيدة ...
جارٍ إعداد تكوين Docker في البرنامج الخفي البعيد ...

$ docker-machine env vbox-test
خطأ في التحقق من اتصال TLS: التحقق من الخطأ و / أو إعادة إنشاء الشهادات: حدث خطأ أثناء التحقق من صحة الشهادات للمضيف "192.168.99.100:2376": x509: انتهت صلاحية الشهادة أو لم تعد صالحة بعد
يمكنك محاولة إعادة إنشائها باستخدام "docker-machine regenerate-certs [name]".
يرجى العلم أن هذا سيؤدي إلى إعادة تشغيل برنامج Docker daemon والذي سيؤدي إلى إيقاف تشغيل الحاويات.

لقد حصلت على هذا في التثبيت الافتراضي لـ 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 ) تم إصلاحها لي.