machine 🚀 - प्रमाणपत्र ठीक से स्थापित नहीं होते, हमेशा पुन: उत्पन्न होते हैं

विस्तृत सारांश के लिए धन्यवाद। मैंने पहले भी इस तरह के मुद्दे देखे हैं और मैं इसे देख लूंगा।

nathanleclaire 8 अक्तू॰ 2015

क्या आप नवीनतम वायरलबॉक्स पर हैं? यानी 5.0.6?

nathanleclaire 8 अक्तू॰ 2015

मैं 5.0.4 का उपयोग कर रहा था जो डॉकर टूलबॉक्स (1.8.2c) के नवीनतम संस्करण के साथ जहाज करता है। मैंने अभी उस संस्करण को हटा दिया है, 5.0.6 स्थापित किया है और मैं उसी व्यवहार का अनुभव कर रहा हूं।

carolynvs 8 अक्तू॰ 2015

ठीक है धन्यवाद।

nathanleclaire 8 अक्तू॰ 2015

@carolynvs यदि आप केवल होस्ट को हटाते हैं जो आपके पास है (यह VirtualBox GUI में कर सकते हैं) और पुनः प्रयास करें, क्या यह काम करता है?

nathanleclaire 8 अक्तू॰ 2015

मैंने मशीन को हटा दिया, एडॉप्टर को हटा दिया और उसी परिणाम के साथ फिर से प्रयास किया।

carolynvs 8 अक्तू॰ 2015

ठीक है धन्यवाद। बहुत ही अजीब व्यवहार। मैं एक परीक्षण निर्माण कर सकता हूं जो कर्ट के बारे में अधिक जानकारी डंप करता है और सुझाव देता है कि यदि आप सहमत हैं तो आप कोशिश करें।

nathanleclaire 8 अक्तू॰ 2015

बेशक! मैं मदद करने में प्रसन्न हूं, हालांकि मैं कर सकता हूं

यदि आप केवल एक शाखा बनाना चाहते हैं और मुझे इसकी ओर इशारा करना चाहते हैं, तो मैं इसे स्वयं बना सकता हूं (: दिल: कंटेनरीकृत बिल्ड!) इस तरह यदि आपको एक से अधिक प्रयास करने पड़ते हैं तो आपको दीवार पर कई बिल्ड फेंकने की आवश्यकता नहीं है।

carolynvs 8 अक्तू॰ 2015

इसे ठीक करते समय संभवतः विचार करने वाली एक और बात, मेरे जैसे कुछ लोग वास्तव में 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 डाउनग्रेड करने के बाद से इसका अनुभव नहीं किया।

bentruyman 10 अक्तू॰ 2015

मैंने आज रिलीज उम्मीदवार पर बिल्कुल वही व्यवहार अनुभव किया।

blaggacao 19 अक्तू॰ 2015

हाय @carolynvs @blaggacao, धन्यवाद आपकी प्रतिक्रिया के लिए एक बहुत।

मैं इस बग को पुन: पेश/ठीक करने का प्रयास कर रहा हूं। क्या आप इस पीआर को आजमा सकते हैं (https://github.com/docker/machine/pull/2006) जिसे मैंने बग की जांच में मदद के लिए बनाया है

dgageot 19 अक्तू॰ 2015

ऐसा लगता है कि मैं भी इसे देख रहा हूं। मैं digitalocean ड्राइवर का उपयोग करके OS X पर नवीनतम master बिल्ड का उपयोग कर रहा हूं, इसलिए यह निश्चित रूप से पर्यावरण से कोई लेना-देना नहीं है। मुझे लगता है कि area/windows और area/driver-virtualbox टैग यहां अप्रासंगिक हैं :)

hairyhenderson 19 अक्तू॰ 2015

हाय @hairyhenderson , क्या आप पीआर #2006 बनाने की कोशिश कर सकते हैं और मुझे docker-machine -D env default लिए आउटपुट बता सकते हैं?

dgageot 19 अक्तू॰ 2015

@dgageot - मौका मिलने पर करूँगा।

मैं इसके बारे में कुछ और सोच रहा हूं और महसूस कर रहा हूं कि मैं एक _local_ बिल्ड (यानी make build OS X पर, बिना कंटेनर का उपयोग किए) कर रहा हूं। उन क्षेत्रों में से एक जहां go build ने अतीत में अलग तरह से व्यवहार किया है, वह प्रमाणपत्रों के आसपास है (esp. root CA certs), इसलिए यह _might_ उससे संबंधित हो... मुझे पता नहीं।

लेकिन मैं #2006 के साथ पुनर्निर्माण करूंगा और इसे आजमाऊंगा। धन्यवाद!

hairyhenderson 19 अक्तू॰ 2015

@hairyhenderson यह एक अच्छी बात है। मैं अपने परीक्षण एक क्रॉस-संकलित डॉकर-मशीन के साथ चलाऊंगा

dgageot 19 अक्तू॰ 2015

@dgageot यहां एक नई मशीन के लिए docker-machine -D env default से विफल आउटपुट https://gist.github.com/carolynvs/e2473d21c3376f1ebec2 है।

मैंने # 2006 बनाया और docker-machine.exe और docker-machine-driver-virtualbox.exe को Docker टूलबॉक्स इंस्टॉलेशन डायरेक्टरी में कॉपी किया। मैं विंडोज 10 पर डॉकर टूलबॉक्स 1.8.2c का उपयोग कर रहा हूं।

carolynvs 19 अक्तू॰ 2015

मैं निर्माण करने का तरीका जानने के लिए पर्याप्त रूप से कुशल नहीं हूं, हो सकता है कि मैं इसे शाम को देख सकूं, अगर मैं इसे समझ सकता हूं।

blaggacao 19 अक्तू॰ 2015

@carolynvs बहुत बहुत धन्यवाद। मुझे अभी भी समझ नहीं आ रहा है कि क्या हो रहा है लेकिन आपके लॉग मेरी मदद करेंगे।

dgageot 19 अक्तू॰ 2015

