Saya rasa saya mengalami hal yang sama saat mencoba menggunakan kandidat rilis docker-compose ...

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

Tapi fig berfungsi dengan baik ...

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

Saya menggunakan OSX, menjalankan semua versi yang sama dengan @gkostyanikov , kecuali versi klien Go saya adalah go1.3.3 . Python / openssl saya juga diinstal melalui Homebrew. Mungkin ada hubungannya dengan itu?

Sunting: Sebenarnya sepertinya Homebrew tidak memiliki tautan openssl, jadi saya menggunakan versi OSX default: OpenSSL 0.9.8za 5 Jun 2014 .

Masalahnya adalah python Homebrew.

docker-compose sekarang berfungsi setelah menghapus instalasi homebrew python / openssl, menginstal pip dengan easy_install , dan menginstal ulang docker-composer menggunakan sistem python.

@adambiggs Solusi Anda berhasil! Terima kasih!

Ini bekerja untuk saya juga, saya menggunakan mac baru dan mengaturnya dengan python homebrew. Memiliki kesalahan ini dengan ara berkomunikasi dengan buruh pelabuhan. Mengikuti saran @adambiggs secara verbatim dan berhasil melewati pemblokir saya, itu bisa menjadi masalah versi python juga tetapi terlepas dari itu saya kira mesin ini akan menggunakan sistem python untuk sementara waktu.

Ini juga terjadi pada saya. Dan saya tidak ingin menggunakan python sistem, ada yang punya solusi lain?

Sudahkah Anda mencoba menggunakan biner? Apakah Anda mengalami masalah yang sama?

Tidak, saya belum mencoba biner.
Jika Anda tidak ingin menginstalnya di python sistem Anda, solusi lain adalah menggunakan virtualenv (pembungkus).

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

Menemukan solusi yang lebih baik menggunakan pyenv untuk memutar kembali ke python 2.7.8:

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

Sunting: Tidak apa-apa, pyenv memperkenalkan banyak masalahnya sendiri ...

Apa yang menyebabkan kesalahan ini bagi saya adalah bahwa home-brew openssl tidak ditautkan ke / usr / local / bin / openssl.

openssl version

mengembalikan OpenSSL 0.9.8zc 15 Okt 2014 bukan OpenSSL 1.0.1j 15 Okt 2014

Lari

brew link --force openssl

dan menginstal ulang ara menyelesaikan masalah.

Menarik, namun versi OpenSSL saya adalah OpenSSL 1.0.1j 15 Okt 2014

@aanand dalam kasus saya biner tidak memiliki masalah ini.

Saya mendapat kesalahan ini ketika saya menginstal ara melalui pip, bukan homebrew. sudo pip uninstall fig dan brew install fig memperbaikinya untuk saya.

+1 untuk solusi @NotBobTheBuilder , juga berhasil untuk saya

: +1: untuk @NotBobTheBuilder

@NotBobTheBuilder solusi yang bagus untuk ara tapi sayangnya buruh pelabuhan belum tersedia di homebrew.

@ocasta bagaimana dengan peringatan yang terdengar menakutkan dari homebrew tentang menautkan OpenSSL ini?

Formula ini hanya berisi tong.
Mac OS X sudah menyediakan perangkat lunak ini dan menginstal versi lain di
paralel dapat menyebabkan semua jenis masalah.

Apple telah menghentikan penggunaan OpenSSL karena mendukung TLS dan pustaka kripto-nya sendiri

Jempol @NotBobTheBuilder - Itu juga memperbaikinya.

ada yang tahu sumber masalah ini? itu terjadi pada saya dengan ara. Saya lebih suka menggunakan pip install fig seperti yang saya miliki sekarang. Semuanya berfungsi dengan baik beberapa minggu yang lalu, tidak tahu apa yang berubah di sistem saya

OpenSSL sistem saya adalah OpenSSL 0.9.8zc 15 Oct 2014 , homebrew saya openssl lebih baru tetapi tidak ditautkan.

... Saya rasa itu rusak ketika saya meningkatkan ke Python 2.7.9, tampaknya ada beberapa bug terkait SSL dengannya ... terlihat sangat seperti ini:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196431
http://bugs.python.org/issue23052

menjalankan brew link --force openssl dan menginstal ulang ara tidak melakukan apa-apa untuk saya.

Apakah ara perlu diperbarui untuk mengatasi perubahan SSL di Py 2.7.9?
https://www.python.org/dev/peps/pep-0476/#opting -out

Saya menggunakan boot2docker. Saya baru saja meningkatkan ke 1.5.0 tetapi tidak ada perubahan.

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}

Kode ara terlihat benar, ini mencoba menggunakan sertifikat yang diinstal oleh boot2docker ... Saya menganggap sertifikat ini baik-baik saja karena selalu berfungsi dan saya baru saja memutakhirkan b2d sehingga seharusnya tidak kedaluwarsa.

Hmm, Python saya (diinstal melalui homebrew) tampaknya menggunakan OpenSSL versi homebrew:

$ 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

... menjalankan /usr/local/opt/openssl/bin/c_rehash tidak membantu :)

Saya mencoba versi python (2.7.8_2) yang diinstal sebelumnya melalui $ brew switch python 2.7.8_2 dengan masalah yang sama (meskipun pesan kesalahannya sedikit berbeda). Jadi versi python 2.7.9 sepertinya tidak jadi masalah.

Kemudian saya mencoba beralih ke versi openssl yang lebih lama, dari 1.0.2 ke 1.0.1j_1 yang tampaknya berfungsi.

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

Bagi saya, saya hanya mendapatkan kesalahan yang berbeda, tetapi mungkin itu membantu mempersempit apa yang salah:

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

Beralih kembali ke OpenSSL 1.0.2 menghasilkan kesalahan CERTIFICATE_VERIFY_FAILED sehingga mengubah versi pasti memiliki beberapa efek

Salah satu solusinya adalah menjalankan docker-compose dalam container:

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

Ini membutuhkan mengekspos port 2376 di VirtualBox:

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

Jawaban @kretz berhasil untuk saya.

+1 Sakelar minuman @kretz openssl 1.0.1j_1
berhasil

brew switch openssl 1.0.1j berfungsi untuk saya (perhatikan kekurangan _1)

Saya tidak menyukainya, tetapi menghapus ara dari virtualenv saya dan menginstal melalui homebrew memperbaiki hal-hal untuk saya

Terima kasih @kretz - jawaban Anda menyelesaikannya untuk saya!

Ini tidak berhasil untuk saya karena:

$ 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

Solusi saya adalah membuat virtualenv dengan python 2.7.8, daripada 2.7.9 yang saya dapatkan dari minuman.

berbagai solusi ... apakah ada yang punya wawasan tentang masalah sebenarnya?

apa hubungannya App Engine dengan segala hal?

Pada 11 Maret 2015 pukul 18:09, Ryan Small [email protected] menulis:

Saya cukup yakin tidak ada barang mesin aplikasi yang berfungsi dengan python 2.7.9

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/compose/issues/890#issuecomment -78329652.

@anentropic Anda perlu menginstal versi openssl yang lebih lama sebelum Anda dapat menggunakan (beralih ke).

# 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

Saya melakukan brew install openssl101 tetapi tidak memberi saya kemungkinan untuk beralih ke 1.0.1j ... itu memberi saya 1.0.1l dan saya khawatir itu akan membingungkan sistem saya karena mereka adalah paket minuman terpisah dan saya sudah memiliki 1.0.2 secara paralel

sepertinya tidak membantu, tetapi mungkin saya tidak melakukannya cukup jauh

Maaf saya membalas masalah github yang salah (segera menghapus komentar saya)
Pada Rabu, 11 Maret 2015 pukul 11.30 anentropic [email protected]
menulis:

Saya melakukan brew install openssl101 tetapi tidak memberi saya kemungkinan untuk itu
beralih ke 1.0.1j ... itu memberi saya 1.0.1l dan saya khawatir itu akan terjadi
membingungkan sistem saya karena mereka adalah paket minuman terpisah dan saya sudah memilikinya
1.0.2 secara paralel

sepertinya tidak membantu, tetapi mungkin saya tidak melakukannya cukup jauh

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/compose/issues/890#issuecomment -78340580.

Jadi saya sepertinya mendapatkan masalah ini juga, berjalan di Mac OSX. Menggunakan docker-compose ini adalah file .yml saya.

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

Saat menjalankan docker-compose pull Saya mendapatkan output berikut yang gagal.

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

Beberapa hal yang saya periksa.
which openssl; openssl version

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

@psykzz Seharusnya berfungsi jika Anda menginstal dengan brew

brew install docker-compose

@arvindtest apa yang membuat Anda berpikir itu terkait dengan masalah ini?

FYI, setelah berjuang keras dengan ini, ternyata ini adalah masalah boot2docker.
Apa yang berhasil bagi saya adalah menonaktifkan TLS. Belum ada cara yang ramah pengguna untuk melakukan ini, tetapi petunjuknya diuraikan di sini:
https://github.com/deis/deis/issues/2230

Pada dasarnya, Anda perlu:

boot2docker ssh
sudo echo 'DOCKER_TLS = no'> / var / lib / boot2docker / profile

