أعتقد أنني أعاني من نفس الشيء أثناء محاولة استخدام مرشح الإصدار 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 ، باستثناء إصدار عميل Go الخاص بي هو go1.3.3 . يتم أيضًا تثبيت My python / openssl عبر Homebrew. قد يكون لها علاقة بها؟

تحرير: في الواقع يبدو أن Homebrew لا يربط opensl ، لذلك أنا أستخدم إصدار OSX الافتراضي: OpenSSL 0.9.8za 5 Jun 2014 .

كانت المشكلة هي Homebrew python.

docker-compose الآن بعد إلغاء تثبيت homebrew python / openssl ، وتثبيت pip مع easy_install ، وإعادة تثبيت docker-composer باستخدام نظام python.

adambiggs الحل الخاص بك يعمل! شكر!

لقد نجح هذا أيضًا بالنسبة لي ، فأنا أستخدم جهاز Mac جديدًا وقمت بإعداده باستخدام homebrew python. كان هذا الخطأ مع التين التواصل مع عامل الميناء. اتبعت نصيحة adambiggs حرفيًا Python أيضًا ولكن بغض النظر عن اعتقادي أن هذا الجهاز سيستخدم نظام python لفترة.

هذا يحدث لي أيضا. ولا أريد استخدام نظام python ، هل لدى أي شخص حل آخر؟

هل جربت استخدام الثنائي؟ هل لديك نفس المشكلة؟

لا لم أجرب البرنامج الثنائي.
إذا كنت لا ترغب في تثبيته في نظام python الخاص بك ، فهناك حل بديل آخر وهو استخدام virtualenv (المجمع).

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

تم العثور على حل أفضل باستخدام pyenv للعودة إلى Python 2.7.8:

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

تحرير: نيفيرمايند ، قدم pyenv مجموعة من مشاكله الخاصة ...

سبب هذا الخطأ بالنسبة لي هو أن المشروب المنزلي openssl لم يكن مرتبطًا بـ / usr / local / bin / openssl.

openssl version

عاد OpenSSL 0.9.8zc 15 أكتوبر 2014 وليس OpenSSL 1.0.1j 15 أكتوبر 2014

ادارة

brew link --force openssl

وإعادة تثبيت الشكل حل المشكلة.

مثير للاهتمام ، ولكن إصدار OpenSSL الخاص بي هو

aanand في حالتي ، لا يحتوي النظام الثنائي على هذه المشكلة.

لقد حصلت على هذا الخطأ عندما قمت بتثبيت التين من خلال النقطة ، وليس البيرة المنزلية. أصلح لي sudo pip uninstall fig و brew install fig ذلك.

+1 لحل NotBobTheBuilder ، يعمل أيضًا معي

: +1: لـ NotBobTheBuilder

NotBobTheBuilder حل لطيف التركيب غير متاح على البيرة حتى الآن للأسف.

ocasta ماذا عن هذا التحذير

هذه الصيغة هي برميل فقط.
يوفر نظام التشغيل Mac OS X هذا البرنامج بالفعل وتثبيت إصدار آخر بتنسيق
يمكن أن يسبب التوازي جميع أنواع المشاكل.

أوقفت Apple استخدام OpenSSL لصالح مكتبات التشفير TLS و crypto الخاصة بها

ممتاز NotBobTheBuilder - لقد أصلح الأمر معي أيضًا.

من يعرف مصدر هذه المشكلة؟ هذا يحدث لي مع التين. أفضل التمسك بـ pip install fig مثلما أفعل الآن. سارت الأمور على ما يرام قبل أسبوعين ، لا أعرف ما الذي تغير في نظامي

نظام OpenSSL الخاص بي هو OpenSSL 0.9.8zc 15 Oct 2014 ، متجر البيرة الخاص بي هو أحدث ولكنه غير مرتبط.

... أعتقد أنه قد كسر عندما قمت بالترقية إلى Python 2.7.9 ، يبدو أن هناك بعض الأخطاء المتعلقة بـ SSL معه ... يبدو كثيرًا مثل هذا:
https://bugs.freebsd.org/bugzilla/show_bug.cgi؟id=196431
http://bugs.python.org/issue23052

تشغيل brew link --force openssl وإعادة تثبيت التين لم يفعل شيئًا بالنسبة لي.

هل يحتاج التين إلى تحديث للتغلب على تغييرات SSL في Py 2.7.9؟
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 ... أفترض أن هذه الشهادات لا بأس بها لأنها كانت تعمل دائمًا وقمت بترقية b2d حتى لا تنتهي صلاحيتها.

حسنًا ، يبدو أن لغة Python الخاصة بي (المثبتة عبر homebrew) تستخدم الإصدار المنزلي من OpenSSL على الرغم من:

$ 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 لم يساعد :)

لقد جربت إصدارًا مثبتًا مسبقًا من python (2.7.8_2) عبر $ brew switch python 2.7.8_2 بنفس المشكلة (حتى لو كانت رسالة الخطأ مختلفة قليلاً). لذا يبدو أن إصدار python 2.7.9 ليس هو المشكلة.

ثم حاولت التبديل إلى إصدار Opensl أقدم ، من 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 لذا فإن تغيير الإصدارات له بعض التأثير بالتأكيد

يتمثل أحد الحلول البديلة في تشغيل Docker-compose في حاوية:

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##*/}"'

يتطلب هذا تعريض المنفذ 2376 في VirtualBox:

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

نجحت إجابة

+1 @ kretz brew switch يفتح على 1.0.1j_1
صنع الحيلة

مفتاح التحضير يفتح لي 1.0.1j (لاحظ عدم وجود _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

كان الحل هو إنشاء Virtualenv باستخدام Python 2.7.8 ، بدلاً من 2.7.9 التي حصلت عليها من الشراب.

حلول مختلفة ... هل لدى أي شخص نظرة ثاقبة على المشكلة الحقيقية؟

ما علاقة App Engine بأي شيء؟

في 11 مارس 2015 الساعة 18:09 ، كتب Ryan Small [email protected] :

أنا متأكد من أن أياً من عناصر محرك التطبيق لا يعمل مع Python 2.7.9

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/docker/compose/issues/890#issuecomment -78329652.

anentropic تحتاج إلى تثبيت الإصدار الأقدم من opensl قبل أن تتمكن من استخدامه (التبديل إليه).

# 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 صباحًا anentropic [email protected]
كتب:

لقد قمت بتثبيت الشراب opensl101 لكنه لم يمنحني إمكانية ذلك
قم بالتبديل إلى 1.0.1j ... أعطاني 1.0.1 لتر وكنت قلقًا من أنه سيحدث
تخلط بين نظامي لأنها حزم تخمير منفصلة ولدي بالفعل
1.0.2 بالتوازي

لا يبدو أنه يساعد ولكن ربما لم أذهب بعيدا بما فيه الكفاية

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/docker/compose/issues/890#issuecomment -78340580.

لذلك يبدو أنني أتلقى هذه المشكلة أيضًا ، حيث تعمل على نظام التشغيل Mac OSX. باستخدام docker-compose ، هذا هو ملف .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 ما الذي يجعلك تعتقد أن هذا مرتبط بهذه المشكلة؟

لمعلوماتك ، بعد الكفاح كثيرًا مع هذا ، يبدو أن هذه مشكلة boot2docker.
ما نجح بالنسبة لي هو تعطيل TLS. لا توجد طريقة سهلة الاستخدام للقيام بذلك حتى الآن ، ولكن الإرشادات موضحة هنا:
https://github.com/deis/deis/issues/2230

في الأساس ، أنت بحاجة إلى:

boot2docker ssh
sudo صدى 'DOCKER_TLS = لا'> / var / lib / boot2docker / profile

ثم أعد تشغيل boot2docker ، أي
توقف boot2docker
بدء boot2docker

وشيء من هذا القبيل لـ ~ / .bashrc الخاص بك (تأكد من صحة عنوان IP)

تصدير DOCKER_HOST = tcp: //192.168.59.103: 2375
قم بإلغاء ضبط DOCKER_CERT_PATH
قم بإلغاء ضبط DOCKER_TLS_VERIFY

في bashrc الخاص بك ، لماذا لا تملك $ (boot2docker shellinit)

يجب أن تساعد في كل شيء بشكل صحيح؟

أعني أنه لا يزال يتعين عليك القيام بحل TLS.
في 21 مارس 2015 23:05 ، كتب "coderfi" [email protected] :

لمعلوماتك ، بعد الكفاح كثيرًا مع هذا ، يبدو أن هذا ملف
مشكلة boot2docker.
ما نجح بالنسبة لي هو تعطيل TLS. لا توجد طريقة سهلة الاستخدام حتى الآن
للقيام بذلك ، ولكن التعليمات موضحة هنا:
deis / deis # 2230 https://github.com/deis/deis/issues/2230

في الأساس ، أنت بحاجة إلى:

boot2docker ssh
sudo صدى 'DOCKER_TLS = لا'> / var / lib / boot2docker / profile

ثم أعد تشغيل boot2docker ، أي
توقف boot2docker
بدء boot2docker

وشيء من هذا القبيل إلى ~ / .bashrc الخاص بك
تأكد من صحة IP

تصدير 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) ؟