@carolynvs क्या आप इसका आउटपुट प्रदान कर सकते हैं:

VBoxManage list hostonlyifs
VBoxManage list dhcpservers

dgageot 19 अक्तू॰ 2015

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 19 अक्तू॰ 2015

@carolynvs मुझे अब तक कोई जानकारी नहीं है।
मैंने अधिक जानकारी मुद्रित करने और चीजों को आजमाने के लिए पीआर पर कुछ और प्रतिबद्धताओं को धक्का दिया।
यदि आपके पास प्राप्त होने वाले आउटपुट को अपडेट करने का समय है, तो यह बहुत अच्छा होगा।

पिंग @ नाथनलेक्लेयर @ dmp42 कोई विचार?

dgageot 19 अक्तू॰ 2015

यहाँ नया आउटपुट है: https://gist.github.com/carolynvs/84cd140bcbf9b696e20f।

मुझे बताएं कि क्या कनेक्शन समस्या को डीबग करने का कोई और तरीका है। मुझे पूरा यकीन नहीं है कि डॉकर-मशीन क्या पता लगा रही है जो इसे सेर्ट्स को पुन: उत्पन्न करने का कारण बन रही है लेकिन मेजबान पर/var/lib/boot2docker में चारों ओर पोक करने में प्रसन्नता हो रही है या विंडोज़ और होस्ट के बीच कर्ट की तुलना करें, आदि अगर मुझे पता था कि क्या को देखने के लिए।

carolynvs 19 अक्तू॰ 2015

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

या तो प्रमाणपत्र को vm पर ठीक से कॉपी नहीं किया गया है।
या वीएम पोर्ट 192.168.99.100:2376 पर पहुंच योग्य नहीं है (होस्ट नेटवर्क कॉन्फ़िगरेशन? फ़ायरवॉल, वीपीएन? वीएम नेटवर्क कॉन्फ़िगरेशन?)
या हमारे जाँच करने के तरीके में कोई समस्या है।

यदि आप docker-machine env द्वारा दिए गए env चरों को निर्यात करते हैं और त्रुटियों को अनदेखा करते हैं, तो क्या आप docker daemon से कनेक्ट करने में सक्षम हैं?

dgageot 19 अक्तू॰ 2015

मैं डॉकर होस्ट को पिंग कर सकता हूं और उसमें एसएसएच कर सकता हूं। जब मैं 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<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

carolynvs 19 अक्तू॰ 2015

: +1: धन्यवाद! मुझे लगता है कि हम करीब आ रहे हैं: मुस्कान:

blaggacao 19 अक्तू॰ 2015

IIRC, /var/lib/boot2docker/tls में certs boot2docker OS में स्टार्टअप स्क्रिप्ट द्वारा सर्वर साइड जेनरेट किए जाते हैं और वर्तमान मशीन मॉडल में किसी भी चीज़ के लिए उपयोग नहीं किए जाते हैं (वे इस बात का एक अवशेष हैं कि कैसे boot2docker-cli ऐतिहासिक रूप से प्रमाण पत्र सेट होने की अपेक्षा करता है यूपी)।

nathanleclaire 20 अक्तू॰ 2015

@carolynvs @nathanleclaire मैं तो पता नहीं है। मेरे लॉग में केवल इतना अंतर है कि मैं VBox संस्करण 5.0.6 और एक हालिया boot2docker का उपयोग कर रहा हूं।

dgageot 20 अक्तू॰ 2015

@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

एफटीआर, यहां वह ट्यूटोरियल है जिसका उपयोग मैं इसे काम करने के लिए करता था: http://opensolitude.com/2015/07/12/curl-docker-remote-api-os-x.html

dgageot 20 अक्तू॰ 2015

@dgageot ओह, हाँ यह मेरी मशीन पर एक समस्या प्रतीत होती है (विंडोज़ के लिए गिट से कर्ल/ओपनएसएल का उपयोग करके सभी कमांड समान हैं)।

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

मैंने vi -b path/to/cert का उपयोग करके ~/.docker/machine/certs में सभी प्रमाणपत्रों की जांच की और सत्यापित किया कि इसमें यूनिक्स लाइन समाप्ति है। मैंने निम्न कमांड का उपयोग यह जांचने के लिए किया कि क्या ओपनएसएल उन्हें पढ़ने में सक्षम था।

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

मैं कर्ट के साथ इधर-उधर ताक-झांक करता रहूंगा, क्योंकि यह इस मुद्दे की तरह लगता है। हो सकता है कि इसे किसी अन्य मशीन पर आज़माएं और देखें कि क्या यह सिर्फ विंडोज 10 की चीज है।

carolynvs 20 अक्तू॰ 2015

@carolynvs बढ़िया काम! मैं कल सुबह इसकी जाँच करूँगा (पेरिस समय)

dgageot 20 अक्तू॰ 2015

हाय @carolynvs , क्या आपने इस आदेश को ca.pem भी आजमाया है?

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

आप जाँच कर सकते हैं कि यह ठीक से साथ शुरू होता है -----BEGIN CERTIFICATE----- और साथ समाप्त होता है -----END CERTIFICATE----- । पहले और बाद में कुछ नहीं।

dgageot 21 अक्तू॰ 2015

@carolynvs मुझे स्वीकार करना होगा कि मुझे नहीं पता कि क्या हो रहा है। क्या आपने इस पीआर की कोशिश की है जो अस्पष्ट रूप से संबंधित लगता है।

dgageot 21 अक्तू॰ 2015

यदि आपको इस मध्यवर्ती सारांश की पुष्टि करने में कोई आपत्ति नहीं है, तो मैं चुपचाप इस पर अपना दिमाग लगा सकता हूं:

Certs कॉपी किए जाते हैं, लेकिन पढ़े नहीं जा सकते?

मुझे यकीन है, आपने पहले ही जाँच कर ली है: http://stackoverflow.com/questions/20837161/openssl-pem-routinespem-read-biono-start-linepem-lib-c703expecting-truste
मैंने इसे दूसरों के संदर्भ के लिए रखा है।