kemudian restart boot2docker, mis
boot2docker berhenti
boot2docker mulai

dan sesuatu seperti ini ke ~ / .bashrc Anda (pastikan ipnya benar)

ekspor DOCKER_HOST = tcp: //192.168.59.103 : 2375
batalkan DOCKER_CERT_PATH
batalkan DOCKER_TLS_VERIFY

Di bashrc Anda mengapa tidak memiliki $ (boot2docker shellinit)

Haruskah membantu semuanya dengan benar?

Maksud saya, Anda masih harus melakukan solusi TLS.
Pada 21 Mar 2015 23:05, "coderfi" [email protected] menulis:

FYI, setelah berjuang keras dengan ini, ternyata ini adalah
masalah boot2docker.
Apa yang berhasil bagi saya adalah menonaktifkan TLS. Belum ada cara yang ramah pengguna
untuk melakukan ini, tetapi petunjuknya diuraikan di sini:
deis / deis # 2230 https://github.com/deis/deis/issues/2230

Pada dasarnya, Anda perlu:

boot2docker ssh
sudo echo 'DOCKER_TLS = no'> / var / lib / boot2docker / profile

kemudian restart boot2docker, mis
boot2docker berhenti
boot2docker mulai

dan sesuatu seperti ini ke ~ / .bashrc Anda
pastikan ip sudah benar

ekspor DOCKER_HOST = tcp: //192.168.59.103 : 2375
batalkan DOCKER_CERT_PATH
batalkan DOCKER_TLS_VERIFY

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/compose/issues/890#issuecomment -84468058.

@kretz berhasil! Terima kasih.

@psykzz maksud Anda $(boot2docker shellinit) ?

ya saya lakukan, memperbarui komentar saya. derp.

Saya dapat mengonfirmasi bahwa solusi @coderfi untuk menonaktifkan TLS berfungsi untuk saya!

Senang itu berhasil untuk Anda. :)

@Matt ya, Anda benar tentang tip ekspansi shell init shell.
Namun, itu mungkin tidak berhasil jika boot2docker belum dimulai, jadi saya baru saja
membuat contoh itu menjadi eksplisit.

Fi
Pada 26 Mar 2015 10:18, "anentropic" [email protected] menulis:

Saya dapat mengonfirmasi bahwa @coderfi https://github.com/coderfi adalah solusi untuk
nonaktifkan TLS bekerja untuk saya!

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/compose/issues/890#issuecomment -86630313.

Mungkin ini jelas, tetapi mereka yang menonaktifkan TLS atau menurunkan OpenSSL hanya agar ini berfungsi harus melangkah dengan hati-hati tergantung pada apa yang mereka lakukan.

Ini tidak akan berhubungan dengan semua, tetapi saya memiliki kesalahan serupa muncul selama pip menginstal menggunakan Dockerfile menarik dari gliderlabs/alpine:3.1 - wadah Linux minimal dari progrium & kru. Masalahnya adalah saya belum menginstal paket sertifikat sistem, masalah tersebut diatasi dengan menginstal paket sebelum menginstal pip dan menjalankan file persyaratan:

RUN apk-install -X ca-certificates

Solusi yang disarankan tidak benar-benar berhasil untuk saya. Tidak dapat beralih ke salah satu versi 1.0.1 OpenSSL. Pada akhirnya saya menemukan bahwa menghapus semua versi docker-compose yang diinstal pip dan hanya melakukan brew install docker-compose entah bagaimana berhasil.

Solusi di atas berhasil tetapi terlalu merepotkan bagi saya. boot2docker upgrade memperbaiki semua yang ada di pihak saya.

Saya sudah memiliki versi boot2docker terbaru dan itu tidak berfungsi untuk saya tanpa perbaikan di atas

Pengembang Homebrew menyarankan docker-py dan docker-compose harus mengupgrade menggunakan requests 2.6.0

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

Semoga ini membantu seseorang ... tidak yakin dengan solusinya tetapi jika Anda menggunakan Charles sebagai Proxy Mac OS X itu akan menyebabkan pesan ini.

FWIW, menginstal docker-compose melalui pip membuat docker-compose itu sendiri berfungsi (menginstal melalui curl di OS X Mavericks menghasilkan kesalahan illegal operation ). Saya kemudian juga mendapatkan kesalahan SSL. Menjalankan brew link --force openssl && brew switch openssl 1.0.1j tampaknya telah memperbaikinya untuk saya.

@rseymour jawaban Anda berhasil untuk saya

Bagi mereka yang gagal menemukan openssl-1.0.1j dalam minuman - Anda dapat mengambil resep openssl versi lama dari github repo dan memanfaatkannya:

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

Saya mencoba 1.0.1m tetapi tidak berhasil.
Jadi saya mencoba cara @lazyval , itu berhasil untuk saya.
Inilah yang telah saya lakukan.

instal minuman https://raw.githubusercontent.com/Homebrew/homebrew/62fc2a1a65e83ba9dbb30b2e0a2b7355831c714b/Library/Formula/openssl.rb
brew switch openssl 1.0.1j_1
brew unlink openssl101 // Karena saya menghubungkan 1.0.1m sebelum ini
brew link openssl --force
buruh pelabuhan-menulis ps

Terima kasih!!

Saya sedang menyelidiki ini, karena kita sekarang perlu membangun binari pada Python 2.7.9+.

_Relokasi dari # 1427_

Server:

• CoreOS Stabil
• Docker 1.5.0.0

Klien:

• CentOS 6.6, 64-bit
• kernel 2.6.32-042stab105.14
• Klien Docker 1.5.0
• buruh pelabuhan-menulis 1.2.0
• Sertifikat SSL ditempatkan pada ~/.docker/{ca.pem,cert.pem,key.pem}
• DOCKER_HOST=tcp://docker-builder:2376
• DOCKER_TLS_VERIFY=1

Menggunakan Makefile berikut untuk membuat sertifikat 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

Berikut adalah skrip data pengguna (memang kurang ideal) untuk menyediakan mesin ini:

#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

Menggunakan klien docker Saya berhasil mengakses server buruh pelabuhan jarak jauh. Kami memanggil server jarak jauh hingga seratus ribu kali sehari dengan kesuksesan yang bagus.

Mencoba menggunakan docker-compose , diinstal melalui curl ATAU pip install --upgrade dengan python 2.7, kami mendapatkan kesalahan SSL:

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

Ini adalah kasus setelah menentukan DOCKER_CERT_PATH=/home/user/.docker/ serta REQUESTS_CA_BUNDLE=/home/user/.docker/ca.pem secara manual, secara individual dan bersama-sama.

Untuk menjadi jelas: setup ini bekerja dengan baik hanya dengan daemon buruh pelabuhan, tapi sesuatu tentang -compose salah.

Beberapa catatan:

1. Biner Compose 1.3.0 RC1 untuk OSX memiliki bug ini. Mungkin bukan kebetulan, ini adalah pertama kalinya dibuat melawan Python 2.7.9 - sebelumnya, ini adalah 2.7.6.
2. Anehnya, saya dapat mereproduksi terhadap VM boot2docker, tetapi tidak terhadap VM Virtualbox yang disediakan oleh Mesin. @ehazlett , @nathanleclaire , @tianon - ada wawasan di sana?
3. Kepada siapa pun yang mengalami ini ketika Compose diinstal dengan Pip, laporkan output dari perintah berikut:

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

Di komputer lokal saya, tempat saya dapat mereproduksi kesalahan, saya memiliki Python 2.7.10 dan OpenSSL 1.0.2a 19 Mar 2015 .

1. Ini telah dilaporkan ke Homebrew, dan beberapa orang mengatakan mereka telah berhasil menginstal ulang Python dan OpenSSL, tetapi itu tidak berhasil untuk saya. https://github.com/Homebrew/homebrew/issues/38226

Hmm itu sangat aneh. Versi b2d apa yang Anda gunakan vs. versinya
mesin? Kami berdua menggunakan b2d jadi saya tidak yakin apa yang akan berbeda
selain versinya.

Saya akan menginstal melalui pip di mesin OS X saya dan melihat apa yang saya dapatkan.

Pada hari Kamis, 28 Mei 2015 jam 09.19, Aanand Prasad [email protected]
menulis:

Beberapa catatan:

1.

Biner Compose 1.3.0 RC1 untuk OSX memiliki bug ini. Mungkin tidak
secara kebetulan, ini adalah pertama kalinya dibuat dengan Python 2.7.9

• sebelumnya, 2,7.6.
  2.

Anehnya, saya dapat mereproduksi terhadap VM boot2docker, tetapi tidak melawan
Virtualbox VM disediakan oleh Mesin. @tokopedia
https://github.com/ehazlett , @nathanleclaire
https://github.com/nathanleclaire , @tianon
https://github.com/tianon - ada wawasan di sana?
3.

Kepada siapa pun yang mengalami ini saat Compose diinstal dengan Pip, silakan
laporkan keluaran dari perintah berikut:

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

Di komputer lokal saya, tempat saya dapat mereproduksi kesalahan, saya memiliki Python
2.7.10 dan OpenSSL 1.0.2a 19 Mar 2015.
4.

