मुझे लगता है कि मैं docker-compose रिलीज़ उम्मीदवार का उपयोग करने की कोशिश कर रहा हूं ...

$ docker-compose ps
SSL error: hostname '192.168.59.103' doesn't match 'boot2docker'

लेकिन fig ठीक काम करता है ...

$ fig -f docker-compose.yml ps
Name   Command   State   Ports
------------------------------

मैं OSX पर हूँ, मेरे गो क्लाइंट संस्करण को छोड़कर #gkostyanikov के समान सभी संस्करण चल रहे हैं, go1.3.3 । मेरा अजगर / खुलता भी Homebrew के माध्यम से स्थापित किया गया है। इसके साथ कुछ करना पड़ सकता है?

संपादित करें: वास्तव में ऐसा लगता है कि होमब्रेव ओपनसिएल को लिंक नहीं करता है, इसलिए मैं डिफ़ॉल्ट ओएसएक्स संस्करण का उपयोग कर रहा हूं: OpenSSL 0.9.8za 5 Jun 2014 ।

मुद्दा था Homebrew python।

docker-compose अब homebrew python / opensl को अनइंस्टॉल करने के बाद काम करता है, pip easy_install स्थापित करता है, और सिस्टम pyon का उपयोग करके docker-composer पुनर्स्थापित करता है।

@adambiggs आपका समाधान काम करता है! धन्यवाद!

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

मुझ पर भी यही हो रहा है। और मैं सिस्टम के अजगर का उपयोग नहीं करना चाहता, किसी को भी एक और समाधान है?

क्या आपने बाइनरी का उपयोग करने की कोशिश की है? क्या आपको भी यही समस्या है?

नहीं, मैंने बाइनरी की कोशिश नहीं की है।
यदि आप इसे अपने सिस्टम अजगर में स्थापित नहीं करना चाहते हैं, तो एक और समाधान वर्चुअन (आवरण) का उपयोग करना है।

mkvirtualenv --python=/usr/bin/python docker-compose
pip install docker-compose==1.1.0-rc2

पायथन 2.7.8 पर वापस जाने के लिए pyenv का उपयोग करके एक बेहतर समाधान मिला:

http://stackoverflow.com/a/28216459/1166293
https://github.com/yyuu/pyenv

संपादित करें: कोई बात नहीं, pyenv ने अपनी समस्याओं का एक गुच्छा पेश किया ...

मेरे लिए इस त्रुटि का कारण यह था कि होम-ब्रूव ओपनसेल को / usr / लोकल / बिन / ओपनसीएल से लिंक नहीं किया गया था।

openssl version

लौटे ओपनएसएसएल 0.9.8zc 15 अक्टूबर 2014 नहीं ओपनएसएसएल 1.0.1j 15 अक्टूबर 2014

दौड़ना

brew link --force openssl

और अंजीर को पुनर्स्थापित करने से समस्या हल हो गई।

दिलचस्प है, हालांकि मेरा OpenSSL संस्करण OpenSSL 1.0.1j 15 अक्टूबर 2014 है

@ मेरे मामले में बाइनरी में यह समस्या नहीं है।

मुझे यह त्रुटि तब मिली जब मैंने पाइप के माध्यम से स्थापित किया था, न कि होमब्रे। sudo pip uninstall fig और brew install fig ने मेरे लिए इसे तय किया।

+1 @NotbusTheBuilder समाधान के लिए, मेरे लिए भी काम किया

: +1: @NotbusTheBuilder के लिए

@NotbusTheBuilder अंजीर के लिए अच्छा समाधान, लेकिन

@ocasta OpenSSL को लिंक करने के बारे में होमब्रे से इस डरावनी आवाज़ की चेतावनी क्या है?

यह सूत्र केवल केग है।
मैक ओएस एक्स पहले से ही यह सॉफ्टवेयर प्रदान करता है और दूसरे संस्करण को स्थापित करता है
समानांतर सभी प्रकार की परेशानी का कारण बन सकता है।

Apple ने अपने खुद के टीएलएस और क्रिप्टो लाइब्रेरी के पक्ष में ओपनएसएसएल के उपयोग को हटा दिया है

अंगूठे @NotbusTheBuilder - कि यह मेरे साथ भी तय की।

किसी को भी इस समस्या का स्रोत पता है? यह मुझे अंजीर के साथ हो रहा है। मैं अब मेरे पास pip install fig रहना पसंद करता हूं। यह सब कुछ हफ्ते पहले ठीक था, पता नहीं क्या मेरे सिस्टम पर बदल गया है

मेरा सिस्टम ओपनएसएसएल OpenSSL 0.9.8zc 15 Oct 2014 , मेरा होमब्रेव ओपनसेल नया है लेकिन लिंक नहीं है।

... मैं अनुमान लगा रहा हूं कि जब मैंने अजगर 2.7.9 में अपग्रेड किया तो यह टूट गया था, इसके साथ कुछ एसएसएल संबंधित कीड़े लगते हैं ... बहुत कुछ दिखता है:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196431
http://bugs.python.org/issue23052

brew link --force openssl चलाना और अंजीर को फिर से स्थापित करना मेरे लिए कुछ नहीं कर पाया।

क्या अंजीर को Py 2.7.9 में SSL परिवर्तन के आसपास काम करने के लिए अद्यतन करने की आवश्यकता है?
https://www.python.org/dev/peps/pep-0476/#opting -out

मैं boot2docker का उपयोग कर रहा हूं। मैंने सिर्फ 1.5.0 में अपग्रेड किया लेकिन कोई बदलाव नहीं हुआ।

In [1]: from fig.cli.docker_client import docker_client

In [2]: client = docker_client()

In [3]: client.version()

SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

In [4]: %debug
> /Users/anentropic/.virtualenvs/dpm/lib/python2.7/site-packages/requests/sessions.py(461)request()
    460         send_kwargs.update(settings)
--> 461         resp = self.send(prep, **send_kwargs)
    462

ipdb> p settings
{'verify': '/Users/anentropic/.boot2docker/certs/boot2docker-vm/ca.pem', 'cert': ('/Users/anentropic/.boot2docker/certs/boot2docker-vm/cert.pem', '/Users/anentropic/.boot2docker/certs/boot2docker-vm/key.pem'), 'proxies': {}, 'stream': False}

अंजीर कोड सही लग रहा है, यह boot2docker द्वारा इंस्टॉल किए गए सीट्स का उपयोग करने का प्रयास कर रहा है ... मुझे लगता है कि ये सीट्स ठीक हैं क्योंकि वे हमेशा काम करते थे और मैंने अभी-अभी बी 2 डी को अपग्रेड किया है, इसलिए उन्हें समाप्त नहीं होना चाहिए।

हम्म, मेरा पायथन (होमब्रे के माध्यम से स्थापित) ओपनएसएसएल के होमब्रे संस्करण का उपयोग करते हुए प्रतीत होता है:

$ python -c 'import ssl; print(ssl.OPENSSL_VERSION)'
OpenSSL 1.0.2 22 Jan 2015

$ brew info openssl
openssl: stable 1.0.2 (bottled)
==> Caveats
A CA file has been bootstrapped using certificates from the system
keychain. To add additional certificates, place .pem files in
  /usr/local/etc/openssl/certs

and run
  /usr/local/opt/openssl/bin/c_rehash

... /usr/local/opt/openssl/bin/c_rehash चलने से मदद नहीं मिली :)

मैंने उसी समस्या के साथ $ brew switch python 2.7.8_2 माध्यम से अजगर (2.7.8_2) के पहले से स्थापित संस्करण की कोशिश की (भले ही त्रुटि संदेश थोड़ा अलग था)। तो अजगर 2.7.9 संस्करण समस्या नहीं लगती है।

फिर मैंने एक पुराने ओपनस्ले संस्करण पर स्विच करने की कोशिश की, जो 1.0.2 से 1.0.1j_1 तक काम करता है।

$ python -c 'import ssl; print(ssl.OPENSSL_VERSION)'
OpenSSL 1.0.2 22 Jan 2015
$ docker-compose ps
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
$ brew switch openssl 1.0.1j_1
$ python -c 'import ssl; print(ssl.OPENSSL_VERSION)'
OpenSSL 1.0.1j 15 Oct 2014
$ docker-compose ps
Name   Command   State   Ports 
------------------------------

मेरे लिए मुझे बस एक अलग त्रुटि मिलती है, लेकिन शायद यह संकीर्ण है जो गलत है में मदद करता है:

$ brew switch openssl 1.0.1j_1
Error: openssl does not have a version "1.0.1j_1" in the Cellar.
Versions available: 1.0.1e, 1.0.1f, 1.0.1g, 1.0.2
$ brew switch openssl 1.0.1g
Opt link created for /usr/local/Cellar/openssl/1.0.1g
$ fig up
SSL error: hostname '192.168.59.103' doesn't match 'boot2docker'

OpenSSL 1.0.2 पर वापस जाने से पिछले CERTIFICATE_VERIFY_FAILED त्रुटि पैदा होती है इसलिए बदलते संस्करणों का निश्चित रूप से कुछ प्रभाव पड़ता है

एक कंटेनर में डॉकटर-कम्पोज़ चलाने के लिए एक वर्कअराउंड है:

git clone [email protected]:docker/fig.git
cd fig
docker build --tag docker-compose .

alias docker-compose='docker run --rm -e "DOCKER_TLS_VERIFY=$DOCKER_TLS_VERIFY" -e DOCKER_HOST=tcp://172.17.42.1:2376 -e DOCKER_CERT_PATH=/usr/local/certs -v "$DOCKER_CERT_PATH:/usr/local/certs" -v "$PWD:/code" docker-compose --project-name "${PWD##*/}"'

यह VirtualBox में पोर्ट 2376 उजागर करने की आवश्यकता है:

VBoxManage controlvm boot2docker-vm natpf1 "docker-s,tcp,127.0.0.1,2376,,2376"

@kretz के जवाब ने मेरे लिए काम किया।

+1 @kretz काढ़ा स्विच खुलता है 1.0.1j_1
चाल बना दी

शराब की भठ्ठी खुलता है 1.0.1 मेरे लिए काम करता है (_1 की कमी पर ध्यान दें)

मुझे यह पसंद नहीं है, लेकिन अपने virtualenv से अंजीर को अनइंस्टॉल करना और मेरे लिए homebrew निश्चित चीजों के माध्यम से स्थापित करना

धन्यवाद @kretz - आपके उत्तर ने इसे मेरे लिए हल कर दिया!

यह मेरे लिए काम नहीं करता है क्योंकि:

$ brew switch openssl 1.0.1j_1
Error: openssl does not have a version "1.0.1j_1" in the Cellar.
Versions available: 1.0.2

मेरा काम केवल 2.7.9 के बजाय python 2.7.8 के साथ एक virtualenv बनाना था, जो कि मुझे काढ़ा मिला।

विभिन्न workarounds ... किसी को भी असली समस्या में अंतर्दृष्टि है?

App Engine को कुछ भी करने को क्या मिला है?

11 मार्च 2015 को 18:09 पर, रयान स्मॉल नोटिफिकेशन @ithub.com ने लिखा:

मुझे पूरा यकीन है कि ऐप इंजन का कोई भी सामान अजगर 2.7.9 के साथ काम नहीं करता है

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/docker/compose/issues/890#issuecomment -78329652

@anentropic इससे पहले कि आप इसका उपयोग कर सकें (स्विच करने के लिए) पुराने

# Find available older versions to install
$ brew search openssl
openssl
homebrew/versions/openssl098  homebrew/versions/openssl101

# Install older 1.0.1 version
$ brew install homebrew/versions/openssl101

# See what versions are installed locally
$ brew info openssl
...
/usr/local/Cellar/openssl/1.0.1f (429 files,  15M)
  Built from source
/usr/local/Cellar/openssl/1.0.1i (430 files,  15M)
  Poured from bottle
/usr/local/Cellar/openssl/1.0.1j (431 files,  15M)
  Poured from bottle
/usr/local/Cellar/openssl/1.0.1j_1 (431 files,  15M)
  Poured from bottle
/usr/local/Cellar/openssl/1.0.2 (459 files,  18M)
  Poured from bottle
...

# Switch to one of the 1.0.1 you got installed
$ brew switch openssl 1.0.1j_1

मैंने brew install openssl101 लेकिन इसने मुझे 1.0.1j पर स्विच करने की संभावना नहीं दी ... इसने मुझे 1.0.1l और मुझे चिंता हुई कि यह मेरे सिस्टम को भ्रमित करने वाला था। वे काढ़ा पैकेज अलग कर रहे हैं और मैं पहले से ही समानांतर में 1.0.2 था

मदद करने के लिए प्रतीत नहीं हुआ, लेकिन शायद मैं इसके साथ बहुत दूर नहीं गया था

क्षमा करें, मैंने गलत गितुब मुद्दे पर जवाब दिया (मेरी टिप्पणी को शीघ्रता से हटा दिया गया)
बुध पर, मार्च 11, 2015 को 11:30 पूर्वाह्न एंथ्रोपिक नोटिफिकेशन @github.com पर
लिखा था:

मैंने काढ़ा स्थापित किया है, लेकिन यह मुझे संभावना नहीं देता है
स्विच करने के लिए 1.0.1j ... यह मुझे एक 1.0.1l दिया और मुझे चिंता थी कि यह जा रहा है
मेरे सिस्टम को भ्रमित करें क्योंकि वे अलग-अलग काढ़ा पैकेज हैं और मेरे पास पहले से ही था
समानांतर में 1.0.2

मदद करने के लिए प्रतीत नहीं हुआ, लेकिन शायद मैं इसके साथ बहुत दूर नहीं गया था

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/docker/compose/issues/890#issuecomment -78340580

इसलिए मुझे लगता है कि यह मुद्दा मैक ओएसएक्स पर चल रहा है। Docker- रचना का उपयोग यह मेरी .yml फ़ाइल है।

web:
    build: .
    links:
        - db
        - cache
        - worker
    ports:
        - "8080:8080"
db:
    image: mysql
cache:
    image: redis
worker:
    build: .
    command: celery -A application.extentions worker -l info

docker-compose pull चलने पर मुझे निम्नलिखित आउटपुट मिलते हैं जो विफल रहा।

$ docker-compose pull
Pulling db (mysql:latest)...
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

कुछ चीजें मैंने चेक कीं।
which openssl; openssl version

/usr/local/bin/openssl
OpenSSL 1.0.2 22 Jan 2015

यदि आप काढ़ा के साथ स्थापित करते हैं तो @psykzz काम कर रहा है

brew install docker-compose

@arvindtest आपको क्या लगता है जो इस मुद्दे से संबंधित है?

FYI करें, इसके साथ बहुत संघर्ष करने के बाद, ऐसा प्रतीत होता है कि यह एक बूट 2 डॉकटर मुद्दा है।
मेरे लिए जो काम किया वह था टीएलएस को निष्क्रिय करना। ऐसा करने के लिए अभी तक उपयोगकर्ता के अनुकूल तरीका नहीं है, लेकिन निर्देश यहां दिए गए हैं:
https://github.com/deis/deis/issues/2230

मूल रूप से, आपको निम्न करने की आवश्यकता है:

boot2docker ssh
sudo echo 'DOCKER_TLS = no'> / var / lib / boot2docker / प्रोफाइल

उसके बाद boot2docker को पुनः आरंभ करें, अर्थात
boot2docker बंद करो
boot2docker प्रारंभ

और कुछ इस तरह से अपने ~ / .bashrc (सुनिश्चित करें कि आईपी सही है)

निर्यात DOCKER_HOST = tcp: //192.168.59.103 : 2375
परेशान DOCKER_CERT_PATH
DOCKER_TLS_VERIFY को परेशान करें

आपके bashrc में क्यों न केवल $ (boot2docker shellinit) हो

सब कुछ सही के साथ मदद करनी चाहिए?

मेरा मतलब है कि आपको अभी भी टीएलएस समाधान करना है।
21 मार्च 2015 23:05 को, "coderfi" नोटिफिकेशन @github.com ने लिखा:

FYI करें, इसके साथ बहुत संघर्ष करने के बाद, ऐसा प्रतीत होता है कि यह एक है
boot2docker समस्या।
मेरे लिए जो काम किया वह था टीएलएस को निष्क्रिय करना। अभी तक उपयोगकर्ता के अनुकूल तरीका नहीं है
ऐसा करने के लिए, लेकिन निर्देश यहां दिए गए हैं:
deis / डेस # 2230 https://github.com/deis/deis/issues/2230

मूल रूप से, आपको निम्न करने की आवश्यकता है:

boot2docker ssh
sudo echo 'DOCKER_TLS = no'> / var / lib / boot2docker / प्रोफाइल

उसके बाद boot2docker को पुनः आरंभ करें, अर्थात
boot2docker बंद करो
boot2docker प्रारंभ