blaggacao 21 अक्तू॰ 2015

मैंने जेनरेट की गई pfx फ़ाइल के बजाय --cert और --key का उपयोग करके एक अलग कर्ल कमांड की कोशिश की और यह कनेक्ट करने में सक्षम है।

$ 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 के आउटपुट को और अधिक बारीकी से देखने पर मुझे लगता है कि यह निर्यात कर रहा है जो मुझे लगता है कि एक खराब प्रमाणित पथ है। मेरे मैक पर यह .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 संदिग्ध चीजें दिखाई देती हैं:

DOCKER_CERT_PATH .docker/machine/ Machines/ के बजाय .docker/machine/certs का उपयोग कर रहा है
Validate cert.pem और key.pem के बजाय server.pem और server-key.pem का उपयोग कर रहा है। मैं नहीं जानता कि प्रत्येक प्रमाणपत्र किस लिए है, लेकिन यह सही नहीं लगता।

carolynvs 21 अक्तू॰ 2015

बहुत बहुत धन्यवाद @carolynvs जो वास्तव में मदद करनी चाहिए। इससे पहले कि मैं आपके द्वारा रिपोर्ट की गई हर चीज को पचा सकूं, क्या आप https://github.com/docker/machine/pull/2006 के नवीनतम संस्करण को आजमा सकते हैं, इसे सत्यापन के लिए उपयोग किए जा रहे प्रमाणपत्रों को प्रिंट करना चाहिए। इससे मदद मिलनी चाहिए

dgageot 21 अक्तू॰ 2015

यहां वे प्रमाणपत्र हैं जिनका वह उपयोग कर रहा है

होस्ट यूआरएल=192.168.99.102:2376
CA CERT PATH=C:\Users\caro8994.docker\ Machine\certsca.pem
सर्वर CERT PATH = C:\Users\caro8994.docker\ Machine\ Machines\bugtest\server.pem
सर्वर कुंजी पथ = C:\Users\caro8994.docker\ Machine\ Machines\bugtest\server-key.pem

यह मेरी अपनी डिबग जानकारी से है, न कि पीआर से जिसे बनाने में लंबा समय लगता है कि यह सभी प्लगइन्स का निर्माण कर रहा है। :मुस्कुराओ:

carolynvs 21 अक्तू॰ 2015

ठीक है, अब मैं असमंजस में हूँ, इसलिए मैं एक संक्षिप्त पुनर्कथन करने की कोशिश करूँगा।

क्या आप इसकी पुष्टि कर सकते हैं:

~/.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 लिए किस मूल्य का उपयोग किया था?
आपके मैक पर, docker-machine env bugtest प्रिंट निर्यात DOCKER_CERT_PATH="~/.docker/machine" न कि DOCKER_CERT_PATH="~/.docker/machine/certs"

समर्थन के लिए फिर से धन्यवाद!

dgageot 21 अक्तू॰ 2015

@carolynvs FTR, क्रॉस-बिल्डिंग केवल डॉकर-मशीन, केवल विंडोज़ के लिए बहुत तेज़ होना चाहिए: TARGET_ARCH=amd64 TARGET_OS=windows बिल्ड-एक्स-मशीन बनाती हैं

dgageot 21 अक्तू॰ 2015

ब्रेन डंप के लिए क्षमा करें!

~/.docker/machine/certs और ~/.docker/machine/machines/bugtest दोनों में ca.pem, cert.pem और key.pm समान हैं।
जब मैंने DOCKER_CERT_PATH से ~.docker/machine/machines/bugtest सेट किया तो डॉकर क्लाइंट ने काम किया
मेरे मैक पर (जो काम करता है) docker-machine env DOCKER_CERT_PATH="~/.docker/machine/machines/bugtest" सेट करता है। विंडोज 10 (जो नहीं करता है) पर, उसी कमांड के परिणामस्वरूप DOCKER_CERT_PATH="~/.docker/machine/certs"

यह मेरे दिमाग के ढेर में था लेकिन शायद खो गया हो। जब डॉकर-मशीन प्रमाणपत्रों को मान्य कर रहा है, तो यह सर्वर.पेम और सर्वर-की.पेम का उपयोग करके डॉकर डेमॉन से जुड़ने का प्रयास कर रहा है। यह सुपर फिश लगता है।

carolynvs 21 अक्तू॰ 2015

ठीक है। आइए बचाव के लिए @nathanleclaire और @ehazlett को कॉल करें। मुझे लगता है कि आपने इसे पकड़ लिया है, लेकिन अब, मैं इस परियोजना के लिए बहुत नया हूं कि यह समझने के लिए कि हमारे पास इतने सारे डुप्लिकेट प्रमाणपत्र क्यों हैं और हम सही लोगों का उपयोग क्यों नहीं करते हैं।

dgageot 21 अक्तू॰ 2015

निर्माण टिप के लिए धन्यवाद!

नीचे पीआर #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 21 अक्तू॰ 2015

बंद/फिर से खोले गए शोर के लिए खेद है। मैं लड़खड़ा गया

dgageot 21 अक्तू॰ 2015

ओय वे। @carolynvs @dgageot आप सभी इस एक का पीछा जारी रखने के लिए चैम्प्स हैं। मुझे लगता है कि कैरोलिन का संदेह सही है: यदि DOCKER_CERT_PATH सही ढंग से सेट नहीं हो रहा है, तो डेमॉन के साथ संचार ठीक से काम नहीं करेगा। ऐसा लगता है कि यह उन पथों के साथ एक समस्या हो सकती है जिन्हें मैंने अनजाने में libmachine परिवर्तनों में पेश किया था। मैं इसकी जांच करना जारी रखूंगा और अब तक आपके निष्कर्षों पर ध्यान दूंगा।

nathanleclaire 21 अक्तू॰ 2015

क्या अपराधी का प्रवेश द्वार यही रेखा हो सकती है?
https://github.com/docker/machine/blob/8aa1572e0dcd75762a7627e1056ef104317f44b9/libmachine/persist/filestore.go#L155