نعم فعلت ، تحديث تعليقي. ديرب.

أستطيع أن أؤكد أن حل coderfi لتعطيل TLS يناسبني!

يسعدني أنه نجح معك. :)

Matt نعم ، أنت محق بشأن نصيحة توسيع shell init.
ومع ذلك ، قد لا يعمل ذلك إذا لم يبدأ boot2docker بعد ، لذلك أنا فقط
جعل المثال صريحًا.

فاي
في 26 مارس 2015 10:18 صباحًا ، كتب "anentropic" [email protected] :

يمكنني أن أؤكد أن حلcoderfi https://github.com/coderfi لـ
تعطيل يعمل TLS بالنسبة لي!

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/docker/compose/issues/890#issuecomment -86630313.

ربما يكون هذا واضحًا ، لكن أولئك الذين يعطلون TLS أو يخفضون مستوى OpenSSL لمجرد الحصول على هذا العمل يجب أن يتعاملوا بحذر اعتمادًا على ما يفعلونه.

لا يتعلق هذا بالجميع ، ولكن كان لدي خطأ مماثل منبثق أثناء تثبيت pip باستخدام Dockerfile سحب من gliderlabs/alpine:3.1 - الحد الأدنى من حاوية Linux من البرنامج والطاقم. كانت المشكلة أنني لم أقم بتثبيت حزمة شهادات النظام ، وتمت معالجة المشكلة عن طريق تثبيت الحزمة قبل تثبيت pip وتشغيل ملف المتطلبات:

RUN apk-install -X ca-certificates

الحلول المقترحة لم تعمل حقًا بالنسبة لي. تعذر التبديل إلى أي من إصدارات OpenSSL 1.0.1. في النهاية ، اكتشفت أن إلغاء تثبيت جميع إصدارات إنشاء عامل الإرساء المثبتة بنقطة وتنفيذ brew install docker-compose بطريقة ما يعمل بطريقة ما.

نجحت الحلول المذكورة أعلاه ولكنها كانت مرهقة للغاية بالنسبة لي. أصلح boot2docker upgrade كل شيء في نهايتي.

لدي بالفعل أحدث إصدار من boot2docker ولا يعمل معي بدون الإصلاحات المذكورة أعلاه

يقترح مطورو Homebrew أنه يجب ترقية docker-py و docker-compose إلى استخدام requests 2.6.0

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

نأمل أن يساعد هذا شخصًا ما ... غير متأكد من الحل ولكن إذا كنت تستخدم Charles كوكيل Mac OS X ، فسيؤدي ذلك إلى ظهور هذه الرسالة.

FWIW ، أدى تثبيت docker-compose عبر pip إلى تشغيل عامل الإرساء نفسه (أدى التثبيت من خلال curl على OS X Mavericks إلى حدوث خطأ illegal operation ). في وقت لاحق ، تلقيت أيضًا خطأ SSL. يبدو أن تشغيل brew link --force openssl && brew switch openssl 1.0.1j قد أصلحه لي.

rseymour الإجابة عملت بالنسبة لي

بالنسبة لأولئك الذين فشلوا في العثور على openssl-1.0.1j في الشراب - يمكنك الحصول على نسخة قديمة من وصفة openssl من github repo والاستفادة منها:

» 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.1 م لكنها لم تنجح.
لذا جربت طريقة lazyval ، فهي تعمل بالنسبة لي.
هذا ما فعلته.

قم بتثبيت الشراب https://raw.githubusercontent.com/Homebrew/homebrew/62fc2a1a65e83ba9dbb30b2e0a2b7355831c714b/Library/Formula/openssl.rb
يفتح مفتاح الشراب 1.0.1j_1
brew unink openssl101 // لأنني ربطت 1.0.1m قبل ذلك
رابط المشروب openssl --force
عامل بناء ps

شكرا لك!!

أنا أقوم حاليًا بالتحقيق في هذا ، حيث نحتاج الآن إلى إنشاء الثنائيات على Python 2.7.9+.

_الانتقال من # 1427_

الخادم:

• CoreOS مستقر
• Docker 1.5.0.0 تحديث

عميل:

• CentOS 6.6 ، 64 بت
• نواة 2.6.32-042stab105.14.0
• عميل Docker 1.5.0
• عامل تركيب 1.2.0
• تم وضع شهادات SSL عند ~/.docker/{ca.pem,cert.pem,key.pem}
• DOCKER_HOST=tcp://docker-builder:2376
• DOCKER_TLS_VERIFY=1

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

محاولة استخدام docker-compose ، مثبتًا إما عن طريق curl أو pip install --upgrade مع python 2.7 ، نحصل على خطأ 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 ، بشكل فردي وجماعي.

لكي نكون واضحين: هذا الإعداد يعمل بشكل رائع مع برنامج Docker daemon فقط ، ولكن هناك شيء ما حول -compose غير صحيح.

بعض الملاحظات:

1. يحتوي الإصدار الثنائي Compose 1.3.0 RC1 لـ OSX على هذا الخطأ. ربما ليس من قبيل الصدفة ، فهذه هي المرة الأولى التي تم بناؤها ضد Python 2.7.9 - قبل ذلك كانت 2.7.6.
2. بغرابة ، يمكنني التكاثر مقابل boot2docker VM ، ولكن ليس ضد Virtualbox VM الذي يوفره الجهاز. ehazlett ، nathanleclaire ، tianon - هل توجد أية رؤى هناك؟
3. لأي شخص يواجه هذا الأمر عند تثبيت Compose مع Pip ، يرجى الإبلاغ عن إخراج الأوامر التالية:

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

على جهازي المحلي ، حيث يمكنني إعادة إنتاج الخطأ ، لدي Python 2.7.10 و OpenSSL 1.0.2a 19 Mar 2015 .

1. تم إبلاغ Homebrew بهذا الأمر ، ويقول بعض الأشخاص إنهم نجحوا في إعادة تثبيت Python و OpenSSL ، لكن ذلك لم ينجح معي. https://github.com/Homebrew/homebrew/issues/38226

حسنًا ، هذا غريب حقًا. ما هو إصدار b2d الذي تستخدمه مقابل الإصدار
من الآلة؟ كلانا يستخدم b2d لذا لست متأكدًا مما سيكون مختلفًا
إلى جانب الإصدار.