और आपके ~ / .bashrc को कुछ इस तरह
सुनिश्चित करें कि आईपी सही है

निर्यात DOCKER_HOST = tcp: //192.168.59.103 : 2375
परेशान DOCKER_CERT_PATH
DOCKER_TLS_VERIFY को परेशान करें

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/docker/compose/issues/890#issuecomment -84468058।

@kretz यह काम करता है! धन्यवाद।

@psykzz का अर्थ है $(boot2docker shellinit) ?

हाँ मैंने किया, मेरी टिप्पणी को अद्यतन किया। Derp।

मैं इस बात की पुष्टि कर सकता हूं कि टीएलएस को निष्क्रिय करने के लिए @coderfi समाधान मेरे लिए काम करता है!

खुशी है कि यह आपके लिए काम करता है। :)

@ मैट हाँ, आप शेल इनिट शेल विस्तार टिप के बारे में सही हैं।
हालाँकि, यह काम नहीं कर सकता है अगर boot2docker अभी तक शुरू नहीं हुआ है, तो मैं बस
उदाहरण स्पष्ट किया।

फाई
26 मार्च, 2015 10:18 पूर्वाह्न पर, "एंथ्रोपिक" सूचनाएँ @ithub.com ने लिखा:

मैं पुष्टि कर सकता हूं कि @coderfi https://github.com/coderfi का समाधान है
अक्षम TLS मेरे लिए काम करता है!

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/docker/compose/issues/890#issuecomment -86630313

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

यह सभी से संबंधित नहीं होगा, लेकिन मुझे pip Dockerfile gliderlabs/alpine:3.1 से खींचने के उपयोग से पॉप अप करने के दौरान एक समान त्रुटि हुई pip स्थापित करने और आवश्यकताओं की फ़ाइल चलाने से पहले पैकेज को स्थापित करके समस्या का निवारण किया गया था:

RUN apk-install -X ca-certificates

सुझाए गए सॉल्यूशंस वास्तव में मेरे लिए काम नहीं करते थे। 1.0.1 ओपनएसएसएल संस्करणों में से किसी पर भी स्विच नहीं किया जा सकता है। अंत में मैंने पाया कि सभी पाइप-इंस्टॉल किए गए डॉक-कंपोज़ संस्करणों को अनइंस्टॉल करना और किसी तरह काम करने पर brew install docker-compose ।

ऊपर दिए गए समाधान काम कर गए लेकिन मेरे लिए बहुत बोझिल थे। एक त्वरित boot2docker upgrade ने मेरे अंत में सब कुछ तय कर दिया।

मेरे पास पहले से ही नवीनतम बूट 2 डॉक संस्करण है और यह मेरे लिए बिना किसी फिक्स के काम नहीं करता है

Homebrew devs सुझाव देते हैं कि docker-py और docker-compose को requests 2.6.0 का उपयोग करके अपग्रेड करना चाहिए

https://github.com/Homebrew/homebrew/issues/38226#issuecomment -84082828

उम्मीद है कि यह किसी को मदद करता है ... एक समाधान के बारे में निश्चित नहीं है लेकिन अगर आप मैक ओएस एक्स प्रॉक्सी के रूप में चार्ल्स का उपयोग कर रहे हैं तो यह इस संदेश का कारण होगा।

एफडब्ल्यूआईडब्ल्यू, पाइप के माध्यम से डॉकटर-कंपोज़ स्थापित करने से डॉकटर-कंपोज़ खुद काम कर रहा है (ओएस एक्स मावरिक्स पर कर्ल के माध्यम से स्थापित करने पर illegal operation त्रुटि हुई)। मुझे बाद में एसएसएल त्रुटि भी मिल रही थी। brew link --force openssl && brew switch openssl 1.0.1j चलना मेरे लिए इसे निश्चित करता है।

@rseymour जवाब ने मेरे लिए काम किया

उन लोगों के लिए जो काढ़ा में openssl-1.0.1j खोजने में विफल रहते हैं - आप जीथब रेपो से खुलने के पुराने संस्करण को हड़प सकते हैं और इसका उपयोग कर सकते हैं:

» brew switch openssl 1.0.1j
Error: openssl does not have a version "1.0.1j" in the Cellar.
Versions available: 1.0.2a-1
» brew unlink openssl
Unlinking /usr/local/Cellar/openssl/1.0.2a-1... 1543 symlinks removed
» brew install https://raw.githubusercontent.com/Homebrew/homebrew/62fc2a1a65e83ba9dbb30b2e0a2b7355831c714b/Library/Formula/openssl.rb
...
🍺  /usr/local/Cellar/openssl/1.0.1j_1: 431 files, 14M, built in 4.2 minutes
» docker-compose up                                                                                                                   
Creating myservice...

मैंने 1.0.1m की कोशिश की, लेकिन यह काम नहीं किया।
तो मैंने @ आलसी तरीके से कोशिश की, यह मेरे लिए काम करता है।
यही मैंने किया है।

काढ़ा स्थापित करें https://raw.githubusercontent.com/Homebrew/homebrew/62fc2a1a65e83ba9db30b2e0a2b7355831c714b/Library/Formula/openssl.rb
काढ़ा स्विच खुलता है 1.0.1j_1
शराब बनाना
काढ़ा लिंक खुलता है - प्रवर्तन
docker- रचना ps

धन्यवाद!!

मैं वर्तमान में इसकी जांच कर रहा हूं, क्योंकि अब हमें पायथन 2.7.9+ पर बायनेरिज़ बनाने की आवश्यकता है।

# 1427_ से हटाए गए

सर्वर:

• कोरोस स्थिर
• डॉकटर 1.5.0

ग्राहक:

• सेंटोस 6.6, 64-बिट
• कर्नेल 2.6.32-042stab105.14
• डॉकर क्लाइंट 1.5.0
• docker- रचना 1.2.0
• SSL प्रमाणपत्र ~/.docker/{ca.pem,cert.pem,key.pem} पर रखा गया है
• DOCKER_HOST=tcp://docker-builder:2376
• DOCKER_TLS_VERIFY=1

SSL प्रमाणपत्र बनाने के लिए निम्न मेकफाइल का उपयोग करना:

#!/bin/bash

SERVER=docker-builder

clean:
    rm ca.* server.* client.* *.key

all: ca.crt server.crt client.crt

%.key:
    openssl genrsa -out $@ 4096

ca.crt: ca.key
    openssl req -new -x509 -days 365 -key ca.key -sha256 -out ca.crt \
        -subj "/C=US/ST=Texas/L=Austin/O=Abc123/OU=Operations/CN=${SERVER}/[email protected]"

server.csr: server.key
    openssl req -new -key server.key -out server.csr \
        -subj "/C=US/ST=Texas/L=Austin/O=Abc123/OU=Operations/CN=${SERVER}/[email protected]"

server.crt: ca.key ca.crt server.csr
    openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key \
        -CAcreateserial -out server.crt

client.csr: client.key
    openssl req -new -key client.key -out client.csr \
        -subj "/C=US/ST=Texas/L=Austin/O=Abc123/OU=Operations/CN=Docker Client/[email protected]"

client.ext.cnf:
    echo "extendedKeyUsage = clientAuth" > client.ext.cnf

client.crt: client.csr ca.crt ca.key client.ext.cnf
    openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key \
        -CAcreateserial -out client.crt -extfile client.ext.cnf

इस मशीन को व्यवस्थित करने के लिए यहां (आदर्श से कम आदर्श) उपयोगकर्ता-डेटा स्क्रिप्ट है:

#cloud-config

write_files:
    - path: /home/core/server.crt
      owner: core:core
      permissions: 0644
      content: |
        -----BEGIN CERTIFICATE-----
        <cert goes here>
        -----END CERTIFICATE-----


    - path: /home/core/server.key
      owner: core:core
      permissions: 0644
      content: |
        -----BEGIN RSA PRIVATE KEY-----
        <key goes here>
        -----END RSA PRIVATE KEY-----


    - path: /home/core/ca.crt
      owner: core:core
      permissions: 0644
      content: |
        -----BEGIN CERTIFICATE-----
        <ca cert goes here>
        -----END CERTIFICATE-----

coreos:
  update:
    reboot-strategy: reboot
  units:
  units:
    - name: var-lib-docker.mount
      command: start
      content: |
        [Unit]
        Description=Mount RAM to /var/lib/docker
        Before=docker.service
        [Mount]
        What=tmpfs
        Where=/var/lib/docker
        Type=tmpfs
        Options=size=200g
    - name: docker.service
      command: restart
      content: |
        [Unit]
        Description=Docker Application Container Engine
        Documentation=http://docs.docker.io
        After=network.target
        [Service]
        ExecStartPre=/bin/mount --make-rprivate /
        # Run docker but don't have docker automatically restart
        # containers. This is a job for systemd and unit files.
        ExecStart=/usr/bin/docker -d \
          --tlsverify \
          --tlscert=/home/core/server.crt \
          --tlscacert=/home/core/ca.crt \
          --tlskey=/home/core/server.key \
          -H 0.0.0.0:2376 -H unix:///var/run/docker.sock

        [Install]
        WantedBy=multi-user.target

docker क्लाइंट का उपयोग करके मुझे दूरस्थ डॉकटर सर्वर तक पहुंचने में अच्छी सफलता मिली है। हम अच्छी सफलता के साथ दिन में सौ हज़ार बार रिमोट सर्वर को कॉल करते हैं।

pip install --upgrade अजगर pip install --upgrade माध्यम से स्थापित docker-compose का उपयोग करने का प्रयास करते हैं, हम एक SSL त्रुटि प्राप्त करते हैं:

$ docker-compose up -d
SSL error: [Errno 1] _ssl.c:504: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

व्यक्तिगत रूप से और साथ में DOCKER_CERT_PATH=/home/user/.docker/ और REQUESTS_CA_BUNDLE=/home/user/.docker/ca.pem निर्दिष्ट करने के बाद यह मामला है।

स्पष्ट होने के लिए: यह सेटअप सिर्फ डॉक डेमॉन के साथ बहुत अच्छा काम करता है, लेकिन -compose बारे में कुछ भी नहीं है।

कुछ नोट:

1. OSX के लिए कंपोजिट 1.3.0 RC1 बाइनरी में यह बग है। संयोग से नहीं, यह पहली बार है जब इसे पायथन 2.7.9 के खिलाफ बनाया गया है - इससे पहले, यह 2.7.6 था।
2. अजीब तरह से, मैं बूट 2docker VM के खिलाफ पुन: पेश कर सकता हूं, लेकिन मशीन द्वारा प्रावधान किए गए वर्चुअलबॉक्स वीएम के खिलाफ नहीं। @ehaletlet , @nathanleclaire , @tianon - कोई अंतर्दृष्टि?
3. पिप के साथ स्थापित होने पर यह अनुभव करने वाले किसी व्यक्ति के लिए, कृपया निम्न आदेशों के आउटपुट की रिपोर्ट करें:

$ python -V $ python -c 'import ssl; print ssl.OPENSSL_VERSION'

अपनी स्थानीय मशीन पर, जहां मैं त्रुटि को पुन: उत्पन्न कर सकता हूं, मेरे पास Python 2.7.10 और OpenSSL 1.0.2a 19 Mar 2015 ।

1. यह Homebrew को सूचित किया गया है, और कुछ लोगों का कहना है कि उन्हें पायथन और ओपनएसएसएल को फिर से स्थापित करने में सफलता मिली है, लेकिन इसने मेरे लिए काम नहीं किया है। https://github.com/Homebrew/homebrew/issues/38226

हम्म जो वास्तव में अजीब है। आप किस वर्जन बनाम b2d के वर्जन का उपयोग कर रहे हैं
मशीन की? हम दोनों b2d का उपयोग करते हैं इसलिए मुझे यकीन नहीं है कि क्या अलग होगा
संस्करण के अलावा।

मैं अपने ओएस एक्स मशीन पर पाइप के माध्यम से स्थापित करूंगा और देखूंगा कि मुझे क्या मिलेगा।

Thu पर, 28 मई, 2015 को 9:19 बजे, Aanand Prasad सूचनाएं @github.com
लिखा था:

कुछ नोट:

1।

OSX के लिए कंपोजिट 1.3.0 RC1 बाइनरी में यह बग है। शायद ऩही
संयोग से, यह पहली बार है जब इसे पायथन 2.7.9 के खिलाफ बनाया गया है

• इससे पहले, यह 2.7.6 था।
  2।

अजीब तरह से, मैं बूट 2docker VM के खिलाफ पुन: पेश कर सकता हूं, लेकिन ए के खिलाफ नहीं
वर्चुअलबॉक्स वीएम मशीन द्वारा प्रावधानित है। @ehazlett
https://github.com/ehazlett , @nathanleclaire
https://github.com/nathanleclaire , @tianon
https://github.com/tianon - कोई अंतर्दृष्टि?
3।

पिप के साथ स्थापित होने पर इसे अनुभव करने वाले किसी को भी, कृपया
निम्नलिखित कमांड के आउटपुट की रिपोर्ट करें:

$ अजगर -वी
$ अजगर -c 'आयात ssl; प्रिंट ssl.OPENSSL_VERSION '

अपनी स्थानीय मशीन पर, जहां मैं त्रुटि को पुन: उत्पन्न कर सकता हूं, मेरे पास पायथन है
2.7.10 और ओपनएसएसएल 1.0.2 ए 19 मार्च 2015।
4।

यह Homebrew को सूचित किया गया है, और कुछ लोगों का कहना है कि उनके पास है
पायथन और ओपनएसएसएल को फिर से स्थापित करना, लेकिन यह मेरे लिए काम नहीं किया है।
Homebrew / homebrew # 38,226
https://github.com/Homebrew/homebrew/issues/38226

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/docker/compose/issues/890#issuecomment -106306690।

$ boot2docker version
Boot2Docker-cli version: v1.6.2
Git commit: cb2c3bc

$ docker-machine --version
docker-machine version 0.2.0 (8b9eaf2)

क्या प्रमाणित पीढ़ी के बारे में कुछ अलग है, हो सकता है? मुझे लगता है कि मेरे बूट 2docker एक की तुलना में मेरे मशीन सर्टिफिकेट में अधिक फाइलें हैं।