blaggacao 21 अक्तू॰ 2015

@blaggacao निश्चित रूप से संभावना के दायरे में दृढ़ता से - वह कोड थोड़ा भंगुर होता है और अतीत में समस्याग्रस्त रहा है।

nathanleclaire 21 अक्तू॰ 2015

मुझे नहीं पता कि यह विंडोज़ और मैक ओएस पर कैसे भिन्न हो सकता है, हालांकि @carolynvs ने पुष्टि की है।
मेरे लिए यह स्पष्ट रूप से .docker\machine\certs पथ का निर्माण करता है।

blaggacao 21 अक्तू॰ 2015

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 21 अक्तू॰ 2015

@blaggacao स्पष्ट रूप से, मैं मैक पर @carolynvs के समान व्यवहार नहीं है। तो कुछ गड़बड़ है।

dgageot 21 अक्तू॰ 2015

हाँ, प्रावधान बिट के दौरान कर्ट उस मशीन की निर्देशिका में कॉपी हो जाते हैं।

nathanleclaire 21 अक्तू॰ 2015

@dgageot भ्रम के लिए क्षमा याचना। मेरा मैक डॉकर-मशीन 0.4.1 चला रहा है। मैं केवल अपने विंडोज मशीन पर पीआर बिल्ड चला रहा हूं क्योंकि मैं वहां फिक्स का परीक्षण कर रहा हूं क्योंकि वे मास्टर में विलय हो गए हैं।

मैं अभी अपने मैक पर फिर से बिल्ड और रन कर सकता हूं।

carolynvs 21 अक्तू॰ 2015

मैं फिर से शुरू करता हूं:

अंतर /machine/certs और /machine/machines/certs बीच अंतर नहीं दिखा रहे हैं
मैं समस्या को हल करने के लिए carlynvs वर्कअराउंड को पुन: पेश नहीं कर सकता।

blaggacao 21 अक्तू॰ 2015

विंडोज़ (बैश में) पर मैन्युअल रूप से DOCKER_CERT_PATH सेट करते समय, आपको यूनिक्स शैली पथ का उपयोग करना चाहिए। उदाहरण के लिए, export DOCKER_CERT_PATH="~./docker/machine/machines/oca" ।

मैं पुष्टि कर सकता हूं कि मेरी (wonky) मशीन पर कर्ट/मशीन/सर्ट और/मशीन/मशीन/सर्ट के बीच मेल खाते हैं।

carolynvs 21 अक्तू॰ 2015

मैं मैन्युअल रूप से कॉपी करके पुष्टि कर सकता हूं, क्योंकि 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 21 अक्तू॰ 2015

VM में कौन से पथ आप certs @blaggacao के लिए उपयोग कर रहे हैं?

nathanleclaire 21 अक्तू॰ 2015

मुझे अभी एहसास हुआ, यह गलत था ...

मैंने ~/.docker विरुद्ध जाँच की मैं /var/lib/boot2docker विरुद्ध फिर से जाँच करूँगा

blaggacao 21 अक्तू॰ 2015

मैं निश्चित रूप से पुष्टि कर सकता हूं कि

/machines/oca और oca:/var/lib/boot2docker/ में प्रमाणपत्र समान हैं
(मैं dos2unix सभी 3 फाइलों पर ca.pem , server.pem , sever-key.pem oca पर चलाता हूं)

blaggacao 21 अक्तू॰ 2015

मुझे अतिरिक्त रूप से यह टाइमआउट त्रुटि मिलती है: https://github.com/docker/machine/blob/6a5219b879db52698ccb2b7e0aafd516b34df839/libmachine/provision/boot2docker.go#L193
हर बार जब मैं env चलाता हूं या तो --native-ssh ध्वज के साथ या नहीं

blaggacao 21 अक्तू॰ 2015

हाँ, @blaggacao ऐसा भी लगता है कि केवल VM को सौंपा गया होस्ट आपके कंप्यूटर पर उपलब्ध नहीं है। क्या आप ping $(docker-machine ip vmname) कर सकते हैं?

nathanleclaire 21 अक्तू॰ 2015

नहीं, या तो काम नहीं करता... "अनुरोध का समय समाप्त हो गया"

blaggacao 21 अक्तू॰ 2015

docker-machine ssh vmname हालांकि काम करता है

blaggacao 21 अक्तू॰ 2015

हाँ, ssh localhost से होकर जाता है। लेकिन ऐसा लगता है कि आप असाइन किए गए होस्ट से केवल VM IP से संपर्क नहीं कर सकते हैं, इसलिए मैं env के सही ढंग से कार्य करने की अपेक्षा नहीं करूंगा। क्या आप किसी वीपीएन या प्रॉक्सी का उपयोग कर रहे हैं?

nathanleclaire 21 अक्तू॰ 2015

नहीं, कि मुझे इसके बारे में पता होगा, बस कार्य प्रबंधक को दोबारा जांचा गया... अद्यतन ने एक का पता लगाया, बंद करना

blaggacao 21 अक्तू॰ 2015

बंद करने से कुछ नहीं बदलता, लेकिन यह एक और मुद्दा है, मुझे लगता है...

blaggacao 21 अक्तू॰ 2015

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

blaggacao 21 अक्तू॰ 2015

यह दोनों समस्याओं के बीच संबंध की तरह गंध करता है। क्या आप मेरी विचारधारा की व्याख्या कर सकते हैं?

blaggacao 21 अक्तू॰ 2015

दूरस्थ खुदाई: https://github.com/leo-stone/fix-go-1.5-tls-issue/blob/master/main.go

blaggacao 22 अक्तू॰ 2015

मुझे अब अपने विंडोज वातावरण पर भरोसा नहीं था इसलिए मैंने विंडोज को फिर से शुरू किया और फिर से #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

क्या समस्या यह हो सकती है कि प्रमाणपत्र भविष्य दिनांकित है? यह समझाएगा कि मूल रूप से मेरे कर्ल कमांड काम क्यों नहीं करते थे लेकिन कुछ घंटों बाद उन्होंने किया।

