Machine: Sertifikat tidak terpasang dengan benar, selalu buat ulang

Terima kasih atas ringkasan detailnya. Saya juga pernah melihat masalah seperti ini sebelumnya dan saya akan menyelidikinya.

Apakah Anda menggunakan VirutalBox terbaru? yaitu 5.0.6?

Saya menggunakan 5.0.4 yang dikirimkan bersama Docker Toolbox versi terbaru (1.8.2c). Saya baru saja menghapus versi itu, menginstal 5.0.6 dan saya mengalami perilaku yang sama.

Ok terima kasih.

@carolynvs Jika Anda menghapus jaringan hanya Host yang Anda miliki (dapat melakukan ini di GUI VirtualBox) dan coba lagi, apakah berhasil?

Saya menghapus mesin, melepas adaptor dan mencoba lagi dengan hasil yang sama.

Ok terima kasih. Perilaku yang sangat aneh. Saya mungkin membuat test build yang membuang lebih banyak informasi tentang sertifikat dan menyarankan Anda mencobanya jika Anda setuju.

Tentu saja! Saya senang membantu semampu saya.

Jika Anda hanya ingin membuat cabang dan mengarahkan saya ke sana, saya dapat membuatnya sendiri (:heart: containerized builds!). Dengan begitu Anda tidak perlu melempar beberapa bangunan ke dinding jika ini membutuhkan lebih dari satu upaya.

Hal lain yang mungkin dipertimbangkan saat memperbaiki ini, beberapa orang seperti saya sebenarnya menulis konten docker-machine env ke file yang akan saya sumber untuk setiap sesi terminal baru (karena ini sedikit lebih cepat daripada menjalankan docker-machine env ). Jika output dari perintah ini berisi sesuatu yang tidak mungkin eval d, itu jelas akan menyebabkan masalah.

Jadi baris seperti berikut akan menyebabkan masalah:

Invalid certs detected; regenerating for 192.168.99.100:2376
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...

Saya mengalami masalah ini pada 0.5.0-dev , tetapi belum mengalaminya sejak menurunkan versi ke 0.4.1 .

Saya mengalami perilaku yang persis sama hari ini pada kandidat rilis.

Hai @carolynvs @blaggacao , terima kasih banyak atas tanggapan Anda.

Saya mencoba mereproduksi/memperbaiki bug ini. Bisakah Anda mencoba PR ini (https://github.com/docker/machine/pull/2006) yang saya buat untuk membantu menyelidiki bug

Sepertinya aku juga melihat ini. Saya menggunakan master build terbaru di OS X menggunakan driver digitalocean , jadi ini jelas tidak ada hubungannya dengan lingkungan. Saya pikir tag area/windows dan area/driver-virtualbox tidak relevan di sini :)

Hai @hairyhenderson , dapatkah Anda mencoba membangun PR #2006 dan memberi tahu saya hasilnya untuk docker-machine -D env default ?

@dgageot - akan dilakukan ketika saya mendapat kesempatan.

Saya juga lebih memikirkan hal ini dan menyadari bahwa saya telah melakukan _local_ build (yaitu make build pada OS X, tanpa menggunakan wadah). Salah satu area di mana go build berperilaku berbeda di masa lalu adalah seputar sertifikat (terutama sertifikat root CA), jadi _mungkin_ ini terkait dengan itu... Saya tidak tahu.

Tapi saya akan membangun kembali dengan #2006 dan mencobanya. Terima kasih!

@hairyhenderson Itu poin yang bagus. Saya akan menjalankan pengujian saya dengan mesin buruh pelabuhan yang dikompilasi silang

@dgageot Ini adalah output yang gagal https://Gist.github.com/carolynvs/e2473d21c3376f1ebec2 dari docker-machine -D env default untuk mesin baru.

Saya membuat #2006 dan menyalin docker-machine.exe dan docker-machine-driver-virtualbox.exe ke direktori instalasi Docker Toolbox. Saya menggunakan Docker Toolbox 1.8.2c di Windows 10.

Saya tidak cukup mahir untuk mengetahui bagaimana membangun, mungkin saya akan melihatnya malam ini, jika saya bisa mengetahuinya.

@carolynvs Terima kasih banyak. Saya masih tidak mengerti apa yang terjadi tetapi log Anda akan membantu saya.

@carolynvs Bisakah Anda memberikan output dari:

VBoxManage list hostonlyifs
VBoxManage list dhcpservers

C:\Program Files\Oracle\VirtualBox>VBoxManage list hostonlyifs
Name:            VirtualBox Host-Only Ethernet Adapter
GUID:            3729f60a-d9c3-4daa-96ca-7ce7bae4ddcc
DHCP:            Disabled
IPAddress:       192.168.56.1
NetworkMask:     255.255.255.0
IPV6Address:     fe80:0000:0000:0000:9d6d:4449:fce1:e1cb
IPV6NetworkMaskPrefixLength: 64
HardwareAddress: 0a:00:27:00:00:00
MediumType:      Ethernet
Status:          Up
VBoxNetworkName: HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter

Name:            VirtualBox Host-Only Ethernet Adapter #2
GUID:            99076a32-c9e5-4930-895a-a35ee45c2542
DHCP:            Disabled
IPAddress:       192.168.99.1
NetworkMask:     255.255.255.0
IPV6Address:     fe80:0000:0000:0000:118b:39e1:36b9:a336
IPV6NetworkMaskPrefixLength: 64
HardwareAddress: 0a:00:27:00:00:00
MediumType:      Ethernet
Status:          Up
VBoxNetworkName: HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter #2


C:\Program Files\Oracle\VirtualBox>VBoxManage list dhcpservers
NetworkName:    HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter
IP:             192.168.56.100
NetworkMask:    255.255.255.0
lowerIPAddress: 192.168.56.101
upperIPAddress: 192.168.56.254
Enabled:        Yes

NetworkName:    HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter #2
IP:             192.168.99.6
NetworkMask:    255.255.255.0
lowerIPAddress: 192.168.99.100
upperIPAddress: 192.168.99.254
Enabled:        Yes

Saya telah menemukan bahwa saya kadang-kadang masih mendapatkan adaptor hanya Host ganda. Saya baru saja menghapus keduanya dan membuat mesin baru. Sertifikat masih dibuat ulang ketika saya menjalankan docker-machine env default .

Berikut adalah output dari perintah VBoxManage untuk kedua kalinya (dengan hanya 1 host adapter).

C:\Program Files\Oracle\VirtualBox>VBoxManage list hostonlyifs
Name:            VirtualBox Host-Only Ethernet Adapter
GUID:            2883b47a-862d-454e-9db7-42c3789585eb
DHCP:            Disabled
IPAddress:       192.168.99.1
NetworkMask:     255.255.255.0
IPV6Address:     fe80:0000:0000:0000:90ff:fd25:e5f0:8c92
IPV6NetworkMaskPrefixLength: 64
HardwareAddress: 0a:00:27:00:00:00
MediumType:      Ethernet
Status:          Up
VBoxNetworkName: HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter


C:\Program Files\Oracle\VirtualBox>VBoxManage list dhcpservers
NetworkName:    HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter
IP:             192.168.99.6
NetworkMask:    255.255.255.0
lowerIPAddress: 192.168.99.100
upperIPAddress: 192.168.99.254
Enabled:        Yes