$ $(boot2docker shellinit)
$ ls -l $DOCKER_CERT_PATH/*.pem
-rw-r--r--  1 aanand  staff  1042 28 May 14:27 /Users/aanand/.boot2docker/certs/boot2docker-vm/ca.pem
-rw-r--r--  1 aanand  staff  1070 28 May 14:27 /Users/aanand/.boot2docker/certs/boot2docker-vm/cert.pem
-rw-r--r--  1 aanand  staff  1675 28 May 14:27 /Users/aanand/.boot2docker/certs/boot2docker-vm/key.pem

$ eval "$(docker-machine env)"
$ ls -l $DOCKER_CERT_PATH/*.pem
-rw-r--r--  1 aanand  staff  1029 11 May 12:15 /Users/aanand/.docker/machine/machines/dev/ca.pem
-rw-r--r--  1 aanand  staff  1054 11 May 12:15 /Users/aanand/.docker/machine/machines/dev/cert.pem
-rw-r--r--  1 aanand  staff  1679 11 May 12:15 /Users/aanand/.docker/machine/machines/dev/key.pem
-rw-------  1 aanand  staff  1679 11 May 12:15 /Users/aanand/.docker/machine/machines/dev/server-key.pem
-rw-r--r--  1 aanand  staff  1086 11 May 12:15 /Users/aanand/.docker/machine/machines/dev/server.pem

यह ठीक है। ग्राहक सिर्फ ca.pem, cert.pem और key.pem का उपयोग करेगा
(सर्वर मशीन में होस्ट के लिए सिर्फ एक स्थानीय कॉपी है)। मैं जैसा बनाऊंगा
अच्छी तरह से और क्या अंतर हो सकता है देखने के लिए certs का निरीक्षण किया।

Thu पर, 28 मई, 2015 को सुबह 9:30 बजे, Aanand Prasad सूचनाएं @github.com
लिखा था:

$ boot2docker संस्करण
Boot2Docker-cli संस्करण: v1.6.2
Git कमिट: cb2c3bc

$ डॉकटर-मशीन - विसर्जन
डॉकटर-मशीन संस्करण 0.2.0 (8b9eaf2)

क्या प्रमाणित पीढ़ी के बारे में कुछ अलग है, हो सकता है? मुझे और लगता है
मेरे बूट सर्टिफ़िकेट की तुलना में मेरी मशीन सर्फ़र की फाइलें।

$ $ (बूट 2 डॉक शेलिनिट)
$ ls -l $ DOCKER_CERT_PATH / *। pem
-rw-r - r-- 1 अनानंद कर्मचारी १०४२ २27 मई १U:२sers / उर्स / आनंद //boot2docker/certs/boot2docker-vm/ca.pem
-rw-r - r-- 1 आंनद कर्मचारी 1070 28 मई 14:27 /User/aanand/.boot2docker/certs/boot2docker-vm/cert.pem
-rw-r - r-- 1 अनानंद स्टाफ 1675 28 मई 14:27 /User/aanand/.boot2docker/certs/boot2docker-vm/key.pem

$ eval "$ (docker- मशीन एनवी)"
$ ls -l $ DOCKER_CERT_PATH / *। pem
-rw-r - r-- 1 अन्नंद कर्मचारी १०२ ९ ११ मई १२:१५ / उर्स / आनंद / डॉकटर / मचाइन / मचाइन्स / देवा / क.पेम
-rw-r - r-- 1 अनानंद कर्मचारी १०५४ ११ मई १२:१५ /User/aanand/.docker/machine/machines/dev/cert.pem
-rw-r - r-- 1 अन्नंद कर्मचारी १६ May ९ ११ मई १२:१५ / उर्स / आनंद / डॉक / मचाईन / मचाइन्स / देवा / की.पेम
-rw ------- १ आंनद कर्मचारी १६ May ९ ११ मई ११:१५ / उर्स / आनंद / डोजर / मचाइन / मचाइन्स / देवर / सेवर-key.pem
-rw-r - r-- 1 अनानंद कर्मचारी १० May६ ११ मई १२:१५/User/aanand/.docker/machine/machines/dev/server.pem

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/docker/compose/issues/890#issuecomment -106309885

grahamc@snap$ python -V
Python 2.7.6

grahamc@snap$ python -c 'import ssl; print ssl.OPENSSL_VERSION'
OpenSSL 1.0.1e-fips 11 Feb 2013

Https://github.com/docker/docker-py/issues/465 भी @garethr का परीक्षण स्क्रिप्ट होस्टनाम जाँच को अक्षम करने के लिए एक संशोधन करने के बाद, मेरे लिए भी त्रुटि को पुन: पेश करता है:

from docker.client import Client
from docker.utils import kwargs_from_env

kwargs = kwargs_from_env()
kwargs['tls'].assert_hostname = False

client = Client(**kwargs)
print client.version()

$ eval "$(boot2docker shellinit)" && python test.py
Writing /Users/aanand/.boot2docker/certs/boot2docker-vm/ca.pem
Writing /Users/aanand/.boot2docker/certs/boot2docker-vm/cert.pem
Writing /Users/aanand/.boot2docker/certs/boot2docker-vm/key.pem
Traceback (most recent call last):
  File "test.py", line 8, in <module>
    print client.version()
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", line 1108, in version
    return self._result(self._get(url), json=True)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", line 106, in _get
    return self.get(url, **self._set_request_timeout(kwargs))
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", line 477, in get
    return self.request('GET', url, **kwargs)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", line 465, in request
    resp = self.send(prep, **send_kwargs)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", line 573, in send
    r = adapter.send(request, **kwargs)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", line 431, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)

यह अभी भी मशीन-प्रावधानित VM के साथ काम करता है, हालांकि:

$ eval "$(docker-machine env)" && python test.py
{u'KernelVersion': u'4.0.3-boot2docker', u'Arch': u'amd64', u'ApiVersion': u'1.18', u'Version': u'1.6.2', u'GitCommit': u'7c8fca2', u'Os': u'linux', u'GoVersion': u'go1.4.2'}

यदि मैं होस्टनाम चेकिंग (टेस्ट स्क्रिप्ट में assert_hostname लाइन टिप्पणी करके) को फिर से सक्षम करता हूं, तो यह बूट 2docker-cli VM के खिलाफ एक ही त्रुटि के साथ विफल रहता है, लेकिन मशीन VM के खिलाफ एक अलग त्रुटि , जो या प्रासंगिक नहीं हो सकता है:

Traceback (most recent call last):
  File "test.py", line 8, in <module>
    print client.version()
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", line 1108, in version
    return self._result(self._get(url), json=True)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", line 106, in _get
    return self.get(url, **self._set_request_timeout(kwargs))
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", line 477, in get
    return self.request('GET', url, **kwargs)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", line 465, in request
    resp = self.send(prep, **send_kwargs)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", line 573, in send
    r = adapter.send(request, **kwargs)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", line 431, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: no appropriate commonName or subjectAltName fields were found

इसके अतिरिक्त मैंने कर्ल के माध्यम से v1.3.0-आरसी 1 (द्विआधारी रिलीज, पाइप के माध्यम से नहीं) का उपयोग करने की कोशिश की और डॉक 1.6.2 डेमन पर पहले की तरह ही त्रुटि मिली:

SSL error: [Errno 1] _ssl.c:507: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

हाँ - RC1 बाइनरी पाइथन 2.7.9 और ओपनएसएसएल 1.0.2 ए के साथ बनाया गया था, जो समस्याग्रस्त संयोजनों में से एक लगता है।

यह समझ में आता है क्योंकि मेरा मानना ​​है कि b2d में प्रमाणित पीढ़ी वीएम पर है
जबकि मशीन उन्हें मशीन में उत्पन्न करती है। हम पता लगा सकते हैं और जोड़ सकते हैं
जरूरत पड़ने पर सैन को मशीन का नाम। वास्तव में यह शायद अच्छा होगा
विशेष रूप से b2d VMs के लिए। कारण यह काम करता है अब मुझे लगता है क्योंकि आप है
आईपी ​​का उपयोग करके इंजन का उपयोग करें जो मशीन एक आईपी सैन के रूप में जोड़ता है। वहां एक है
पीआर मनमाने ढंग से अतिरिक्त SANs की अनुमति के लिए खुला है जो भी काम करेगा।

गुरुवार, 28 मई, 2015 को, आनंद प्रसाद नोटिफिकेशन @ithub.com ने लिखा:

डॉकटर / docker-py # 465 भी देखें
https://github.com/docker/docker-py/issues/465। @garethr
https://github.com/garethr की परीक्षण स्क्रिप्ट वहाँ के लिए त्रुटि पुन: पेश करती है
मुझे भी, होस्टनाम जाँच को अक्षम करने के लिए एक संशोधन करने के बाद:

docker.client आयात से Clientfrom docker.utils आयात kwargs_from_env

kwargs = kwargs_from_env ()
kwargs ['tls']। assert_hostname = गलत

ग्राहक = ग्राहक (** kwargs) ग्राहक को प्रिंट करें।

$ eval "$ (boot2docker shellinit)" और& python test.py
राइटिंग / यूजर्स / आनंद / बी.बी .2 डॉकटर / वेटर / बीओटी 2 डॉकटर- एमएम / एनएपी।
लिखना
राइटिंग / यूजर्स / आनंद / बी.बी .2 डॉकटर / वेटर / बीओटी 2 डॉकटर- एमएम / एसकेपी। पेम
ट्रेसबैक (सबसे हालिया कॉल अंतिम):
फ़ाइल "test.py", पंक्ति 8, में
ग्राहक प्रिंट करें।
फ़ाइल "/User/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", लाइन 1108, संस्करण में
स्वंय वापस लौटें। स्वयंसिद्धा (आत्म.गेट (url), json = True)
फ़ाइल "/User/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", पंक्ति 106, _get में
स्वंय लौटें (url, * _self._set_request_timeout (kwargs))
फ़ाइल "/User/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/session.py", पंक्ति 477, प्राप्त करें
स्व वापस लौटें। ('प्राप्त करें', url, * _kwargs)
अनुरोध में फ़ाइल "/User/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/session.py", पंक्ति 465
सम्मान = स्व.सेंड (प्रस्तुत करने का, * _send_kwargs)
फ़ाइल "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/session.py", पंक्ति 573, भेजें में
r = adapter.send (अनुरोध, * _kwargs)
फ़ाइल "/User/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", पंक्ति 431, भेजें में
SSLError बढ़ाएँ (e, request = अनुरोध)
request.exception.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] प्रमाणपत्र सत्यापित विफल रहा

यह अभी भी मशीन-प्रावधानित VM के साथ काम करता है, हालांकि:

$ eval "$ (docker-machine env)" && python test.py
{u'KernelVersion ': u'4.0.3-boot2docker', u'Arch ': u'amd64', u'ApiVersion ': u'1.18', u'Version ': u'1.6.2.2', u'GitCommit ': u'7c8fca2', u'Os ': u'linux', u'GoVersion ': u'go1.4.2'}

अगर मैं होस्टनाम चेकिंग को पुनः सक्षम करता हूं (assert_hostname टिप्पणी करके)
परीक्षण स्क्रिप्ट में लाइन), यह _same error_ के खिलाफ विफल रहता है
boot2docker-cli VM, लेकिन मशीन VM के खिलाफ एक _different error_, जो
प्रासंगिक हो सकता है या नहीं:

ट्रेसबैक (सबसे हालिया कॉल अंतिम):
फ़ाइल "test.py", पंक्ति 8, में
ग्राहक प्रिंट करें।
फ़ाइल "/User/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", लाइन 1108, संस्करण में
स्वंय वापस लौटें। संदेश (self._get (url), json = True)
फ़ाइल "/User/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", पंक्ति 106, _get में
स्वंय लौटें (url, * _self._set_request_timeout (kwargs))
फ़ाइल "/User/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/session.py", पंक्ति 477, प्राप्त करें
स्व वापस लौटें। ('प्राप्त करें', url, * _kwargs)
अनुरोध में फ़ाइल "/User/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/session.py", पंक्ति 465
सम्मान = स्व.सेंड (प्रस्तुत करने का, * _send_kwargs)
फ़ाइल "/User/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/session.py", पंक्ति 573, भेजें में
r = adapter.send (अनुरोध, * _kwargs)
फ़ाइल "/User/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", पंक्ति 431, भेजें में
SSLError बढ़ाएँ (e, request = अनुरोध)
request.exception.SSLError: कोई उपयुक्त सामान्य नाम या विषय नहीं है जैसे फ़ील्ड मिले थे

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/docker/compose/issues/890#issuecomment -106363305।

ठीक है, मुझे विश्वास है कि मैं ओएस एक्स के लिए एक फिक्स पर आया हूं: https://github.com/docker/compose/pull/1474

लिनक्स के लिए इसे ठीक करने में पाइकॉन 2.7.9 और ओपनएसएसएल 1.0.1 को पिन करने के लिए डॉकरफाइल को अपडेट करना शामिल होगा, जो एक मजेदार प्रयास होगा जो इसे debian:wheezy से शुरू होता है (जो यह सुनिश्चित करता है कि हम एक पर्याप्त उपयोग कर रहे हैं। पुराने glibc - https://github.com/docker/compose/pull/505 देखें)।

@Kretz की टिप्पणी में वर्णित के रूप में 1.0.1k पर स्विच करना और पाइप के माध्यम से 1.3.0 RC1 को स्थापित करना मेरे लिए ट्रिक था।

स्विच करने से पहले अजगर ने 1.0.2a की सूचना दी:

❯ python -c 'import ssl; print ssl.OPENSSL_VERSION'
OpenSSL 1.0.2a 19 Mar 2015

स्विच करने के बाद रिपोर्ट किया गया 1.0.1k और docker-compose अपेक्षा के अनुसार काम करता है:

❯ python -c 'import ssl; print ssl.OPENSSL_VERSION'
OpenSSL 1.0.1k 8 Jan 2015

इस त्रुटि को दूर करने वाला एक वर्कअराउंड पैकेज मेरे virtualenv में स्थापित करना था
pip install pyopenssl==0.14 ndg-httpsclient==0.4 pyasn1==0.1.7

Https://github.com/docker/compose/issues/890#issuecomment -106289821 पर वर्णित वातावरण में जो Python 2.7.6 (Snap-ci.com के माध्यम से, जिसे आप मुफ्त खाता प्राप्त कर सकते हैं) प्रदान करता है।

निम्नलिखित स्क्रिप्ट के साथ जो @ jsh2134 के वर्कपॉइंट का उपयोग एक पाइप स्थापित (https://github.com/docker/compose/issues/890#issuecomment-106806702) में करता है:

#!/bin/bash

set -e
set -u
set -x


readonly DOCKER_VERSION=1.5.0
readonly TARGETFILE=$SNAP_CACHE_DIR/docker-$DOCKER_VERSION
[[ -f "$TARGETFILE" ]] || curl https://get.docker.io/builds/Linux/x86_64/docker-$DOCKER_VERSION > $TARGETFILE
cp $TARGETFILE ~/docker
chmod +x ~/docker


export DOCKER_HOST="tcp://docker-builds:2376" DOCKER_TLS_VERIFY=1

mkdir -p ~/.docker
cat > ~/.docker/ca.pem <<EOC
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

EOC
cat > ~/.docker/key.pem <<EOC
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

EOC
cat > ~/.docker/cert.pem <<EOC
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
EOC

function install_docker_compose {
  pip install --upgrade pip
  pip install --upgrade docker-compose
  pip install pyopenssl==0.14 ndg-httpsclient==0.4 pyasn1==0.1.7
  export COMPOSE=docker-compose
}

install_docker_compose

export COMPOSE_PROJECT_NAME=$(basename "$(pwd)")-${SNAP_COMMIT:-HEAD}

# Before running anything, setup the EXIT trap to always rm the container on
# exit of the script.
function cleanup {
  $COMPOSE kill
  $COMPOSE rm --force
}

trap cleanup EXIT

$COMPOSE --version
$COMPOSE build
$COMPOSE up -d

set +e
$COMPOSE run $@
exitcode=$?
set -e

set +x
echo ""
echo "Component Data:"
for id in `$COMPOSE ps -q`; do
  ~/docker inspect \
    -f 'Container {{ .Name }} exited with status {{ .State.ExitCode }}' $id
  ~/docker logs $id 2>&1 | sed -e "s/^/        /"
  echo "---"
done

exit $exitcode

मुझे निम्न आउटपुट मिले:

+ readonly DOCKER_VERSION=1.5.0
+ DOCKER_VERSION=1.5.0
+ readonly TARGETFILE=/var/go/docker-1.5.0
+ TARGETFILE=/var/go/docker-1.5.0
+ [[ -f /var/go/docker-1.5.0 ]]
+ cp /var/go/docker-1.5.0 /var/go/docker
+ chmod +x /var/go/docker
+ export DOCKER_HOST=tcp://docker-builds:2376 DOCKER_TLS_VERIFY=1
+ DOCKER_HOST=tcp://docker-builds:2376
+ DOCKER_TLS_VERIFY=1
+ mkdir -p /var/go/.docker
+ cat
+ cat
+ cat
+ install_docker_compose
+ /bin/true
+ pip install --upgrade pip
/var/go/py-virtualenv2.7/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Collecting pip
  Using cached pip-7.0.1-py2.py3-none-any.whl
Installing collected packages: pip
  Found existing installation: pip 6.0.8
    Uninstalling pip-6.0.8:
      Successfully uninstalled pip-6.0.8
Successfully installed pip-7.0.1
+ pip install --upgrade docker-compose
/var/go/py-virtualenv2.7/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Requirement already up-to-date: docker-compose in /var/go/py-virtualenv2.7/lib/python2.7/site-packages
Requirement already up-to-date: docopt<0.7,>=0.6.1 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: PyYAML<4,>=3.10 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: requests<2.6,>=2.2.1 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: texttable<0.9,>=0.8.1 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: websocket-client<1.0,>=0.11.0 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: docker-py<1.2,>=1.0.0 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: dockerpty<0.4,>=0.3.2 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: six<2,>=1.3.0 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: backports.ssl-match-hostname in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from websocket-client<1.0,>=0.11.0->docker-compose)
+ pip install pyopenssl==0.14 ndg-httpsclient==0.4 pyasn1==0.1.7
Collecting pyopenssl==0.14
/var/go/py-virtualenv2.7/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
  Downloading pyOpenSSL-0.14.tar.gz (128kB)
Collecting ndg-httpsclient==0.4
  Downloading ndg_httpsclient-0.4.0.tar.gz
Collecting pyasn1==0.1.7
  Downloading pyasn1-0.1.7.tar.gz (68kB)
Collecting cryptography>=0.2.1 (from pyopenssl==0.14)
  Downloading cryptography-0.9.tar.gz (302kB)
Requirement already satisfied (use --upgrade to upgrade): six>=1.5.2 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from pyopenssl==0.14)
Collecting idna (from cryptography>=0.2.1->pyopenssl==0.14)
  Downloading idna-2.0.tar.gz (135kB)
Requirement already satisfied (use --upgrade to upgrade): setuptools in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from cryptography>=0.2.1->pyopenssl==0.14)
Collecting enum34 (from cryptography>=0.2.1->pyopenssl==0.14)
  Downloading enum34-1.0.4.tar.gz
Collecting ipaddress (from cryptography>=0.2.1->pyopenssl==0.14)
  Downloading ipaddress-1.0.7-py27-none-any.whl
Collecting cffi>=0.8 (from cryptography>=0.2.1->pyopenssl==0.14)
  Downloading cffi-1.0.3.tar.gz (317kB)
Collecting pycparser (from cffi>=0.8->cryptography>=0.2.1->pyopenssl==0.14)
  Downloading pycparser-2.13.tar.gz (299kB)
Installing collected packages: idna, pyasn1, enum34, ipaddress, pycparser, cffi, cryptography, pyopenssl, ndg-httpsclient
  Running setup.py install for idna
  Running setup.py install for pyasn1
  Running setup.py install for enum34
  Running setup.py install for pycparser
  Running setup.py install for cffi
  Running setup.py install for cryptography
  Running setup.py install for pyopenssl
  Running setup.py install for ndg-httpsclient
Successfully installed cffi-1.0.3 cryptography-0.9 enum34-1.0.4 idna-2.0 ipaddress-1.0.7 ndg-httpsclient-0.4.0 pyasn1-0.1.7 pycparser-2.13 pyopenssl-0.14
+ export COMPOSE=docker-compose
+ COMPOSE=docker-compose
+++ pwd
++ basename /var/snap-ci/repo/tests/composer
+ export COMPOSE_PROJECT_NAME=composer-a71ac4f39281a9571a2b5da1284ab1c05da40646
+ COMPOSE_PROJECT_NAME=composer-a71ac4f39281a9571a2b5da1284ab1c05da40646
+ trap cleanup EXIT
+ docker-compose --version
docker-compose 1.2.0
+ docker-compose build
test1 uses an image, skipping
test2 uses an image, skipping
test uses an image, skipping
+ docker-compose up -d
SSL error: [Errno bad handshake] [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')]
+ cleanup
+ docker-compose kill
SSL error: [Errno bad handshake] [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')]

विशेष रूप से त्रुटि पर ध्यान दें (जो नया लगता है):

/var/go/py-virtualenv2.7/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.

मेरे निष्कर्षों को अभी तक मस्तिष्क में डंप करने के लिए https://github.com/docker/compose/issues/1484 बनाया गया।

मैंने # 1474 में फिक्स के साथ कुछ बायनेरिज़ का निर्माण किया है। यदि आप SSL समस्याओं का सामना कर रहे हैं, तो कृपया उन्हें आज़माएं:

http://cl.ly/3W3a2S3t2c32/download/docker-compose-Linux-x86_64
http://cl.ly/0i00310l3x27/download/docker-compose-Darwin-x86_64

+ curl -L http://cl.ly/3W3a2S3t2c32/download/docker-compose-Linux-x86_64
+ /usr/bin/docker-compose --version
docker-compose version: 1.3.0rc1
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013

+ /var/go/docker-compose up -d
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

@ jsh2134 क्यों आप 0.14 को pyOpenSSL पिन कर रहे हैं?

@Kretz उत्तर के लिए +1 :)

+1 वही मुद्दा :( ऐसा लगता है जैसे ऑस्कर पूरी तरह से ओएक्सएक्स पर टूट गया है?

@coderfi समाधान ने मेरे लिए काम किया: विंडोज 7 docker- रचना Cygwin में पाइप के माध्यम से स्थापित

एक Centos7 VM पर विभिन्न प्रकार की त्रुटियों से निपटना, जो एक डॉकटर-मशीन पर कंटेनर शुरू करने के लिए एक ग्राहक के रूप में कार्य कर रहा है:

[ रूट @ xxxx सेमी] # डॉक-कम्पोज़ पीएस
एसएसएल त्रुटि: कोई उपयुक्त सामान्य नाम या विषय नहीं मिला

यह क्षणिक हुआ करता था; मैं लॉग आउट कर सकता हूं, वापस ssh और कुछ समय के लिए त्रुटि नहीं देख सकता हूं। अब इसे हमेशा देखना।

[ रूट @ xxxx सेमी] # अजगर-सी 'आयात ssl; प्रिंट (ssl.OPENSSL_VERSION) '
OpenSSL 1.0.1e-fips 11 फ़रवरी 2013

[ रूट @ xxxx सेमी] # डॉक वर्जन
ग्राहक संस्करण: 1.6.2
क्लाइंट एपीआई संस्करण: 1.18
गो संस्करण (ग्राहक): go1.4.2
Git कमिट (ग्राहक): ba1f6c3 / 1.6.2
OS / Arch (क्लाइंट): linux / amd64
सर्वर संस्करण: झुंड / 0.2.0
गो संस्करण (सर्वर): go1.3.3
Git कमिट (सर्वर): 48fd993
OS / Arch (सर्वर): linux / amd64

[ रूट @ xxxx सेमी] # डॉकटर-कंपोज़ --version
docker- रचना 1.2.0

मुझे यकीन नहीं है कि मेरे वातावरण में ऊपर दिए गए कुछ सुधारों को कैसे लागू किया जाए। मैं boot2docker का उपयोग नहीं कर रहा हूं; बैश कमांड लाइन पर दाईं ओर 1.6.2 से निपटना।

नमस्ते। मैंने वास्तव में इस बात के लिए एक मुद्दा खोला कि मैं इसे ठीक नहीं कर सकता। मैंने बहुत सी चीजों की कोशिश की है अर्थात पाइप / ब्रू / न्यूस्ट वर्जन के साथ कम्पोज़ स्थापित करें। Opensl के समान ही 0.x 1.0.2x संस्करण आदि की कोशिश की और अभी भी काम नहीं कर रहा है।

पुनश्च: मैं boot2docker का उपयोग नहीं करता। मेरा अपना वीएम है जिसे मैं योनि के माध्यम से बनाता हूं, सीरेट्स उत्पन्न करता हूं और उनके साथ डॉकटर डेमन को लॉन्च करता हूं। जाहिरा तौर पर यह docker के साथ काम करता है इसलिए समस्या मेरे प्रमाण पत्र से नहीं आती है।

>>> docker run hello-world
Hello from Docker.
[...]
>>> docker-compose up
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
>>> docker-compose -v
docker-compose version: 1.3.1
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1j 15 Oct 2014
>>> docker -v
Docker version 1.6.2, build 7c8fca2

एक समय में यह त्रुटि मिली:

/usr/local/Cellar/fig/1.3.1/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
SSL error: [Errno 1] _ssl.c:507: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

यहाँ पढ़ने के बाद और सुझाए गए पैकेजों को स्थापित करने के साथ mucking:

https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning

डॉकटर-कंपोज़ से त्रुटि संदेश बदल गया है:

[ रूट @ xxx सेमी] # डॉक-कम्पोज़ अप -d
/usr/lib/python2.7/site-packages/requests/packages/urllib3/connection.py:251: SecurityWarning: प्रमाण पत्र में कोई subjectAltName , वापस गिरने एक जांच करने के लिए commonName के लिए अभी। यह सुविधा प्रमुख ब्राउज़रों द्वारा निकाली जा रही है और RFC 2818 द्वारा अपग्रेड की गई है। (विवरण के लिए https://github.com/shazow/urllib3/issues/497 देखें।)
सुरक्षा चेतावनी
SSL त्रुटि: होस्टनाम 'xx.xx.xx.xx' किसी से मेल नहीं खाता

(बिंदीदार क्वाड I xx'd बाहर झुंड मास्टर / docker होस्ट का है)।

क्या प्रमाण पत्र को संपादित या पुनर्जीवित करके भी इस समस्या का समाधान किया जा सकता है?

परिशिष्ट: इन वीएम पर प्रमाण पत्र "docker-machine create" द्वारा बनाए गए थे।

क्या हम डॉक-मशीन में एक बग के साथ काम कर सकते हैं जिसके परिणामस्वरूप एक अपर्याप्त विस्तृत प्रमाण पत्र है?

मैं केवल डॉकर-होस्ट बनाए गए डॉकटर-मशीन के साथ इस त्रुटि को देख रहा हूं। मेरा मानना ​​है कि एसएसएल सीट्स ठीक से नहीं बन रहे हैं?

किसी को भी यह ठीक करने के लिए एक काम के आसपास या एक घुला हुआ पदार्थ है? यह मेरे लिए अभी एक अवरोधक का एक सा है: /

@prologic क्या आपको बाइनरी के साथ या पिप-संस्थापित requests[security] स्थापित करने का प्रयास करता है।

@आनंद धन्यवाद! मैं कोशिश करूँगा और रिपोर्ट करूँगा कि काम करता है या नहीं!

@prologic हम पायथन के बग्गी एसएसएल मॉड्यूल पर निर्भर होने के बजाय requests[security] पैकेज करना चाहते हैं; हम # 1530 में प्रयास पर नज़र रख रहे हैं।

@आनंद धन्यवाद! यह पूरी तरह से काम किया :)

@coderfi आपके समाधान ने मेरे लिए काम किया, धन्यवाद

@ आनंद 2 जून निर्माण मेरे लिए ठीक काम करता है। इस दर्दनाक बग को दूर करने के लिए शुभकामनाएँ।

@neilsarkar मैं

मैं ओएस एक्स 10.9.5 का उपयोग कर रहा हूं, यहां मेरा बहुत ध्यान है:

# ➜  openssl version
# OpenSSL 1.0.2d 9 Jul 2015

➜  pyenv local system # switch to built-in python 2.7.5 for current directory
# ➜  python --version
# Python 2.7.5
# ➜  python -c 'import ssl; print(ssl.OPENSSL_VERSION)'
# OpenSSL 0.9.8zd 8 Jan 2015

# ➜  docker-compose --version
# docker-compose version: 1.3.1
# CPython version: 2.7.5
# OpenSSL version: OpenSSL 0.9.8zd 8 Jan 2015

# ➜  docker-compose ps
# /usr/local/Cellar/fig/1.3.1/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
#   InsecurePlatformWarning
# Name   Command   State   Ports
# ------------------------------

मेरा समाधान:

246: 253 की पंक्तियों में टिप्पणी करें
/usr/local/Cellar/fig/1.3.1/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connection.py

यह वह हिस्सा है जो सुरक्षा अपवाद को फेंक रहा है

मेरे लिए समस्या यह थी कि यहां तक ​​कि आपने मुझे काढ़ा लिंक निर्दिष्ट किया --फोर्स ओपनसेल, अंजीर / डोकर-कम्पोज अभी भी उपयोग करता है / यूएसआर / बिन / ओपनसेल।

$ sudo mv /usr/bin/openssl /usr/bin/openssl_old
$ brew link --force openssl OR brew unlink openssl && brew link --force openssl

इसने मेरे लिए काम किया। अब मुझे परेशान करने वाला मैसेज नहीं आता।

FYI करें, काढ़ा अंजीर / docker-compose रेसिपी सिस्टम python का उपयोग करता है, इसलिए यदि आप pythv को pyenv या brew के माध्यम से स्थापित करते हैं, तो भी brew / fig / docker-compose स्थापित करें फिर भी यदि उपलब्ध हो, तो सिस्टम opensl lib का उपयोग करेगा, अन्यथा, इसका कुछ अन्य संस्करण स्थापित करना।

काम पर मेरे मैक पर मैंने इसे pyenv के साथ हल किया 2.7.8 स्थापित, फिर easy_install पाइप, और पाइप स्थापित docker- रचना।

लेकिन घर पर मेरे मैक पर, "दोनों रनिंग योसमाइट" मैंने वही किया है और अभी भी चेतावनी प्राप्त कर रहा हूं।

खुदाई करते रहेंगे।

@dtunes - मूल कारण ( @aanand ऊपर संदर्भित) https://github.com/boot2docker/boot2docker/issues/808 है। सिस्टम-पाइथन / होमब्रेव-पाइथन चीज़ एक लाल हेरिंग है, क्योंकि यह सिर्फ इस बात पर निर्भर करता है कि आप नए या पुराने ओपनएसएसएल से जुड़े हैं या नहीं।

हां, मैंने वह टिकट देखा। जो चीज मुझे परेशान कर रही है, वह यह है कि मेरे मैक पर काम करने के बाद, अलग-अलग तरीकों से कोशिश करने के बाद भी कोई काम नहीं किया गया।
फिर मैं / usr / bin / खुलने का समय बढ़ाता / usr / bin / opensl_old करता गया, होम ओपन का उपयोग कर नवीनतम खुलने वाले को स्थापित किया और इसे लिंक किया। तभी मैंने निम्नलिखित कार्य किया:

~ $ brew install pyenv
~ $ pyenv install 2.7.8
~ $ pyenv global 2.7.8
~ $ easy_install pip
~ $ pip install docker-compose

यह मेरे घर पर मैक पर काम पर चाल चली, हालांकि, यह काम नहीं किया। लेकिन मैं फिर से कोशिश करूँगा कि मैं एक गलती करूँ और परिणाम वापस रिपोर्ट करूँ।

@dtunes - अपने सभी निर्भरता को फिर से बनाने के लिए आपको ~/Library/Caches/pip निकालने की आवश्यकता है ताकि गलत ओपनएसएसएल के खिलाफ निर्मित कैश्ड बाइनरी व्हील फिर से उपयोग न हो।

@glyph ने लिखा :

मूल कारण (जैसा कि @aanand ऊपर बताया गया है) boot2docker / boot2docker # 808 है। सिस्टम-पाइथन / होमब्रेव-पाइथन चीज़ एक लाल हेरिंग है, क्योंकि यह सिर्फ इस बात पर निर्भर करता है कि आप नए या पुराने ओपनएसएसएल से जुड़े हैं या नहीं।

@glyph या @aanand , क्या यह सुझाव देता है कि # 1474 से विलय किया गया @aand का फ़िक्स (काम के आस-पास) केवल टूटे हुए b2d को समायोजित करता है? @आनंद , अगर boot2docker / boot2docker # 808 को ठीक से संबोधित किया जाता है, तो # 1474 का समर्थन किया जाना चाहिए? अगले में आशा दे रहा है क्रिप्टोग्राफी रिहाई (देखें इस और इस भी एक रेड हेरिंग)?

@ आनंद ने लिखा :

ध्यान दें कि मैं इस त्रुटि को पुन: उत्पन्न नहीं कर सकता बूट 2 डॉक वीएम के लिए डॉकटर-मशीन के साथ प्रावधान किया गया है - यह केवल बूट 2 डॉक कमांड के साथ एक वीएम के प्रावधान के खिलाफ होता है।

@ehazlett ने लिखा :

यह समझ में आता है क्योंकि मेरा मानना ​​है कि b2d में प्रमाणित पीढ़ी वीएम पर है जबकि मशीन उन्हें मशीन में उत्पन्न करती है।

मुझे गलतफहमी हो सकती है, लेकिन इस और संबंधित मुद्दों के लिए विभिन्न होस्ट-साइड पायथन / ओपनएसएसएल संयोजनों को दोषी ठहराते हुए बहुत सारी बकवास है। यदि समस्या का स्रोत b2d के साथ वितरित एक टूटा हुआ ओपनएसएसएल है, तो मुझे यकीन नहीं है कि सबसे अच्छा तरीका यह सुनिश्चित कर रहा है कि कम्पोज़ की मेजबान-साइड ओपनएसएसएल समान रूप से टूटी हुई है? जो इसके लायक है, उसके लिए इस प्रकार के होस्ट-साइड कॉन्ट्रोवर्सीज़ उन लोगों के लिए इस समस्या को हल करने की संभावना नहीं है जो बी 2 डी चलाते हैं (जैसे) वैग्रंट, और इसे कंपोज़ के बाहर एक्सेस करते हैं (देखें, उदाहरण के लिए, docker / docker-py (465 )।

यदि यह टिप्पणी boot2docker / boot2docker # 808 में अधिक उपयुक्त है, तो मैं इसे वहां स्थानांतरित कर सकता हूं।

मैं एक Homebrew अनुचर हूँ और मैंने इसे नीचे चलाने में ग्लिफ़ की मदद की।

Boot2docker द्वारा सृजित सर्वर सर्टिफिकेट के विषय और जारीकर्ता डीएन की पहचान /O=Boot2Docker । मेरा मानना ​​है कि सर्वर सर्टिफिकेट वास्तव में CA सर्टिफिकेट पर हस्ताक्षरित है, लेकिन AFAICT OpenSSL 1.0.2 इस जानकारी (यानी समरूप सब्जेक्ट और जारीकर्ता डीएन) का उपयोग करता है ताकि सर्वर सर्टिफिकेट को स्व-हस्ताक्षरित के बजाय सर्वर सर्टिफिकेट को सत्यापित करने के लिए अस्वीकार कर दिया जाए। सीए सर्टिफिकेट। 1.0.2 से पहले ओपनएसएसएल के संस्करण प्रदान किए गए सीए प्रमाणपत्र के खिलाफ सर्वर प्रमाणपत्र को मान्य करते हैं, जो सफल होता है।

मेरा मानना ​​है कि लेकिन यह परीक्षण नहीं किया है कि सर्वर और CA सर्टिफिकेट को अलग-अलग सब्जेक्ट डीएन (ताकि सर्टिफिकेट सर्टिफिकेट में अलग-अलग सब्जेक्ट्स और इशूअर डीएन हों) देने से सर्टिफिकेट सभी ओपनएसएसएल वर्जन के तहत मान्य हो जाएंगे। मुझे संदेह है ( इस X.509 उत्तरजीविता मार्गदर्शिका के मेरे पढ़ने के आधार पर लेकिन किसी भी संबंधित विनिर्देश नहीं), लेकिन मुझे विश्वास नहीं है, कि OpenSSL 1.0.2 का व्यवहार उचित है और एक प्रतिगमन का प्रतिनिधित्व नहीं करता है जिसे OpenSSL डेवलपर्स द्वारा हल किया जाना चाहिए।

1474 दो अलग बातें करता है:

• 2.7.9 पर एक न्यूनतम पायथन संस्करण की स्थापना: यह urllib3 को InsecurePlatformWarning को जारी किए बिना अनुरोधों को पूरा करने की अनुमति देता है, जो HTTPS कनेक्शन बनाते समय जारी किया जाता है यदि दोनों दो शर्तें पूरी होती हैं: पायथन संस्करण 2.7.9 से पहले है, और PyOpenSSL मॉड्यूल मौजूद नहीं है। बंडलिंग PyOpenSSL समान रूप से प्रभावी होगा लेकिन मैं इस चर्चा से समझता हूं कि यह PyInstaller के साथ संगत नहीं है। किसी भी तरह से, urllib3 का InsecurePlatformWarning boot2docker प्रमाणपत्र समस्या से संबंधित नहीं है, और प्रमाणपत्रों को ठीक करने से इस समाधान की आवश्यकता नहीं है।
• 1.0.1j पर अधिकतम ओपनएसएसएल संस्करण सेट करना। मेरा मानना ​​है कि boot2docker प्रमाणपत्र तय होने के बाद यह अनावश्यक होना चाहिए।

यदि समस्या का स्रोत b2d के साथ वितरित एक टूटा हुआ ओपनएसएसएल है

यह नहीं; Open2L boot 1.0.2 का उपयोग करने वाले ग्राहकों के अनुसार boot2docker प्रमाणपत्र ( इस कोड द्वारा उत्पन्न) अमान्य हैं; OpenSSL लाइब्रेरी को boot2docker के साथ वितरित किया गया है, उसे फंसाया नहीं गया है।

@glyph या @aanand , क्या यह सुझाव देता है कि # 1474 से विलय किया गया @aand का फ़िक्स (काम के आस-पास) केवल टूटे हुए b2d को समायोजित करता है? @आनंद , अगर boot2docker / boot2docker # 808 को ठीक से संबोधित किया जाता है, तो # 1474 का समर्थन किया जाना चाहिए? क्या अगली क्रिप्टोग्राफी रिलीज़ में आशा है (इसे देखें और यह भी) एक लाल हेरिंग है?

हां मुझे ऐसा लगता है। मेरा मानना ​​है कि OpenSSL इस मुद्दे के साथ 1.0.2 है, और इसे 1.0.1 तक सीमित करके, यह जो भी सत्यापन तर्क विफल होने का कारण बन रहा है, उससे बचना होगा। मुझे अभी भी _what_ नहीं पता है कि यह उस प्रमाणपत्र के बारे में है जिसे वह पसंद नहीं करता है, क्योंकि त्रुटि संदेश बहुत ही अप्रिय हैं।

इसके अलावा, मुझे लगता है कि # 1474 जो कर रहा है वह बहुत विशिष्ट है; कम से कम मेरे पढ़ने से, यह _minimum_ python संस्करण सेट नहीं कर रहा है, लेकिन एक _exact_ संस्करण निर्दिष्ट कर रहा है। यह भी पता चलता है कि आप जो भी करते हैं उसका चेक फेल हो जाता है, जो कि j से अलग है, जिसका अर्थ है कि सुरक्षा अपडेट को भी 1.0.1 पर लागू नहीं किया जाएगा, जो _definitely_ एक समस्या है।

मेरा मानना ​​है कि लेकिन यह परीक्षण नहीं किया है कि सर्वर और CA सर्टिफिकेट को अलग-अलग सब्जेक्ट डीएन (ताकि सर्टिफिकेट सर्टिफिकेट में अलग-अलग सब्जेक्ट्स और इशूअर डीएन हों) देने से सर्टिफिकेट सभी ओपनएसएसएल वर्जन के तहत मान्य हो जाएंगे। मुझे संदेह है (इस X.509 उत्तरजीविता गाइड के मेरे पढ़ने के आधार पर लेकिन किसी भी संबंधित विनिर्देश नहीं), लेकिन मुझे विश्वास नहीं है, कि OpenSSL 1.0.2 का व्यवहार उचित है और एक प्रतिगमन का प्रतिनिधित्व नहीं करता है जिसे OpenSSL डेवलपर्स द्वारा हल किया जाना चाहिए।

मैं docker-machine -प्रमाणित प्रमाणपत्र की जांच करूंगा और देखूंगा कि क्या यह संपत्ति है। आप क्यों कहते हैं कि ओपनएसएसएल में यह व्यवहार स्वीकार्य होगा / प्रतिगमन नहीं होगा? एक स्व-हस्ताक्षरित प्रमाण पत्र पर भरोसा करना पूरी तरह से ठीक है, और इस विषय पर कोई विशेष प्रतिबंध नहीं हैं कि किस विषय या जारीकर्ता में यह हो सकता है कि मैं जागरूक हूं। मैंने उस गाइड का थोड़ा सा स्किम किया और यह केवल इंगित करने के लिए लगता है कि स्व-हस्ताक्षरित प्रमाणपत्रों में सीए-कार्टेल ट्रस्ट नहीं होगा, इसलिए आपका वेब ब्राउज़र अतिरिक्त कॉन्फ़िगरेशन के बिना उन पर भरोसा नहीं करेगा।

मेरे docker-machine VM में प्रमाण पत्र को देखते हुए, मैं देखता हूं:

...
        Issuer: O=glyph
...
        Subject: O=dev
...

तो आप इस बारे में सही हो सकते हैं ...

मैं डॉकटर-मशीन-जनरेटेड सर्टिफिकेट की जांच करूंगा और देखूंगा कि उसमें [मिलान विषय और जारीकर्ता डीएन] है या नहीं।

आप देख सकते हैं कि आनंद के डॉकटर-मशीन सेर के अलग-अलग DNs भी हैं: https://gist.github.com/aanand/3d865623481ba8ae66ee#file -docker-machine-log-L30-L32

एक स्व-हस्ताक्षरित प्रमाण पत्र पर भरोसा करना पूरी तरह से ठीक है

जब तक आप स्व-हस्ताक्षरित प्रमाण पत्र पर भरोसा नहीं करते हैं तब तक एक स्व-हस्ताक्षरित प्रमाणपत्र मान्य नहीं है। हम सर्वर प्रमाणपत्र पर भरोसा करने के लिए ओपनएसएसएल को निर्देश नहीं देते हैं; हम OpenSSL को निर्देश देते हैं कि सर्वर प्रमाण पत्र जारी करने वाले CA पर भरोसा करें।

आप क्यों कहते हैं कि ओपनएसएसएल में यह व्यवहार स्वीकार्य होगा / प्रतिगमन नहीं होगा?

IANAL, लेकिन मेरा तर्क भाषा से लिया गया है "एक सख्त स्तर पर [स्व-हस्ताक्षरित] का अर्थ है कि प्रमाण पत्र में जारीकर्ता और विषय क्षेत्र समान हैं।" यही कारण है कि boot2docker सर्वर प्रमाणपत्र के लिए मामला है। जब OpenSSL boot2docker सर्वर प्रमाणपत्र को मान्य करने का प्रयास करता है, तो CA प्रमाण पत्र पर विचार किए बिना एक पूर्ण विश्वास श्रृंखला बनाना संभव है क्योंकि सर्वर प्रमाणपत्र स्वयं हस्ताक्षरित प्रतीत होता है, लेकिन स्पष्ट रूप से विश्वसनीय नहीं है, और इसलिए मान्य नहीं हो सकता। मुझे विश्वास नहीं है कि यह कड़ाई से सही या आवश्यक व्यवहार है और मैं निर्णय लेने के योग्य नहीं हूं लेकिन मुझे लगता है कि यह "उचित" है।

खुदाई के लिए धन्यवाद, दोस्तों।

इसके अलावा, मुझे लगता है कि # 1474 जो कर रहा है वह बहुत विशिष्ट है; कम से कम मेरे पढ़ने से, यह एक न्यूनतम अजगर संस्करण सेट नहीं कर रहा है, लेकिन एक सटीक संस्करण निर्दिष्ट कर रहा है। यह भी पता चलता है कि आप जो भी करते हैं उसका चेक फेल हो जाता है, जो कि j से अलग है, जिसका अर्थ है कि सुरक्षा अपडेट को भी 1.0.1 पर लागू नहीं किया जाएगा, जो निश्चित रूप से एक समस्या है।

माना। यह मानकर कि यह OpenSSL 1.0.2 है जो boot2docker के समारोहों से असहमत है, उस भाग को कम से कम निश्चित होना चाहिए - मैं एक ओपन-टू-डेट OpenSSL 1.0.1 प्राप्त करूँगा।

@tdsmith , स्पष्टीकरण के लिए धन्यवाद और गलतफहमी के लिए माफी। @glyph , स्पष्टीकरण के लिए धन्यवाद।

FWIW, मैंने @tdsmith के सिद्धांत का परीक्षण करने का प्रयास किया और Issuer और Subject लिए अलग-अलग मान बनाने के लिए generate_cert (यह मुझे माफ कर दिया) वर्तमान में generate_cert बनाम मेरे हैक किए गए संस्करण से उत्पन्न प्रमाणपत्रों के साथ b2d चलाने पर मुझे यहां क्या मिलेगा:

0.9.8zd मूल generate_cert (0.1) के साथ काम करता है

% /usr/bin/openssl version
OpenSSL 0.9.8zd 8 Jan 2015
% /usr/bin/openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
depth=1 /O=Boot2Docker
verify return:1
depth=0 /O=Boot2Docker
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2Docker
-----BEGIN CERTIFICATE-----
MIIC/TCCAeegAwIBAgIRAKt8Sy0ND8z8omBU0uhODVAwCwYJKoZIhvcNAQELMBYx
...
qKFg5oUO9wigoGlwnSjqC/5ZmFRf9B+nWeCUVi/vWl0skOIqCMlDamD8AOVtmtRg
tg==
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Boot2Docker
issuer=/O=Boot2Docker
---
Acceptable client certificate CA names
/O=Boot2Docker
---
SSL handshake has read 2554 bytes and written 2188 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 621C9DF6883DA1FAF273408D0C984AC6E1DA33BA44ADA0EBA88BE59490560CFC
    Session-ID-ctx: 
    Master-Key: 39A75DE8551C41241CDBF889A5EF32DC7F86A45C792218B7E380E90627C7D0691BC5FCCAB69154B84142171F866F36C2
    Key-Arg   : None
    TLS session ticket:
    0000 - 77 ca 24 b7 2e 33 6a fc-9d 6e d0 eb aa 0d d5 89   w.$..3j..n......
    ...
    0630 - db 49 35 a1 97                                    .I5..

    Start Time: 1438703085
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
DONE

1.0.2d (MacPorts द्वारा स्थापित) _not_ मूल generate_cert (0.1) के साथ काम करता है

% openssl version
OpenSSL 1.0.2d 9 Jul 2015
% openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
depth=0 O = Boot2Docker
verify error:num=18:self signed certificate
verify return:1
depth=0 O = Boot2Docker
verify error:num=21:unable to verify the first certificate
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2Docker
-----BEGIN CERTIFICATE-----
MIIC/TCCAeegAwIBAgIRAKt8Sy0ND8z8omBU0uhODVAwCwYJKoZIhvcNAQELMBYx
...
qKFg5oUO9wigoGlwnSjqC/5ZmFRf9B+nWeCUVi/vWl0skOIqCMlDamD8AOVtmtRg
tg==
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Boot2Docker
issuer=/O=Boot2Docker
---
Acceptable client certificate CA names
/O=Boot2Docker
Client Certificate Types: RSA sign, ECDSA sign
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2156 bytes and written 1373 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: BAE02ACF63C2F4E28C46664CEB8E790DB0F00E8CB75913484BFE88CC215995D2
    Session-ID-ctx: 
    Master-Key: C7227519074A26A51D815655721F18C63932897D731D1BF077B8374F8A021D51EDF2E603386D249ED62127BD71A86048
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    0000 - 14 b0 7a 58 68 91 62 10-14 53 04 cf da 41 63 6e   ..zXh.b..S...Acn
    ...
    0350 - 5f 8e fe fd 9c b0 d0                              _......

    Start Time: 1438703297
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---
DONE

0.9.8zd हैक किए गए generate_cert (0.1.1 के साथ काम करता है; आश्चर्य की बात नहीं)

% /usr/bin/openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
depth=1 /O=Boot2DockerCA
verify return:1
depth=0 /O=Boot2Docker
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2DockerCA
-----BEGIN CERTIFICATE-----
MIIC/zCCAemgAwIBAgIRAMLl0tA00F2BDjyktFSD5aEwCwYJKoZIhvcNAQELMBgx
...
jhzP4aW3a8uAdpQXjf8nmJ5Qrq4Xb6yWAezXRdmPWfG1u4neBQKy1Zp64PiBd+0v
1UPu
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Boot2Docker
issuer=/O=Boot2DockerCA
---
Acceptable client certificate CA names
/O=Boot2DockerCA
---
SSL handshake has read 2563 bytes and written 2193 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 1E52C9982BE1F98559529B9E804D330ADD5EC8654EE9F3AFE6139B2AEAB24919
    Session-ID-ctx: 
    Master-Key: 0714B120A52F735C484BF0F6612909CEB5FAF27D5E66B3DDB76DCB32FFE506F70E4BC5EFC42BB19E5CBE6223ACEA5803
    Key-Arg   : None
    TLS session ticket:
    0000 - c4 54 e0 2f 90 68 f2 22-7a c9 ee 2f fb da 25 7a   .T./.h."z../..%z
    ...
    0630 - 5c 95 c6 0a e9 bd 21 70-fd                        \.....!p.
    063a - <SPACES/NULS>

    Start Time: 1438703534
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
DONE

1.0.2d _works (!) _: Tada:: see_no_evil:: Hear_no_evil:: Speak_no_evil: हैक किए गए generate_cert (0.1.1) के साथ

% openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
depth=1 O = Boot2DockerCA
verify return:1
depth=0 O = Boot2Docker
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2DockerCA
-----BEGIN CERTIFICATE-----
MIIC/zCCAemgAwIBAgIRAMLl0tA00F2BDjyktFSD5aEwCwYJKoZIhvcNAQELMBgx
...
jhzP4aW3a8uAdpQXjf8nmJ5Qrq4Xb6yWAezXRdmPWfG1u4neBQKy1Zp64PiBd+0v
1UPu
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Boot2Docker
issuer=/O=Boot2DockerCA
---
Acceptable client certificate CA names
/O=Boot2DockerCA
Client Certificate Types: RSA sign, ECDSA sign
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2899 bytes and written 2111 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: 0F1A3A0AB7B1E7C1CFD43CED169E730745DEB935C4DBEDDC7CD8AB698ECB8896
    Session-ID-ctx: 
    Master-Key: A48F441FD8677E1602BFB96DC7E9B39D0E9A7241D1C4AF93F3022ACB621C73E16BD69F557FF4428B033B1C07DF5EB0FB
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    0000 - 30 e1 e9 1a 4d e0 48 78-14 22 e8 21 5d 84 e7 6f   0...M.Hx.".!]..o
    ...
    0630 - 27 15 8a 64 ff 2e 24 44-3d d8                     '..d..$D=.

    Start Time: 1438703550
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
DONE

चेतावनियां

सभी परिवर्तनों को नियंत्रित करने की कोशिश करने के हित में, ध्यान दें कि जब मूल generate_cert (0.1) जारी किया गया था, तो इसका निर्माण तब किया गया था जब golang:1.3-cross डॉकटर छवि का निर्माण करने के लिए इसका उपयोग पैकेज में किया गया था। ssh कहा जाता है। उस पैकेज को तब से openssh-client बदल दिया गया है। मेरे हैक किए गए generate_cert का उपयोग करते समय OpenSSL संस्करण का उपयोग 1.0.1k । यह वैधानिक रूप से जुड़ा हुआ प्रतीत होता है:

% ldd generate_cert-0.1.1-linux-amd64
        linux-vdso.so.1 (0x00007ffd0936c000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007fddefe7f000)
        libc.so.6 => /lib/libc.so.6 (0x00007fddefb11000)
        /lib64/ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x00007fddf009a000)

तो ऐसा लगता है कि दो चीजों में से एक हो सकता है:

• ओपनएसएसएल के या तो देर से संस्करण भ्रमित हो जाते हैं जब Issuer == Subject , जैसा कि @tdsmith बताते हैं; या
• सर्टिफिकेट जनरेशन के बारे में कुछ और है जो ओपनएसएसएल में बदल गया है जैसे कि ओपनएसएसएल के बाद के संस्करणों को पहले के जनरेट किए गए सर्टिफिकेट को सत्यापित करने में परेशानी होती है।

इसका परीक्षण करने का एक तरीका मेरी हैक के बिना generate_cert का पुनर्निर्माण करना है, लेकिन ओपनएसएसएल के एक अद्यतन संस्करण के साथ। मैं इसके बाद करूँगा।

तो ऐसा लगता है कि @tdsmith सही है। बाद मेरी हैक बाहर समर्थन सुनिश्चित करने के लिए Issuer <> Subject , लेकिन पुनर्निर्माण generate_cert से OpenSSL के नए संस्करण के साथ golang:1.3-cross , इसके साथ में नाकाम रहने के लिए वापस चला जाता है बाद में क्लाइंट पक्ष पर OpenSSL संस्करण:

0.9.8zd generate_cert (0.1.2) के साथ अद्यतन OpenSSL के साथ काम करता है

% /usr/bin/openssl version
OpenSSL 0.9.8zd 8 Jan 2015
% /usr/bin/openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
depth=1 /O=Boot2Docker
verify return:1
depth=0 /O=Boot2Docker
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2Docker
-----BEGIN CERTIFICATE-----
MIIC/TCCAeegAwIBAgIRAIVQ9IAYtPQwnu/FHM8HNS0wCwYJKoZIhvcNAQELMBYx
...
xZ+XhXvepeJ/mBIui1qT3yAMum0Mj1zLAxqCY/qsEU4odsgU9N9DbUGngoIkBCrY
gw==
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Boot2Docker
issuer=/O=Boot2Docker
---
Acceptable client certificate CA names
/O=Boot2Docker
---
SSL handshake has read 2554 bytes and written 2188 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: FDE088ECF8D0EB2B36EC909B9A66C9C6770AE31355040761CB35150C5A56E92E
    Session-ID-ctx: 
    Master-Key: 86522F869CDE85C8171EEC3A7CF76FDF26F81AE6162DDDEA7D1C55FD5E49E4BDCA56D827C3BFECBFAD9AA2F71A5A94EE
    Key-Arg   : None
    TLS session ticket:
    0000 - 67 d0 60 8e 54 54 7c 7a-3e 5e 71 97 26 e0 06 2c   g.`.TT|z>^q.&..,
    ...
    0630 - cf 68 86 83 d7                                    .h...

    Start Time: 1438705996
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
DONE

1.0.2d (MacPorts द्वारा स्थापित) _not_ generate_cert (0.1.2) के साथ अद्यतन OpenSSL के साथ काम करता है

% openssl version
OpenSSL 1.0.2d 9 Jul 2015
% openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
depth=0 O = Boot2Docker
verify error:num=18:self signed certificate
verify return:1
depth=0 O = Boot2Docker
verify error:num=21:unable to verify the first certificate
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2Docker
-----BEGIN CERTIFICATE-----
MIIC/TCCAeegAwIBAgIRAIVQ9IAYtPQwnu/FHM8HNS0wCwYJKoZIhvcNAQELMBYx
...
xZ+XhXvepeJ/mBIui1qT3yAMum0Mj1zLAxqCY/qsEU4odsgU9N9DbUGngoIkBCrY
gw==
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Boot2Docker
issuer=/O=Boot2Docker
---
Acceptable client certificate CA names
/O=Boot2Docker
Client Certificate Types: RSA sign, ECDSA sign
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2156 bytes and written 1373 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: C2A8BF01E9B754CBF48C69243091C54DAD19DCF52D285C9379B684A3B333AFDD
    Session-ID-ctx: 
    Master-Key: F8510162517AF4C115A13B7CA9E05E04868B4D78CBFA57B28A5B9616EE6FBED6B7B4FC52C2003EBC5D150FA8BDE95F4C
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    0000 - bc bc 2c 3e 2d b0 92 49-80 c2 c0 df 4f bd fb 84   ..,>-..I....O...
    ...
    0350 - 1e c7 c2 b2 e6 f5 74                              ......t

    Start Time: 1438705985
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---
DONE

SvenDowideit / generate_cert # 10 की आवश्यकता है। वैसे, अगर कोई भी b2d छवियां बनाना चाहता है जो मेरे हैक किए गए generate_cert s की ओर इशारा करते हैं, तो आप इन्हें तब तक

अगर मैं सही तरीके से समझूं, तो यह _should_ क्लाइंट साइड पर OpenSSL / पायथन संस्करण गेम खेलने की आवश्यकता को कम से कम (इस मुद्दे के संबंध में)।

@SvenDowideit को टैग करना

मैंने ओपनएसएसएल लोगों के साथ थोड़ा आगे-पीछे किया है। यहाँ स्टीव Henson से एक सारांश है:

From: Stephen Henson via RT <[email protected]>
Subject: [openssl.org #3979] New OpenSSL issue: valid certificate fails validation where subject text == issuer text
Date: August 5, 2015 at 04:32:18 PDT
Cc: [email protected]
Reply-To: [email protected]

... The bug is that OpenSSL 1.0.2 is less strict about
what counts as a valid self signed certificate. Before 1.0.2 the certificate
had to have issuer and subject matching, if present AKID==SKID and
keyUsage (if present) had to include keyCertSign. For1.0.2 and later the
keyCertSign check is no longer present.

The attached patch should fix it. Let me know if it works for you.

A workaround (other than making subject != issuer) is to include SKID/AKID in
all certificates.

Regards, Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

जिस तरह से b2d को बदलने के लिए अपने सर्टिफिकेट बनाता है ताकि छोटी गाड़ी ओपनएसएसएल ग्राहकों को समायोजित कर सके और क्लाइंट की तरफ से ओपनएसएसएल को पैचिंग और इंस्टॉल करने में बेहतर हो। मुझे यकीन नहीं है कि कौन सा विशिष्ट दृष्टिकोण अधिक उपयुक्त है (विषय बनाते हुए! = जारीकर्ता बनाम सभी प्रमाणपत्रों में SKID / ADID सहित)। मैं उस रुपये को @SvenDowideit पर पास कर दूंगा। : बनावटी हंसी:

जिज्ञासु के लिए (फिर मुझे नहीं लगता कि हमें यह मार्ग लेना चाहिए), यहाँ स्टीव से ओपनएसएसएल पैच है:

diff --git a/crypto/x509v3/v3_purp.c b/crypto/x509v3/v3_purp.c
index 1f9296a..7a0130a 100644
--- a/crypto/x509v3/v3_purp.c
+++ b/crypto/x509v3/v3_purp.c
@@ -63,6 +63,7 @@
 #include <openssl/x509_vfy.h>

 static void x509v3_cache_extensions(X509 *x);
+static int check_ca(const X509 *x);

 static int check_ssl_ca(const X509 *x);
 static int check_purpose_ssl_client(const X509_PURPOSE *xp, const X509 *x,
@@ -493,7 +494,7 @@ static void x509v3_cache_extensions(X509 *x)
     if (!X509_NAME_cmp(X509_get_subject_name(x), X509_get_issuer_name(x))) {
         x->ex_flags |= EXFLAG_SI;
         /* If SKID matches AKID also indicate self signed */