carolynvs 22 अक्तू॰ 2015

मुझे भी:

$ 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) कहता है। बोगोटा यूटीसी-5 . है

blaggacao 22 अक्तू॰ 2015

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

blaggacao 22 अक्तू॰ 2015

अपडेट करें: फिक्स

जैसा कि यहां बताया गया है: https://github.com/docker/docker/issues/11534#issuecomment -89405874

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

मुझे एक अलग त्रुटि मिली (एक समय में एक कदम :)

blaggacao 22 अक्तू॰ 2015

मुझे लगता है कि यह बात है, बाकी मेरा वर्चुअलबॉक्स है।

blaggacao 22 अक्तू॰ 2015

मैं रात का खाना खाने जा रहा हूँ और 5 घंटे में वापस जाँच करूँगा जब मुझे संदेह होगा कि मेरा प्रमाण पत्र मान्य होगा और सब कुछ बस काम करेगा। :मुस्कुराओ:

carolynvs 22 अक्तू॰ 2015

बुरी खबर, मुझे इसे हर वीएम पुनरारंभ पर करना है।

blaggacao 22 अक्तू॰ 2015

: मुस्कान: मुझे लगता है कि आप मूल कारण मारा! धन्यवाद!

blaggacao 22 अक्तू॰ 2015

ताली :: ताली :: ताली :: ताली :: ताली :: ताली :: ताली:

blaggacao 22 अक्तू॰ 2015

@carolynvs ने जो फिक्स मैंने पोस्ट किया है वह आपके लिए काम करता है?

blaggacao 22 अक्तू॰ 2015

मैं सिर्फ यह पुष्टि करना चाहता था कि सर्टिफिकेट वैध होने तक 5 घंटे इंतजार करने के बाद, docker-machine env काम करता है। कोई सुराग नहीं है कि मुझे भविष्य के दिनांकित प्रमाणपत्र क्यों मिल रहे हैं, लेकिन शायद वास्तविक मूल कारण को प्रतिबिंबित करने के लिए समस्या को अद्यतन करना चाहिए जो अब हम जानते हैं।

carolynvs 22 अक्तू॰ 2015

मेरे मामले में certs मुद्दा नहीं था, लेकिन boot2docker पर समय सेटिंग ... जैसा कि मैं आपके github प्रोफ़ाइल पर देख सकता हूं, आप शिकागो से हैं, यह बोगोटा के समान टाइमज़ोन है, हो सकता है कि boot2docker हमारे टाइमज़ोन में गलत तरीके से सेटअप हो जाए ...

blaggacao 22 अक्तू॰ 2015

आपके वर्कअराउंड का उपयोग करके समय को सिंक करने के बाद, मुझे अभी भी वही त्रुटि प्राप्त होती है (प्रमाणपत्र समाप्त हो गया है या अभी तक मान्य नहीं है) मेरे डॉकटर होस्ट से कनेक्ट करने के लिए उन कर्टों का उपयोग करते समय।

मेरे मैक पर, एक नया बॉक्स बनाने और उसके समय की जांच करने के बाद मैं यही देखता हूं।

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

यहाँ विंडोज़ पर एक नए होस्ट पर समान कमांड है:

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

तारीख मेरा स्थानीय समय दिखा रही है लेकिन सोचता है कि यह यूटीसी है और मुझे नहीं पता कि इसे hwclock से मिलान करने के लिए कैसे अपडेट किया जाए। मैंने मैन्युअल रूप से तिथि बदलने की कोशिश की है लेकिन व्यस्त बॉक्स या वर्चुअलबॉक्स के बारे में कुछ ऐसा है जो तुरंत किसी भी बदलाव को पूर्ववत कर रहा है।

carolynvs 22 अक्तू॰ 2015

यह वर्कअराउंड लागू करने के बाद कल की स्थिति में काम कर रहा है:

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 मेरे मामले में सही तारीख दिखा रहा है, मुझे लगता है कि मेरे मामले में वर्कअराउंड निश्चित तारीख है और इसलिए यह मुद्दा है।

blaggacao 22 अक्तू॰ 2015

cc @tianon @SvenDowideit PTAL उपरोक्त आरई पर: boot2docker समय/तिथि मुद्दे ^^

nathanleclaire 22 अक्तू॰ 2015

मुझे मिले कुछ कोड टाइमस्टैम्प समस्या में योगदान दे रहे हैं:

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

लेकिन यह पहले हमेशा ठीक काम कर रहा है।

nathanleclaire 3 नव॰ 2015

@carolynvs @blaggacao आप अभी भी इन मुद्दों में चलाने है?

nathanleclaire 3 नव॰ 2015

मेरे लिए यह संदर्भित वर्कअराउंड के बाद काम कर रहा है। यह, बदले में, इंगित करता है कि कुछ boot2docker time पैरामीटर जहां सही ढंग से सेट नहीं है। आमतौर पर यह मशीन के निर्माण के ठीक बाद सीमित समय सीमा के दौरान ही होता है। (शायद केवल कुछ समय क्षेत्रों में)।

इसका फिर से मतलब होगा, कि कर्ट टाइमस्टैम्प सही होंगे।

blaggacao 3 नव॰ 2015

मैंने अपने आरसी पर पीसी को पुनरारंभ करने के बाद अभी फिर से इस पर ठोकर खाई, लेकिन 5.0 के अपडेट के बाद सब कुछ काम करने लगता है। हम शायद इसे अभी के लिए बंद कर सकते हैं। किसी भी तरह, जैसे ही मुझे अजीब व्यवहार दिखाई देता है, मैं इसे फिर से खोल दूंगा।

blaggacao 5 नव॰ 2015

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

मुझे भी यही समस्या है। इसे बंद मत करो।

damontic 13 नव॰ 2015

@damontic जो यहां चर्चा की जा रही एक से अलग मुद्दे की तरह दिखता है।

nathanleclaire 13 नव॰ 2015

मैं 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.