Ini telah dilaporkan ke Homebrew, dan beberapa orang mengatakan pernah
berhasil menginstal ulang Python dan OpenSSL, tetapi tidak berhasil untuk saya.
Homebrew / homebrew # 38226
https://github.com/Homebrew/homebrew/issues/38226

-
Balas email ini secara langsung atau lihat di 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)

Apakah ada sesuatu yang berbeda tentang pembuatan sertifikat, mungkin? Saya tampaknya memiliki lebih banyak file di direktori sertifikat mesin saya daripada di boot2docker saya.

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

Ini baik saja. Klien hanya akan menggunakan ca.pem, cert.pem dan key.pem
(server hanyalah salinan lokal untuk host di mesin). Saya akan membuat sebagai
baik dan periksa sertifikat untuk melihat apa perbedaannya.

Pada hari Kamis, 28 Mei 2015 jam 09.30, Aanand Prasad [email protected]
menulis:

versi $ boot2docker
Versi Boot2Docker-cli: v1.6.2
Git komit: cb2c3bc

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

Apakah ada sesuatu yang berbeda tentang pembuatan sertifikat, mungkin? Sepertinya saya punya lebih banyak
file di mesin cert dir daripada di boot2docker saya.

$ $ (shellinit boot2docker)
$ ls -l $ DOCKER_CERT_PATH / *. pem
-rw-r - r-- 1 aanand staff 1042 28 Mei 14:27 /Users/aanand/.boot2docker/certs/boot2docker-vm/ca.pem
-rw-r - r-- 1 aanand staff 1070 28 Mei 14:27 /Users/aanand/.boot2docker/certs/boot2docker-vm/cert.pem
-rw-r - r-- 1 aanand staf 1675 28 Mei 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 Mei 12:15 /Users/aanand/.docker/machine/machines/dev/ca.pem
-rw-r - r-- 1 aanand staff 1054 11 Mei 12:15 /Users/aanand/.docker/machine/machines/dev/cert.pem
-rw-r - r-- 1 aanand staff 1679 11 Mei 12:15 /Users/aanand/.docker/machine/machines/dev/key.pem
-rw ------- 1 aanand staff 1679 11 Mei 12:15 /Users/aanand/.docker/machine/machines/dev/server-key.pem
-rw-r - r-- 1 aanand staff 1086 11 Mei 12:15 /Users/aanand/.docker/machine/machines/dev/server.pem

-
Balas email ini secara langsung atau lihat di 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

Lihat juga https://github.com/docker/docker-py/issues/465. Skrip pengujian

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)

Ini masih berfungsi dengan VM yang disediakan Mesin, meskipun:

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

Jika saya mengaktifkan kembali pemeriksaan nama host (dengan mengomentari baris assert_hostname dalam skrip pengujian), ini gagal dengan kesalahan yang sama terhadap VM boot2docker-cli, tetapi kesalahan yang berbeda terhadap VM Mesin, yang mungkin atau mungkin tidak relevan:

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

Selain itu saya mencoba menggunakan v1.3.0-rc1 melalui curl (rilis biner, bukan melalui pip) dan mendapatkan kesalahan yang sama seperti sebelumnya pada daemon buruh pelabuhan 1.6.2:

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

Ya - biner RC1 dibuat dengan Python 2.7.9 dan OpenSSL 1.0.2a, yang tampaknya menjadi salah satu kombinasi yang bermasalah.

Ini masuk akal karena saya yakin generasi cert di b2d ada di VM
sedangkan mesin menghasilkannya di mesin. Kami dapat mendeteksi dan menambahkan file
nama mesin ke SAN jika diperlukan. Sebenarnya itu mungkin bagus
terutama untuk VM b2d. Alasan mengapa ini berhasil sekarang, menurut saya adalah karena Anda
mengakses mesin menggunakan IP yang ditambahkan mesin sebagai IP SAN. Ada sebuah
PR terbuka untuk memungkinkan SAN tambahan sewenang-wenang yang juga akan berfungsi.

Pada hari Kamis, 28 Mei 2015, Aanand Prasad [email protected] menulis:

Lihat juga docker / docker-py # 465
https://github.com/docker/docker-py/issues/465. @garethr
https://github.com/garethr 's script pengujian di sana mereproduksi kesalahan untuk
saya juga, setelah melakukan satu modifikasi untuk menonaktifkan pemeriksaan nama host:

dari docker.client, impor Klien dari docker.utils, impor kwargs_from_env

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

klien = Klien (** kwargs) mencetak klien.version ()

$ eval "$ (boot2docker shellinit)" && python test.py
Menulis /Users/aanand/.boot2docker/certs/boot2docker-vm/ca.pem
Menulis /Users/aanand/.boot2docker/certs/boot2docker-vm/cert.pem
Menulis /Users/aanand/.boot2docker/certs/boot2docker-vm/key.pem
Traceback (panggilan terakhir terakhir):
File "test.py", baris 8, dalam
print client.version ()
File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", baris 1108, dalam versi
return self._result (self._get (url), json = True)
File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", baris 106, di _get
return self.get (url, * _self._set_request_timeout (kwargs))
File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", baris 477, di get
return self.request ('GET', url, * _kwargs)
File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", baris 465, dalam permintaan
resp = self.send (prep, * _send_kwargs)
File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", baris 573, sedang dikirim
r = adapter.send (request, * _kwargs)
File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", baris 431, sedang dikirim
naikkan SSLError (e, request = request)
requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] verifikasi sertifikat gagal (_ssl.c: 590)

Ini masih berfungsi dengan VM yang disediakan Mesin, meskipun:

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

Jika saya mengaktifkan kembali pemeriksaan nama host (dengan mengomentari assert_hostname
baris dalam skrip pengujian), gagal dengan kesalahan _same_ terhadap
boot2docker-cli VM, tetapi kesalahan _different_ terhadap VM Mesin, yang
mungkin atau mungkin tidak relevan:

Traceback (panggilan terakhir terakhir):
File "test.py", baris 8, dalam
print client.version ()
File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", baris 1108, dalam versi
return self._result (self._get (url), json = True)
File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", baris 106, di _get
return self.get (url, * _self._set_request_timeout (kwargs))
File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", baris 477, di get
return self.request ('GET', url, * _kwargs)
File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", baris 465, dalam permintaan
resp = self.send (prep, * _send_kwargs)
File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", baris 573, sedang dikirim
r = adapter.send (request, * _kwargs)
File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", baris 431, sedang dikirim
naikkan SSLError (e, request = request)
requests.exceptions.SSLError: tidak ada bidang commonName atau subjectAltName yang ditemukan

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/compose/issues/890#issuecomment -106363305.

Oke, saya yakin saya telah sampai pada perbaikan untuk OS X: https://github.com/docker/compose/pull/1474