-        if (X509_check_akid(x, x->akid) == X509_V_OK)
+        if (X509_check_akid(x, x->akid) == X509_V_OK && check_ca(x) == 1)
             x->ex_flags |= EXFLAG_SS;
     }
     x->altname = X509_get_ext_d2i(x, NID_subject_alt_name, NULL, NULL);

पूरा इतिहास: http://rt.openssl.org/Ticket/History.html?user=guest&pass=guest&id=3979।

रुको ... _less_ सख्त? मैं असमंजस में हूँ कि कैसे एक _less_ सख्त जाँच विफल हो रही है जहाँ एक और अधिक सख्त गुजरता है?

रुको ... _less_ सख्त? मैं असमंजस में हूँ कि कैसे एक _less_ सख्त जाँच विफल हो रही है जहाँ एक और अधिक सख्त गुजरता है?

हाँ, मुझे भाषा के उस विकल्प से भी परेशानी थी। फ़र्क को देखते हुए, मुझे लगता है कि उनका अर्थ है कि अधिक प्रमाण-पत्रों में गलत तरीके से व्यापक रूप से स्वीप करना, जो कि कई चेक (जैसे कि, यह निर्धारित करने में कम सख्त न हो कि स्व-हस्ताक्षरित के रूप में अर्हता प्राप्त कर सकता है) या नहीं। लेकिन तुम सही हो। यह वाक्यांश का एक अजीब मोड़ है।