इसे चलाने से पहले, मैंने मशीन 0.5.1 . में अपडेट किया

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

मैं मशीन "कंसल" के संदर्भ में जा सकता हूं लेकिन "डेमो0" या "डेमो 1" के लिए नहीं

$ 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 18 नव॰ 2015

@lucj यदि प्रावधान विफल रहता है, तो बनाए गए उदाहरण "अमान्य" होंगे। उन्हें हटाने का प्रयास करें और फिर से शुरू से शुरू करें।

nathanleclaire 18 नव॰ 2015

@nathanleclaire मैंने अभी-अभी मशीनों को हटा दिया है (क्या 'docker-machine rm consul demo0 demo1' पर्याप्त है या क्या मुझे मैन्युअल रूप से कुछ अन्य सामान हटाना चाहिए?) अजीब बात यह है कि 'कंसल' मशीन में कोई समस्या नहीं है, लेकिन केवल झुंड वाले (demo0, demo1) के साथ है।

वर्चुअलबॉक्स (5.0.10) पर झुंड बनाते समय यह ठीक काम कर रहा है।

lucj 18 नव॰ 2015

एडब्ल्यूएस ड्राइवर का उपयोग करते समय मैं इसे देख रहा हूँ

dzlab 25 नव॰ 2015

मैंने कई परीक्षण किए हैं (वास्तव में बहुत कुछ), वीएम को हटाने और उन्हें फिर से बनाने के बाद (एक झुंड के साथ) मुझे अभी भी वही समस्या है।

lucj 25 नव॰ 2015

MacOSX 10.10.5 पर डॉकर टूलबॉक्स का उपयोग करके संस्करण 1.8 से 1.9.1 में अपग्रेड करने के बाद अब मेरे पास यह समस्या है

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

dlgoodchild 9 दिस॰ 2015

मेरे साथ भी समय-समय पर ऐसा हो रहा है। डॉकर v1.9.1

spieden 30 दिस॰ 2015

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 चलाने के बाद कर्ट सत्यापन ठीक काम करता है।

डॉकर-मशीन 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 12 फ़र॰ 2016

@alambike आप इस मुद्दे को 0.6.0 से मार रहे हैं?

nathanleclaire 13 फ़र॰ 2016

हां, 0.5.5 से आगे। मैंने इसका परीक्षण 0.5.6 और 0.6.0 के साथ किया है।

alambike 13 फ़र॰ 2016

मैक 10.10.5 पर एडब्ल्यूएस ड्राइवर (लगातार) के साथ 0.6.0 पर मेरे लिए वही। वर्चुअल बॉक्स ड्राइवर के साथ नहीं हो रहा है।

helinwang 14 फ़र॰ 2016

डॉकर-मशीन 0.6.0 का उपयोग करके --engine-opt="cluster-advertise=eth1:2376" से --engine-opt="cluster-advertise=eth0:2376" बदलने के बाद तय किया गया (डॉकर-मशीन 0.5.4 अभी भी विफल है)

helinwang 14 फ़र॰ 2016

मुझे लगता है कि मैं अपनी मशीन पर उसी मुद्दे से जूझ रहा हूं। मैं उबंटू 14.04 का उपयोग कर रहा हूं
डॉकर-मशीन संस्करण 0.5.5, 02c4254 . का निर्माण करें
आरएचईएल 7.1 . पर रनिंग होस्ट
सर्वर संस्करण: 1.10.2-cs1-rc3

मशीनों पर समय के साथ सुझाई गई हर चीज की कोशिश की, यहाँ आउटपुट है जो मुझे कर्ल से मिलता है

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://$(डॉकर-मशीन आईपी $NODE_NAME):2376/संस्करण