@carolynvs Saya tidak tahu sejauh ini.
Saya mendorong beberapa komitmen lagi pada PR untuk mencetak lebih banyak informasi dan mencoba berbagai hal.
Jika Anda punya waktu untuk memperbarui hasil yang Anda dapatkan, itu akan sangat bagus.

ping @nathanleclaire @dmp42 ada ide?

Inilah keluaran baru: https://Gist.github.com/carolynvs/84cd140bcbf9b696e20f.

Beri tahu saya jika ada cara lain untuk men-debug masalah koneksi. Saya tidak yakin mesin buruh pelabuhan apa yang mendeteksi yang menyebabkannya membuat ulang sertifikat tetapi saya senang untuk melihat-lihat /var/lib/boot2docker pada Host atau membandingkan sertifikat antara windows dan Host, dll jika saya tahu apa untuk mencari.

@carolynvs Itu akan luar biasa. Seperti yang Anda tunjukkan, masalah muncul di cert.go :

Certs are not valid: read tcp 192.168.99.1:49755->192.168.99.100:2376: wsarecv: An established connection was aborted by the software in your host machine.

Sertifikat tidak disalin dengan benar ke file vm.
Atau vm tidak dapat dijangkau pada port 192.168.99.100:2376 (konfigurasi jaringan host? firewall, vpn? konfigurasi jaringan vm?)
Atau ada masalah dalam cara kami memeriksa.

Jika Anda mengekspor variabel env yang diberikan oleh docker-machine env dan mengabaikan kesalahan, apakah Anda dapat terhubung ke daemon buruh pelabuhan?

Saya bisa melakukan ping ke Host buruh pelabuhan dan ssh ke dalamnya. Ketika saya mengabaikan pesan tentang membuat ulang sertifikat dari docker-machine env dan mengatur variabel secara manual, saya masih tidak dapat terhubung dengan klien buruh pelabuhan.

An error occurred trying to connect: Get https://192.168.99.101:2376/v1.20/containers/json: WSARecv tcp 192.168.99.1:50072: An established connection was aborted by the software in your host machine.

Sertifikat pada Host di /var/lib/boot2docker/tls/ tidak cocok dengan yang lokal di ~/.docker/machine/machines/default/ . Sertifikat di /var/lib/boot2docker/ cocok dengan apa yang ada di mesin lokal saya. Juga sertifikat di ~/.docker/machine/certs/ cocok dengan apa yang ada di ~/.docker/machine/machines/default/ .

Saya menduga masalahnya terletak pada sertifikat yang tidak cocok, yang mencegah mesin buruh pelabuhan terhubung dengan aman ke daemon buruh pelabuhan, sehingga memicu regen sertifikat?

Saya telah memverifikasi bahwa daemon buruh pelabuhan sedang berjalan:

docker<strong i="18">@default2</strong>:/var/log$ ps aux | grep docker
root      2439  0.1  1.9 122904 19872 ?        Sl   13:23   0:00 /usr/local/bin/docker daemon -D -g /var/lib/docker -H unix:// -H tcp://0.0.0.0:2376 --label provider=virtualbox --tlsverify --tlscacert=/var/lib/boot2docker/ca.pem --tlscert=/var/lib/boot2docker/server.pem --tlskey=/var/lib/boot2docker/server-key.pem -s aufs

Juga di sini adalah log dari boot2docker dan buruh pelabuhan: https://Gist.github.com/carolynvs/f7965455ebbceb85d4e6

:+1: Terima kasih! aku merasa kita semakin dekat :smile:

IIRC, sertifikat di /var/lib/boot2docker/tls dihasilkan di sisi server oleh skrip startup di OS boot2docker dan tidak digunakan untuk apa pun dalam model Mesin saat ini (ini adalah peninggalan bagaimana boot2docker-cli secara historis mengharapkan sertifikat ditetapkan naik).

@carolynvs @nathanleclaire Saya tidak tahu kalau begitu. Satu-satunya perbedaan yang saya miliki di log saya adalah bahwa saya menggunakan VBox versi 5.0.6 dan boot2docker yang lebih baru.

@carolynvs Bisakah Anda mencoba menghubungkan ke daemon buruh pelabuhan menggunakan curl? Kami mungkin mendapatkan umpan balik yang lebih baik tentang apa yang salah. Saya pikir Anda menggunakan windows, jadi saya tidak benar-benar tahu bagaimana mencapainya, tetapi inilah cara saya melakukannya di OSX:

$ openssl pkcs12 -export -in ~/.docker/machine/certs/cert.pem -inkey ~/.docker/machine/certs/key.pem -out ~/.docker/machine/certs/cert.pfx -password pass:supersecret
$ curl -v --cacert ~/.docker/machine/machines/default/ca.pem --cert ~/.docker/machine/certs/cert.pfx --pass supersecret https://192.168.99.100:2376/version