मैंने ओपनएसएसएल स्रोतों में बहुत समय व्यतीत नहीं किया है, लेकिन मैं उन्हें कई स्थानों पर काफी अभेद्य लगता हूं। शायद यह उस परियोजना पर काम करने के लिए एक "विशेष" मानसिकता लेता है। : मुस्कुराहट:

मैंने ओपनएसएसएल स्रोतों में बहुत समय व्यतीत नहीं किया है, लेकिन मैं उन्हें कई स्थानों पर काफी अभेद्य लगता हूं। शायद यह उस परियोजना पर काम करने के लिए एक "विशेष" मानसिकता लेता है।

एक ख़ामोश, मुझे लगता है: पलक:।

किसी भी मामले में, ओपनएसएसएल लोगों तक पहुंचने के लिए धन्यवाद, खुशी से यहां इसे हल किया जाएगा। इस बीच, बी 2 डी में इसके आसपास काम करना सही काम करने जैसा लगता है। मुझे नहीं लगता कि यहां कुछ भी करने के लिए तैयार है लेकिन प्रतीक्षा करें।

जैसा कि यहां बताया गया

pip install requests[security]

@ शिवाय एक लाल हेरिंग है; यह संभवतः आपके लिए इसे ठीक करता है क्योंकि आपके पास एक कैश्ड बाइनरी व्हील था जो एक अलग ओपनएसएसएल के खिलाफ जुड़ा हुआ था।