سوف أقوم بالتثبيت عبر نقطة على جهاز OS X الخاص بي وأرى ما سأحصل عليه.

يوم الخميس ، 28 مايو 2015 ، الساعة 9:19 صباحًا ، إخطارات عناند براساد@github.com
كتب:

بعض الملاحظات:

1.

يحتوي الإصدار الثنائي Compose 1.3.0 RC1 لـ OSX على هذا الخطأ. على الاغلب لا
من قبيل الصدفة ، هذه هي المرة الأولى التي يتم بناؤها فيها ضد Python 2.7.9

• من قبل ، كان 2.7.6.
  2.

بغرابة ، يمكنني التكاثر مقابل boot2docker VM ، ولكن ليس ضد ملف
Virtualbox VM الذي يوفره الجهاز. تضمين التغريدة
https://github.com/ehazlett،nathanleclaire
https://github.com/nathanleclaire ، @ tianon
https://github.com/tianon - هل هناك أية رؤى؟
3.

من فضلك لأي شخص يعاني من هذا عند تثبيت Compose مع Pip
قم بالإبلاغ عن إخراج الأوامر التالية:

$ python -V
استيراد ssl $ python -c ؛ طباعة ssl.OPENSSL_VERSION '

على جهازي المحلي ، حيث يمكنني إعادة إنتاج الخطأ ، لدي بايثون
2.7.10 و OpenSSL 1.0.2a 19 مارس 2015.
4.

تم إبلاغ Homebrew بهذا الأمر ، ويقول بعض الأشخاص إنهم فعلوه
نجاح إعادة تثبيت Python و OpenSSL ، لكنها لم تنجح معي.
البيرة / البيرة # 38226
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)

هل هناك شيء مختلف حول إنشاء الشهادات ، ربما؟ يبدو أن لدي المزيد من الملفات في مسار سيرت جهازي أكثر من ملف boot2docker.

$ $(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
(الخادم هو مجرد نسخة محلية للمضيف في الجهاز). سأخلق باسم
جيدًا وفحص الشهادات لمعرفة الفرق الذي قد يكون.

يوم الخميس 28 مايو 2015 الساعة 9:30 صباحًا ، Aanand Prasad [email protected]
كتب:

إصدار $ boot2docker
إصدار Boot2Docker-cli: v1.6.2
Git الالتزام: cb2c3bc

$ آلة عامل الإرساء - الإصدار
إصدار آلة الإرساء 0.2.0 (8b9eaf2)

هل هناك شيء مختلف حول إنشاء الشهادات ، ربما؟ يبدو أن لدي المزيد
الملفات الموجودة في جهازي cert dir من الموجودة في boot2docker one.

$ (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 / المستخدمون/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 / المستخدمون / 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. يقوم البرنامج النصي التجريبي الخاص بـ

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)

لا يزال يعمل مع الجهاز الظاهري المزود آليًا ، على الرغم من:

$ 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 في البرنامج النصي للاختبار) ، فإنه يفشل مع نفس الخطأ ضد boot2docker-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-rc1 عبر curl (الإصدار الثنائي ، وليس من خلال النقطة) وحصلت على نفس الخطأ كما كان من قبل في docker 1.6.2 daemon:

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

نعم - تم إنشاء ثنائي RC1 باستخدام Python 2.7.9 و OpenSSL 1.0.2a ، والذي يبدو أنه أحد التوليفات الإشكالية.

هذا منطقي لأنني أعتقد أن إنشاء الشهادة في b2d موجود على الجهاز الظاهري
في حين أن الآلة تولدها في الآلة. يمكننا الكشف عن وإضافة
اسم الجهاز لشبكات SAN إذا لزم الأمر. في الواقع ربما يكون ذلك جيدًا
خاصة بالنسبة لـ b2d VMs. أعتقد أن سبب نجاحها الآن هو أنك أنت
الوصول إلى المحرك باستخدام عنوان IP الذي يضيفه الجهاز باعتباره IP SAN. هناك
العلاقات العامة مفتوحة للسماح بشبكات SAN إضافية تعسفية والتي ستعمل أيضًا.

في يوم الخميس الموافق 28 مايو 2015 ، كتب Aanand Prasad [email protected] :

انظر أيضًا docker / docker-py # 465
https://github.com/docker/docker-py/issues/465. تضمين التغريدة
https://github.com/garethr البرنامج النصي للاختبار هناك يعيد إنتاج الخطأ لـ
أنا أيضًا ، بعد إجراء تعديل واحد لتعطيل التحقق من اسم المضيف:

من docker.client استيراد العميل من docker.utils استيراد kwargs_from_env

kwargs = kwargs_from_env ()
kwargs ['tls']. assert_hostname = خطأ

العميل = العميل (** kwargs) print client.version ()

$ Eval "$ (boot2docker shellinit)" && python test.py
الكتابة /Users/aanand/.boot2docker/certs/boot2docker-vm/ca.pem
الكتابة /Users/aanand/.boot2docker/certs/boot2docker-vm/cert.pem
الكتابة /Users/aanand/.boot2docker/certs/boot2docker-vm/key.pem
Traceback (أحدث مكالمة أخيرة):
ملف "test.py" ، السطر 8 ، بتنسيق
طباعة client.version ()
ملف "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py" ، السطر 1108 ، في الإصدار
إرجاع self._result (self._get (url) ، json = صحيح)
ملف "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py" ، السطر 106 ، في _get
إرجاع self.get (url، * _self._set_request_timeout (kwargs))
ملف "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py" ، السطر 477 ، في get
إرجاع self.request ('GET' ، url ، * _kwargs)
ملف "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py" ، السطر 465 ، في الطلب
Resp = self.send (الإعدادية ، * _send_kwargs)
ملف "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py" ، السطر 573 ، في الإرسال
r = adapter.send (طلب ، * _kwargs)
ملف "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py" ، السطر 431 ، في الإرسال
رفع SSLError (e، request = request)
request.exceptions.SSLE خطأ: [SSL: CERTIFICATE_VERIFY_FAILED] فشل التحقق من الشهادة (_ssl.c: 590)

لا يزال يعمل مع الجهاز الظاهري المزود آليًا ، على الرغم من:

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

إذا قمت بإعادة تمكين التحقق من اسم المضيف (عن طريق التعليق خارج اسم المضيف
في البرنامج النصي للاختبار) ، فإنه يفشل مع الخطأ _ نفس الخطأ مقابل ملف
boot2docker-cli VM ، ولكن خطأ مختلف _ ضد الجهاز VM ، والذي
قد تكون ذات صلة أو لا تكون ذات صلة:

Traceback (أحدث مكالمة أخيرة):
ملف "test.py" ، السطر 8 ، بتنسيق
طباعة client.version ()
ملف "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py" ، السطر 1108 ، في الإصدار
إرجاع self._result (self._get (url) ، json = صحيح)
ملف "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py" ، السطر 106 ، في _get
إرجاع self.get (url، * _self._set_request_timeout (kwargs))
ملف "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py" ، السطر 477 ، في get
إرجاع self.request ('GET' ، url ، * _kwargs)
ملف "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py" ، السطر 465 ، في الطلب
Resp = self.send (الإعدادية ، * _send_kwargs)
ملف "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py" ، السطر 573 ، في الإرسال
r = adapter.send (طلب ، * _kwargs)
ملف "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py" ، السطر 431 ، في الإرسال
رفع SSLError (e، request = request)
request.exceptions.SSLE خطأ: لم يتم العثور على حقول اسم مشترك أو عنوان موضوع مناسب

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/docker/compose/issues/890#issuecomment -106363305.

حسنًا ، أعتقد أنني وصلت إلى إصلاح لنظام التشغيل OS X: https://github.com/docker/compose/pull/1474