Memperbaiki itu untuk Linux akan melibatkan pembaruan Dockerfile untuk disematkan ke Python 2.7.9 dan OpenSSL 1.0.1, yang akan menjadi usaha yang menyenangkan mengingat itu dimulai dari debian:wheezy (yang dilakukan untuk memastikan kami menggunakan glibc lama - lihat https://github.com/docker/compose/pull/505).

Beralih ke 1.0.1k seperti yang dijelaskan dalam komentar @kretz dan menginstal 1.3.0 RC1 melalui pip melakukan trik bagi saya.

Sebelum beralih, python melaporkan 1.0.2a:

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

Setelah beralih, dilaporkan 1.0.1k dan docker-compose tampaknya berfungsi seperti yang diharapkan:

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

solusi yang menghapus kesalahan ini adalah menginstal paket berikut di virtualenv saya
pip install pyopenssl==0.14 ndg-httpsclient==0.4 pyasn1==0.1.7

Dalam lingkungan yang dijelaskan di https://github.com/docker/compose/issues/890#issuecomment -106289821 yang menyediakan Python 2.7.6 (melalui snap-ci.com, Anda bisa mendapatkan akun gratis di)

dengan skrip berikut yang menggunakan solusi @ jsh2134 dalam penginstalan pip (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

Saya mendapatkan output berikut:

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

Perhatikan terutama kesalahannya (yang sepertinya baru):

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

Membuat https://github.com/docker/compose/issues/1484 untuk membuang temuan saya sejauh ini.

Saya telah membangun beberapa binari dengan perbaikan di # 1474. Silakan mencobanya jika Anda pernah mengalami masalah 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 mengapa tepatnya Anda menyematkan pyOpenSSL ke 0,14?

+1 untuk jawaban @kretz :)

+1 masalah yang sama :( sepertinya buruh pelabuhan benar-benar rusak di osx?

Solusi @coderfi bekerja untuk saya: Windows 7 buruh pelabuhan 1.7 Cygwin dan docker-compose diinstal melalui pip di Cygwin

Berurusan dengan salah satu kesalahan varian pada VM Centos7, yang bertindak sebagai klien untuk memulai kontainer pada mesin buruh pelabuhan:

[ root @ xxxx cm] # docker-compose ps
Kesalahan SSL: tidak ada bidang commonName atau subjectAltName yang sesuai ditemukan

Ini dulunya hanya sementara; Saya bisa keluar, ssh kembali, dan tidak melihat kesalahan untuk sementara waktu. Sekarang selalu melihatnya.

[ root @ xxxx cm] # python -c 'import ssl; cetak (ssl.OPENSSL_VERSION) '
OpenSSL 1.0.1e-fips 11 Feb 2013

[ root @ xxxx cm] # versi buruh pelabuhan
Versi klien: 1.6.2
Versi API Klien: 1.18
Go versi (klien): go1.4.2
Git commit (klien): ba1f6c3 / 1.6.2
OS / Arch (klien): linux / amd64
Versi server: swarm / 0.2.0
Go versi (server): go1.3.3
Git commit (server): 48fd993
OS / Arch (server): linux / amd64

[ root @ xxxx cm] # docker-compose --version
buruh pelabuhan-menulis 1.2.0

Saya tidak yakin bagaimana menerapkan beberapa perbaikan yang disebutkan di atas di lingkungan saya. Saya tidak menggunakan boot2docker; berurusan dengan buruh pelabuhan 1.6.2 tepat di baris perintah bash.

Halo. Saya sebenarnya membuka masalah karena itu saya tidak dapat memperbaikinya. Saya mencoba banyak hal yaitu menginstal compose dengan versi pip / brew / newst. Sama seperti openssl mencoba versi 0.x 1.0.2x dll dan masih tidak berfungsi.

PS: Saya tidak menggunakan boot2docker. Saya memiliki VM saya sendiri yang saya buat melalui vagrant, menghasilkan sertifikat dan meluncurkan daemon buruh pelabuhan bersama mereka. Rupanya ini berfungsi dengan buruh pelabuhan sehingga masalah tidak datang dari sertifikat saya.

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

mendapatkan kesalahan ini juga pada satu waktu:

/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

Setelah membaca di sini dan menyia-nyiakan dengan menginstal paket yang disarankan:

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

Pesan kesalahan dari docker-compose telah berubah:

[ root @ xxx cm] # buruh pelabuhan-susun -d
/usr/lib/python2.7/site-packages/requests/packages/urllib3/connection.py:251: SecurityWarning: Sertifikat tidak memiliki subjectAltName , kembali untuk memeriksa commonName untuk sekarang. Fitur ini sedang dihapus oleh browser utama dan dihentikan oleh RFC 2818. (Lihat https://github.com/shazow/urllib3/issues/497 untuk detailnya.)
Peringatan keamanan
Kesalahan SSL: nama host 'xx.xx.xx.xx' tidak cocok dengan Tidak ada

(Quad bertitik yang saya keluar adalah dari swarm master / host buruh pelabuhan).

Bisakah masalah ini juga diatasi dengan mengedit atau membuat ulang sertifikat?

Tambahan: Sertifikat dibuat pada VM ini dengan "pembuatan mesin buruh pelabuhan".

Mungkinkah kami menangani bug di mesin galangan yang menghasilkan sertifikat yang tidak cukup mendetail?

Saya hanya melihat kesalahan ini dengan host Docker yang dibuat oleh mesin buruh pelabuhan. Saya yakin sertifikat SSL tidak dibuat dengan benar?

Apakah ada yang punya solusi atau solusi untuk memperbaikinya? Ini adalah sedikit pemblokir bagi saya sekarang: /

@prologic Apakah Anda mendapatkan kesalahan dengan biner atau dengan Tulis yang diinstal Pip? Jika yang terakhir, coba instal requests[security] juga.

@aanand Terima kasih! Saya akan mencobanya dan melaporkan kembali jika itu berhasil atau tidak!

@prologic Kita ingin mengemas requests[security] daripada mengandalkan modul SSL buggy Python; kami melacak upaya di # 1530.

@aanand Terima kasih! Ini bekerja dengan sempurna :)

@coderfi solusi Anda berhasil untuk saya, terima kasih

@aandan 2 Juni build berfungsi dengan baik untuk saya. semoga sukses membasmi serangga yang menyakitkan ini.

@neilsarkar Saya kebetulan menjalankan charles proxy, komentar Anda menyelamatkan saya. : +1:

Saya menggunakan OS X 10.9.5, berikut adalah pilihan saya:

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

Solusi saya:

komentari baris 246: 253 masuk
/usr/local/Cellar/fig/1.3.1/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connection.py

ini adalah bagian yang melempar Pengecualian Keamanan

Masalahnya bagi saya adalah bahwa bahkan Anda menentukan link brew - force openssl, fig / docker-compose masih menggunakan / usr / bin / openssl.

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

Ini berhasil untuk saya. Sekarang saya tidak mendapatkan pesan yang mengganggu lagi.

FYI, resep brew fig / docker-compose menggunakan system python, jadi meskipun Anda menginstal python melalui pyenv atau brew, brew install fig / docker-compose akan tetap menggunakan sistem openssl lib jika tersedia, jika tidak, menginstal versi lain.

Di MAC saya di tempat kerja, saya menyelesaikannya dengan pyenv install 2.7.8, lalu pip easy_install, dan pip install docker-compose.

tapi di mac saya di rumah, "keduanya menjalankan yosemite" saya telah melakukan hal yang sama dan masih mendapatkan peringatan.

Akan terus menggali.

@dtunes - akar masalah (seperti @aanand direferensikan di atas) adalah https://github.com/boot2docker/boot2docker/issues/808. Masalah system-python / homebrew-python adalah herring merah, karena itu hanya tergantung pada apakah Anda ditautkan ke OpenSSL baru atau lama.

Ya, saya melihat tiket itu. Hal yang mengganggu saya, adalah bahwa di Mac saya di tempat kerja, setelah mencoba berbagai pendekatan di atas tidak ada yang berhasil.
Saya kemudian memindahkan / usr / bin / openssl ke / usr / bin / openssl_old, menginstal openssl terbaru menggunakan home brew dan menautkannya secara paksa. baru kemudian saya melakukan hal berikut:

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

Ini berhasil di tempat kerja, pada Mac saya di rumah, namun tidak berhasil. Tetapi saya akan mencoba lagi jika saya membuat kesalahan dan melaporkan hasilnya kembali.

@dtunes - Untuk membangun kembali semua dependensi Anda, Anda perlu menghapus ~/Library/Caches/pip sehingga roda biner yang di-cache yang dibuat dengan OpenSSL yang salah tidak dapat digunakan kembali.

@glyph menulis :

akar penyebabnya (seperti @aanand direferensikan di atas) adalah boot2docker / boot2docker # 808. Masalah system-python / homebrew-python adalah herring merah, karena itu hanya tergantung pada apakah Anda ditautkan ke OpenSSL baru atau lama.

@glyph atau @aanand , apakah itu menunjukkan bahwa perbaikan @aanand (penyelesaian masalah ) yang digabungkan dari # 1474 hanya mengakomodasi b2d yang rusak? @aanand , jika boot2docker / boot2docker # 808 ditangani dengan benar, haruskah # 1474 dicadangkan? Apakah menempatkan harapan dalam rilis kriptografi berikutnya (lihat ini dan ini ) juga merupakan hal yang tidak menyenangkan?

@aanand menulis :

Perhatikan bahwa saya tidak dapat mereproduksi kesalahan ini terhadap VM Boot2Docker yang disediakan dengan mesin galangan - ini hanya terjadi pada VM yang disediakan dengan perintah boot2docker.

@ehazlett menulis :

Ini masuk akal karena saya yakin generasi cert di b2d ada di VM sedangkan mesin menghasilkannya di mesin.

Saya mungkin salah paham, tetapi ada banyak obrolan yang menyalahkan berbagai kombinasi Python / OpenSSL sisi host untuk ini dan masalah terkait. Jika sumber masalahnya adalah OpenSSL rusak yang didistribusikan dengan b2d, saya tidak yakin pendekatan terbaik adalah memastikan bahwa OpenSSL sisi host Compose juga rusak? Untuk apa nilainya, jenis perubahan sisi host tersebut tidak mungkin menyelesaikan masalah ini bagi mereka yang menjalankan b2d melalui (misalnya) Vagrant, dan mengaksesnya di luar Tulis (lihat, misalnya, docker / docker-py # 465 ).

Jika komentar ini lebih sesuai di boot2docker / boot2docker # 808, saya dapat memindahkannya ke sana.

Saya adalah pengelola Homebrew dan saya membantu mesin terbang menjalankannya.

DN Subjek dan Penerbit sertifikat server yang dibuat oleh boot2docker secara identik disetel ke /O=Boot2Docker . Saya yakin sertifikat server sebenarnya ditandatangani oleh sertifikat CA, tetapi AFAICT OpenSSL 1.0.2 menggunakan informasi ini (yaitu DN Subjek dan Penerbit identik) untuk menolak sertifikat server sebagai ditandatangani sendiri alih-alih mencoba memverifikasi sertifikat server terhadap yang disediakan Sertifikat CA Versi OpenSSL sebelum 1.0.2 memvalidasi sertifikat server terhadap sertifikat CA yang diberikan, yang berhasil.

Saya yakin tetapi belum menguji bahwa memberikan server dan sertifikat CA DN Subjek yang berbeda (sehingga sertifikat server memiliki DN Subjek dan Penerbit yang berbeda) akan memungkinkan sertifikat untuk divalidasi pada semua versi OpenSSL. Saya menduga (berdasarkan pembacaan saya tentang panduan bertahan hidup X.509 ini tetapi tidak ada spesifikasi terkait), tetapi saya tidak yakin, bahwa perilaku OpenSSL 1.0.2 wajar dan tidak mewakili regresi yang harus diselesaikan oleh pengembang OpenSSL.

1474 melakukan dua hal yang berbeda:

• menyetel versi Python minimum di 2.7.9: ini memungkinkan urllib3 menyelesaikan permintaan tanpa mengeluarkan InsecurePlatformWarning, yang dikeluarkan saat membuat koneksi HTTPS jika kedua kondisi terpenuhi: versi Python sebelum 2.7.9, dan modul PyOpenSSL tidak hadir. Membundel PyOpenSSL akan sama efektifnya tetapi saya mengerti dari diskusi bahwa itu tidak kompatibel dengan PyInstaller. Bagaimanapun, InsecurePlatformWarning urllib3 tidak terkait dengan masalah sertifikat boot2docker, dan memperbaiki sertifikat tidak menghilangkan kebutuhan untuk solusi ini.
• menyetel versi OpenSSL maksimum pada 1.0.1j. Saya percaya bahwa ini seharusnya tidak diperlukan setelah sertifikat boot2docker diperbaiki.

Jika sumber masalahnya adalah OpenSSL rusak yang didistribusikan dengan b2d

Bukan itu; sertifikat boot2docker (dibuat oleh kode ini ) tidak valid menurut klien yang menggunakan OpenSSL ≥ 1.0.2; pustaka OpenSSL yang didistribusikan dengan boot2docker tidak terlibat.

@glyph atau @aanand , apakah itu menunjukkan bahwa perbaikan @aanand (penyelesaian masalah ) yang digabungkan dari # 1474 hanya mengakomodasi b2d yang rusak? @aanand , jika boot2docker / boot2docker # 808 ditangani dengan benar, haruskah # 1474 dicadangkan? Apakah menempatkan harapan dalam rilis kriptografi berikutnya (lihat ini dan ini) juga merupakan hal yang tidak menyenangkan?

Ya, saya rasa begitu. Saya yakin OpenSSL dengan masalah adalah 1.0.2, dan dengan membatasinya ke 1.0.1, itu akan menghindari logika verifikasi apa pun yang menyebabkan sertifikat gagal. Saya masih tidak tahu _apa_ yang ini tentang sertifikat yang tidak disukai, karena pesan kesalahannya sangat tumpul.

Juga, saya pikir apa yang dilakukan # 1474 terlalu spesifik; setidaknya dari bacaan saya, ini bukan menyetel versi python _minimum_, tetapi menentukan versi _exact_. Tampaknya juga gagal dalam pemeriksaannya, Anda kebetulan memiliki 1.0.1 yang berbeda dari j, yang berarti pembaruan keamanan tidak akan diterapkan bahkan ke 1.0.1, yang merupakan masalah _definitely_.

Saya yakin tetapi belum menguji bahwa memberikan server dan sertifikat CA DN Subjek yang berbeda (sehingga sertifikat server memiliki DN Subjek dan Penerbit yang berbeda) akan memungkinkan sertifikat untuk divalidasi pada semua versi OpenSSL. Saya menduga (berdasarkan pembacaan saya tentang panduan bertahan hidup X.509 ini tetapi tidak ada spesifikasi terkait), tetapi saya tidak yakin, bahwa perilaku OpenSSL 1.0.2 wajar dan tidak mewakili regresi yang harus diselesaikan oleh pengembang OpenSSL.

Saya akan menyelidiki sertifikat docker-machine -generated dan melihat apakah ia memiliki properti ini. Mengapa Anda mengatakan perilaku ini akan diterima / bukan regresi di OpenSSL? Mempercayai sertifikat yang ditandatangani sendiri tidak masalah, dan tidak ada batasan khusus tentang apa yang mungkin dimuat subjek atau penerbit yang saya ketahui. Saya membaca sedikit panduan itu dan sepertinya hanya menunjukkan bahwa sertifikat yang ditandatangani sendiri tidak akan memiliki kepercayaan CA-kartel, jadi browser web Anda tidak akan mempercayainya tanpa konfigurasi tambahan.

Melihat sertifikat di docker-machine VM saya, saya melihat:

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

jadi kamu mungkin benar tentang ini ...

Saya akan menyelidiki sertifikat yang dibuat oleh mesin buruh pelabuhan dan melihat apakah sertifikat tersebut memiliki [DN Subjek dan Penerbit yang cocok].

Anda dapat melihat bahwa sertifikat mesin galangan aanand juga memiliki DN yang berbeda: https://gist.github.com/aanand/3d865623481ba8ae66ee#file -docker-machine-log-L30-L32

Mempercayai sertifikat yang ditandatangani sendiri tidak masalah

Tapi sertifikat yang ditandatangani sendiri tidak valid kecuali Anda mempercayai sertifikat yang ditandatangani sendiri. Kami tidak menginstruksikan OpenSSL untuk mempercayai sertifikat server; kami menginstruksikan OpenSSL untuk mempercayai CA yang mengeluarkan sertifikat server.

Mengapa Anda mengatakan perilaku ini akan diterima / bukan regresi di OpenSSL?

IANAL, tetapi alasan saya berasal dari bahasa "Pada tingkat yang ketat [penandatanganan sendiri] berarti bahwa bidang penerbit dan subjek dalam sertifikat adalah sama." Itu adalah kasus untuk sertifikat server boot2docker. Saat OpenSSL mencoba untuk memvalidasi sertifikat server boot2docker, adalah mungkin untuk membangun rantai kepercayaan lengkap tanpa mempertimbangkan sertifikat CA karena sertifikat server tampaknya ditandatangani sendiri, tetapi tidak dipercaya secara eksplisit, dan oleh karena itu tidak dapat valid. Saya tidak yakin bahwa ini benar-benar perilaku yang benar atau diwajibkan dan saya tidak memenuhi syarat untuk memutuskan, tetapi menurut saya ini tampak "masuk akal".

Terima kasih atas penggaliannya, kawan.

Juga, saya pikir apa yang dilakukan # 1474 terlalu spesifik; setidaknya dari bacaan saya, ini bukan menetapkan versi python minimum, tetapi menentukan versi yang tepat. Tampaknya juga gagal pemeriksaannya Anda kebetulan memiliki 1.0.1 yang berbeda dari j, yang berarti pembaruan keamanan tidak akan diterapkan bahkan ke 1.0.1, yang pasti merupakan masalah.

Sepakat. Dengan asumsi itu OpenSSL 1.0.2 yang tidak setuju dengan sertifikat boot2docker, bagian itu setidaknya harus dapat diperbaiki - Saya akan melihat OpenSSL 1.0.1 terbaru.

@tdsmith , terima kasih atas penjelasannya dan mohon maaf atas kesalahpahamannya. @glyph , terima kasih atas klarifikasinya.

FWIW, saya mencoba menguji teori @tdsmith dan meretas generate_cert (jelek, maafkan saya) untuk membuat nilai yang berbeda untuk Issuer dan Subject . Ini _mungkin_ tampaknya menahan air (tapi lihat peringatan di bawah). Inilah yang saya dapatkan saat menjalankan b2d dengan sertifikat yang dihasilkan dari generate_cert vs. versi saya yang diretas:

0.9.8zd bekerja dengan orig 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 (diinstal melalui MacPorts) _not_ berfungsi dengan orig 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 bekerja dengan diretas generate_cert (0.1.1; tidak mengherankan)

% /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: dengan diretas 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

Peringatan

Untuk kepentingan mencoba mengontrol semua perubahan, perhatikan bahwa ketika generate_cert (0.1) asli dirilis, itu dibuat ketika gambar Docker golang:1.3-cross digunakan untuk membuatnya memiliki akses ke sebuah paket disebut ssh . Paket itu telah diganti dengan openssh-client . Versi OpenSSL yang digunakan saat membuat generate_cert diretas adalah 1.0.1k . Ini tampaknya terhubung secara statis:

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

Jadi sepertinya salah satu dari dua hal mungkin terjadi:

• Salah satu versi OpenSSL yang terlambat menjadi bingung ketika Issuer == Subject , seperti yang disarankan @tdsmith ; atau
• Ada hal lain tentang pembuatan sertifikat yang berubah di OpenSSL sehingga versi OpenSSL yang lebih baru mengalami masalah dalam memvalidasi sertifikat yang dibuat oleh yang sebelumnya

Salah satu cara untuk mengujinya adalah dengan membangun kembali generate_cert tanpa peretasan saya, tetapi dengan versi OpenSSL yang telah diperbarui. Saya akan melakukan itu selanjutnya.

Jadi sepertinya @tdsmith benar. Setelah mundur dari retasan saya untuk memastikan Issuer <> Subject , tetapi membangun kembali generate_cert dengan versi OpenSSL yang lebih baru dari golang:1.3-cross , itu kembali gagal dengan versi OpenSSL yang lebih baru di sisi klien:

0.9.8zd bekerja dengan generate_cert (0.1.2) dengan OpenSSL yang diperbarui

% /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 (diinstal melalui MacPorts) _not_ berfungsi dengan generate_cert (0.1.2) dengan OpenSSL yang diperbarui

% 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

Membutuhkan SvenDowideit / generate_cert # 10. Omong-omong, jika ada yang ingin membuat gambar b2d yang mengarah ke generate_cert s saya yang diretas, Anda dapat mencobanya hingga perbaikan resmi dirilis.

Jika saya mengerti dengan benar, _should_ ini meniadakan kebutuhan untuk memainkan game versi OpenSSL / Python di sisi klien (setidaknya sehubungan dengan masalah ini).

menandai @SvenDowideit

Saya telah sedikit bolak-balik dengan orang-orang OpenSSL. Berikut ringkasan dari Steve Henson:

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

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

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

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

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

Mengubah cara b2d menghasilkan sertifikatnya untuk mengakomodasi klien OpenSSL yang bermasalah tampaknya jauh lebih unggul daripada menambal dan menginstal OpenSSL di sisi klien. Saya tidak yakin pendekatan spesifik mana yang lebih tepat (membuat subjek! = Penerbit vs. menyertakan SKID / ADID di semua sertifikat). Saya akan memberikan uang itu ke @SvenDowideit. :menyeringai:

Bagi yang penasaran (sekali lagi saya rasa kita tidak harus mengambil rute ini), berikut patch OpenSSL dari Steve:

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

Riwayat lengkap: http://rt.openssl.org/Ticket/History.html?user=guest&pass=guest&id=3979.

Tunggu ... _less_ strict? Saya bingung bagaimana pemeriksaan ketat _less_ gagal jika pemeriksaan yang lebih ketat lolos?

Tunggu ... _less_ strict? Saya bingung bagaimana pemeriksaan ketat _less_ gagal jika pemeriksaan yang lebih ketat lolos?

Ya, saya juga kesulitan dengan pilihan bahasa itu. Melihat perbedaannya, saya pikir maksudnya salah menyapu lebih banyak sertifikat sebagai ditandatangani sendiri dengan tidak melakukan banyak pemeriksaan (yaitu, kurang ketat dalam menentukan apa yang _doesn't_ memenuhi syarat sebagai ditandatangani sendiri). Tapi kamu benar. Ini adalah pergantian frase yang aneh.

Saya belum menghabiskan banyak waktu untuk mempelajari sumber OpenSSL, tetapi saya menemukan mereka cukup tidak bisa ditembus di banyak tempat. Mungkin dibutuhkan pola pikir "khusus" untuk mengerjakan proyek itu. :menyeringai:

Saya belum menghabiskan banyak waktu untuk mempelajari sumber OpenSSL, tetapi saya menemukan mereka cukup tidak bisa ditembus di banyak tempat. Mungkin dibutuhkan pola pikir "khusus" untuk mengerjakan proyek itu.

Sebuah pernyataan yang meremehkan, saya pikir: wink:.

Bagaimanapun, terima kasih telah menghubungi orang-orang OpenSSL, senang di sini ini akan diselesaikan di sana. Sementara itu, mengerjakannya di b2d sepertinya hal yang tepat untuk dilakukan. Saya tidak berpikir bahwa ada yang perlu dilakukan compose di sini selain menunggu.

Seperti yang disebutkan di sini , ini memperbaiki beberapa hal untuk saya:

pip install requests[security]

@iffy Itu ikan haring merah; itu mungkin memperbaikinya untuk Anda karena Anda memiliki roda biner cache yang ditautkan ke OpenSSL yang berbeda.

FYI, PR dengan perbaikan dikirimkan sebagai boot2docker / boot2docker # 1029.

Perbaikan untuk ini (terima kasih @posita!) Ada di versi terbaru boot2docker. Untuk meningkatkan:

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

Itu memperbaiki masalah saya. Silakan coba dan laporkan kembali.

Atau, beralihlah ke Docker Machine , yang sekarang hadir sebagai standar sebagai bagian dari Toolbox Docker baru.

Saya masih mengalami masalah ini ...

❯ 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 Panggilan docker-compose Anda berhasil; peringatan yang Anda lihat tidak berbahaya. Anda harus meningkatkan ke OS X 10.10.5 jika Anda memilih untuk tidak melihatnya.

@tdsmith tidak berbahaya bagi saya, membuat OCD saya gila: smile: terima kasih atas tipnya, akan meningkatkan sekarang.

Menghapus instalasi versi python yang diinstal melalui brew memecahkan masalah ini untuk saya. brew remove --force python

Saya telah mencopot pemasangan versi bir, tetapi masih memiliki Python 2.7.10 dan masih memiliki
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) kesalahan.

Saya memiliki penyiapan berikutnya:

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

@chiefy
sudahkah kamu menyelesaikan masalahmu?

apakah ada kode yang tahu jika pekerja galangan kapal bekerja untuk menyelesaikan masalah, atau pada dasarnya itu bukan masalah mereka?

Salam,

@Tokopedia
tidak. di kedua Mac saya (10.9.x dan 10.10.x), saya telah mencoba berbagai hal tanpa perubahan. Saya tidak berpikir ini adalah docker-compose dan lebih banyak hal tentang Python FWIW.

@chiefy
Saya setuju, tetapi saya belum menemukan varian apa pun cara membuatnya bekerja :(

Sepertinya semua orang sudah memecahkan masalah ini, tetapi bukan saya :)

Saya telah menginstal python menggunakan brew sekali, dan saya rasa saya telah menghapus sistem yang satu, jadi saya tidak memiliki opsi untuk kembali ke yang lama.

Saya telah mencoba menginstal buruh pelabuhan dengan beberapa varian:

1. dari biner (mengunduh kotak alat buruh pelabuhan)
2. dari minuman itu sendiri

namun saya masih memiliki:

apakah ada yang punya panduan lengkap tentang cara mengatasi perilaku ini?

Salam,

@PavelPolyakov - ~/.docker pada host Anda.

@PavelPolyakov dan @chiefy , selain saran @glyph , Anda juga dapat mencoba ini (jika Anda tidak ingin sepenuhnya mengubah lingkungan 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] khusus untuk lingkungan VM Anda. Mungkin ada metode yang lebih mudah (mis., vagrant ssh , jika Anda menggunakan Vagrant). Kemudian restart instance boot2docker dan lihat apakah kesalahan SSL masih terjadi.

@tokopedia

Terima kasih atas sarannya, bagi saya bukanlah masalah untuk melakukan reprovisioning pada mesin buruh pelabuhan. Namun itu tidak membantu.

Ketika saya menginstal docker & co dengan:
brew install docker docker-machine docker-compose

Kemudian, mesin default tidak dibuat. Dan saya tidak tahu bagaimana membuatnya menggunakan docker-machine create .

Ketika saya menginstal docker-toolbelt menggunakan file * .pkg, maka mesin dibuat, tetapi saya mengalami kesalahan SSL.
Saya bahkan telah mencoba melakukan:

docker-machine regenerate-certs default

Tapi itu tidak membantu.

@posita
Terima kasih atas sarannya juga.
Dalam panduan Anda, Anda menyarankan untuk mv ~/.docker ~/.docker-bak - untuk alasan apa? Segera setelah kami melakukan ini, kami tidak dapat menjalankan mesin lagi, karena file telah dipindahkan.
Ya, saya dapat masuk ke mesin dan menghapus tls/* , lalu mematikannya, tetapi bagaimana cara memulainya lagi?

Bagaimana cara melakukan reprovisioning dari awal?

@semua
Bagaimana cara Anda menginstal buruh pelabuhan (dengan docker-compose yang berfungsi), apakah melalui brew install atau melalui toolbelt .pkg?
Bagaimana saya bisa yakin, bahwa sertifikat, yang ada di mesin galangan saya valid dan berguna oleh python, bagaimana saya bisa memutakhirkan python dan openssl bahkan lebih dari brew can, dll?

Terima kasih telah membantu.

Salam,

@PavelPolyakov - docker-machine tidak memiliki gagasan tentang mesin "default". Anda dapat menjalankan docker-machine create --driver virtualbox my-docker-machine .

@PavelPolyakov Setelah Anda selesai melakukannya, Anda perlu melakukan eval "$(docker-machine env my-docker-machine)" , atau apa pun yang Anda pilih untuk memanggil mesin dev lokal Anda.

@tokopedia
Benar, itu adalah bagian yang hilang dari menjalankan semuanya dari brew . Saya telah berhasil menyediakan mesin dengan nama default (sama seperti yang dilakukan saat menginstal dari * .pkg).

Namun, seperti biasa, saya mengakhirinya dengan:

:(

Dalam panduan Anda, Anda menyarankan untuk mv ~ / .docker ~ / .docker-bak - untuk alasan apa? Segera setelah kami melakukan ini, kami tidak dapat menjalankan mesin lagi, karena file telah dipindahkan.

@PavelPolyakov , saya tidak yakin. Saya tidak menggunakan docker-machine . Saya menebak berdasarkan lingkungan lain. Harap abaikan jika ini tidak berhasil.

Ya, saya dapat masuk ke mesin dan menghapus tls/* , lalu mematikannya, tetapi bagaimana cara memulainya lagi?

Apakah docker-machine restart tidak berfungsi?

Komentar saya didasarkan pada pengalaman saya sendiri menjalankan boot2docker dengan Vagrant. Ini mungkin tidak berlaku dengan baik untuk docker-machine . Sepertinya @glyph memiliki lebih banyak pengalaman dengan lingkungan tersebut. Saya akan mencoba sarannya.

Bagaimana cara Anda menginstal buruh pelabuhan (dengan docker-compose yang berfungsi), apakah melalui brew install atau melalui toolbelt .pkg?

Ini agak di luar cakupan masalah ini (yang secara khusus menangani masalah sertifikat dengan boot2docker seperti yang dimanifestasikan dalam docker-compose ), tetapi di OS X, saya menggunakan versi biner .

@PavelPolyakov , apa yang terjadi jika Anda melakukan hal berikut?

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

Apa versi untuk boot2docker yang ditampilkan ketika Anda melakukan hal berikut?

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

Jangan ragu untuk mengganti shiny-new-machine-74d5a19e dengan apapun yang Anda inginkan, selama itu tidak mereferensikan contoh yang ada (yaitu, nama seharusnya tidak muncul ketika Anda melakukan docker-machine ls sebelum menjalankan perintah di atas .).

@posita

Hmmm ....: confused: @PavelPolyakov , ini memberi Anda apa?

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
Terima kasih Anda terus membantu.

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

Telah mencoba melakukan hal yang sama pada mesin OSX yang berbeda.
Dengan semua update terbaru (os dan paket brew), dan menghadapi masalah yang sama dengan SSL.

@PavelPolyakov , saya melihat ini dari dump openssl s_client ... :

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

Ini bukan boot2docker default, yang (sekarang) seharusnya:

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

Tanpa mengetahui lebih banyak, tebakan saya adalah bahwa docker-machine menimpa default (entah bagaimana) ketika menyediakan mesin virtual. Tetapi panggilan openssl tampaknya berhasil, jadi saya tidak yakin ini merupakan masalah, dan saya tidak mengerti mengapa docker-compose akan gagal. :terkutuk:

Apa hasil Anda untuk berikut ini?

(
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

Ini akan membuat file seperti ~/Desktop/docker-compose-890-outerr-2015-09-18T14:45:29Z.txt cocok untuk ditempel / diunggah.

@posita
Ini dia:
http://pastebin.com/vWqZgVKi

Saya cukup yakin ini tidak ada hubungannya dengan masalah Anda, tetapi versi docker-compose dan docker-py ketinggalan. Ini adalah rilis terbaru:

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

Juga (dan saya mungkin salah membaca ini), sepertinya ca.pem dan cert.pem berbagi Subject (yang merupakan penyebab asli boot2docker masalah, tetapi datang dari arah lain). Karena sertifikat ini tampaknya dibuat / dikelola oleh docker-machine , apakah masalahnya ada? Saya menemukan buruh pelabuhan / mesin # 1335 dan buruh pelabuhan / mesin # 1767, yang mungkin terkait, tetapi tampaknya tidak ada yang secara langsung tepat.

FWIW, saya menggunakan docker-compose (diinstal melalui pip dalam virtualenv ) dengan OpenSSL dan Python 2.7 yang diinstal dari MacPorts. Versi OpenSSL itu tunduk pada masalah yang teridentifikasi dalam masalah ini (dan diselesaikan dengan pembaruan ke boot2docker ). Bagi saya, kombinasi ini bekerja tanpa masalah dengan boot2docker 1.8.1+ dan Vagrant ( Vagrantfile menangani penyalinan sertifikat boot2docker kembali ke host melalui beberapa sihir penyediaan):

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

Saya menyadari Anda mungkin tidak memiliki pilihan itu. Saya hanya mempostingnya untuk membantu menjelaskan perbedaan, yang dapat membantu dalam mendiagnosis masalah Anda. Bandingkan hal di atas dengan sertifikat yang dibuat 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
...

Perhatikan bahwa Subject dari ca.pem sama dengan Subject dari cert.pem .

Saya rasa masalah Anda bukan masalah dengan docker-compose . ( @aanand , mungkin Anda dapat berkomentar?) Melihat bagaimana masalah ini cukup berantakan, pertimbangkan untuk mengajukan masalah baru untuk buruh pelabuhan / mesin . Saya akan mereferensikan yang ini, mulai dari komentar awal Anda.

Jika Anda memutuskan untuk mengajukan masalah baru ke buruh pelabuhan / mesin , pertimbangkan untuk menambahkan di mana ada sesuatu yang menarik di /var/log/docker.log atau /var/log/boot2docker.log pada instance VM Anda. Misalnya, coba ini:

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

Atau:

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

Mendapatkan ini di OSX el capitain,

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

Hai @DaBelemania ,

hanya penasaran, apakah Anda juga memiliki python dan barang-barang yang diinstal menggunakan brew? Atau sebaliknya.
Dan apakah Anda mengalami kesalahan persis saat melakukan docker-compose build ?

Melalui homebrew, Python 2.7.10

Jadi pasti sesuatu terjadi karena brew :(

@DaveBlooman , lihat juga buruh pelabuhan / mesin # 1910. Jika Anda dapat mereproduksi masalah @PavelPolyakov , mungkin Anda berdua dapat berkolaborasi dalam diagnosis?

Saya memiliki masalah yang sama dan itu karena fakta bahwa saya memiliki koneksi vpn yang terbuka dengan aplikasi lain (Astrill dalam kasus saya) yang mungkin mengacaukan sesuatu dengan konfigurasi jaringan. Semoga ini bisa membantu orang lain yang mengalami masalah yang sama.

Saya mendapatkan kesalahan pada 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

Python 2.7.10
buruh pelabuhan versi 0.5.0
versi docker-compose: 1.5.0

semua diinstal melalui Homebrew

@anthonygreen , sepertinya masalah yang sangat berbeda. Saya tidak melihat pesan kesalahan yang sama seperti yang dibahas di sini. Tampaknya pengguna Homebrew mengalami sejumlah besar masalah yang tidak terkait dengan yang satu ini. Harap pertimbangkan untuk mengajukan masalah baru.

Saya belum membaca seluruh posting ini, tetapi saya melihat kesalahan yang sama pada pengaturan terbaru di OS X Yosemite menggunakan 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

Ternyata saya memiliki set variabel lingkungan CURL_CA_BUNDLE (dengan beberapa sertifikat internal khusus), dan membatalkan pengaturan env var ini sebelum menjalankan docker-compose memungkinkannya melewati kesalahan [SSL: CERTIFICATE_VERIFY_FAILED] .

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

edit: oops, dimaksudkan untuk berkomentar di sini https://github.com/docker/machine/issues/1880

@pmahoney , terima kasih telah memberi tahu kami semua! Saya tidak akan pernah menyangka itu. FYI, Anda mungkin juga dapat melakukan sesuatu seperti ini (jika Anda tidak menginginkan subkulit):

$ CURL_CA_BUNDLE= docker-compose up

@posita Menyetel env var ke string kosong menghasilkan peringatan:

$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

Padahal saya tidak mendapatkan error SSL.

@pmahoney , menarik. Jadi ini terlihat seperti set-but-empty CURL_CA_BUNDLE memiliki semantik yang berbeda (misalnya, sebuah null override) daripada tidak menyetelnya sama sekali (yang mungkin terlihat ke beberapa lokasi default). Saya mencoba menemukan perilaku ini di dokumen, tetapi tidak berhasil. Hal terdekat yang saya temukan adalah ini .

@neilsarkar masalah saya juga proxy Charles berjalan! Terima kasih!

Ya Tuhan, saya juga memiliki CURL_CA_BUNDLE khusus pada kedua mesin tempat saya menguji.

Terima kasih

erf tidak ada untuk saya, tidak ada variabel CURL_CA_BUNDLE :(
Jadi saya mencoba mengaturnya ke nilai yang tidak berhasil sama sekali tetapi jika saya menetapkan CURL_CA_BUNDLE menjadi tidak ada (CURL_CA_BUNDLE =) maka saya memiliki peringatan seperti yang dikatakan @pmahoney dan berfungsi tetapi terminal saya benar-benar dibanjiri oleh pesan peringatan.
Saya harap ada solusi yang lebih baik untuk saya :)

Jika Anda tahu apa nilai yang baik untuk variabel CURL_CA_BUNDLE, saya ambil :)

Terima kasih

Saya memiliki masalah yang sama dengan webkit-patch. Dari melihat dokumen python pada modul SSL / TLS , ssl.get_default_verify_paths() menunjukkan kepada kita di mana Python / OpenSSL mengharapkan file sertifikat CA. Jadi jika Anda menjalankan ini di terminal Anda:

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

kita harus melihat bahwa tanpa SSL_CERT_FILE disetel, modul SSL Python mengharapkan file sertifikat CA di /usr/local/ssl/cert.pem (bagi mereka yang menginstal OpenSSL ke /usr/local/ssl ). Jadi, Anda dapat menyetel SSL_CERT_FILE ke file sertifikat dengan sertifikat CA Root, atau Anda menempatkan file dengan sertifikat Root CA di /usr/local/ssl/cert.pem . Jika Anda memerlukan sertifikat Root CA, unduh curl dan di pohon sumber jalankan lib/mk-ca-bundle.pl dan file ca-bundle.crt akan dibuat. Saya dapat mengonfirmasi bahwa pengaturan SSL_CERT_FILE akan berfungsi dengan OpenSSL 1.0.2d dengan Python 2.7.11 dan Python 3.5.0.

@grahamc Apakah Anda kebetulan memecahkan masalah? Saya memiliki pengaturan yang serupa seperti milik Anda yang berfungsi baik dengan daemon buruh pelabuhan jarak jauh tetapi gagal dengan docker-compose

Kesalahan yang saya dapatkan adalah ERROR: SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

Tidak, saya hanya harus meninggalkan host buruh pelabuhan jarak jauh, sayangnya :(

Saya baru saja mengalami masalah di mana CURL_CA_BUNDLE menyebabkan docker-compose gagal dengan:

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

sementara docker berfungsi dengan baik. Akan lebih baik jika docker-compose mengabaikan variabel lingkungan atau setidaknya mencatat peringatan bahwa itu tidak akan menggunakan sertifikat yang diharapkan.

@buckett , pertimbangkan untuk mengajukan masalah baru untuk menambahkannya sebagai permintaan fitur. Pertimbangkan juga untuk mengajukan masalah saudara dengan docker-py dan minta mereka untuk saling mereferensikan. Saya tidak yakin lapisan mana yang paling sesuai.

edit: Membuat terbitan baru # 3114

Apakah semua orang sudah memperbaikinya? Saya tetap mengalami masalah yang sama. docker-compose version adalah:

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

Inilah yang saya dapatkan dari 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)

Saya menginstal buruh pelabuhan, buruh pelabuhan-mahine dan buruh pelabuhan-menulis melalui kotak alat Docker.

Saya sudah mencoba semua saran di atas tetapi tidak berhasil. Saya tidak memiliki pengalaman dalam docker jadi saya tidak bisa mengetahuinya sendiri.

Apakah ada yang punya akar masalah atau solusi untuk ini? Saya melihatnya di compose 1.7.0 dengan versi openssl yang lebih baru.
Ini semua dibangun dan dijalankan dari alpine, jadi lingkungannya harus murni:

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

@bayu_joo
dalam kasus saya itu disebabkan oleh variabel CURL_CA_BUNDLE env yang telah didefinisikan ulang. Anda harus memeriksa apakah Anda memiliki kasus seperti itu juga.

@PavelPolyakov periksa dump env saya ... tidak ada CURL_CA_BUNDLE

@PavelPolyakov oke ini aneh, saya secara eksplisit membatalkan variabel env itu dan berhasil, meskipun tidak berada di lingkungan saya.

@jmmills huh… sama di sini. Mungkin python memperlakukan set-as-empty secara berbeda dengan tidak disetel?

Mac OS, homebrew docker-compose dan docker-machine, menggunakan system python. Mesin yang baru dibuat dengan: docker-machine create --driver=vmwarefusion --vmwarefusion-memory-size 1536 dev

env | grep CURL tidak menghasilkan apa-apa
docker-compose ps kembali

EROR: Kesalahan SSL: nama host '172.16.129.133' tidak cocok dengan 'localhost'

CURL_CA_BUNDLE='' docker-compose ps kembali:

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

Saya memiliki hal yang sama persis - CURL_CA_BUNDLE tidak disetel di env saya, dan menyetelnya ke string kosong memberi saya keluaran yang sama dengan @inanimatt.

Ini pasti berbau seperti bug upstream, tebakan saya adalah beberapa kode kompatibilitas lingkungan untuk curl, di mana "didefinisikan" dan "kosong" diperlakukan secara berbeda.

Terima kasih,
Jason Mills

• dikirim dari HP.

Pada 24 April 2016, pukul 6:14 pagi, Alex Wilson [email protected] menulis:

Saya memiliki hal yang sama persis - CURL_CA_BUNDLE tidak disetel di env saya, dan menyetelnya ke string kosong memberi saya keluaran yang sama dengan @inanimatt.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub

Hanya tampaknya mempengaruhi versi homebrew - menginstal homebrew Python kemudian menginstal docker-compose melalui pip menyelesaikan semua kesalahan.

Pada 24 Apr 2016, pada 14:14, Alex Wilson [email protected] menulis:

Saya memiliki hal yang sama persis - CURL_CA_BUNDLE tidak disetel di env saya, dan menyetelnya ke string kosong memberi saya keluaran yang sama dengan @inanimatt.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub

Saya yakin saya telah menempelkan replikasi masalah di Linux sebelumnya. Saya bisa mengecek ulang besok di tempat kerja

Terima kasih,
Jason Mills

• dikirim dari HP.

Pada 24 April 2016, pukul 12:22, Matt Robinson [email protected] menulis:

Hanya tampaknya mempengaruhi versi homebrew - menginstal homebrew Python kemudian menginstal docker-compose melalui pip menyelesaikan semua kesalahan.

Pada 24 Apr 2016, pada 14:14, Alex Wilson [email protected] menulis:

Saya memiliki hal yang sama persis - CURL_CA_BUNDLE tidak disetel di env saya, dan menyetelnya ke string kosong memberi saya keluaran yang sama dengan @inanimatt.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub

Masalah yang sama di sini karena saya memperbarui docker-compose ke versi 1.7 menggunakan brew.

$ 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

Mengosongkan jenis CURL_CA_BUNDLE env var memecahkan masalah:

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

Menurunkan versi ke 1.6.2 juga menyelesaikan masalah.

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

Daripada menonaktifkan CURL_CA_BUNDLE, Anda dapat menjalankan menggunakan:
CURL_CA_BUNDLE = ~ / .docker / mesin / mesin / default / ca.pem docker-compose ps

Saya mungkin bukan orang pertama yang mengemukakan hal ini, tetapi bukankah itu berlawanan dengan intuisi bahwa variabel lingkungan curl memiliki efek apa pun pada aplikasi Python yang tidak terkait?

Terima kasih,
Jason Mills

• dikirim dari HP.

Pada 7 Mei 2016, pukul 15.22, Lorenzo Sicilia [email protected] menulis:

Daripada menonaktifkan CURL_CA_BUNDLE, Anda dapat menjalankan menggunakan:
CURL_CA_BUNDLE = ~ / .docker / mesin / mesin / default / ca.pem docker-compose ps

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub

Saya mengalami masalah ini dan masalahnya ada pada variabel lingkungan REQUESTS_CA_BUNDLE yang menunjuk ke lokasi khusus untuk sertifikat yang ditandatangani sendiri. Encase ini membantu siapa saja.

• Michael Housh

@aboutlo Ini berfungsi - tidak bekerja dengan berkas ca.pem , hanya dengan yang ini. Saya juga menggunakan Windows jadi saya memiliki konfigurasi voodoo yang lebih banyak, terima kasih!

Menghapus instalasi ndg-httpsclient (dengan pip - adalah versi 0.4.0) memecahkan masalah bagi saya, lihat posting saya di sini: https://github.com/docker/compose/issues/3365

Saya men-debug docker-compose dan docker-py dan menemukan bahwa Anda harus menggunakan variabel lingkungan atau opsi dalam perintah. Anda tidak boleh mencampur ini. Jika Anda bahkan menentukan --tls dalam perintah maka Anda harus menentukan semua opsi sebagai objek TLSConfig, karena sekarang objek TLSConfig dibuat sepenuhnya dari opsi perintah dan mengoperasikan objek TFSConfig yang dibuat dari variabel lingkungan.

@ m-housh OMG terima kasih atas tip itu! Hal yang persis sama terjadi pada saya! Menghapus REQUESTS_CA_BUNDLE dari lingkungan saya dan menyelesaikan masalah ini untuk saya.

Saya mengalami masalah yang sama. Pertama saya pikir itu karena perbedaan versi OpenSSL (Pyhton memiliki 1.0.2 tetapi OS memiliki 0.9.8) Saya membuat keduanya 1.0.2 tetapi tetap tidak berfungsi.
Saya telah memecahkan masalah saya hanya dengan ssh ke buruh pelabuhan dan kemudian memeriksa sertifikat saya di kunci resmi dan memperbaruinya. Menariknya, ternyata ternyata ada sertifikat yang salah.

Ikuti langkah-langkah ini:

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

Periksa apakah sertifikat ini benar-benar sertifikat dari komputer Anda. Jika tidak, salin saja milik Anda ke file ini dan simpan. Lalu jalankan saja:

docker-compose up

Ini berhasil bagi saya dan semoga membantu.

Perawatan masalah: Tampaknya ada berbagai mode kegagalan dan skenario kesalahan / kesalahan konfigurasi pengguna (semuanya sebagian besar bersifat historis) yang dijelaskan di sini.

Saya tidak melihat apa pun yang tampaknya mengarah ke masalah aktif yang sedang berlangsung dalam penulisan, jadi saya menutup masalah tersebut. Jika Anda masih melihat kesalahan terkait dengan versi modern kemudian silakan buka masalah segar dengan rincian lengkap dari skenario Anda dll