FYI करें, PR फिक्स के साथ boot2docker / boot2docker # 1029 के रूप में प्रस्तुत किया गया।

इस के लिए फिक्स (धन्यवाद @ एक्सपो!) Boot2docker के नवीनतम संस्करण में बाहर है। अपग्रेड करना:

$ boot2docker upgrade
$ boot2docker delete
$ boot2docker init
$ boot2docker up

मेरे लिए यह मुद्दा तय हो गया। कृपया इसे आज़माएँ और वापस रिपोर्ट करें।

वैकल्पिक रूप से, डॉकर मशीन पर स्विच करें, जो अब नए डॉकर टूलबॉक्स के हिस्से के रूप में मानक के रूप में आती है।

मैं अभी भी इस मुद्दे पर आ रहा हूँ ...

❯ openssl version && docker-compose --version && docker-machine --version && python --version
OpenSSL 1.0.2d 9 Jul 2015
docker-compose version: 1.4.0
docker-machine version 0.4.1 (HEAD)
Python 2.7.10

❯ docker-compose ps
/usr/local/Cellar/fig/1.4.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Name   Command   State   Ports
------------------------------

@chiefy आपका कंपोज़ कॉल सफल हो रहा है; आपके द्वारा देखी जा रही चेतावनी हानिरहित है। यदि आप इसे देखने से बचना चाहते हैं तो आपको OS X 10.10.5 में अपग्रेड करना चाहिए।

@ टीएसडीएमिथ मेरे लिए हानिरहित नहीं है, मेरी ओसीडी पागल: ड्राइविंग: मुस्कान: टिप के लिए धन्यवाद, अभी अपग्रेड करेगा।

काढ़ा के माध्यम से स्थापित अजगर संस्करण की स्थापना रद्द करना मेरे लिए इस समस्या को हल करता है। brew remove --force python

मैंने काढ़ा संस्करण की स्थापना रद्द कर दी है, लेकिन अभी भी Python 2.7.10 और अभी भी है
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) त्रुटि।

मेरे पास अगला सेटअप है:

OpenSSL 0.9.8zg 14 July 2015
docker-compose version: 1.4.0
docker-machine version 0.4.1 (e2c88d6)
Python 2.7.10

@chiefy
क्या आपने अपनी समस्या हल कर ली है?

क्या किसी को पता है कि क्या डॉक-कंपोज़ लोग समस्या को हल करने के लिए काम कर रहे हैं, या यह मूल रूप से उनका मुद्दा नहीं है?

सादर,

@PavelPolyakov
नहीं। मेरे दोनों macs (10.9.x और 10.10.x) पर, मैंने विभिन्न चीजों की कोशिश की है w / कोई बदलाव नहीं। मुझे नहीं लगता कि यह एक docker-compose चीज़ है और पायथन चीज़ FWIW से अधिक है।

@chiefy
मैं सहमत हूँ, लेकिन मुझे यह काम करने का कोई रूप नहीं मिला है :(

लगता है कि हर किसी ने इस मुद्दे को पहले ही हल कर दिया है, लेकिन मुझे नहीं :)

मैंने एक बार काढ़ा का उपयोग करके अजगर को स्थापित किया है, और मुझे लगता है कि मैंने सिस्टम को हटा दिया है, इसलिए मेरे पास पुराने वाले पर लौटने का कोई विकल्प नहीं है।

मैंने कई वेरिएंट्स द्वारा docker स्थापित करने का प्रयास किया है:

1. बाइनरी से (डॉकर टूलबॉक्स डाउनलोड करना)
2. काढ़ा से ही

हालाँकि मेरे पास अभी भी है:

किसी को भी इस व्यवहार को दूर करने के लिए एक व्यापक गाइड है?

सादर,

@PavelPolyakov - बग वह बूट 2docker है (और कुछ मामलों में, मुझे लगता है, docker-machine) कुछ प्रमाणपत्रों का निर्माण कर रहा था जो कि अजगर के SSL समर्थन द्वारा अनुपयोगी थे। यदि आपने अपने सभी सॉफ़्टवेयर को अपग्रेड किया है, लेकिन अभी भी पुराने प्रमाण पत्र खराब हैं, तो भी चीजें टूट जाएंगी। इसलिए इस बिंदु पर मैं डॉकटर-मशीन के वर्तमान संस्करण के साथ जो भी देव वीएम मिला है, उसे फिर से प्रोविजन करने की सलाह दूंगा, ताकि नए एसएसएल प्रमाणपत्रों का प्रावधान किया जाएगा। इसमें आपके होस्ट पर ~/.docker एक तरफ बढ़ना शामिल हो सकता है।

@PavelPolyakov और @chiefy , @glyph की सलाह के अलावा, आप यह भी आज़मा सकते हैं (यदि आप अपने boot2docker पर्यावरण को पूरी तरह से नहीं हटाना चाहते हैं):

% mv ~/.docker ~/.docker.bak
% ssh docker@[boot2dockerip]
docker@[boot2dockerip]'s password: [typically "tcuser"]
...
Boot2Docker version 1.8.1, build master : 7f12e95 - Thu Aug 13 03:24:56 UTC 2015
Docker version 1.8.1, build d12ea79
docker<strong i="10">@boot2docker</strong>:~$ rm -frv ~/.docker
...
docker<strong i="11">@boot2docker</strong>:~$ sudo -s
root<strong i="12">@boot2docker</strong>:/home/docker# rm -v /var/lib/boot2docker/tls/*
...
root<strong i="13">@boot2docker</strong>:/home/docker# shutdown -h now
...

[boot2dockerip] आपके VM वातावरण के लिए विशिष्ट है। आसान तरीके हो सकते हैं (जैसे, vagrant ssh , यदि आप वैग्रंट का उपयोग कर रहे हैं)। फिर अपने boot2docker उदाहरण को पुनरारंभ करें और देखें कि क्या SSL त्रुटि अभी भी होती है।

@glyph

सलाह के लिए धन्यवाद, मेरे लिए यह डॉकटर-मशीन को फिर से तैयार करने का मुद्दा नहीं है। हालांकि यह मदद नहीं करता है।

जब मैं docker & co को स्थापित करता हूं:
brew install docker docker-machine docker-compose

फिर, default मशीन नहीं बनाई गई है। और मुझे docker-machine create का उपयोग करके इसे बनाने का कोई पता नहीं है।

जब मैं * .pkg फ़ाइल का उपयोग कर docker-toolbelt स्थापित करता हूं, तो मशीन बनाई जाती है, लेकिन मेरे पास SSL त्रुटि है।
मैंने भी करने की कोशिश की है:

docker-machine regenerate-certs default

लेकिन यह मदद नहीं करता है।