سيتضمن إصلاحه لنظام Linux تحديث Dockerfile للتثبيت على Python 2.7.9 و OpenSSL 1.0.1 ، والذي سيكون مسعى ممتعًا نظرًا لأنه يبدأ من debian:wheezy (وهو ما يفعله للتأكد من أننا نستخدم ما يكفي من glibc القديم - راجع https://github.com/docker/compose/pull/505).

التبديل إلى 1.0.1k كما هو موضح في تعليق kretz وتثبيت 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 ويبدو أن إنشاء عامل الإرساء يعمل كما هو متوقع:

❯ 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 لماذا بالضبط تقوم بتثبيت pyOpenSSL إلى 0.14؟

+1 لـ @ kretz إجابة :)

+1 نفس المشكلة :( يبدو أن عامل الإرساء معطل تمامًا في OSX؟

نجح حل Docker-Compose عبر نقطة في Cygwin

التعامل مع أحد الأخطاء المتغيرة على Centos7 VM ، والتي تعمل كعميل لبدء الحاويات على جهاز الإرساء:

[ root @ xxxx cm] # عامل إنشاء ملاحظة
خطأ في SSL: لم يتم العثور على حقول subjectAltName أو الاسم الشائع المناسب

كان هذا عابرًا ؛ يمكنني تسجيل الخروج والدخول مرة أخرى وعدم رؤية الخطأ لفترة من الوقت. الآن نراه دائما.

[ root @ xxxx cm] # python -c استيراد ssl؛ طباعة (ssl.OPENSSL_VERSION) '
OpenSSL 1.0.1e-fips 11 فبراير 2013

[ root @ xxxx cm] # إصدار عامل ميناء
إصدار العميل: 1.6.2
إصدار واجهة برمجة تطبيقات العميل: 1.18.1
إصدار Go (العميل): go1.4.2
Git الالتزام (العميل): ba1f6c3 / 1.6.2
OS / Arch (العميل): linux / amd64
إصدار الخادم: سرب / 0.2.0
إصدار Go (الخادم): go1.3.3
Git الالتزام (الخادم): 48fd993
OS / Arch (الخادم): linux / amd64

[ root @ xxxx cm] # docker-compose --version
عامل تركيب 1.2.0

لست متأكدًا من كيفية تطبيق بعض الإصلاحات المذكورة أعلاه في بيئتي. أنا لا أستخدم boot2docker ؛ التعامل مع docker 1.6.2 مباشرة على سطر أوامر bash.

مرحبا. لقد فتحت بالفعل مشكلة لهذا السبب لا يمكنني إصلاحها. لقد جربت الكثير من الأشياء ، مثل التثبيت والتركيب باستخدام إصدارات pip / brew / newst. مثل Opensl الذي جرب إصدارات 0.x 1.0.2x وما زال لا يعمل.

ملاحظة: أنا لا أستخدم boot2docker. لدي جهاز VM الخاص بي الذي أقوم بإنشائه عبر المتشرد ، وقم بإنشاء الشهادات وإطلاق برنامج عامل الميناء الخفي معهم. يبدو أنه يعمل مع عامل ميناء لذا فإن المشكلة لا تأتي من شهاداتي.

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

بعد القراءة هنا والتلاعب بتثبيت الحزم المقترحة:

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

تم تغيير رسالة الخطأ من Docker-compose:

[ root @ xxx cm] # docker-compose up -d
/usr/lib/python2.7/site-packages/requests/packages/urllib3/connection.py:251: تحذير الأمان: الشهادة لا تحتوي على subjectAltName ، تراجع للتحقق من commonName لـ الآن. يتم إزالة هذه الميزة بواسطة المتصفحات الرئيسية ويتم إهمالها بواسطة RFC 2818. (راجع https://github.com/shazow/urllib3/issues/497 للحصول على التفاصيل.)
تحذير الأمان
خطأ في طبقة المقابس الآمنة: اسم المضيف "xx.xx.xx.xx" لا يطابق بلا

(الرباعية المنقطة التي أنا xx'd بها هي من السرب الرئيسي / مضيف عامل الميناء).

هل يمكن معالجة هذه المشكلة أيضًا عن طريق تحرير الشهادة أو إعادة إنشائها؟

ملحق: تم إنشاء الشهادات على هذه الأجهزة الظاهرية بواسطة "إنشاء جهاز عامل إرساء."

هل يمكن أن نتعامل مع خطأ في آلة الرصيف ينتج عنه شهادة غير مفصلة بشكل كاف؟

لا أرى هذا الخطأ إلا مع مضيفات Docker التي تم إنشاؤها بواسطة جهاز عامل ميناء. أعتقد أنه لم يتم إنشاء شهادات SSL بشكل صحيح؟

هل لدى أي شخص حل أو حل لإصلاح هذا؟ هذا بعض الشيء بالنسبة لي مانع الآن: /

prologic هل تحصل على الخطأ في الملف الثنائي أم مع إنشاء نقطة مثبتة؟ إذا كان الخيار الأخير ، فحاول تثبيت requests[security] أيضًا.

aanand شكرا! سأحاول ذلك وأبلغ إذا نجح ذلك أم لا!

prologic نريد تجميع requests[security] بدلاً من الاعتماد على وحدة SSL الخاصة بعربة Python ؛ نحن نتتبع الجهد في # 1530.

aanand شكرا لك! لقد عملت بشكل مثالي :)

coderfi لقد نجح حلك معي ، شكرًا

بناءaanand 2 يونيو يعمل بشكل جيد بالنسبة لي. حظا سعيدا في سحق هذا الخطأ المؤلم.

neilsarkar تصادف أنني أدير وكيل تشارلز ، لقد أنقذني تعليقك. : +1:

أنا أستخدم OS X 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

هذا هو الجزء الذي يرمي استثناء الأمان

كانت المشكلة بالنسبة لي هي أنه حتى إذا قمت بتحديد رابط الشراب - لا يزال استخدام القوة المفتوحة ، ولا يزال استخدام fig / docker-compose / usr / bin / openssl.

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

هذا عمل معي. الآن لم أعد أتلقى الرسالة المزعجة.

FYI، brew fig / docker-compose recipe تستخدم نظام python ، لذلك حتى إذا قمت بتثبيت python عبر pyenv أو brew ، فإن brew install fig / docker-compose سيظل يستخدم النظام openssl lib إذا كان متاحًا ، وإلا فإنه يقوم بتثبيت إصدار آخر.

على جهاز MAC الخاص بي في العمل ، قمت بحلها باستخدام pyenv install 2.7.8 ، ثم easy_install pip ، و pip install docker-compose.

ولكن على جهاز Mac في المنزل ، "كلا تشغيل yosemite" فعلت الشيء نفسه وما زلت أتلقى التحذير.

سوف نستمر في الحفر.

dtunes - السبب الأساسي (كما هو مذكور أعلاه https://github.com/boot2docker/boot2docker/issues/808. شيء system-python / homebrew-python هو رنجة حمراء ، لأنه يعتمد فقط على ما إذا كنت مرتبطًا ببرنامج OpenSSL جديد أو قديم.

نعم ، لقد رأيت تلك التذكرة. الشيء الذي يزعجني هو أنه على جهاز Mac الخاص بي في العمل ، بعد تجربة الأساليب المختلفة فوق أي شيء.
ثم قمت بنقل / usr / bin / openssl إلى / usr / bin / openssl_old ، وقمت بتثبيت أحدث opensl باستخدام المشروب المنزلي وفرض ربطه. عندها فقط فعلت ما يلي:

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

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

dtunes - من أجل إعادة بناء جميع التبعيات الخاصة بك ، تحتاج إلى إزالة ~/Library/Caches/pip حتى لا تتم إعادة استخدام العجلة الثنائية المخزنة مؤقتًا والمبنية على OpenSSL الخاطئ.

كتب glyph :

السبب الجذري (كما هو موضح أعلاه) هو boot2docker / boot2docker # 808. شيء system-python / homebrew-python هو رنجة حمراء ، لأنه يعتمد فقط على ما إذا كنت مرتبطًا ببرنامج OpenSSL جديد أو قديم.

glyph أو aanand ، هل يشير ذلك إلى أن إصلاح aanand (حل aanand ، إذا تمت معالجة boot2docker / boot2docker # 808 بشكل صحيح ، فهل يجب دعم # 1474؟ هل وضع الأمل في إصدار التشفير القادم (انظر هذا وهذا ) هو أيضًا خدعة حمراء؟

كتب aanand :

لاحظ أنه لا يمكنني إعادة إنتاج هذا الخطأ مقابل Boot2Docker VM المزود بجهاز عامل إرساء - يحدث ذلك فقط مقابل جهاز افتراضي مزود بأمر boot2docker.

ehazlett كتب :

هذا منطقي لأنني أعتقد أن إنشاء الشهادة في b2d موجود على الجهاز الظاهري بينما تقوم الآلة بتوليدها في الجهاز.

ربما أسيء فهمي ، ولكن هناك الكثير من الأحاديث التي تلقي باللوم على مجموعات Python / OpenSSL المتنوعة من جانب المضيف في هذا والمشكلات ذات الصلة. إذا كان مصدر المشكلة عبارة عن OpenSSL معطل موزع مع b2d ، فلست متأكدًا من أن أفضل نهج هو التأكد من أن OpenSSL من جانب المضيف في Compose معطل بالمثل؟ بالنسبة لما يستحق ، من غير المرجح أن تحل هذه الأنواع من التشوهات من جانب المضيف هذه المشكلة لأولئك الذين يقومون بتشغيل b2d عبر (على سبيل المثال) Vagrant ، والوصول إليها خارج Compose (انظر ، على سبيل المثال ، docker / docker-py # 465 ).

إذا كان هذا التعليق أكثر ملاءمة في boot2docker / boot2docker # 808 ، فيمكنني نقله هناك.

أنا عامل صيانة في Homebrew وساعدت الصورة الرمزية في تشغيل هذا الأمر.

تم تعيين الاسمين المميزين (DN) للموضوع والمُصدر لشهادة الخادم التي تم إنشاؤها بواسطة boot2docker على /O=Boot2Docker . أعتقد أن شهادة الخادم موقَّعة بالفعل من خلال شهادة CA ، لكن AFAICT OpenSSL 1.0.2 يستخدم هذه المعلومات (على سبيل المثال ، الموضوع المتطابق و DNs المُصدر) لرفض شهادة الخادم باعتبارها موقعة ذاتيًا بدلاً من محاولة التحقق من شهادة الخادم مقابل ما تم توفيره شهادة CA. تتحقق إصدارات OpenSSL السابقة للإصدار 1.0.2 من صحة شهادة الخادم وفقًا لشهادة CA المقدمة ، والتي نجحت.

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

1474 يفعل شيئين متميزين:

• تعيين حد أدنى لإصدار Python عند 2.7.9: يسمح هذا لـ urllib3 بإكمال الطلبات دون إصدار InsecurePlatformWarning ، والذي يتم إصداره أثناء إجراء اتصالات HTTPS إذا تم استيفاء كلا الشرطين: إصدار Python قبل 2.7.9 ، ووحدة PyOpenSSL غير موجود. سيكون تجميع PyOpenSSL فعالاً بنفس القدر لكنني أفهم من المناقشة أنه غير متوافق مع PyInstaller. في كلتا الحالتين ، لا يرتبط InsecurePlatformWarning الخاص بـ urllib3 بمشكلة شهادة boot2docker ، ولا يؤدي إصلاح الشهادات إلى إزالة الحاجة إلى هذا الحل البديل.
• تعيين حد أقصى لإصدار OpenSSL عند 1.0.1j. أعتقد أن هذا يجب أن يكون غير ضروري بمجرد إصلاح شهادات boot2docker.

إذا كان مصدر المشكلة هو OpenSSL معطل موزع مع b2d

ليس؛ شهادات boot2docker (التي تم إنشاؤها بواسطة هذا الرمز ) غير صالحة وفقًا للعملاء الذين يستخدمون OpenSSL ≥ 1.0.2 ؛ مكتبة OpenSSL الموزعة مع boot2docker ليست متورطة.

glyph أو aanand ، هل يشير ذلك إلى أن إصلاح aanand (حل aanand ، إذا تمت معالجة boot2docker / boot2docker # 808 بشكل صحيح ، فهل يجب دعم # 1474؟ هل وضع الأمل في إصدار التشفير القادم (انظر هذا وهذا) هو أيضًا خدعة حمراء؟

نعم أعتقد ذلك. أعتقد أن OpenSSL الذي يحتوي على المشكلة هو 1.0.2 ، وبتقييده بـ 1.0.1 ، فإنه سيتجنب أي منطق تحقق يتسبب في فشل الشهادة. ما زلت لا أعرف _ماذا_ يتعلق الأمر بالشهادة التي لا تحبها ، لأن رسائل الخطأ منفرجة للغاية.

أيضًا ، أعتقد أن ما يفعله # 1474 محدد للغاية ؛ على الأقل من قراءتي ، لم يتم تعيين إصدار _ minimum_ python ، ولكن تحديد إصدار _exact_. يبدو أيضًا أنه فشل في التحقق من وجود أي 1.0.1 يختلف عن j ، مما يعني أن تحديثات الأمان لن يتم تطبيقها حتى على 1.0.1 ، وهي مشكلة _ بلا شك _.

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

سأحقق في الشهادة التي تم إنشاؤها docker-machine وأرى ما إذا كانت تتضمن هذه الخاصية. لماذا تقول أن هذا السلوك مقبول / ليس تراجعًا في OpenSSL؟ الوثوق بشهادة موقعة ذاتيًا أمر جيد تمامًا ، ولا توجد قيود معينة على ما قد يحتويه الموضوع أو المُصدر التي أعرفها. لقد قمت بقراءة القليل من هذا الدليل ويبدو أنني أشير فقط إلى أن الشهادات الموقعة ذاتيًا لن تتمتع بثقة CA-cartel ، لذلك لن يثق بها متصفح الويب الخاص بك بدون تكوين إضافي.

بالنظر إلى الشهادة في جهاز VM docker-machine ، أرى:

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

لذلك قد تكون محقًا في هذا ...

سأقوم بالتحقيق في الشهادة المُنشأة بواسطة جهاز الإرساء ومعرفة ما إذا كانت تحتوي على [مطابقة للموضوع و DNs المُصدر].

يمكنك أن ترى أن شهادات docker-machine الخاصة بـ aanand لها أيضًا DNs مميزة: https://gist.github.com/aanand/3d865623481ba8ae66ee#file -docker-machine-log-L30-L32

الوثوق بشهادة موقعة ذاتيًا أمر جيد تمامًا

لكن الشهادة الموقعة ذاتيًا غير صالحة إلا إذا كنت تثق في الشهادة الموقعة ذاتيًا. نحن لا نوجه OpenSSL إلى الوثوق بشهادة الخادم ؛ نحن نوجه OpenSSL للثقة في المرجع المصدق الذي أصدر شهادة الخادم.

لماذا تقول أن هذا السلوك مقبول / ليس تراجعًا في OpenSSL؟

IANAL ، ولكن استنتاجي مشتق من اللغة "على مستوى صارم [توقيع ذاتي] يعني أن المصدر والموضوع في الشهادة متماثلان." هذا هو الحال بالنسبة لشهادة خادم boot2docker. عندما يحاول OpenSSL التحقق من صحة شهادة خادم boot2docker ، فمن الممكن إنشاء سلسلة ثقة كاملة دون مراعاة شهادة المرجع المصدق (CA) نظرًا لأن شهادة الخادم تبدو موقعة من تلقاء نفسها ، ولكنها غير موثوقة بشكل صريح ، وبالتالي لا يمكن أن تكون صالحة. لست واثقًا من أن هذا السلوك صحيح تمامًا أو مطلوب ولست مؤهلاً لاتخاذ القرار ولكن أعتقد أنه يبدو "معقولًا".

شكرا على الحفر يا رفاق.

أيضًا ، أعتقد أن ما يفعله # 1474 محدد للغاية ؛ على الأقل من قراءتي ، لم يتم تعيين حد أدنى لإصدار Python ، ولكن تحديد إصدار دقيق. يبدو أيضًا أنه فشل في التحقق من وجود أي 1.0.1 مختلفًا عن j ، مما يعني أن تحديثات الأمان لن يتم تطبيقها حتى على 1.0.1 ، وهي مشكلة بالتأكيد.

متفق عليه. بافتراض أن OpenSSL 1.0.2 الذي لا يتوافق مع شهادات boot2docker ، يجب أن يكون هذا الجزء قابلاً للإصلاح على الأقل - سأبحث في الحصول على OpenSSL 1.0.1 محدث في.

@ tdsmith شكرا على الشرح والاعتذار عن سوء التفاهم. glyph ، شكرا للتوضيح.

FWIW ، لقد حاولت اختبار نظرية tdsmith واخترق generate_cert (إنه أمر قبيح ، سامحني) لإنشاء قيم مميزة لـ Issuer و Subject . قد يبدو أنه يحتفظ بالماء (لكن انظر المحاذير أدناه). هذا ما أحصل عليه عند تشغيل b2d بالشهادات التي تم إنشاؤها من الإصدار الحالي generate_cert مقابل الإصدار المخترق الخاص بي:

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) لا يعمل _ مع الأصل 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) الأصلي ، تم إنشاؤه عندما كانت صورة Docker golang:1.3-cross المستخدمة في إنشائها تتمتع بإمكانية الوصول إلى الحزمة يسمى ssh . تم استبدال هذه الحزمة منذ ذلك الحين بـ openssh-client . إصدار OpenSSL المستخدم عند إنشاء generate_cert تم اختراقه هو 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)

لذلك يبدو أن أحد أمرين قد يحدث:

• يتم الخلط بين الإصدارات المتأخرة من OpenSSL عند Issuer == Subject ، كما يقترح tdsmith ؛ أو
• هناك شيء آخر حول إنشاء الشهادات تغير في OpenSSL بحيث تواجه الإصدارات اللاحقة من OpenSSL مشكلة في التحقق من صحة الشهادات التي تم إنشاؤها بواسطة الإصدارات السابقة

إحدى طرق اختبار ذلك هي إعادة إنشاء generate_cert بدون الاختراق الخاص بي ، ولكن بإصدار محدث من OpenSSL. سأفعل ذلك بعد ذلك.

لذلك يبدو أن 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) لا _ يعمل مع 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 / Generator_cert # 10. بالمناسبة ، إذا أراد أي شخص إنشاء صور ثنائية الأبعاد تشير إلى مخترق generate_cert s ، يمكنك تجربتها حتى يتم إصدار إصلاح رسمي.

إذا فهمت بشكل صحيح ، فهذا _يجب_ أن يغني عن الحاجة إلى تشغيل ألعاب إصدار OpenSSL / Python من جانب العميل (على الأقل فيما يتعلق بهذه المشكلة).

وسمSvenDowideit

لقد كان لدي القليل من التبادل مع شباب OpenSSL. إليكم ملخص من ستيف هينسون:

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 شهاداته من أجل استيعاب عملاء OpenSSL الذي يحتوي على عربات التي تجرها الدواب أفضل بكثير من تصحيح OpenSSL وتثبيته على جانب العميل. لست متأكدًا من الأسلوب المحدد الأكثر ملاءمة (جعل الموضوع! = المُصدر مقابل تضمين SKID / ADID في جميع الشهادات). سأقوم بتمرير هذا المبلغ إلىSvenDowideit. : smirk:

للفضوليين (مرة أخرى لا أعتقد أننا يجب أن نسلك هذا الطريق) ، إليك تصحيح OpenSSL من ستيف:

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_ حيث يمر اختبار أكثر صرامة؟

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

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

لم أقض الكثير من الوقت في الخوض في مصادر OpenSSL ، لكنني أجدها غير قابلة للاختراق إلى حد ما في العديد من الأماكن. ربما يتطلب الأمر عقلية "خاصة" للعمل في هذا المشروع.

باختصار ، أعتقد: غمزة:.

على أي حال ، نشكرك على التواصل مع أفراد OpenSSL ، ويسعدنا أن يتم حل المشكلة هناك. في غضون ذلك ، يبدو أن العمل على حلها في b2d هو الشيء الصحيح الذي يجب القيام به. لا أعتقد أن هناك أي شيء للقيام به هنا ولكن انتظر.

كما هو مذكور هنا ، فإن هذا يعمل على إصلاح الأمور بالنسبة لي:

pip install requests[security]

iffy هذا هو الرنجة الحمراء ؛ من المحتمل أن يصلحه لك لأن لديك عجلة ثنائية مخزنة مؤقتًا مرتبطة ببرنامج OpenSSL مختلف.

لمعلوماتك ، العلاقات العامة مع الإصلاح المقدم كـ boot2docker / boot2docker # 1029.

الإصلاح الخاص بهذا (شكرًاposita!) موجود في أحدث إصدار من boot2docker. لترقية:

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

هذا أصلح المشكلة بالنسبة لي. يرجى المحاولة والإبلاغ مرة أخرى.

بدلاً من ذلك ، قم بالتبديل إلى Docker Machine ، والتي أصبحت الآن قياسية كجزء من Docker Toolbox الجديد.

ما زلت أواجه هذه المشكلة ...

❯ 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 نجحت مكالمة إنشاء عامل

@ tdsmith ليست ضارة بالنسبة لي ، يقود بلدي الوسواس القهري مجنون: ابتسم: شكرا

أدى إلغاء تثبيت إصدار python المثبت عبر brew إلى حل هذه المشكلة بالنسبة لي. 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

تضمين التغريدة
هل حللت مشكلتك؟

هل يعرف anybode ما إذا كان الأشخاص الذين يؤلفون عمال النقل يعملون على حل المشكلة ، أم أنها ليست مشكلتهم في الأساس؟

مع تحياتي،

تضمين التغريدة
لا. على كل من جهازي Mac (10.9.x و 10.10.x) ، لقد جربت أشياء مختلفة بدون تغيير. لا أعتقد أن هذا شيء docker-compose وأكثر من شيء Python FWIW.

تضمين التغريدة
أوافق ، لكن لم أجد أي متغير حول كيفية إنجاحه :(

يبدو أن الجميع قد حل هذه المشكلة بالفعل ، لكن ليس أنا :)

لقد قمت بتثبيت python باستخدام الشراب مرة واحدة ، وأعتقد أنني قمت بإزالة نظام التشغيل ، لذلك ليس لدي خيار للعودة إلى القديم.

لقد حاولت تثبيت عامل ميناء بعدة متغيرات:

1. من ثنائي (تنزيل مربع أدوات عامل التشغيل)
2. من الشراب نفسه

ومع ذلك لا يزال لدي:

هل لدى أي شخص دليل شامل لكيفية التغلب على هذا السلوك؟

مع تحياتي،

PavelPolyakov - الخطأ هو أن boot2docker (وفي بعض الحالات ، على ما أعتقد ، جهاز عامل الإرساء) كان ينشئ بعض الشهادات التي كانت غير قابلة للاستخدام بواسطة دعم Python SSL. إذا قمت بترقية جميع برامجك ولكن لا تزال لديك الشهادات القديمة السيئة ، فستظل الأشياء معطلة. لذا في هذه المرحلة ، أوصي بإعادة توفير أي أجهزة افتراضية مطورة لديك ، مع إصدار حالي من جهاز الإرساء ، بحيث يتم توفير شهادات 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 ، إذا كنت تستخدم Vagrant). ثم أعد تشغيل مثيل boot2docker وتأكد من استمرار حدوث خطأ SSL.

glyph

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

عندما أقوم بتثبيت Docker & co مع:
brew install docker docker-machine docker-compose

بعد ذلك ، لم يتم إنشاء آلة default . وليس لدي أي فكرة عن كيفية إنشائه باستخدام docker-machine create .

عندما أقوم بتثبيت docker-toolbelt باستخدام ملف * .pkg ، يتم إنشاء الجهاز ، ولكن لدي خطأ SSL.
لقد حاولت حتى أن أفعل:

docker-machine regenerate-certs default

لكنها لا تساعد.

posita
شكرا على النصيحة ايضا
في دليلك ، تقترح على mv ~/.docker ~/.docker-bak - لأي سبب؟ بمجرد القيام بذلك ، لا يمكننا بدء تشغيل الجهاز مرة أخرى ، لأنه يتم نقل الملفات.
نعم ، يمكنني تسجيل الدخول إلى الجهاز وإزالة tls/* ، ثم إيقاف تشغيله ، ولكن كيف يمكنني تشغيله مرة أخرى؟

كيف يمكن إعادة توفيرها من الصفر؟

@الكل
ما هي طريقتك في تثبيت عامل الإرساء (مع عامل عامل إنشاء عامل) ، هل هو عبر brew install أم عبر toolbelt .pkg؟
كيف يمكنني التأكد من أن الشهادات الموجودة على جهاز الإرساء الخاص بي صالحة ومفيدة بواسطة python ، كيف يمكنني ترقية python و opensl أكثر من brew can ، إلخ؟

شكرا للمساعدة.

مع تحياتي،

PavelPolyakov - docker-machine ليس لديه فكرة عن آلة "افتراضية". يمكنك تشغيل docker-machine create --driver virtualbox my-docker-machine .

PavelPolyakov بمجرد الانتهاء من ذلك ، يتعين عليك القيام بـ eval "$(docker-machine env my-docker-machine)" ، أو أي شيء تختاره للاتصال بجهاز التطوير المحلي الخاص بك.

glyph
صحيح ، كان هذا هو الجزء المفقود من تشغيل كل شيء بدءًا من brew . لقد قمت بتزويد الجهاز بنجاح بالاسم default (وهو نفس الاسم الذي يتم أثناء التثبيت من * .pkg).

ومع ذلك ، كالعادة ، أختتم بـ:

:(

في دليلك ، تقترح استخدام mv ~ / .docker ~ / .docker-bak - لأي سبب؟ بمجرد القيام بذلك ، لا يمكننا بدء تشغيل الجهاز مرة أخرى ، لأنه يتم نقل الملفات.

PavelPolyakov ، لست متأكدًا. لا أستخدم docker-machine . كنت أخمن بناءً على بيئات أخرى. يرجى تجاهل إذا لم يفلح ذلك.

نعم ، يمكنني تسجيل الدخول إلى الجهاز وإزالة tls/* ، ثم إيقاف تشغيله ، ولكن كيف يمكنني تشغيله مرة أخرى؟

هل docker-machine restart لا يعمل؟

استند تعليقي إلى تجربتي الخاصة في تشغيل boot2docker مع Vagrant. قد لا ينطبق جيدًا على docker-machine . يبدو أن glyph لديه خبرة أكبر في هذه البيئة. سأجرب اقتراحاته.

ما هي طريقتك في تثبيت عامل الإرساء (باستخدام عامل عامل إنشاء عامل) ، هل يتم ذلك عبر brew install أم عبر toolbelt .pkg؟

هذا إلى حد ما خارج نطاق هذه المشكلة (التي تتعامل بشكل خاص مع مشكلة الشهادة مع boot2docker كما يظهر في docker-compose ) ، ولكن في OS X ، أستخدم البنيات الثنائية .

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

هممم ....: مرتبك: PavelPolyakov ، ماذا يعطيك هذا؟

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 المختلفة.
مع جميع التحديثات الأخيرة (حزم نظام التشغيل والتخمير) ، وواجهت نفس المشكلة مع SSL.

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 و Python 2.7 مثبتًا من MacPorts. يخضع هذا الإصدار من OpenSSL للمشكلة المحددة في هذه المشكلة (وتم حلها بواسطة التحديث إلى boot2docker ). بالنسبة لي ، تعمل هذه المجموعة بدون مشكلة مع boot2docker 1.8.1+ و Vagrant (يعالج 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 . ( aanand ، ربما يمكنك التعليق؟) بالنظر إلى أن هذه المشكلة مزدحمة تمامًا ، فكر في تقديم مشكلة جديدة لعمال الرصيف / الجهاز . أود الإشارة إلى هذا ، بدءًا من تعليقك الأولي .

إذا قررت تقديم مشكلة جديدة لعامل الإرساء / الجهاز ، ففكر في إضافة أي شيء مثير للاهتمام في /var/log/docker.log أو /var/log/boot2docker.log على مثيل VM الخاص بك. على سبيل المثال ، جرب هذا:

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 ، فربما يمكنك التعاون معًا في التشخيص؟

واجهت نفس المشكلة وكان ذلك بسبب حقيقة أن لدي اتصال vpn مفتوحًا جالسًا بواسطة تطبيق آخر (Astrill في حالتي) ربما كان يعبث بشيء ما في تكوين الشبكة. آمل أن يساعد هذا شخصًا آخر يعاني من نفس المشكلة.

أحصل على أخطاء في 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
نسخة آلة عامل الميناء 0.5.0
إصدار عامل التركيب: 1.5.0

كلها مثبتة عبر Homebrew

anthonygreen ، يبدو أن مشكلة مختلفة تمامًا. لا أرى نفس رسالة الخطأ التي تتم مناقشتها هنا. يبدو أن مستخدمي Homebrew يواجهون عددًا كبيرًا من المشكلات التي لا علاقة لها بهذه المشكلة. يرجى النظر في تقديم قضية جديدة.

لم أقرأ هذا المنشور بالكامل ، لكنني رأيت نفس الخطأ في الإعداد الأخير على OS X Yosemite باستخدام Docker Toolbox 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 (مع بعض الشهادات الداخلية المخصصة) ، وإلغاء تعيين env var قبل تشغيل docker-compose سمح له بتجاوز الخطأ [SSL: CERTIFICATE_VERIFY_FAILED] .

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

تحرير: عفوًا ، المقصود بالتعليق هنا https://github.com/docker/machine/issues/1880

pmahoney ، شكرًا

$ 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

على الرغم من أنني لا أحصل على خطأ SSL.

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

neilsarkar كانت مشكلتي أيضًا تشغيل وكيل تشارلز! شكرا لك!

يا إلهي ، لدي أيضًا CURL_CA_BUNDLE مخصص على كلا الجهازين حيث كنت أختبر.

شكر

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

إذا كنت تعرف ما هي القيمة الجيدة لمتغير CURL_CA_BUNDLE ، فأنا أعتبرها :)

شكرا

لدي نفس المشكلة مع webkit-patch. من خلال النظر إلى مستندات python على وحدة 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 وجود ملف شهادة CA بسعر /usr/local/ssl/cert.pem (لمن قاموا بتثبيت OpenSSL على /usr/local/ssl ) لذلك ، إما أن تقوم بتعيين SSL_CERT_FILE لملف شهادة يحتوي على شهادات CA الجذر ، أو تضع ملفًا بشهادات CA الجذر على /usr/local/ssl/cert.pem . إذا كنت بحاجة إلى شهادات CA الجذر ، فقم بتنزيل curl وفي الشجرة المصدر ، قم بتشغيل lib/mk-ca-bundle.pl وسيتم إنشاء ملف ca-bundle.crt. أستطيع أن أؤكد أن إعداد SSL_CERT_FILE سيعمل مع OpenSSL 1.0.2d مع Python 2.7.11 و Python 3.5.0.

grahamc هل حدث لك حل المشكلة؟ لديّ إعداد مشابه لك وهو يعمل بشكل رائع مع برنامج Docker daemon ولكنه فشل مع 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 المتغير البيئي أو على الأقل سجل تحذيرًا بأنه لن يستخدم الشهادات المتوقعة.

buckett ، ضع في اعتبارك تقديم مشكلة جديدة 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 و docker-mahine و docker-compose عبر Docker toolbox.

لقد جربت كل الاقتراحات أعلاه ولكن لم يحالفني الحظ. ليس لدي خبرة في docker لذا لم أستطع معرفة ذلك بنفسي.

هل لدى أي شخص سبب جذري أو حل بديل لهذا؟ أراه في إنشاء 1.7.0 مع إصدار Opensl أحدث.
تم بناء هذا كله وتشغيله من جبال الألب ، لذلك يجب أن تكون البيئة نقية:

/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)

تضمين التغريدة
في حالتي ، كان السبب هو المتغير env المعاد تعريفه CURL_CA_BUNDLE . يجب عليك التحقق مما إذا كان لديك مثل هذه الحالة أيضًا.

PavelPolyakov تحقق من تفريغ env ... لا CURL_CA_BUNDLE

PavelPolyakov حسنًا ، هذا غريب ، لقد بيئتي .

jmmills huh… نفسه هنا. ربما يعامل بيثون الوضع الفارغ بشكل مختلف لإلغاء ضبطه؟

نظام التشغيل Mac OS ، أداة إنشاء وتركيب آلة عامل بناء البيرة ، باستخدام نظام python. الجهاز الذي تم إنشاؤه حديثًا بـ: 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.

تنبعث منه بالتأكيد رائحة خطأ في المنبع ، أعتقد أنه سيكون بعض كود التوافق البيئي لـ curl ، حيث يتم التعامل مع "المعرفة" و "الفارغة" بشكل مختلف.

شكر،
جايسون ميلز

• أرسلت من الجوال.

في 24 أبريل 2016 ، الساعة 6:14 صباحًا ، كتب Alex Wilson [email protected] :

لقد كان لدي نفس الشيء تمامًا - لم يتم تعيين CURL_CA_BUNDLE في بيدي ، وقد أعطاني تعيينه على سلسلة فارغة نفس الإخراج مثلinanimatt.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub

يبدو أنه يؤثر فقط على إصدار البيرة - تثبيت البيرة المنزلية ثم تثبيت عامل إنشاء عبر نقطة يحل جميع الأخطاء.

في 24 أبريل 2016 ، الساعة 14:14 ، كتب Alex Wilson [email protected] :

لقد كان لدي نفس الشيء تمامًا - لم يتم تعيين CURL_CA_BUNDLE في بيدي ، وقد أعطاني تعيينه على سلسلة فارغة نفس الإخراج مثلinanimatt.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub

أعتقد أنني قمت بلصق نسخة متماثلة من المشكلة في Linux سابقًا. يمكنني التحقق مرة أخرى غدًا عندما تكون في محطة العمل

شكر،
جايسون ميلز

• أرسلت من الجوال.

في 24 أبريل 2016 ، الساعة 12:22 مساءً ، كتب مات روبنسون [email protected] :

يبدو أنه يؤثر فقط على إصدار البيرة - تثبيت البيرة المنزلية ثم تثبيت عامل إنشاء عبر نقطة يحل جميع الأخطاء.

في 24 أبريل 2016 ، الساعة 14:14 ، كتب Alex Wilson [email protected] :

لقد كان لدي نفس الشيء تمامًا - لم يتم تعيين CURL_CA_BUNDLE في بيدي ، وقد أعطاني تعيينه على سلسلة فارغة نفس الإخراج مثلinanimatt.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub

نفس المشكلة هنا منذ أن قمت بتحديث docker-compose إلى الإصدار 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 / machine / machines / default / ca.pem docker-compose ps

ربما لست أول من طرح هذا الأمر ، لكن أليس من البديهي أن يكون لمتغير بيئة curl أي تأثير على الإطلاق على تطبيق Python غير ذي صلة؟

شكر،
جايسون ميلز

• أرسلت من الجوال.

في 7 مايو 2016 ، الساعة 3:22 مساءً ، كتب Lorenzo Sicilia [email protected] :

بدلاً من تعطيل CURL_CA_BUNDLE ، يمكنك تشغيلها باستخدام:
CURL_CA_BUNDLE = ~ / .docker / machine / machines / default / ca.pem docker-compose ps

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub

واجهت هذه المشكلة وكانت المشكلة مع متغير البيئة REQUESTS_CA_BUNDLE الذي يشير إلى موقع مخصص للشهادات الموقعة ذاتيًا. غلاف هذا يساعد أي شخص.

• مايكل حوش

aboutlo هذا يعمل - لم يعمل مع ملف ca.pem ، فقط مع هذا الملف. أنا أيضًا على نظام Windows ، لذا لدي المزيد من إعدادات الفودو ، شكرًا لك!

أدى إلغاء تثبيت ndg-httpsclient (مع النقطة - كان الإصدار 0.4.0) إلى حل المشكلة بالنسبة لي ، راجع المنشور الخاص بي هنا: https://github.com/docker/compose/issues/3365

لقد قمت بتصحيح أخطاء docker-compose و docker-py واكتشفت أنه يجب عليك إما استخدام متغيرات البيئة أو الخيارات في الأمر. يجب ألا تخلط هذه. إذا قمت بتحديد --tls في الأمر ، فسيتعين عليك تحديد جميع الخيارات ككائن TLSConfig ، حيث يتم الآن إنشاء كائن TLSConfig بالكامل من خيارات الأوامر وتشغيل كائن TFSConfig الذي تم إنشاؤه من متغير البيئة.

@ م-housh OMG شكرا لهذه النصيحة! نفس الشيء تماما حدث معي! تمت إزالة REQUESTS_CA_BUNDLE من بيئتي وتم حل هذه المشكلة بالنسبة لي.

لقد واجهت نفس المشكلة. أولاً ، على الرغم من أن السبب في ذلك هو الاختلافات في إصدار OpenSSL (كان لدى Pyhton 1.0.2 لكن نظام التشغيل كان 0.9.8) ، فقد صنعت كلاهما 1.0.2 ولكنه ما زال لا يعمل.
لقد قمت بحل مشكلتي ببساطة عن طريق ssh to docker ثم التحقق من شهادتي في المفاتيح المصرح بها وتحديثها. ومن المثير للاهتمام بطريقة ما أنها كانت شهادة خاطئة هناك.

اتبع هذه الخطوات من فضلك:

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

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

docker-compose up

هذا عمل معي وآمل أن يساعد.

معالجة المشكلة: يبدو أن هناك مجموعة متنوعة من أوضاع الفشل وسيناريوهات المستخدم الخطأ / التهيئة الخاطئة (كلها تاريخية إلى حد كبير) الموضحة هنا.

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