DNS कैश में होस्टनाम नहीं मिला
१६.८५.३.१४० कोशिश कर रहा है...
16.85.3.140 (16.85.3.140) पोर्ट 2376 (#0) से जुड़ा है
सफलतापूर्वक प्रमाणपत्र सत्यापित स्थान सेट करें:
CAfile: /home/eraigosa/.docker/machine/certs/ca.pem
CApath: /etc/ssl/certs
एसएसएलवी3, टीएलएस हैंडशेक, क्लाइंट हैलो (1):
एसएसएलवी3, टीएलएस हैंडशेक, सर्वर हैलो (2):
एसएसएलवी3, टीएलएस हैंडशेक, सीईआरटी (11):
एसएसएलवी3, टीएलएस हैंडशेक, सर्वर की एक्सचेंज (12):
एसएसएलवी3, टीएलएस हैंडशेक, सीईआरटी का अनुरोध करें (13):
SSLv3, TLS हैंडशेक, सर्वर समाप्त (14):
एसएसएलवी3, टीएलएस हैंडशेक, सीईआरटी (11):
एसएसएलवी3, टीएलएस हैंडशेक, क्लाइंट की एक्सचेंज (16):
एसएसएलवी3, टीएलएस हैंडशेक, सीईआरटी सत्यापन (15):
SSLv3, TLS सिफर बदलें, क्लाइंट हैलो (1):
एसएसएलवी3, टीएलएस हैंडशेक, समाप्त (20):
SSLv3, TLS अलर्ट, सर्वर हैलो (2):
त्रुटि: १४०९४४१२ : SSL रूटीन: SSL3_READ_BYTES : sslv3 चेतावनी खराब प्रमाणपत्र
कनेक्शन बंद करना 0
कर्ल: (३५) त्रुटि: १४० ९ रूटीन: SSL3_READ_BYTES : sslv3 चेतावनी खराब प्रमाणपत्र

wenlock 25 फ़र॰ 2016

@nathanleclaire मुझे boot2docker से prltoolsd लगातार मेरी तिथि/समयक्षेत्र गलत तरीके से सेट कर रहा है।

$ 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 रोकने और तारीख को रीसेट करने के बाद, मेरे सभी डॉकटर-मशीन कमांड अपेक्षित रूप से काम करते हैं और मेरे प्रमाणपत्र पुन: उत्पन्न नहीं होते हैं।

मुझे अभी भी पता नहीं है कि नई मशीन बनाने के बाद टाइमज़ोन यूटीसी और स्थानीय समय के लिए क्यों सेट किया गया है, इसलिए यह सिर्फ एक समाधान है, ठीक नहीं है।

carolynvs 11 मार्च 2016

❤1

अच्छा @carolynvs ! हम यह देखने पर काम करेंगे कि क्या हम इसे boot2docker में ठीक कर सकते हैं।

@tianon @legal90 FYI करें ^^

nathanleclaire 11 मार्च 2016

@carolynvs वाह: भयभीत:। यह वास्तव में अजीब लग रहा है, क्योंकि prltoolsd प्रक्रिया Parallels Desktop को छोड़कर किसी अन्य वर्चुअलाइजेशन सिस्टम पर शुरू नहीं होनी चाहिए। डेमॉन तभी शुरू होगा जब /usr/bin/prlvmcheck 0 एग्जिट-कोड लौटाएगा, जिसका अर्थ है कि हम Parallels VM में हैं।

क्या आपने वर्चुअलबॉक्स वीएम पर इस मुद्दे को पुन: पेश किया है? आप किस Boot2Docker संस्करण का उपयोग कर रहे हैं?

इसके अलावा, अगर हम मानते हैं कि prltoolsd ही एकमात्र कारण है, तो डॉकर मशीन संस्करण का कोई मतलब नहीं होना चाहिए। हालाँकि, ऊपर दी गई अन्य टिप्पणियाँ ( लिंक ) बताती हैं कि समस्या केवल मशीन में दिखाई देती है 0.5.5+

legal90 12 मार्च 2016

@ कानूनी 90 यह अधिक समझ में आता है। मेरा वातावरण थोड़ा भद्दा है, लेकिन यह ठीक काम करता था:

मैं एक मैक पर समानताएं चला रहा हूं।
समानताएं के अंदर मैं विंडोज चलाता हूं, फिर नवीनतम डॉकर टूलबॉक्स इंस्टॉलेशन। मैं ऐसा इसलिए करता हूं क्योंकि मैं डॉकर के लिए प्रलेखन और ट्यूटोरियल लिखता हूं, और मैक, लिनक्स और विंडोज उपयोगकर्ताओं को लक्षित करने की आवश्यकता है।

यह बताता है कि क्यों prltoolsd मेरे डॉकटर होस्ट घड़ी को प्रबंधित करने का प्रयास कर रहा है। यह समानताएं के अंदर नेस्टेड होने पर उठा रहा होगा। क्या यह यह भी बताता है कि सिस्टम घड़ी स्थानीय समय पर क्यों सेट है लेकिन लगता है कि यह यूटीसी है?

यही मूल समस्या है जिसके कारण मुझे यह बग खोलना पड़ा। मैं सुबह 10 बजे सीएसटी (-6) में एक नई डॉकटर मशीन बनाता हूं। नई मशीन पर सिस्टम क्लॉक ( date ) सोचता है कि यह 10 AM UTC है, इसलिए प्रमाणपत्रों पर टाइमस्टैम्प "भविष्य में" हैं। 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 से केवल यह सत्यापित करने के लिए बनाया है कि मैं पुराने आईएसओ का उपयोग नहीं कर रहा हूं। मुझे आश्चर्य है कि /etc/localtime फ़ाइल गुम होने से गलत समय की समस्या हो रही है?

carolynvs 14 मार्च 2016

@carolynvs आह, अब मुझे मिल गया।

यह बताता है कि क्यों prltoolsd मेरे डॉकर होस्ट घड़ी को प्रबंधित करने का प्रयास कर रहा है। यह समानताएं के अंदर नेस्टेड होने पर उठा रहा होगा।

हाँ, यही समस्या की जड़ है। वर्चुअलबॉक्स VM में prltoolsd चलता है जो Parallels VM में नेस्टेड है। मैंने इसे दोबारा तैयार किया है और Parallels के जिम्मेदार लोगों को रिपोर्ट किया है। जैसे ही यह ठीक हो जाएगा मैं आपको बता दूंगा।

क्या यह यह भी बताता है कि सिस्टम घड़ी स्थानीय समय पर क्यों सेट है लेकिन लगता है कि यह यूटीसी है?

ठीक है, इसे प्रतिबद्ध करना कठिन है लेकिन यह समानताएं डेस्कटॉप (और इसके अतिथि उपकरण) का एक ज्ञात मुद्दा है। यह मूल रूप से यहां बताया गया था: https://github.com/Parallels/vagrant-parallels/issues/186।
यह prlctl उपयोगिता के लिए अतिरिक्त विकल्प द्वारा पीडी 11 में चारों ओर काम किया गया था, लेकिन यह आपके दुर्लभ मामले में मदद नहीं करता है, क्योंकि आप वास्तव में विंडोज़ पर वर्चुअलबॉक्स वीएम चला रहे हैं।

मुझे खेद है, लेकिन इस समय मैं आपको एकमात्र उपाय सुझा सकता हूं कि prltoolsd को बूट पर आपके VM में चलने से रोका जाए। यदि आप एक कस्टम Boot2Docker ISO बिल्ड का उपयोग करते हैं, तो आप Dockerfile से समानांतर-संबंधित लाइनों को हटा सकते हैं और ISO का पुनर्निर्माण कर सकते हैं। या इस लाइन पर टिप्पणी करें: https://github.com/boot2docker/boot2docker/blob/master/rootfs/rootfs/bootscript.sh#L101

legal90 14 मार्च 2016

Prltoolsd कैसे काम करता है, इस बारे में अतिरिक्त जानकारी के लिए धन्यवाद! जैसा आप सुझाव देंगे मैं वैसा ही करूंगा और अपने सेटअप के लिए एक कस्टम आईएसओ बनाउंगा। :बीयर:

मैं इस मुद्दे को बंद कर दूंगा, क्योंकि यह मेरी समस्या को ठीक करता है, लेकिन मैं इसे आप पर छोड़ दूंगा क्योंकि अन्य लोग इसे मार रहे हैं (हालांकि शायद विभिन्न कारणों से!)।

carolynvs 14 मार्च 2016

मुझे लगता है कि हम इसे प्रभावी ढंग से हल कर सकते हैं; यदि कोई नई समस्या मिलती है तो हम फिर से खोल सकते हैं।

इस लंबे समय तक चलने वाले मुद्दे की रिपोर्टिंग और परीक्षण में आपके योगदान के लिए सभी का धन्यवाद!

nathanleclaire 14 मार्च 2016

मैं विंडोज़ पर डॉकरटूलबॉक्स 1.10.3 का उपयोग कर रहा हूं। जब तक मैंने पुनः आरंभ नहीं किया तब तक यह ठीक काम कर रहा था, और अब मुझे यही समस्या हो रही है। मैं भी डॉकर से परिचित नहीं हूं, तो क्या कोई मुझे बता सकता है कि फिक्स क्या है?

mtrtm 22 मार्च 2016

@mtrtm क्या docker-machine regenerate-certs -f काम नहीं करता है?

nathanleclaire 22 मार्च 2016

हां, डॉकर-मशीन रीजेनरेट-सर्ट-एफ करता है। ऐसा लगता है कि हर बार जब मैं डॉकर क्विकस्टार्ट टर्मिनल शुरू करता हूं तो ऐसा होता है

mtrtm 25 मार्च 2016

+1
मैं मुख्य रूप से रेडहैट सर्वर पर डॉकर का उपयोग कर रहा हूं और सबकुछ ठीक काम करता है। मैं कोई विशेषज्ञ नहीं हूं लेकिन मुझे पता है कि मैं क्या कर रहा हूं। वर्चुअलबॉक्स के साथ विंडोज़ पर, हालांकि, हर बार जब डॉकर वीएम पुनरारंभ होता है तो मुझे पुन: उत्पन्न करने की आवश्यकता होती है। मैं टूलबॉक्स पर हूँ 1.11.1

virtualmackem 10 मई 2016

👍1

+1

2009 के अंत में मैकबुक
2,26 गीगाहर्ट्ज़ इंटेल कोर 2 डुओ
मैक ओएस सिएरा 10.12
डॉकर टोलबॉक्स 1.2.1
वर्चुअलबॉक्स 5.0.26

$ डोकर-मशीन ls
नाम सक्रिय चालक राज्य यूआरएल झुंड डोकर त्रुटियाँ
vbox-test - वर्चुअलबॉक्स चल रहा है docker संस्करण को क्वेरी करने में असमर्थ: https://192.168.99.100 :2376/v1.15/version: x509: प्रमाणपत्र की समय सीमा समाप्त हो गई है या अभी तक मान्य नहीं है

$ डोकर-मशीन env vbox-test
टीएलएस कनेक्शन की जांच करने में त्रुटि: प्रमाणपत्रों की जांच और/या पुन: उत्पन्न करने में त्रुटि: होस्ट "192.168.99.100:2376" के लिए प्रमाणपत्र सत्यापित करने में त्रुटि हुई: x509: प्रमाणपत्र समाप्त हो गया है या अभी तक मान्य नहीं है
आप 'डॉकर-मशीन रीजेनरेट-सर्ट [नाम]' का उपयोग करके उन्हें पुन: उत्पन्न करने का प्रयास कर सकते हैं।
सावधान रहें कि यह एक डॉकर डेमॉन पुनरारंभ को ट्रिगर करेगा जो कंटेनर चलाना बंद कर देगा।

$ डोकर-मशीन पुन: उत्पन्न-सर्ट vbox-परीक्षण
टीएलएस मशीन सेर्ट्स को पुन: उत्पन्न करें? चेतावनी: यह अपरिवर्तनीय है। (वाई/एन): वाई
टीएलएस प्रमाणपत्रों को पुन: उत्पन्न करना
SSH के उपलब्ध होने की प्रतीक्षा की जा रही है...
प्रावधानकर्ता का पता लगाया जा रहा है...
स्थानीय मशीन निर्देशिका में प्रमाणपत्रों की प्रतिलिपि बनाई जा रही है...
रिमोट मशीन पर प्रमाणपत्र कॉपी कर रहा है...
दूरस्थ डेमॉन पर डॉकर कॉन्फ़िगरेशन सेट करना...

$ डोकर-मशीन env vbox-test
टीएलएस कनेक्शन की जांच करने में त्रुटि: प्रमाणपत्रों की जांच और/या पुन: उत्पन्न करने में त्रुटि: होस्ट "192.168.99.100:2376" के लिए प्रमाणपत्र सत्यापित करने में त्रुटि हुई: x509: प्रमाणपत्र समाप्त हो गया है या अभी तक मान्य नहीं है
आप 'डॉकर-मशीन रीजेनरेट-सर्ट [नाम]' का उपयोग करके उन्हें पुन: उत्पन्न करने का प्रयास कर सकते हैं।
सावधान रहें कि यह एक डॉकर डेमॉन पुनरारंभ को ट्रिगर करेगा जो कंटेनर चलाना बंद कर देगा।

leandropincini 29 सित॰ 2016

मेरे पास 2016-10-30 डाउनलोड किए गए डॉकर टूकिट (विंडोज 10 होम पर स्थापित) की डिफ़ॉल्ट स्थापना पर था। चलने के बाद त्रुटि दूर हो गई:

docker-machine regenerate-certs

hholst80 30 अक्तू॰ 2016

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 4 मार्च 2018

@paddor प्रमाणपत्रों को पुन: docker-machine regenerate-certs -f --client-certs ) ने इसे मेरे लिए तय किया।

wkruse 18 अग॰ 2018

👍2

Machine: प्रमाणपत्र ठीक से स्थापित नहीं होते, हमेशा पुन: उत्पन्न होते हैं

सबसे उपयोगी टिप्पणी

सभी 115 टिप्पणियाँ

संबंधित मुद्दों