@posita
सलाह के लिए भी धन्यवाद।
आपके गाइड में, आप mv ~/.docker ~/.docker-bak को किस कारण से सुझाते हैं? जैसे ही हम ऐसा करते हैं, हम मशीन को फिर से शुरू नहीं कर सकते, क्योंकि फाइलें स्थानांतरित हो जाती हैं।
हां, मैं मशीन को लॉगिन करने और tls/* निकालने में सक्षम हूं, फिर इसे बंद कर दूं, लेकिन इसे फिर से कैसे शुरू किया जाए?

इसे खरोंच से कैसे पुन: उत्पन्न करें?

@सब
Docker (वर्किंग डॉक-कंपोज़ के साथ) स्थापित करने का आपका तरीका क्या है, क्या यह brew install या टूलबेल्ट .pkg के माध्यम से है?
मैं कैसे सुनिश्चित हो सकता हूं, कि मेरे डॉकटर-मशीन पर जो प्रमाण पत्र हैं, वे अजगर द्वारा मान्य और उपयोगी हैं, मैं अजगर को कैसे उन्नत कर सकता हूं और इससे भी अधिक पीसा जा सकता है, आदि?

मदद के लिए धन्यवाद।

सादर,

@PavelPolyakov - docker-machine पास "डिफ़ॉल्ट" मशीन की धारणा नहीं है। आप docker-machine create --driver virtualbox my-docker-machine चला सकते हैं।

@PavelPolyakov एक बार जब आप कर लेते हैं तो आपको eval "$(docker-machine env my-docker-machine)" करने की आवश्यकता होती है, या जो भी आपने अपने स्थानीय देव मशीन को कॉल करने के लिए चुना है।

@glyph
सही है, कि brew से सब कुछ चलाने का गायब हिस्सा था। मैंने default (जो कि .pkg से स्थापित करते समय किया जाता है) नाम के साथ मशीन को सफलतापूर्वक प्रावधानित किया है।

हालांकि, हमेशा की तरह, मैं इसके साथ समाप्त होता हूं:

:(

अपने गाइड में, आप एमवी को सुझाव देते हैं ~ /। डॉकटर ~ /। डॉकर-बक - किस कारण से? जैसे ही हम ऐसा करते हैं, हम मशीन को फिर से शुरू नहीं कर सकते, क्योंकि फाइलें स्थानांतरित हो जाती हैं।

@PavelPolyakov , मुझे यकीन नहीं है। मैं docker-machine उपयोग नहीं करता। मैं अन्य वातावरणों के आधार पर अनुमान लगा रहा था। यदि यह काम नहीं करता है तो कृपया अवहेलना करें।

हां, मैं मशीन को लॉगिन करने और tls/* निकालने में सक्षम हूं, फिर इसे बंद कर दूं, लेकिन इसे फिर से कैसे शुरू किया जाए?

क्या docker-machine restart काम नहीं करता है?

मेरी टिप्पणी वैग्रांत के साथ boot2docker चलने के अपने अनुभव पर आधारित थी। यह docker-machine पर बहुत अच्छी तरह से लागू नहीं हो सकता है। ऐसा लगता है कि @glyph को उस वातावरण के साथ अधिक अनुभव है। मैं उनके सुझावों की कोशिश करूंगा।

Docker (वर्किंग docker-Compose के साथ) स्थापित करने का आपका तरीका क्या है, क्या यह brew install या टूलबेल्ट .pkg के माध्यम से है?

यह कुछ हद तक बाहर इस मुद्दे की गुंजाइश (जो के साथ एक प्रमाण पत्र समस्या के साथ विशेष रूप से संबंधित है boot2docker में प्रकट docker-compose ), लेकिन ओएस एक्स पर, मैं का उपयोग द्विआधारी बनाता है ।

@PavelPolyakov , जब आप निम्नलिखित करते हैं तो क्या होता है?

docker-machine create --driver virtualbox shiny-new-machine-74d5a19e
eval $( docker-machine env shiny-new-machine-74d5a19e )
docker-compose build

boot2docker लिए वह संस्करण क्या है जो आप निम्न कार्य करते समय प्रदर्शित करते हैं?

docker-machine ssh shiny-new-machine-74d5a19e

बेझिझक shiny-new-machine-74d5a19e को जो कुछ भी आप चाहते हैं उसके साथ बदलें, इसलिए जब तक यह एक मौजूदा उदाहरण का संदर्भ नहीं देता है (यानी, नाम पहले से ही प्रकट नहीं होना चाहिए जब आप उपरोक्त आदेशों को निष्पादित करने से पहले docker-machine ls करते हैं। ।)।

@posita

हम्मम ....: उलझन:

eval $( docker-machine env shiny-new-machine-74d5a19e ) # probably unnecessary if you're still in the same shell as above
which openssl
openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null

@posita
धन्यवाद कि आप मदद करना जारी रखें।

openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
http://pastebin.com/Y9ZqfTVG

अलग OSX मशीन पर ऐसा ही करने की कोशिश की है।
सभी नवीनतम अपडेट (ओएस और काढ़ा पैकेज) के साथ, और एसएसएल के साथ एक ही मुद्दे का सामना करना पड़ा।

@PavelPolyakov , मैं इसे आपके openssl s_client ... डंप से देख रहा हूँ:

...
Certificate chain
 0 s:/O=shiny-new-machine-74d5a19e
   i:/O=PavelPolyakov
...

ये boot2docker डिफ़ॉल्ट नहीं हैं, जो (अब) होना चाहिए:

...
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2Docker
...

अधिक जानकारी के बिना, मेरा अनुमान है कि docker-machine डिफ़ॉल्ट (किसी तरह) को ओवरराइट कर रहा है जब यह वर्चुअल मशीन का प्रावधान करता है। लेकिन openssl कॉल ने काम किया प्रतीत होता है, इसलिए मुझे यकीन नहीं है कि यह एक मुद्दा है, और मुझे समझ नहीं आता कि docker-compose विफल क्यों होंगे। : चकित:

निम्नलिखित के लिए आपका आउटपुट क्या है?

(
set -x
eval $( docker-machine env shiny-new-machine-74d5a19e )
env | grep DOCKER
ls -al "${DOCKER_CERT_PATH}"
openssl x509 -in "${DOCKER_CERT_PATH}/cert.pem" -text
openssl x509 -in "${DOCKER_CERT_PATH}/ca.pem" -text
docker-compose --verbose version
docker-compose --verbose ps
DOCKER_TLS_VERIFY=0 docker-compose --verbose ps
) >"${HOME}/Desktop/docker-compose-890-outerr-$( date -u +%Y-%m-%dT%H:%M:%SZ ).txt" 2>&1

यह चिपकाने / अपलोड करने के लिए ~/Desktop/docker-compose-890-outerr-2015-09-18T14:45:29Z.txt तरह एक फ़ाइल बनाना चाहिए।

@posita
यह रहा:
http://pastebin.com/vWqZgVKi

मुझे पूरा यकीन है कि इसका आपके मुद्दे से कोई लेना-देना नहीं है, लेकिन आपके docker-compose और docker-py संस्करण पीछे हैं। ये नवीनतम रिलीज़ हैं:

...
 docker-compose version: 1.4.1
 docker-py version: 1.4.0
...

इसके अलावा (और मैं यह गलत समझ सकता हूं), यह आपके ca.pem और cert.pem समान Subject (जो मूल boot2docker का कारण था) की तरह दिखता है। मुद्दा है, लेकिन दूसरी दिशा से आ रहा है)। चूँकि ये प्रमाण पत्र docker-machine द्वारा बनाए / बनाए गए प्रतीत होते हैं, मुझे संदेह है कि समस्या है? मुझे डॉकटर / मशीन # 1335 और डॉकटर / मशीन # 1767 मिला, जो संबंधित हो सकता है, लेकिन न तो सीधे बिंदु पर दिखाई देता है।

Fwiw, मैं उपयोग कर रहा हूँ docker-compose (के माध्यम से स्थापित pip एक में virtualenv OpenSSL और अजगर 2.7 MacPorts से स्थापित के साथ)। ओपनएसएसएल का वह संस्करण इस समस्या में पहचानी गई समस्या के अधीन है (और boot2docker के अपडेट द्वारा काम किया गया)। मेरे लिए, यह संयोजन boot2docker 1.8.1+ और वैग्रांट (मेरे Vagrantfile हैंडल को boot2docker कुछ प्रमाणपत्रों के माध्यम से मेजबान को वापस कॉपी करते हुए) के साथ जारी किए बिना काम करता है:

% cat /.../Vagrantfile
...
         # See <http://tinyurl.com/nz4tgy6>
         boot2docker.vm.provision :shell, inline: "set -e ; while ! docker >/dev/null ps --quiet ; do echo 'Waiting for Docker to come alive so we can kill it...' ; sleep 1 ; done ; sudo /etc/init.d/docker stop ; sudo rm -f /var/lib/boot2docker/tls/*.pem ~docker/.docker/*.pem ; sudo /etc/init.d/docker restart ; while ! docker >/dev/null ps --quiet ; do echo 'Waiting for Docker to come alive again so we can steal its keys...' ; sleep 1 ; done ; echo 'It lives!' ; [ -z \"$( find ~docker/.docker -name '*.pem' 2>/dev/null )\" ] || cp -Rv ~docker/.docker/*.pem '/vagrant/certs" , privileged: true
...
% env | grep DOCKER
DOCKER_HOST=tcp://w.x.y.z:2376
DOCKER_TLS_VERIFY=1
DOCKER_CERT_PATH=/.../certs
% ls "${DOCKER_CERT_PATH}"
ca.pem
cert.pem
key.pem
% openssl x509 -in "${DOCKER_CERT_PATH}/cert.pem" -text
...
        Issuer: O=Boot2DockerCA
...
        Subject: O=Boot2Docker
...
% openssl x509 -in "${DOCKER_CERT_PATH}/ca.pem" -text
...
        Subject: O=Boot2DockerCA
...
% virtualenv --python=python2.7 .../venv
...
% .../venv/bin/pip install docker-compose
...
% .../venv/bin/docker-compose --verbose version
docker-compose version: 1.4.1
docker-py version: 1.4.0
CPython version: 2.7.10
OpenSSL version: OpenSSL 1.0.2d 9 Jul 2015
% .../venv/bin/docker-compose ps
Name   Command   State   Ports
------------------------------

मुझे लगता है कि आपके पास वह विकल्प नहीं हो सकता है। मैं इसे केवल अंतरों को प्रकाशित करने में मदद करने के लिए पोस्ट कर रहा हूं, जो आपके मुद्दे का निदान करने में सहायता कर सकता है। ऊपर की तुलना अपने docker-machine -संचित सेर के साथ करें:

+-zsh:39> openssl x509 -in /.../.docker/machine/machines/shiny-new-machine-74d5a19e/cert.pem -text
...
        Issuer: O=PavelPolyakov
...
        Subject: O=PavelPolyakov
...
+-zsh:40> openssl x509 -in /.../.docker/machine/machines/shiny-new-machine-74d5a19e/ca.pem -text
...
        Subject: O=PavelPolyakov
...

ध्यान दें कि Subject ca.pem Subject cert.pem ।

मुझे नहीं लगता कि आपका मुद्दा docker-compose । ( @आनंद , शायद आप टिप्पणी कर सकते हैं?) यह देखते हुए कि यह मुद्दा कितना अव्यवस्थित है, डॉकटर / मशीन के लिए एक प्रारंभिक टिप्पणी के बाद , मैं इसे संदर्भित करूंगा।

यदि आप डॉकटर / मशीन के लिए एक /var/log/docker.log या /var/log/boot2docker.log में कुछ भी दिलचस्प होने पर विचार करें। उदाहरण के लिए, इसे आज़माएँ:

ssh docker@[machine-instance] grep generate_cert /var/log/boot2docker.log

या:

docker-machine ssh grep generate_cert /var/log/boot2docker.log

OSX el capitain पर इसे प्राप्त करना,

docker-machine version 0.4.1 (HEAD)
Docker version 1.8.2, build 0a8c2e3
docker-compose version: 1.4.2

हाय @DaveBlooman ,

बस जिज्ञासु, क्या आपके पास भी काढ़ा का उपयोग करके अजगर और सामान स्थापित है? या दूसरा तरीका।
और क्या आपके पास docker-compose build करते समय सटीक त्रुटि है?

वाया होमब्रे, पायथन 2.7.10

तो निश्चित रूप से brew कारण कुछ होता है :(

@DaveBlooman , @PavelPolyakov के मुद्दे को पुन: पेश कर सकते हैं, तो हो सकता है कि आप दो एक निदान पर सहयोग कर सकते हैं?

मेरे पास एक ही समस्या थी और यह इस तथ्य के कारण था कि मेरे पास एक अन्य एप्लिकेशन (मेरे मामले में एस्ट्रिल) द्वारा बैठा वीपीएन कनेक्शन था जो शायद नेटवर्क कॉन्फ़िगरेशन के साथ कुछ गड़बड़ कर रहा था। आशा है कि यह किसी और की मदद कर सकता है जो समान समस्या प्राप्त करता है।

मुझे OSX 10.9.5 पर त्रुटियाँ हैं

/usr/local/Cellar/docker-compose/1.5.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Starting compose_maven_1
/usr/local/Cellar/docker-compose/1.5.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Starting compose_ssh_1
/usr/local/Cellar/docker-compose/1.5.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning

पायथन 2.7.10
docker- मशीन संस्करण 0.5.0
docker- रचना संस्करण: 1.5.0

सभी Homebrew के माध्यम से स्थापित किया गया

@anthonygreen , जो काफी हद तक एक अलग मुद्दे की तरह दिखता है। मुझे लगता है कि यहाँ जो चर्चा हो रही है, उसी त्रुटि संदेश को मैं नहीं देखता हूँ। ऐसा लगता है कि Homebrew उपयोगकर्ताओं को इस एक से संबंधित समस्याओं की एक बड़ी संख्या का अनुभव है। कृपया एक नया मुद्दा दर्ज करने पर विचार करें।

मैंने इस पूरी पोस्ट को नहीं पढ़ा है, लेकिन मैंने OS X Yosemite पर हाल ही के सेटअप पर एक ही त्रुटि देखी है जो डॉकर टूलबॉक्स 1.9.1a का उपयोग कर रहा है।

$ docker-machine --version
docker-machine version 0.5.1 (7e8e38e)
$ docker-compose --version
docker-compose version: 1.5.1
$ docker --version
Docker version 1.9.1, build a34a1d5

पता चलता है कि मेरे पास CURL_CA_BUNDLE पर्यावरण चर सेट (कुछ कस्टम आंतरिक सेरट के साथ) था, और docker-compose चलाने से पहले इस env var को परेशान करने से इसे [SSL: CERTIFICATE_VERIFY_FAILED] त्रुटि प्राप्त करने की अनुमति मिली।

$ (unset CURL_CA_BUNDLE; docker-compose up)
Starting ...

संपादित करें: उफ़, यहाँ पर टिप्पणी करने का मतलब है https://github.com/docker/machine/issues/1880

@pmahoney , धन्यवाद हम में से बाकी लोगों को बताने के लिए! मैंने कभी अनुमान नहीं लगाया होगा। FYI करें, आप शायद कुछ इस तरह भी कर सकते हैं (यदि आप सबस्क्रिप्शन नहीं चाहते हैं):

$ CURL_CA_BUNDLE= docker-compose up

@posita चेतावनियों में रिक्त स्ट्रिंग परिणामों में env var सेट करना:

$TMPDIR/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html

हालांकि मुझे एसएसएल त्रुटि नहीं मिलती है।

@pmahoney , दिलचस्प। तो यह एक सेट-लेकिन-खाली CURL_CA_BUNDLE की तरह दिखता है, जिसमें अलग-अलग शब्दार्थ (जैसे, एक शून्य ओवरराइड) है जो इसे बिल्कुल भी सेट नहीं करता है (जो शायद किसी डिफ़ॉल्ट स्थान पर दिखता है)। मैंने इसे डॉक्स में व्यवहार में खोजने की कोशिश की, लेकिन सफल नहीं था। मुझे जो सबसे निकटतम चीज़ मिली, वह यही थी ।

@neilsarkar मेरी समस्या भी चार्ल्स प्रॉक्सी चल रही थी! धन्यवाद!

हे भगवान, मेरे पास दोनों मशीनों पर कस्टम CURL_CA_BUNDLE है जहां मैं परीक्षण कर रहा था।

धन्यवाद

मेरे लिए कुछ भी नहीं, कोई CURL_CA_BUNDLE चर नहीं :(
इसलिए मैंने इसे बिना किसी सफलता के एक मूल्य पर सेट करने की कोशिश की, लेकिन अगर मैंने CURL_CA_BUNDLE को कुछ भी नहीं (CURL_CA_BUNDLE =) पर सेट किया है, तो मेरे पास चेतावनी है जैसा कि @pmahoney ने कहा और यह काम करता है, लेकिन यह टर्मिनल चेतावनी संदेश द्वारा पूरी तरह से काम करता है।
मुझे आशा है कि मेरे लिए एक बेहतर समाधान है :)

अगर आपको पता है कि CURL_CA_BUNDLE चर का अच्छा मूल्य क्या है, तो मैं इसे ले लेता हूं :)

धन्यवाद

मैं वेबकिट-पैच के साथ एक ही मुद्दा था। SSL / TLS मॉड्यूल पर अजगर डॉक्स को देखने से , ssl.get_default_verify_paths() हमें दिखाते हैं जहां Python / OpenSSL CA प्रमाणपत्र फ़ाइल की अपेक्षा करता है। इसलिए यदि आप इसे अपने टर्मिनल में चलाते हैं:

python3 -c "import ssl; [print(i) for i in ssl.get_default_verify_paths()]"

हमें यह देखना चाहिए कि SSL_CERT_FILE सेट किए बिना, Python का SSL मॉड्यूल /usr/local/ssl/cert.pem (OpenSSL को /usr/local/ssl स्थापित करने वालों के लिए) पर CA प्रमाणपत्र फ़ाइल की अपेक्षा करता है। तो या तो, आप रूट CA प्रमाण पत्र के साथ एक प्रमाण पत्र फ़ाइल में SSL_CERT_FILE सेट करते हैं, या आप /usr/local/ssl/cert.pem CA curl और स्रोत ट्री में lib/mk-ca-bundle.pl चलाएं और ca-bundle.crt फ़ाइल जेनरेट होगी। मैं पुष्टि कर सकता हूं कि SSL_CERT_FILE स्थापना ओपनएसएसएल 1.0.2d के साथ पायथन 2.7.11 और पायथन 3.5.0 के साथ काम करेगी।

@grahamc क्या आप समस्या को हल करने के लिए हुए थे? मेरे पास आपके जैसा ही सेट अप है जो रिमोट डॉकटर डेमन के साथ बहुत अच्छा काम करता है लेकिन docker-compose साथ विफल रहता है

मुझे मिलने वाली त्रुटि ERROR: SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

नहीं, मुझे बस दूरस्थ डॉक मेजबानों को छोड़ना पड़ा, दुर्भाग्य से :(

मेरे पास अभी यह मुद्दा है जहां CURL_CA_BUNDLE कारण docker-compose का विफल होना है:

ERROR: SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

जबकि docker ठीक काम कर रहा था। अच्छा होगा कि docker-compose पर्यावरण वैरिएबल को अनदेखा करें या कम से कम एक चेतावनी दें कि यह अपेक्षित प्रमाण पत्र का उपयोग नहीं करेगा।

@ बकेट , सुविधा अनुरोध के रूप में इसे जोड़ने के लिए एक नया मुद्दा दर्ज करने पर विचार करें। docker-py साथ एक बहन के मुद्दे को दर्ज करने पर विचार करें और उन्हें एक दूसरे का संदर्भ दें। मुझे यकीन नहीं है कि कौन सी परत सबसे उपयुक्त होगी।

संपादित करें: नया अंक # 3114 बनाया गया

क्या सभी ने इसे अभी तक ठीक किया है? मुझे अब भी वही त्रुटि मिलती है। मेरा docker-compose version है:

docker-compose version 1.6.2, build 4d72027
docker-py version: 1.7.2
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1j 15 Oct 2014

यह वही है जो मुझे docker-compose --verbose build से मिला है:

compose.config.config.find: Using configuration files: ./docker-compose.yml
docker.auth.auth.load_config: File doesn't exist
Traceback (most recent call last):
  File "<string>", line 3, in <module>
  File "compose/cli/main.py", line 56, in main
  File "compose/cli/docopt_command.py", line 23, in sys_dispatch
  File "compose/cli/docopt_command.py", line 26, in dispatch
  File "compose/cli/main.py", line 189, in perform_command
  File "compose/cli/command.py", line 52, in project_from_options
  File "compose/cli/command.py", line 85, in get_project
  File "compose/cli/command.py", line 68, in get_client
  File "site-packages/docker/api/daemon.py", line 78, in version
  File "site-packages/docker/utils/decorators.py", line 47, in inner
  File "site-packages/docker/client.py", line 112, in _get
  File "site-packages/requests/sessions.py", line 477, in get
  File "site-packages/requests/sessions.py", line 465, in request
  File "site-packages/requests/sessions.py", line 573, in send
  File "site-packages/requests/adapters.py", line 431, in send
requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

मैंने डॉकर के टूलबॉक्स के माध्यम से डॉकटर, डॉक-माहाइन और डॉक-कम्पोज स्थापित किए।

मैंने ऊपर दिए गए सभी सुझावों की कोशिश की है लेकिन कोई भाग्य नहीं है। मुझे docker में कोई अनुभव नहीं है, इसलिए मैं इसे स्वयं नहीं समझ सका।

किसी को भी इस पर एक मूल कारण या एक वैकल्पिक हल है? मैं इसे एक नए Opensl संस्करण के साथ 1.7.0 रचना में देख रहा हूं।
यह सभी अल्पाइन से बनाया और चलाया गया है, इसलिए पर्यावरण शुद्ध होना चाहिए:

/usr/src/app # env | sed 's/DOCKER_HOST=.*/DOCKER_HOST=#redacted/' && docker version && docker ps && docker-compose version && docker-compose pull
HOSTNAME=aebfe81b5938
SHLVL=1
PYTHON_PIP_VERSION=8.1.1
HOME=/root
GPG_KEY=97FC712E4C024BBEA48A61ED3A5CA953F73C700D
DOCKER_TLS_VERIFY=1
TERM=xterm
DOCKER_CERT_PATH=/certs
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
LANG=C.UTF-8
PYTHON_VERSION=3.5.1
DOCKER_HOST=#redacted
PWD=/usr/src/app
Client:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   20f81dd
 Built:        Thu Mar 10 21:49:11 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   20f81dd
 Built:        Thu Mar 10 15:39:25 2016
 OS/Arch:      linux/amd64
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
docker-compose version 1.7.0, build 0d7bf73
docker-py version: 1.8.0
CPython version: 3.5.1
OpenSSL version: OpenSSL 1.0.2g  1 Mar 2016
Pulling registry (registry:2)...
ERROR: SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:645)