*   Trying 192.168.99.100...
* Connected to 192.168.99.100 (192.168.99.100) port 2376 (#0)
* WARNING: SSL: Certificate type not set, assuming PKCS#12 format.
* Client certificate: dgageot
* WARNING: using IP address, SNI is being disabled by the OS.
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: default
* Server certificate: dgageot
> GET /version HTTP/1.1
> Host: 192.168.99.100:2376
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Server: Docker/1.8.3 (linux)
< Date: Tue, 20 Oct 2015 14:47:14 GMT
< Content-Length: 192
<
{"Version":"1.8.3","ApiVersion":"1.20","GitCommit":"f4bf5c7","GoVersion":"go1.4.2","Os":"linux","Arch":"amd64","KernelVersion":"4.1.10-boot2docker","BuildTime":"Mon Oct 12 18:01:15 UTC 2015"}
* Connection #0 to host 192.168.99.100 left intact

FTR, inilah tutorial yang saya gunakan untuk membuatnya berfungsi: http://opensolitude.com/2015/07/12/curl-docker-remote-api-os-x.html

@dgageot Ooh, ya ini sepertinya menjadi masalah di mesin saya (menggunakan curl/openssl dari Git untuk Windows jadi semua perintahnya sama).

$ openssl pkcs12 -export -in ~/.docker/machine/certs/cert.pem -inkey ~/.docker/machine/certs/key.pem -out ~/.docker/machine/certs/cert.pfx -password pass:supersecret
Loading 'screen' into random state - done

caro8994<strong i="7">@CAROLYNVANS87E4</strong> MINGW64 ~
$ docker-machine ip default
192.168.99.100

caro8994<strong i="8">@CAROLYNVANS87E4</strong> MINGW64 ~
$ curl -v --cacert ~/.docker/machine/machines/default/ca.pem --cert ~/.docker/machine/certs/cert.pfx --pass supersecret https://192.168.99.100:2376/version
* timeout on name lookup is not supported
*   Trying 192.168.99.100...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to 192.168.99.100 (192.168.99.100) port 2376 (#0)
* ALPN, offering http/1.1
* could not load PEM client certificate, OpenSSL error error:0906D06C:PEM routines:PEM_read_bio:no start line, (no key found, wrong pass phrase, or wrong file format?)
* Closing connection 0
curl: (58) could not load PEM client certificate, OpenSSL error error:0906D06C:PEM routines:PEM_read_bio:no start line, (no key found, wrong pass phrase, or wrong file format?)

Saya memeriksa semua sertifikat di ~/.docker/machine/certs menggunakan vi -b path/to/cert dan memverifikasi bahwa ia memiliki akhiran baris unix. Saya juga menggunakan perintah berikut untuk mencoba memeriksa apakah openssl dapat membacanya.

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

Saya akan terus mengaduk-aduk sertifikat, karena ini sepertinya masalahnya. Mungkin mencobanya di komputer lain dan lihat apakah itu hanya masalah Windows 10.

@carolynvs Kerja bagus ! Saya akan memeriksanya besok pagi (waktu Paris)

Hai @carolynvs , ca.pem juga?

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

Bisakah Anda memeriksa bahwa itu dimulai dengan -----BEGIN CERTIFICATE----- dan diakhiri dengan -----END CERTIFICATE----- . Tidak ada sebelum dan sesudah.

@carolynvs Saya harus mengakui bahwa saya tidak tahu apa yang terjadi. Sudahkah Anda mencoba PR ini yang tampaknya terkait secara samar.

Jika Anda tidak keberatan mengkonfirmasi ringkasan menengah ini, jadi saya bisa diam-diam menghabiskan otak untuk ini:

• Sertifikat disalin, tetapi tidak dapat dibaca?

Saya yakin, Anda sudah memeriksa: http://stackoverflow.com/questions/20837161/openssl-pem-routinespem-read-biono-start-linepem-lib-c703expecting-truste
Saya meletakkannya untuk referensi bagi orang lain.

Saya baru saja mencoba perintah curl yang berbeda menggunakan --cert dan --key alih-alih file pfx yang dihasilkan dan itu dapat terhubung.

$ curl --cacert ~/.docker/machine/machines/bugtest/ca.pem --cert ~/.docker/machine/machines/bugtest/cert.pem --key ~/.docker/machine/machines/bugtest/key.pem https://$(docker-machine ip bugtest):2376/version
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   192  100   192    0     0   1761      0 --:--:-- --:--:-- --:--:--  1761{"Version":"1.8.3","ApiVersion":"1.20","GitCommit":"f4bf5c7","GoVersion":"go1.4.2","Os":"linux","Arch":"amd64","KernelVersion":"4.1.10-boot2docker","BuildTime":"Mon Oct 12 18:01:15 UTC 2015"}

Melihat lebih dekat pada output docker-machine env Saya melihat bahwa itu mengekspor apa yang menurut saya merupakan jalur sertifikat yang buruk. Di mac saya ini menunjuk ke .docker/machines/machine/sementara di output di bawah, itu menunjuk ke .docker/machine/certs.

$ docker-machine env bugtest
Certs are not valid: remote error: bad certificate
Invalid certs detected; regenerating for 192.168.99.102:2376
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.102:2376"
export DOCKER_CERT_PATH="C:\Users\caro8994\.docker\machine\certs"
export DOCKER_MACHINE_NAME="bugtest"
# Run this command to configure your shell:
# eval "$(C:\Program Files\Docker Toolbox\docker-machine.exe env bugtest)"

Setelah secara manual mengatur variabel lingkungan, mengubah jalur sertifikat ke apa yang saya pikir seharusnya, saya dapat terhubung dengan klien buruh pelabuhan.

Mungkin ketika mesin buruh pelabuhan sedang menguji apakah dapat terhubung, ia menggunakan sertifikat yang salah?

Saya menambahkan beberapa info debug ketika memvalidasi sertifikat dan kemudian mencoba menghubungkan secara manual menggunakan terlebih dahulu apa yang digunakan mesin buruh pelabuhan kemudian apa yang menurut saya harus digunakan.

caro8994<strong i="16">@CAROLYNVANS87E4</strong> MINGW64 ~
$ docker-machine env bugtest
HOST URL=192.168.99.102:2376
CA CERT PATH=C:\Users\caro8994\.docker\machine\certs\ca.pem
SERVER CERT PATH=C:\Users\caro8994\.docker\machine\machines\bugtest\server.pem
SERVER KEY PATH=C:\Users\caro8994\.docker\machine\machines\bugtest\server-key.pem
Certs are not valid: read tcp 192.168.99.1:50658->192.168.99.102:2376: wsarecv: An established connection was aborted by the software in your host machine.
Invalid certs detected; regenerating for 192.168.99.102:2376
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.102:2376"
export DOCKER_CERT_PATH="C:\Users\caro8994\.docker\machine\certs"
export DOCKER_MACHINE_NAME="bugtest"
# Run this command to configure your shell:
# eval "$(C:\Program Files\Docker Toolbox\docker-machine.exe env bugtest)"

caro8994<strong i="17">@CAROLYNVANS87E4</strong> MINGW64 ~
$ curl --cacert ~/.docker/machine/certs/ca.pem --cert ~/.docker/machine/machines/bugtest/server.pem --key ~/.docker/machine/machines/bugtest/server-key.pem https://$(docker-machine ip bugtest):2376/version
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (35) error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate

caro8994<strong i="18">@CAROLYNVANS87E4</strong> MINGW64 ~
$ curl --cacert ~/.docker/machine/certs/ca.pem --cert ~/.docker/machine/machines/bugtest/cert.pem --key ~/.docker/machine/machines/bugtest/key.pem https://$(docker-machine ip bugtest):2376/version
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   192  100   192    0     0    472      0 --:--:-- --:--:-- --:--:--   472{"Version":"1.8.3","ApiVersion":"1.20","GitCommit":"f4bf5c7","GoVersion":"go1.4.2","Os":"linux", "Arch":"amd64","KernelVersion":"4.1.10-boot2docker","BuildTime":"Mon Oct 12 18:01:15 UTC 2015"}

Jadi saya melihat 2 hal yang mencurigakan:

1. DOCKER_CERT_PATH menggunakan .docker/machine/certs alih-alih .docker/machine/machines/
2. Validasi menggunakan server.pem dan server-key.pem bukan cert.pem dan key.pem. Saya tidak tahu untuk apa setiap sertifikat tetapi itu sepertinya tidak benar.

Terima kasih banyak @carolynvs yang seharusnya sangat membantu. Sebelum saya mencerna semua yang Anda laporkan, dapatkah Anda mencoba versi terbaru https://github.com/docker/machine/pull/2006 Ini harus mencetak sertifikat yang digunakan untuk validasi. Itu seharusnya membantu

Berikut adalah sertifikat yang digunakannya

URL HOST=192.168.99.102:2376
CA CERT PATH=C:\Users\caro8994.docker\machine\certsca.pem
SERVER CERT PATH=C:\Users\caro8994.docker\machine\machines\bugtest\server.pem
SERVER KEY PATH=C:\Users\caro8994.docker\machine\machines\bugtest\server-key.pem

Itu dari info debug saya sendiri, bukan PR yang membutuhkan waktu lama untuk membangun sekarang karena membangun semua plugin. :tersenyum:

Oke, sekarang saya bingung, jadi saya coba rekap saja.

Dapatkah Anda mengkonfirmasi bahwa:

• ~/.docker/machine/certs/ca.pem sama dengan ~/.docker/machine/machines/bugtest/ca.pem
• ~/.docker/machine/certs/cert.pem sama dengan ~/.docker/machine/machines/bugtest/cert.pem
• ~/.docker/machine/certs/key.pem sama dengan ~/.docker/machine/machines/bugtest/key.pem
• Anda berhasil membuat docker cli mencapai server. Nilai DOCKER_CERT_PATH Anda gunakan saat itu?
• Di mac Anda, docker-machine env bugtest mencetak ekspor DOCKER_CERT_PATH="~/.docker/machine" dan bukan DOCKER_CERT_PATH="~/.docker/machine/certs"

Terima kasih untuk dukungannya!

@carolynvs FTR, cross-building hanya docker-machine, hanya untuk windows seharusnya lebih cepat: TARGET_ARCH=amd64 TARGET_OS=windows make build-x-machine

Maaf untuk dump otak!

• ca.pem, cert.pem dan key.pm sama di ~/.docker/machine/certs dan ~/.docker/machine/machines/bugtest
• Klien buruh pelabuhan bekerja ketika saya mengatur DOCKER_CERT_PATH ke ~.docker/machine/machines/bugtest
• Di mac saya (yang berfungsi) docker-machine env set DOCKER_CERT_PATH="~/.docker/machine/machines/bugtest" . Pada Windows 10 (yang tidak), perintah yang sama menghasilkan DOCKER_CERT_PATH="~/.docker/machine/certs"

Ini ada di tempat pembuangan otak saya tetapi mungkin telah hilang. Saat mesin buruh pelabuhan memvalidasi sertifikat, mesin tersebut mencoba untuk terhubung ke daemon buruh pelabuhan menggunakan server.pem dan server-key.pem. Ini tampaknya sangat mencurigakan.

BAIK. Mari kita panggil @nathanleclaire dan @ehazlett untuk menyelamatkan. Saya pikir Anda berhasil, tetapi sekarang, saya terlalu baru dalam proyek untuk memahami mengapa kami memiliki begitu banyak sertifikat yang digandakan dan mengapa kami tidak menggunakan yang benar.

Terima kasih atas tip pembuatannya!

Di bawah ini adalah output yang relevan dari build terbaru PR #2006 dan inilah output lengkapnya: https://Gist.github.com/carolynvs/8b7034c26fe3a764c537

Reading CA certificate from C:\Users\caro8994\.docker\machine\certs\ca.pem
Reading server certificate from C:\Users\caro8994\.docker\machine\machines\bugtest\server.pem
Reading server key from C:\Users\caro8994\.docker\machine\machines\bugtest\server-key.pem

Maaf untuk kebisingan yang ditutup/dibuka kembali. aku meraba-raba

Oi ya. @carolynvs @dgageot kalian semua adalah juara untuk terus mengejar yang satu ini. Saya pikir kecurigaan Carolyn benar: jika DOCKER_CERT_PATH tidak diatur dengan benar, maka komunikasi dengan daemon tidak akan berfungsi dengan baik. Sepertinya ini mungkin masalah dengan jalur yang saya perkenalkan secara tidak sengaja dalam perubahan libmachine . Saya akan terus menyelidiki ini dan menyelidiki temuan Anda sejauh ini.

Mungkinkah pintu gerbang ke pelakunya adalah jalur ini?
https://github.com/docker/machine/blob/8aa1572e0dcd75762a7627e1056ef104317f44b9/libmachine/persist/filestore.go#L155

@blaggacao Pasti kuat di bidang kemungkinan - kode itu cenderung sedikit rapuh dan telah bermasalah di masa lalu.

Saya tidak mengerti bagaimana ini bisa berbeda di windows dan mac os, meskipun seperti yang dikonfirmasi oleh @carolynvs .
Bagi saya itu jelas membangun jalur .docker\machine\certs .

diff .docker/machine/certs/ca.pem .docker/machine/machines/oca/ca.pem
diff .docker/machine/certs/cert.pem .docker/machine/machines/oca/cert.pem
diff .docker/machine/certs/key.pem .docker/machine/machines/oca/key.pem

tetap diam.

@blaggacao jelas, saya tidak memiliki perilaku yang sama dengan @carolynvs di mac. Jadi ada yang mencurigakan.

Ya, sertifikat disalin ke direktori mesin itu selama bit penyediaan.

@dgageot Mohon maaf atas kebingungannya. Mac saya menjalankan mesin buruh pelabuhan 0.4.1. Saya hanya menjalankan PR build di mesin Windows saya karena saya telah menguji perbaikan di sana saat mereka digabungkan menjadi master.

Saya dapat membuat dan menjalankan lagi di mac saya sekarang.

saya melanjutkan:

• diffs tidak menunjukkan perbedaan antara /machine/certs dan /machine/machines/certs
• Saya tidak dapat mereproduksi solusi carlynvs untuk menyelesaikan masalah.

Saat mengatur DOCKER_CERT_PATH secara manual di windows (di bash), Anda harus menggunakan jalur gaya UNIX. Misalnya, export DOCKER_CERT_PATH="~./docker/machine/machines/oca" .

Saya dapat mengonfirmasi bahwa pada mesin (miring) saya, sertifikat cocok antara /machine/certs dan /machine/machines/certs.

Saya dapat mengonfirmasi, dengan menyalin secara manual, karena scp tidak berfungsi:

diff ca.pem.local       ca.pem.vm       FALSE
diff server.pem.local   server.pem.vm   TRUE
diff key.pam.local      key.pem.vm      TRUE

yang kedua dan ketiga berbeda antara /machines/oca dan oca:~/.docker

Jalur mana di VM yang Anda gunakan untuk sertifikat @blaggacao ?

Aku baru sadar, itu salah...

Saya memeriksa ~/.docker Saya akan memeriksa lagi terhadap /var/lib/boot2docker

Saya pasti bisa mengkonfirmasi itu

• sertifikat di /machines/oca dan oca:/var/lib/boot2docker/ adalah sama
  ( Saya menjalankan dos2unix pada semua 3 bidang ca.pem , server.pem , sever-key.pem pada oca )

Saya juga mendapatkan kesalahan batas waktu ini: https://github.com/docker/machine/blob/6a5219b879db52698ccb2b7e0aafd516b34df839/libmachine/provision/boot2docker.go#L193
setiap kali saya menjalankan env baik dengan flag --native-ssh atau tidak

Ya, @blaggacao juga sepertinya IP hanya host yang ditetapkan untuk VM tidak dapat dijangkau di komputer Anda. Bisakah Anda ping $(docker-machine ip vmname) ?

tidak, tidak berhasil juga... "Waktu permintaan habis"

docker-machine ssh vmname berhasil

Ya, ssh melewati localhost . Tetapi tampaknya Anda tidak dapat menghubungi IP VM Host yang ditetapkan saja, jadi saya tidak berharap env berfungsi dengan benar. Apakah Anda menggunakan VPN atau proxy?

tidak, yang akan saya ketahui, cukup periksa kembali task manager ... UPDATE mendeteksi satu, tutup

Penutupan tidak mengubah apa pun, tetapi ini masalah lain, saya pikir ...

https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/commands/config.go#L88

membawa saya ke

https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/libmachine/cert/cert.go#L177

Karena saya tidak mendapatkan apa pun dari: https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/libmachine/cert/cert.go#L22

kandidat yang tersisa adalah:
https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/libmachine/cert/cert.go#L198 -L205

Ini berbau seperti hubungan antara kedua masalah. Bisakah Anda menafsirkan jalan pikiran saya?

Penggalian jarak jauh: https://github.com/leo-stone/fix-go-1.5-tls-issue/blob/master/main.go

Saya tidak mempercayai lingkungan Windows saya lagi, jadi saya memulai kembali dan membangun kembali Windows lalu memakai #2006.

Di file docker.log saya melihat kesalahan ini

2015/10/21 17:06:23 http: TLS handshake error from 192.168.99.1:50386: tls: failed to verify client's certificate: x509: certificate has expired or is not yet valid

jadi saya memeriksa tanggal sertifikat

$ openssl x509 -in server.pem -noout -dates
notBefore=Oct 21 22:00:00 2015 GMT
notAfter=Oct  5 22:00:00 2018 GMT

Mungkinkah masalahnya adalah bahwa sertifikat itu bertanggal di masa mendatang? Itu akan menjelaskan mengapa awalnya perintah curl saya tidak berfungsi tetapi beberapa jam kemudian berhasil.

sama disini:

$ openssl x509 -in .docker/machine/machines/oca/server.pem -noout -dates
notBefore=Oct 21 22:00:00 2015 GMT
notAfter=Oct  5 22:00:00 2018 GMT

Itu kira-kira 5 jam di zona waktu saya (Bogota/Amerika) Yah, tapi tertulis GMT (UTC). Bogota adalah UTC-5

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

Pembaruan: PERBAIKI

Seperti yang dinyatakan di sini: https://github.com/docker/docker/issues/11534#issuecomment -89405874

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

menghasilkan saya kesalahan yang berbeda (satu langkah pada satu waktu :)

Saya pikir ini dia, sisanya adalah kotak virtual saya.

Saya akan makan malam dan memeriksa kembali dalam 5 jam ketika saya curiga sertifikat saya akan valid dan semuanya akan berfungsi. :tersenyum:

Berita buruk, saya harus melakukan ini pada setiap restart vm.

:smile: Saya kira Anda mencapai akar masalahnya! Terima kasih!

: tepuk:: tepuk:: tepuk:: tepuk:: tepuk:: tepuk:: tepuk:

@carolynvs apakah perbaikan yang saya posting berhasil untuk Anda?

Saya hanya ingin mengonfirmasi bahwa setelah menunggu 5 jam hingga sertifikat valid, env mesin buruh pelabuhan berfungsi. Tidak tahu mengapa saya mendapatkan sertifikat yang tertanggal di masa mendatang tetapi mungkin harus memperbarui masalah untuk mencerminkan akar penyebab sebenarnya sekarang yang kita ketahui.

Dalam kasus saya, bukan sertifikat yang menjadi masalah, tetapi pengaturan waktu pada boot2docker ... Seperti yang saya lihat di profil github Anda, Anda berasal dari Chicago, itu adalah zona waktu yang mirip dengan Bogota, mungkin boot2docker mendapatkan pengaturan yang salah di zona waktu kami ...

Setelah menyinkronkan waktu menggunakan solusi Anda, saya masih menerima kesalahan yang sama (sertifikat telah kedaluwarsa atau belum valid) saat menggunakan sertifikat tersebut untuk terhubung ke Host buruh pelabuhan saya.

Di mac saya, inilah yang saya lihat setelah membuat kotak baru dan memeriksa waktunya.

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

docker<strong i="8">@bugtest</strong>:~$ hwclock
Thu Oct 22 15:54:29 2015  0.000000 seconds

docker<strong i="9">@bugtest</strong>:~$ date
Thu Oct 22 15:54:06 UTC 2015

docker<strong i="10">@bugtest</strong>:~$ openssl x509 -in /var/lib/boot2docker/server.pem -noout -dates
notBefore=Oct 22 15:48:00 2015 GMT
notAfter=Oct  6 15:48:00 2018 GMT

Berikut adalah perintah yang sama pada host baru di windows:

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

docker<strong i="15">@bugtest</strong>:~$ hwclock
Thu Oct 22 15:58:56 2015  0.000000 seconds

docker<strong i="16">@bugtest</strong>:~$ date
Thu Oct 22 10:58:58 UTC 2015

docker<strong i="17">@bugtest</strong>:~$ openssl x509 -in /var/lib/boot2docker/server.pem -noout -dates
notBefore=Oct 22 15:45:00 2015 GMT
notAfter=Oct  6 15:45:00 2018 GMT

Tanggal menunjukkan waktu lokal saya tetapi berpikir bahwa itu adalah UTC dan saya tidak tahu bagaimana memperbaruinya agar sesuai dengan jam. Saya sudah mencoba mengubah tanggal secara manual tetapi ada sesuatu tentang busybox atau virtualbox yang segera membatalkan perubahan apa pun.

Ini adalah status kerja pada kemarin setelah menerapkan solusi:

docker<strong i="6">@oca</strong>:~$ time
BusyBox v1.23.1 (2015-02-22 15:53:49 UTC) multi-call binary.
docker<strong i="7">@oca</strong>:~$ hwclock
Thu Oct 22 10:10:46 2015  0.000000 seconds
docker<strong i="8">@oca</strong>:~$ date
Thu Oct 22 16:28:19 UTC 2015
docker<strong i="9">@oca</strong>:~$
docker<strong i="10">@oca</strong>:~$ openssl x509 -in /var/lib/boot2docker/server.pem -noout -dates
notBefore=Oct 21 22:32:00 2015 GMT
notAfter=Oct  5 22:32:00 2018 GMT

di sini, date sesuai dengan waktu lokal saya yang dinyatakan dalam UTC

beberapa petunjuk untuk gejala saya: https://forums.virtualbox.org/viewtopic.php?f=3&t=60558#p281836

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

karena date menunjukkan tanggal yang benar dalam kasus saya, saya menganggap tanggal penyelesaian solusi dalam kasus saya dan karena itu masalahnya.

cc @tianon @SvenDowideit PTAL di RE di atas: masalah waktu/tanggal boot2docker ^^

Beberapa kode yang saya temukan mungkin berkontribusi pada masalah stempel waktu:

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

Tapi itu selalu bekerja dengan baik sebelumnya.

@carolynvs @blaggacao Apakah Anda masih mengalami masalah ini?

Bagi saya ini berfungsi setelah referensi work-around. Ini, pada gilirannya, menunjukkan, bahwa beberapa parameter waktu boot2docker tidak disetel dengan benar. Biasanya itu akan terjadi hanya selama jangka waktu terbatas tepat setelah pembuatan mesin. (Mungkin hanya di beberapa zona waktu).

Sekali lagi, ini berarti, bahwa cap waktu sertifikat akan benar.

Saya tersandung lagi sekarang setelah me-restart pc di rc saya, tetapi setelah memperbarui ke 5.0 semuanya tampak berfungsi. Kita mungkin bisa menutup ini untuk saat ini. Bagaimanapun, Segera setelah saya melihat perilaku aneh saya akan membukanya kembali.

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

Saya punya masalah ini juga. Jangan tutup.

@damontic Sepertinya masalah yang berbeda dari yang sedang dibahas di sini.

Saya mencoba mengatur segerombolan di DigitalOcean dan saya memiliki kesalahan yang sama.

init-do.sh yang membuat toko KV, master swarm, dan node:

 # KV Store
docker-machine create \
--driver digitalocean \
--digitalocean-access-token ${TOKEN} \
--digitalocean-region "lon1" \
--digitalocean-size "1gb" \
consul
eval "$(docker-machine env consul)"
docker run -d -p "8500:8500" -h "consul" progrium/consul -server -bootstrap

sleep 5

# Swarm master
docker-machine create \
--driver digitalocean \
--digitalocean-access-token ${TOKEN} \
--digitalocean-region "lon1" \
--digitalocean-size "1gb" \
--swarm --swarm-image="swarm" --swarm-master \
--swarm-discovery="consul://$(docker-machine ip consul):8500" \
--engine-opt="cluster-store=consul://$(docker-machine ip consul):8500" \
--engine-opt="cluster-advertise=eth1:2376" \
demo0

sleep 5

# Swarm node
docker-machine create \
--driver digitalocean \
--digitalocean-access-token ${TOKEN} \
--digitalocean-region "lon1" \
--digitalocean-size "1gb" \
--swarm --swarm-image="swarm:1.0.0-rc2" \
--swarm-discovery="consul://$(docker-machine ip consul):8500" \
--engine-opt="cluster-store=consul://$(docker-machine ip consul):8500" \
--engine-opt="cluster-advertise=eth1:2376" \
demo1

Log / kesalahan yang saya dapatkan

$> ./init-do.sh
Running pre-create checks...
Creating machine...
(consul) OUT | Creating SSH key...
(consul) OUT | Creating Digital Ocean droplet...
(consul) OUT | Waiting for IP address to be assigned to the Droplet... 
Waiting for machine to be running, this may take a few minutes... 
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Detecting the provisioner...
Provisioning created instance...
Copying certs to the local machine directory... 
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
To see how to connect Docker to this machine, run: docker-machine env consul
Unable to find image 'progrium/consul:latest' locally
latest: Pulling from progrium/consul
3b4d28ce80e4: Pull complete
...
d9125e9e799b: Pull complete
Digest: sha256:8cc8023462905929df9a79ff67ee435a36848ce7a10f18d6d0faba9306b97274
Status: Downloaded newer image for progrium/consul:latest
ab964fd70394d34f8d1de5c76246490b5857adaffbc1c02235bdc53663c33b37
Running pre-create checks...
Creating machine...
(demo0) OUT | Creating SSH key...
(demo0) OUT | Creating Digital Ocean droplet...
(demo0) OUT | Waiting for IP address to be assigned to the Droplet...
Waiting for machine to be running, this may take a few minutes... 
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Detecting the provisioner...
Provisioning created instance...
Copying certs to the local machine directory... 
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Error creating machine: Error running provisioning: Unable to verify the Docker daemon is listening:        Maximum number of retries (5) exceeded
Running pre-create checks...
Creating machine...
(demo1) OUT | Creating SSH key...
(demo1) OUT | Creating Digital Ocean droplet...
(demo1) OUT | Waiting for IP address to be assigned to the Droplet...  
Waiting for machine to be running, this may take a few minutes...
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Detecting the provisioner...
Provisioning created instance...
Error creating machine: Error running provisioning: Something went wrong running an SSH command!
command : sudo apt-get update
err     : exit status 100
output  : Ign http://mirrors.digitalocean.com trusty InRelease
Get:1 http://mirrors.digitalocean.com trusty-updates InRelease [64.4 kB]
Hit http://mirrors.digitalocean.com trusty Release.gpg
Hit http://mirrors.digitalocean.com trusty Release
Get:2 http://mirrors.digitalocean.com trusty-updates/main Sources [244 kB]
Get:3 http://mirrors.digitalocean.com trusty-updates/universe Sources [144 kB]
Get:4 http://mirrors.digitalocean.com trusty-updates/main amd64 Packages [652 kB]
Get:5 http://mirrors.digitalocean.com trusty-updates/universe amd64 Packages [331 kB] 
Get:6 http://mirrors.digitalocean.com trusty-updates/main i386 Packages [631 kB]
Get:7 http://mirrors.digitalocean.com trusty-updates/universe i386 Packages [332 kB]
Get:8 http://mirrors.digitalocean.com trusty-updates/main Translation-en [319 kB]
Get:9 http://security.ubuntu.com trusty-security InRelease [64.4 kB]
Get:10 http://mirrors.digitalocean.com trusty-updates/universe Translation-en [173 kB]
Hit http://mirrors.digitalocean.com trusty/main Sources
Hit http://mirrors.digitalocean.com trusty/universe Sources
Hit http://mirrors.digitalocean.com trusty/main amd64 Packages
Hit http://mirrors.digitalocean.com trusty/universe amd64 Packages
Hit http://mirrors.digitalocean.com trusty/main i386 Packages
Hit http://mirrors.digitalocean.com trusty/universe i386 Packages
Hit http://mirrors.digitalocean.com trusty/main Translation-en
Hit http://mirrors.digitalocean.com trusty/universe Translation-en
Ign http://mirrors.digitalocean.com trusty/main Translation-en_US
Ign http://mirrors.digitalocean.com trusty/universe Translation-en_US
Get:11 http://security.ubuntu.com trusty-security/main Sources [99.2 kB]
Get:12 http://security.ubuntu.com trusty-security/universe Sources [32.5 kB]
Get:13 http://security.ubuntu.com trusty-security/main amd64 Packages [370 kB]
Get:14 http://security.ubuntu.com trusty-security/universe amd64 Packages [122 kB]
Get:15 http://security.ubuntu.com trusty-security/main i386 Packages [350 kB]
Get:16 http://security.ubuntu.com trusty-security/universe i386 Packages [123 kB]   
Get:17 http://security.ubuntu.com trusty-security/main Translation-en [200 kB]
Get:18 http://security.ubuntu.com trusty-security/universe Translation-en [69.6 kB]
Fetched 4,323 kB in 4s (925 kB/s) 
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/trusty-security/universe/i18n/Translation-en    Hash Sum mismatch

E: Some index files failed to download. They have been ignored, or old ones used instead.

Sebelum menjalankan ini, saya memperbarui ke Mesin 0.5.1

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

Saya dapat pindah ke konteks "konsul" mesin tetapi tidak ke "demo0" atau "demo1"

$ docker-machine env consul
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://178.62.93.196:2376"
export DOCKER_CERT_PATH="/Users/luc/.docker/machine/machines/consul"
export DOCKER_MACHINE_NAME="consul"
# Run this command to configure your shell:
# eval "$(/usr/local/bin/docker-machine env consul)"

$ docker-machine env    demo0
Error running connection boilerplate: Error checking and/or regenerating the certs: There was an error   validating certificates for host "46.101.74.179:2376": dial tcp 46.101.74.179:2376: getsockopt: connection  refused
You can attempt to regenerate them using 'docker-machine regenerate-certs name'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

$ docker-machine env demo1
Error running connection boilerplate: Error checking and/or regenerating the certs: There was an error  validating certificates for host "46.101.17.195:2376": open   /Users/luc/.docker/machine/machines/demo1/server.pem: no such file or directory
You can attempt to regenerate them using 'docker-machine regenerate-certs name'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

@lucj Jika penyediaan gagal, instance yang dibuat akan "tidak valid". Coba hapus dan mulai lagi dari awal.

@nathanleclaire Saya baru saja menghapus mesin (apakah 'docker-machine rm consul demo0 demo1' cukup atau haruskah saya menghapus beberapa hal lain secara manual?) dan jalankan kembali dengan file pengaturan dan saya mendapatkan masalah sertifikat yang sama (saat membuat di DigitalOcean). Anehnya tidak ada masalah dengan mesin 'konsul', tetapi hanya dengan yang swarm (demo0, demo1).

Saat membuat swarm di VirtualBox (5.0.10) itu berfungsi dengan baik.

saya melihat ini saat menggunakan driver aws

Saya telah melakukan beberapa tes (sebenarnya banyak), setelah menghapus VM dan membuatnya kembali (dengan segerombolan) saya masih memiliki masalah yang sama.

Saya sekarang memiliki masalah ini setelah memutakhirkan dari versi 1.8 ke 1.9.1 menggunakan kotak alat buruh pelabuhan di MacOSX 10.10.5

Error running connection boilerplate: Error checking and/or regenerating the certs: There was an error validating certificates for host "192.168.99.100:2376": dial tcp 192.168.99.100:2376: getsockopt: connection refused
You can attempt to regenerate them using 'docker-machine regenerate-certs name'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

command failed; 1

Ini terjadi pada saya secara berkala juga. Docker v1.9.1

Masalah yang sama di sini dengan driver Azure. Setiap kali kami membuat mesin Azure baru, ia gagal dengan kesalahan:

Error creating machine: Error checking the host: Error checking and/or regenerating the certs: There was an error validating certificates for host "testcargo2-prefapp-in.cloudapp.net:2376": tls: DialWithDialer timed out
You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'

Setelah menjalankan docker-machine regenerate-certs validasi sertifikat berfungsi dengan baik.

Di docker-machine v0.5.5 tidak ada masalah, dan pembuatan host docker berfungsi dengan baik:

Running pre-create checks...
Creating machine...
(testcargo3-prefapp-in) Creating Azure machine...
Waiting for machine to be running, this may take a few minutes...
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Detecting the provisioner...
Provisioning with ubuntu(upstart)...
Installing Docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect Docker to this machine, run: docker-machine env 

@alambike Anda mengalami masalah ini dengan 0.6.0?

Ya, dari 0.5.5 dan seterusnya. Saya telah menguji ini dengan 0.5.6 dan 0.6.0.

sama untuk saya di 0.6.0 dengan driver aws (terus-menerus) di mac 10.10.5. Tidak terjadi dengan driver kotak virtual.

diperbaiki setelah mengubah --engine-opt="cluster-advertise=eth1:2376" menjadi --engine-opt="cluster-advertise=eth0:2376" menggunakan docker-machine 0.6.0 (docker-machine 0.5.4 masih gagal)

Saya pikir saya sedang berjuang melawan masalah yang sama di mesin saya. Saya menggunakan ubuntu 14.04
versi mesin buruh pelabuhan 0.5.5, build 02c4254
Menjalankan host di RHEL 7.1
Versi Server: 1.10.2-cs1-rc3

Mencoba semua yang disarankan dengan waktu di mesin, ini adalah output yang saya dapatkan dari curl

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

• Nama host TIDAK ditemukan di cache DNS
• Mencoba 16.85.3.140...
• Terhubung ke 16.85.3.140 (16.85.3.140) port 2376 (#0)
• berhasil mengatur lokasi verifikasi sertifikat:
• CAfile: /home/eraigosa/.docker/machine/certs/ca.pem
  CApath: /etc/ssl/certs
• SSLv3, jabat tangan TLS, Klien halo (1):
• SSLv3, jabat tangan TLS, Server halo (2):
• SSLv3, jabat tangan TLS, CERT (11):
• SSLv3, jabat tangan TLS, Pertukaran kunci server (12):
• SSLv3, jabat tangan TLS, Minta CERT (13):
• SSLv3, jabat tangan TLS, Server selesai (14):
• SSLv3, jabat tangan TLS, CERT (11):
• SSLv3, jabat tangan TLS, Pertukaran kunci klien (16):
• SSLv3, jabat tangan TLS, verifikasi CERT (15):
• SSLv3, TLS mengubah cipher, Klien halo (1):
• SSLv3, jabat tangan TLS, Selesai (20):
• SSLv3, peringatan TLS, Server halo (2):
• kesalahan:14094412 : rutinitas SSL
• Menutup koneksi 0
  curl: (35) kesalahan: 14094412 : rutinitas SSL

@nathanleclaire Saya telah menemukan pemujanya! prltoolsd dari boot2docker terus-menerus mengatur tanggal/zona waktu saya secara tidak benar.

$ date
<the current local time with the timezone set to UTC>

$ date -s '<the correct time in UTC>'
<prints the correct time>

$ date
<the date/time is now broken again>

$ /usr/local/etc/init.d/prltoolsd stop

$ date -s '<the correct time in UTC>'
<prints the correct time>

$ date
<prints the correct time and stays put>

Setelah menghentikan prltoolsd dan mengatur ulang tanggal, semua perintah mesin buruh pelabuhan saya berfungsi seperti yang diharapkan dan sertifikat saya tidak dibuat ulang.

Saya masih tidak tahu mengapa zona waktu diatur ke UTC dan waktu ke waktu lokal setelah membuat mesin baru, jadi ini hanya solusi, bukan perbaikan.

Bagus @carolynvs ! Kami akan bekerja untuk melihat apakah kami dapat memperbaikinya di boot2docker.

@tianon @legal90 FYI ^^

@carolynvs Wow :takut: . Kelihatannya sangat aneh, karena proses prltoolsd tidak boleh dimulai pada sistem virtualisasi lain kecuali Parallels Desktop. Daemon akan mulai hanya jika /usr/bin/prlvmcheck mengembalikan 0 kode keluar, yang berarti kita berada di Parallels VM.

Sudahkah Anda mereproduksi masalah ini di Virtualbox VM? Versi Boot2Docker apa yang Anda gunakan?

Ps Juga, jika kita berasumsi bahwa prltoolsd adalah satu-satunya alasan, maka versi Docker Machine seharusnya tidak masuk akal. Namun, komentar lain di atas ( tautan ) memberi tahu bahwa masalah hanya muncul di Mesin 0.5.5+

@legal90 Itu lebih masuk akal. Lingkungan saya agak miring, tetapi dulu berfungsi dengan baik:

1. Saya menggunakan Mac yang menjalankan Parallels.
2. Di dalam Parallels saya menjalankan Windows, lalu instalasi kotak alat buruh pelabuhan terbaru. Saya melakukan ini karena saya menulis dokumentasi dan tutorial untuk Docker, dan perlu menargetkan pengguna Mac, Linux, dan Windows.

Ini menjelaskan mengapa prltoolsd mencoba mengelola jam host buruh pelabuhan saya. Itu harus menangkap bersarang di dalam Parallels. Apakah itu juga menjelaskan mengapa jam sistem diatur ke waktu lokal tetapi menganggapnya UTC?

Itulah akar masalah yang menyebabkan saya membuka bug ini. Saya membuat mesin buruh pelabuhan baru pada pukul 10 pagi CST (-6). Jam sistem ( date ) pada mesin baru berpikir bahwa ini adalah pukul 10 pagi UTC, jadi stempel waktu pada sertifikat adalah "di masa depan". hwclock melaporkan waktu yang benar.

Melihat Dockerfile boot2docker, saya perhatikan bahwa itu mengatur /etc/timezone ke UTC dan _should_ telah menyetel /etc/localtime ke UTC juga.

lihat https://github.com/boot2docker/boot2docker/blob/master/Dockerfile#L311

RUN echo 'UTC' > $ROOTFS/etc/timezone \
    && cp -L /usr/share/zoneinfo/UTC $ROOTFS/etc/localtime

Tetapi pada Host mesin buruh pelabuhan saya, paket tzdata tidak diinstal, jadi /usr/share/zoneinfo tidak ada dan juga /etc/localtime . Saya telah membuat boot2docker saya sendiri dari Dockerfile terbaru hanya untuk memverifikasi bahwa saya tidak menggunakan iso lama. Saya ingin tahu apakah kehilangan file /etc/localtime berkontribusi pada masalah waktu yang salah?

@carolynvs Ah, sekarang saya mengerti.

Ini menjelaskan mengapa prltoolsd mencoba mengelola jam host buruh pelabuhan saya. Itu harus menangkap bersarang di dalam Parallels.

Ya, itulah akar masalahnya. prltoolsd berjalan di Virtualbox VM yang disarangkan ke dalam Parallels VM. Saya telah mereproduksi ini dan melaporkan kepada orang yang bertanggung jawab di Parallels. Saya akan memberi tahu Anda segera setelah diperbaiki.

Apakah itu juga menjelaskan mengapa jam sistem diatur ke waktu lokal tetapi menganggapnya UTC?

Yah, sulit untuk berkomitmen tetapi ini adalah masalah yang diketahui dari Parallels Desktop (dan alat tamunya). Awalnya dilaporkan di sini: https://github.com/Parallels/vagrant-parallels/issues/186 .
Itu berhasil di PD 11 dengan opsi tambahan untuk utilitas prlctl , tetapi itu tidak membantu dalam kasus langka Anda, karena Anda sebenarnya menjalankan Virtualbox VM di Windows.

Maaf, tetapi satu-satunya solusi yang dapat saya sarankan kepada Anda saat ini adalah mencegah prltoolsd berjalan di VM Anda saat boot. Jika Anda menggunakan build ISO Boot2Docker kustom, Anda dapat menghapus baris terkait paralel dari Dockerfile dan membangun kembali ISO. Atau komentari baris ini: https://github.com/boot2docker/boot2docker/blob/master/rootfs/rootfs/bootscript.sh#L101

Terima kasih atas info tambahan tentang cara kerja prltoolsd! Saya akan melakukan seperti yang Anda sarankan dan membuat iso khusus untuk pengaturan saya. :Bir:

Saya akan menutup masalah ini, karena ini memperbaiki masalah saya, tetapi saya akan menyerahkannya kepada Anda karena orang lain tampaknya memukulnya (meskipun mungkin karena alasan yang berbeda!).

Saya pikir kita dapat memperlakukannya sebagai solusi yang efektif; kami dapat membuka kembali jika ada masalah baru yang ditemukan.

Terima kasih semuanya atas kontribusi Anda dalam melaporkan dan menyelesaikan masalah yang sangat panjang ini!

Saya menggunakan DockerToolbox 1.10.3 di Windows. Itu berfungsi dengan baik sampai saya memulai kembali, dan sekarang saya mengalami masalah yang sama. Saya juga tidak begitu akrab dengan Docker, jadi bisakah seseorang memberi tahu saya apa perbaikannya?

@mtrtm Apakah docker-machine regenerate-certs -f tidak berfungsi?

Ya, docker-machine regenerate-certs -f bisa. Tampaknya juga melakukannya setiap kali saya memulai Terminal Docker Quickstart

+1
Saya menggunakan buruh pelabuhan terutama di server Redhat dan semuanya berfungsi dengan baik. Saya bukan ahli tapi saya tahu apa yang saya lakukan. Namun, pada Windows dengan virtualbox, setiap kali VM buruh pelabuhan dimulai ulang, saya perlu membuat ulang sertifikat. Saya menggunakan kotak alat 1.11.1

+1

Macbook akhir 2009
2,26 GHz Intel Core 2 Duo
Mac OS Sierra 10.12
Kotak Tol Docker 1.2.1
VirtualBox 5.0.26

$ mesin buruh pelabuhan ls
NAMA AKTIF DRIVER NEGARA URL KESALAHAN SWARM DOCKER
vbox-test - virtualbox Menjalankan tcp://192.168.99.100 :2376 Tidak diketahui Tidak dapat menanyakan versi buruh pelabuhan: Dapatkan https://192.168.99.100 :2376/v1.15/versi: x509: sertifikat telah kedaluwarsa atau belum valid

$ docker-mesin env vbox-test
Kesalahan saat memeriksa koneksi TLS: Kesalahan saat memeriksa dan/atau membuat ulang sertifikat: Ada kesalahan saat memvalidasi sertifikat untuk host "192.168.99.100:2376": x509: sertifikat telah kedaluwarsa atau belum valid
Anda dapat mencoba membuatnya kembali menggunakan 'docker-machine regenerate-certs [name]'.
Harap diperhatikan bahwa ini akan memicu restart daemon Docker yang akan berhenti menjalankan container.

$ docker-machine regenerate-certs vbox-test
Buat ulang sertifikat mesin TLS? Peringatan: ini tidak dapat diubah. (y/t): y
Membuat ulang sertifikat TLS
Menunggu SSH tersedia...
Mendeteksi penyedia...
Menyalin sertifikat ke direktori mesin lokal...
Menyalin sertifikat ke mesin jarak jauh...
Mengatur konfigurasi Docker pada daemon jarak jauh...

$ docker-mesin env vbox-test
Kesalahan saat memeriksa koneksi TLS: Kesalahan saat memeriksa dan/atau membuat ulang sertifikat: Ada kesalahan saat memvalidasi sertifikat untuk host "192.168.99.100:2376": x509: sertifikat telah kedaluwarsa atau belum valid
Anda dapat mencoba membuatnya kembali menggunakan 'docker-machine regenerate-certs [name]'.
Harap diperhatikan bahwa ini akan memicu restart daemon Docker yang akan berhenti menjalankan container.

Saya memiliki ini pada instalasi default Docker Tookit (diinstal pada Windows 10 Home) yang diunduh pada 30-10-2016. Kesalahan hilang setelah dijalankan:

docker-machine regenerate-certs

Mengalami masalah ini di macOS. docker-machine env mengeluh:

$ docker-machine env docker1
Error checking TLS connection: Error checking and/or regenerating the certs: There was an error validating certificates for host "192.168.99.100:2376": x509: certificate has expired or is not yet valid
You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'.
Be advised that this will trigger a Docker daemon restart which might stop running containers.

Membuat ulang sertifikat (bahkan dengan -f ) tidak membantu. docker-machine ssh docker1 date menunjukkan tanggal dan waktu yang benar.

Ada ide?

@paddor Membuat ulang sertifikat termasuk. sertifikat klien ( docker-machine regenerate-certs -f --client-certs ) memperbaikinya untuk saya.