@jmmills
मेरे मामले में यह पुनर्निर्धारित CURL_CA_BUNDLE env वैरिएबल के कारण हुआ। अगर आपके पास भी ऐसा मामला है तो आपको जांच करनी चाहिए।

@PavelPolyakov मेरे एनवी डंप की जांच करें ... कोई CURL_CA_BUNDLE नहीं

@PavelPolyakov ठीक है यह अजीब है, मैं स्पष्ट रूप से

@jmmills हुह ... वही यहाँ। शायद अजगर सेट-ए-खाली को अलग-अलग करने के लिए परेशान करता है?

मैक ओएस, होमब्रे डॉकटर-कम्पोज़ और डूकर-मशीन, सिस्टम पायथन का उपयोग करते हुए। नव निर्मित मशीन के साथ: docker-machine create --driver=vmwarefusion --vmwarefusion-memory-size 1536 dev

env | grep CURL कुछ भी नहीं मिलता है
docker-compose ps रिटर्न

त्रुटि: SSL त्रुटि: होस्टनाम '172.16.129.133' 'लोकलहोस्ट' से मेल नहीं खाता

CURL_CA_BUNDLE='' docker-compose ps रिटर्न:

/usr/local/Cellar/docker-compose/1.7.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
/usr/local/Cellar/docker-compose/1.7.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
Name   Command   State   Ports 
------------------------------

मेरे पास बिल्कुल वही है - CURL_CA_BUNDLE मेरे एनवी में सेट नहीं किया जा रहा था, और इसे एक खाली स्ट्रिंग पर सेट करने से मुझे @inanimatt के समान आउटपुट मिला।

यह निश्चित रूप से एक अपस्ट्रीम बग की तरह बदबू आ रही है, मेरा अनुमान कर्ल के लिए कुछ पर्यावरण अनुकूलता कोड होगा, जिसमें "परिभाषित" और "खाली" अलग तरह से व्यवहार किया जा रहा है।

धन्यवाद,
जेसन मिल्स

• मोबाइल से भेजा गया।

24 अप्रैल, 2016 को सुबह 6:14 बजे, एलेक्स विल्सन नोटिफिकेशन @github.com ने लिखा:

मेरे पास ठीक वैसा ही है - CURL_CA_BUNDLE मेरे env में सेट नहीं हो रहा था, और इसे एक खाली स्ट्रिंग पर सेट करने से मुझे @inanimatt जैसा ही आउटपुट मिला।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें

केवल होमब्रेव संस्करण को प्रभावित करने के लिए लगता है - होमब्रेव पायथन को स्थापित करना और फिर सभी त्रुटियों को पाइप सॉल्व के माध्यम से डॉकटर-कम्पोज़ स्थापित करना।

24 अप्रैल 2016 को 14:14 बजे, एलेक्स विल्सन नोटिफिकेशन @ithub.com ने लिखा:

मेरे पास ठीक वैसा ही है - CURL_CA_BUNDLE मेरे env में सेट नहीं हो रहा था, और इसे एक खाली स्ट्रिंग पर सेट करने से मुझे @inanimatt जैसा ही आउटपुट मिला।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें

मेरा मानना ​​है कि मैंने पहले लिनक्स में इस मुद्दे की प्रतिकृति को चिपकाया था। मैं एक कार्य केंद्र में कल की दोबारा जांच कर सकता हूं

धन्यवाद,
जेसन मिल्स

• मोबाइल से भेजा गया।

24 अप्रैल, 2016 को दोपहर 12:22 बजे, मैट रॉबिन्सन सूचनाएँ @ithub.com ने लिखा:

केवल होमब्रेव संस्करण को प्रभावित करने के लिए लगता है - होमब्रेव पायथन को स्थापित करना और फिर सभी त्रुटियों को पाइप सॉल्व के माध्यम से डॉकटर-कम्पोज़ स्थापित करना।

24 अप्रैल 2016 को 14:14 बजे, एलेक्स विल्सन नोटिफिकेशन @ithub.com ने लिखा:

मेरे पास ठीक वैसा ही है - CURL_CA_BUNDLE मेरे env में सेट नहीं हो रहा था, और इसे एक खाली स्ट्रिंग पर सेट करने से मुझे @inanimatt जैसा ही आउटपुट मिला।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें

एक ही समस्या यहाँ के बाद से मैं अद्यतन काढ़ा-संस्करण 1.7 का उपयोग कर काढ़ा।

$ docker-compose ps
ERROR: SSL error: hostname '192.168.99.100' doesn't match 'localhost'

$ docker-compose version
docker-compose version 1.7.0, build unknown
docker-py version: 1.8.0
CPython version: 2.7.10
OpenSSL version: OpenSSL 0.9.8zh 14 Jan 2016

समस्या को हल करने के CURL_CA_BUNDLE env var को खाली करना:

CURL_CA_BUNDLE= docker-compose ps
/opt/boxen/homebrew/Cellar/docker-compose/1.7.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
/opt/boxen/homebrew/Cellar/docker-compose/1.7.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
/opt/boxen/homebrew/Cellar/docker-compose/1.7.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
   Name                 Command               State    Ports
------------------------------------------------------------

1.6.2 पर डाउनग्रेड करना भी समस्या को हल करता है।

$ brew switch docker-compose 1.6.2
Cleaning /opt/boxen/homebrew/Cellar/docker-compose/1.4.2
Cleaning /opt/boxen/homebrew/Cellar/docker-compose/1.5.1
Cleaning /opt/boxen/homebrew/Cellar/docker-compose/1.5.2
Cleaning /opt/boxen/homebrew/Cellar/docker-compose/1.6.0
Cleaning /opt/boxen/homebrew/Cellar/docker-compose/1.6.2
Cleaning /opt/boxen/homebrew/Cellar/docker-compose/1.7.0
3 links created for /opt/boxen/homebrew/Cellar/docker-compose/1.6.2

$ docker-compose ps
   Name                 Command               State    Ports
------------------------------------------------------------

CURL_CA_BUNDLE को अक्षम करने के बजाय आप इसका उपयोग कर सकते हैं:
CURL_CA_BUNDLE = ~ / .docker / मशीन / मशीनें / डिफ़ॉल्ट / ca.pem docker- रचना ps

मैं शायद पहले वाला नहीं हूं, जो इसे ऊपर ले आया हो, लेकिन क्या यह सहज नहीं है कि कर्ल पर्यावरण चर का कोई प्रभाव है जो कभी भी एक असंबंधित पायथन अनुप्रयोग पर होता है?

धन्यवाद,
जेसन मिल्स

• मोबाइल से भेजा गया।

7 मई, 2016 को 3:22 बजे, लोरेंजो सिसिलिया सूचनाएं @github.com ने लिखा:

CURL_CA_BUNDLE को अक्षम करने के बजाय आप इसका उपयोग कर सकते हैं:
CURL_CA_BUNDLE = ~ / .docker / मशीन / मशीनें / डिफ़ॉल्ट / ca.pem docker- रचना ps

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें

मैं इस समस्या में भाग गया और समस्या पर्यावरण चर REQUESTS_CA_BUNDLE के साथ स्व-हस्ताक्षरित समारोहों के लिए एक कस्टम स्थान की ओर इशारा करती थी। यह किसी को भी मदद करता है।

• माइकल हाउश

@aboutlo यह काम करता है - यह अन्य ca.pem फ़ाइल के साथ काम नहीं करता था, केवल इस एक के साथ। मैं विंडोज पर भी हूं इसलिए मेरे पास एक अधिक वूडू कॉन्फ़िगरेशन है, धन्यवाद!

Ndg-httpsclient की स्थापना रद्द करें (पाइप के साथ - संस्करण 0.4.0 था) ने मेरे लिए इस मुद्दे को हल किया, मेरी पोस्ट यहाँ देखें: https://github.com/docker/compose/issues/3365

मैंने docker-compose और docker-py को डिबग किया और यह पता लगाया कि आपको कमांड में पर्यावरण चर या विकल्पों का उपयोग करना चाहिए। आपको ये नहीं मिलाना चाहिए। यदि आप कमांड में भी निर्दिष्ट करते हैं - तो आपको TLSConfig ऑब्जेक्ट के रूप में सभी विकल्पों को निर्दिष्ट करना होगा, क्योंकि अब TLSConfig ऑब्जेक्ट पूरी तरह से कमांड विकल्पों से बना है और पर्यावरण चर से निर्मित TFSConfig ऑब्जेक्ट को संचालित करता है।

@ m-housh OMG उस टिप के लिए धन्यवाद! ठीक वैसा ही मेरे साथ हुआ! मेरे वातावरण से REQUESTS_CA_BUNDLE निकाले और इसने मेरे लिए इस समस्या को हल कर दिया।

मैंने उसी समस्या का सामना किया है। पहले मैं हालांकि यह है क्योंकि ओपनएसएसएल संस्करण अंतर (पायथन में 1.0.2 था लेकिन ओएस में 0.9.8 था) मैंने उन्हें 1.0.2 दोनों बनाया लेकिन यह अभी भी काम नहीं किया।
मैंने अपनी समस्या को केवल do ssh द्वारा हल किया है और फिर अधिकृत कुंजियों में अपने प्रमाणपत्र की जांच करके इसे अपडेट किया है। दिलचस्प है कि किसी तरह यह वहां गलत प्रमाणपत्र था।

कृपया इन चरणों का पालन करें:

boot2docker ssh
docker<strong i="10">@boot2docker</strong>:~$ cat .ssh/authorized_keys

जांचें कि क्या यह प्रमाणपत्र वास्तव में आपके कंप्यूटर से प्रमाण पत्र है। अगर न सिर्फ इस फाइल में अपना कॉपी करें और इसे सेव करें। फिर बस चलाएं:

docker-compose up

इसने मेरे लिए काम किया और आशा है कि यह मदद करता है।

इश्यू ग्रूमिंग: यहाँ वर्णित विभिन्न विफलता मोड और उपयोगकर्ता त्रुटि / ग़लतफ़हमी परिदृश्य (सभी बड़े पैमाने पर ऐतिहासिक) की एक किस्म प्रतीत होती है।

मैं कुछ भी नहीं देख रहा हूं, जो रचना में सक्रिय चल रहे मुद्दे की ओर इशारा करता है, इसलिए मैं इस मुद्दे को बंद कर रहा हूं। यदि आप अभी भी आधुनिक संस्करणों के साथ संबंधित त्रुटि देख रहे हैं, तो कृपया अपने परिदृश्य आदि के पूर्ण विवरण के साथ एक ताज़ा मुद्दा खोलें।