Bisakah Anda memberikan lebih banyak detail tentang masalah ini?

• Versi Mesin apa?
• Driver apa (saya berasumsi vbox berdasarkan IP)?
• Baris perintah digunakan untuk membuat mesin

Terima kasih

buruh pelabuhan versi 0.1.0
virtualbox
docker-machine buat -d virtualbox --virtualbox-disk-size '40000' --virtualbox-memory '4096' devbox

Saya juga menambahkan --insecure-registry ke daemon sehingga saya dapat berbicara dengan private registry kami (jika itu penting).

Maukah Anda menguji dari master (Anda dapat menggunakan https://docker-machine-builds.evanhazlett.com/latest/ jika Anda tidak ingin membangun secara lokal). Saya telah menguji ini dengan VM mengubah IP dan semuanya berfungsi seperti yang diharapkan:

ehazlett machine> docker-machine ls
NAME        ACTIVE   DRIVER       STATE     URL
test-vbox   *        virtualbox   Running   tcp://192.168.99.100:2376
ehazlett machine> docker-machine stop test-vbox
ehazlett machine> docker-machine create -d virtualbox test-vbox-2
...
ehazlett machine> docker-machine ls
NAME          ACTIVE   DRIVER       STATE     URL
test-vbox              virtualbox   Stopped   
test-vbox-2   *        virtualbox   Running   tcp://192.168.99.100:2376
ehazlett machine> docker-machine start test-vbox
...      
ehazlett machine> docker-machine ls
NAME          ACTIVE   DRIVER       STATE     URL
test-vbox              virtualbox   Running   tcp://192.168.99.101:2376
test-vbox-2   *        virtualbox   Running   tcp://192.168.99.100:2376            
ehazlett machine> docker $(docker-machine config test-vbox) ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

Anda dapat melihat bahwa test-vbox IP yang dialihkan.

Oke, inilah yang saya lakukan:

Hentikan mesin saat ini
Mulai gunakan nampan mesin baru
"mesin ls" dengan mesin baru baik-baik saja dan menunjukkan:
"devbox * virtualbox Menjalankan tcp: //192.168.99.100 : 2376
devbox2 virtualbox Berhenti "

"info buruh pelabuhan" menghasilkan:
FATA [0000] Terjadi kesalahan saat mencoba menyambungkan: Dapatkan https://192.168.99.100 : 2376 / v1.16 / info: x509: sertifikat valid untuk 192.168.99.103, bukan 192.168.99.100

Terima kasih. apakah Anda mencoba dengan master build di atas? Saya menjalankan prosedur yang sama dengan yang Anda lakukan dan saya tidak memiliki masalah sertifikat.

Saya mendownload biner "terbaru" itu.

Hmm baiklah. @sthulb dapatkah Anda mencoba untuk melihat apakah Anda dapat mereproduksi ini?

• Buat mesin virtualbox
• Hentikan mesin pertama
• Buat mesin virtualbox kedua
• Mulai mesin pertama
• Periksa apakah IP mesin pertama berubah
• Periksa apakah Anda dapat mengakses daemon buruh pelabuhan di keduanya

@ Stephenlawrence apakah proses itu benar?

Terima kasih

@ehazlett Secara teknis ini bukanlah bagaimana hal itu dimulai. Ini dimulai ketika saya me-reboot Mac saya dan DM muncul dengan IP yang berbeda saat reboot. Saya tidak tahu apakah itu berbeda dari sekadar melakukan apa yang Anda gambarkan. Tapi sekarang, setiap upaya untuk mengakses mesin yang sebelumnya berfungsi menghasilkan pesan x509.

@stephenlawrence saya tidak dapat membuatnya kembali karena IP saya selalu berubah dan VM tetap ada. Saya hanya meniru VM yang mendapatkan IP berbeda yang seharusnya membuat hal yang sama seperti yang saya yakini. Maukah Anda mencoba hal di atas dengan biner baru dan satu set VM baru? Saya bertanya-tanya apakah sertifikat dibuat menggunakan build lama tidak menggunakan proses yang benar atau semacamnya.

@stephenlawrence Anda yakin tidak ada sesuatu di bashrc yang mengacaukan pengaturan Anda, seperti DOCKER_CERT_PATH?

Karena saya tidak melihat orang lain mereferensikan kode yang relevan, saya hanya akan menunjukkan bahwa machine sedang membuat sertifikat dengan alamat IP di sini: https://github.com/docker/machine/ blob / 973b267fec3ec0a900e26557475b387891c0138a / host.go # L123

Jika alamat IP berubah, sertifikat itu tidak akan berfungsi lagi.

Dalam skrip init b2d, ada kode yang membuat kembali sertifikat server jika alamat IP yang relevan berubah: https://github.com/boot2docker/boot2docker/blob/5db7efbb4e0557f6efefdb56cb0263f80ed55834/rootfs/rootfs/usr/local/etc/rootfs/usr/local/etc / buruh pelabuhan # L46

Saya tidak sepenuhnya yakin mengapa sedikit kode b2d itu tidak dipicu dalam kasus machine karena saya pikir kalian menggunakan ISO b2d.

Ya terima kasih, saya tahu kode ini ada di sana, ketika IP berubah (seperti
ditunjukkan di atas) tidak ada masalah saat menguji jadi saya mencoba setidaknya
dapatkan produk ini untuk diuji.

Pada hari Sabtu, 14 Feb 2015 pukul 12:58, Mike Dillon [email protected]
menulis:

Karena saya tidak melihat orang lain merujuk kode yang relevan, saya akan melakukannya
tunjukkan bahwa mesin membuat sertifikat dengan alamat IP di
itu disini:
https://github.com/docker/machine/blob/973b267fec3ec0a900e26557475b387891c0138a/host.go#L123

Jika alamat IP berubah, sertifikat itu tidak akan berfungsi lagi.

Dalam skrip init b2d, ada kode yang meregenerasi server
sertifikat jika alamat IP yang relevan berubah:
https://github.com/boot2docker/boot2docker/blob/5db7efbb4e0557f6efefdb56cb0263f80ed55834/rootfs/rootfs/usr/local/etc/init.d/docker#L46

Saya tidak sepenuhnya yakin mengapa sedikit kode b2d itu tidak terpicu di
kasus mesin karena saya pikir kalian menggunakan b2d ISO.

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/machine/issues/531#issuecomment -74363452.

@ md5 @stephenlawrence Maukah Anda memeriksa untuk melihat apakah Anda memiliki sesuatu yang akan menggunakan sertifikat b2d secara kebetulan? setelah debugging, sepertinya b2d certs sedang digunakan dengan mesin.

@ehazlett Saya tidak yakin apa yang Anda minta untuk saya periksa.

@ md5 maaf saya seharusnya lebih jelas. periksa variabel lingkungan DOCKER_CERT_PATH dan DOCKER_HOST untuk melihat apakah mereka diarahkan ke mesin yang benar. Sepertinya DOCKER_CERT_PATH dapat dikonfigurasi ke sertifikat b2d saat mengakses mesin atau sebaliknya.

@ehazlett jika ini adalah kasus kesalahan DOCKER_CERT_PATH , kesalahannya akan berbeda. Masalah dalam situasi itu bisa jadi bahwa ca.pem bukan root kepercayaan untuk sertifikat yang disajikan oleh server Docker pada instance machine -controlled atau sertifikat klien cert.pem tidak diterima oleh server.

Kesalahan yang kita lihat di sini jelas bahwa klien (yaitu docker exec ) tidak menerima sertifikat server. Ini mencoba untuk memukul server pada 192.168.99.100 , tetapi server menyajikan sertifikat yang hanya berlaku untuk 192.168.99.103 . Ini hanya dapat berarti bahwa server yang merespons 192.168.99.100 pada port 2376 dikonfigurasi untuk menggunakan sertifikat yang dibuat untuk 192.168.99.103 .

@ md5 itu masuk akal. bagaimana cara membuat ulang? seperti yang Anda lihat di atas, saya telah mengubah IP instance virtualbox saya dan tidak melihat masalah ini.

Itu pertanyaan yang bagus. Saya juga belum bisa mereproduksinya sendiri.

Menutup karena sepertinya kami tidak dapat mereproduksi. Kecurigaan saya adalah bahwa variabel lingkungan bercampur untuk VM boot2docker dan instance mesin. Saya akan merekomendasikan untuk memeriksa .bashrc dll Anda untuk apa pun yang mungkin mengaturnya.

Saya mengalami masalah ini lagi. Saya memiliki mesin buruh pelabuhan yang berjalan pada 192.168.99.101, dan setelah boot ulang Mac saya, mesin tersebut sekarang berjalan pada 192.168.99.100.

Sepertinya ini adalah masalah buruh pelabuhan karena saya dapat melakukan "pembuatan galangan-galangan" ke dalam wadah OK, tetapi mencoba perintah buruh pelabuhan apa pun akan memunculkan kesalahan ini:

$ buruh pelabuhan ps
FATA [0000] Terjadi kesalahan saat mencoba menyambungkan: Dapatkan https://192.168.99.100 : 2376 / v1.17 / containers / json: x509: sertifikat valid untuk 192.168.99.101, bukan 192.168.99.100

Env saat ini:
DOCKER_CERT_PATH = / Pengguna / nama pengguna saya / .docker / mesin / .client
DOCKER_TLS_VERIFY = ya
DOCKER_HOST = tcp: //192.168.99.100 : 2376

$ ls -l ~ / .docker / mesin / .client /
total 48
-rw-r - r-- 1 staf nama pengguna saya 1054 11 Feb 10:21 ca.pem
-rw-r - r-- 1 staf nama pengguna saya 1054 30 Jan 08:53 ca.pem.bak
-rw-r - r-- 1 staf nama pengguna saya 1094 11 Feb 10:21 cert.pem
-rw-r - r-- 1 staf nama pengguna saya 1094 30 Jan 08:53 cert.pem.bak
-rw ------- 1 staf nama pengguna saya 1675 11 Feb 10:21 key.pem
-rw ------- 1 staf nama pengguna saya 1679 30 Jan 08:53 key.pem.bak

@hhhhh . apakah Anda juga akan menggunakan b2d secara kebetulan? satu-satunya saat saya melihat ini adalah sesuatu antara b2d dan mesin. secara pribadi saya tidak dapat mereproduksi tetapi itu ada hubungannya dengan certs dan env vars.

mungkin kita membutuhkan perintah "regenerate-certs" lebih cepat daripada nanti :)

Nah, saya telah menggunakan b2d sendiri sebelum saya beralih ke DM. DM menggunakan b2d juga bukan?

@stephenlawrence cukup menggunakan machine untuk mengelola b2d . hapus instalasi dan VM asli b2d

Saya pernah mengalami hal ini pada saya juga. Saya menggunakan machine untuk membuat mesin virtual, bukan b2d secara langsung. Perintah untuk meregenerasi sertifikat terdengar membantu.

Menghapus b2d tidak selalu menyelesaikan masalah saya, tetapi saya telah menghapusnya.

Saya akan menambahkan bahwa ini membuat mesin buruh pelabuhan tidak dapat digunakan untuk saya saat ini. Saya baru saja membuat mesin baru dengan harapan dapat mengatasi masalah itu, tetapi saya memiliki masalah yang sama pada mesin baru.

@stephenlawrence dapatkah Anda mencoba PR saya di atas dan melihat apakah itu menyelesaikan masalah? itu harus seperti itu akan membuat sertifikat untuk instance.

702 memperbaiki ini untuk saya: smiley: Membuat ulang sertifikat setelah machine start berfungsi setelah saya mem-boot ulang Mac.

@ jeffdm thx untuk tanggapannya!

Saya pikir ini masih menjadi masalah. Dua kemungkinan solusi yang dapat saya pikirkan:

• Asumsikan bahwa alamat IP akan berubah. Apakah kita perlu memeriksa alamat IP di jabat tangan TLS? Tidak bisakah kita memvalidasi sertifikat spesifik yang dimiliki mesin?
• Tidak bergantung pada DHCP. Mungkin kita bisa memberikan IP statis VM?

Saya mengalami masalah yang sama ... klien Cisco VPN yang saya gunakan menyiapkan aturan ipfw yang cukup banyak memblokir kemampuan untuk pergi ke alamat 192.168.x yang terikat ke vboxnetN.

Jadi saya menyiapkan aturan pemetaan port di virtualbox sehingga 127.0.0.1:2376 menyentuh server buruh pelabuhan. Masalahnya adalah bahwa sertifikat server buruh pelabuhan untuk 192.168.99.101 bukan 127.0.0.1:

$ ekspor DOCKER_TLS_VERIFY = ""
gambar $ docker
FATA [0000] Dapatkan http://127.0.0.1 : 2376 / v1.17 / images / json: respons HTTP cacat "\ x15 \ x03 \ x01 \ x00 \ x02 \ x02". Apakah Anda mencoba menyambung ke daemon berkemampuan TLS tanpa TLS?
$ ekspor DOCKER_TLS_VERIFY = ya
gambar $ docker
FATA [0000] Terjadi kesalahan saat mencoba menyambungkan: Dapatkan https://127.0.0.1 : 2376 / v1.17 / images / json: x509: sertifikat valid untuk 192.168.99.101, bukan 127.0.0.1
$ docker --tlsverify = gambar salah
(ini bekerja)

Meskipun ini bukan penghenti acara karena saya dapat meletakkan "--tlsverify = false" di semua perintah yang saya jalankan, tetapi alat lain seperti ara tidak akan melakukannya. Juga untuk beberapa alasan DOCKER_OPTS tidak berhasil untuk saya.

Mungkin ada opsi saat membuat instance virtualbox agar sertifikat tersebut juga valid untuk alamat lain? Saya dapat melihat itu juga menjadi masalah jika server memiliki alamat IP internal dan eksternal yang sama-sama digunakan (misalnya di ec2, tetapi kemudian saya akan menggunakan nama DNS).

@cwilkes ada / ada masalah untuk mengizinkannya dikonfigurasi.

Sepertinya https://github.com/docker/machine/pull/702 dapat membantu saya, dan saya melihatnya didorong menjadi master hari ini https://github.com/docker/machine/compare/v0.1.0 .. .master. Semoga segera ada rilis 0.1.1 :)

Ok setelah membahas ini dengan @sthulb dan @nathanleclaire saya pikir kita harus melakukan pemeriksaan serupa dengan apa yang dilakukan b2d. Kita dapat memeriksa IP saat start mesin dan membandingkannya dengan IP SAN di cert. Jika tidak cocok, kita bisa beregenerasi. Pikiran @sthulb @nathanleclaire ?

Sepakat.

Ya, silakan @ehazlett

+1 mengalami masalah yang sama

Saya mengalami ini juga. Saya memutar mesin menggunakan driver AWS dan kemudian menetapkan IP Elastis ke kotak. Mencoba menghentikan dan memulai mesin melalui CLI, tetapi setiap kali saya menjalankan docker ps setelah mengaktifkan env, saya mendapatkan:

certificate is valid for 52.11.XXX.XXX, not 52.10.XXX.XXX

Saya memang mencoba mengubah IP secara manual di konfigurasi `~ / .docker / machine '. Itu tidak berhasil.

@duro @killerwolf @cwilkes @jeffdm @stephenlawrence @ md5

silakan checkout # 770. ini menambahkan regenerasi otomatis jika terjadi kesalahan sertifikat. perhatikan bahwa ini hanya bekerja dengan perintah config dan env jadi jika Anda memiliki masalah dengan buruh pelabuhan (yaitu docker ps dll) Anda harus menjalankan $(docker-machine env <name>) atau docker $(docker-machine config <name>) ps untuk memperbaikinya. PR itu juga menambahkan kemampuan untuk meregenerasi sertifikat secara manual dengan perintah regenerate-certs (saya menggunakan fungsionalitas dari # 702).

Semoga ini akan menyelesaikan kesalahan TLS sekali dan untuk selamanya :)

Saya mendeteksi perubahan IP AWS setelah reboot normal dari instance aws.
docker-machine ssh amazonec2-03 hanya bekerja setelah mengedit IPAddress secara manual di /.docker/machine/machines/amazonec2-03/confg.json

sertifikat daemon buruh pelabuhan tidak berfungsi, saya dapat memeriksa # 770 besok.

PTAL @nathanleclaire @sthulb

Memiliki masalah yang sama, akan segera memeriksa # 770 ...

Anda dapat menggunakan kepala saat ini :)

Atau Anda dapat menggunakan RC - mereka memiliki perbaikan.

memiliki masalah yang sama tetapi dengan tonggak sejarah terbaru versi 0.2.0 itu diselesaikan! Terima kasih!

@gschmutz terima kasih atas umpan baliknya!

Saya mengalami ini sejak saya meningkatkan ke 1.7.0.
Memulai ulang b2d akan menyebabkan kesalahan ini:

$ eval "$(boot2docker shellinit)"
Writing /Users/gravis/.boot2docker/certs/boot2docker-vm/ca.pem
Writing /Users/gravis/.boot2docker/certs/boot2docker-vm/cert.pem
Writing /Users/gravis/.boot2docker/certs/boot2docker-vm/key.pem
Your environment variables are already set correctly.
$ docker ps -a
An error occurred trying to connect: Get https://192.168.59.103:2376/v1.19/containers/json?all=1: x509: certificate is valid for 127.0.0.1, 10.0.2.15, not 192.168.59.103

Terima kasih

@gravis Kenapa Anda menggunakan boot2docker shellinit dengan mesin?

Maaf, saya memposting di repo yang salah :)
Saya pikir itu b2d, saya mengacaukan tab saya.

Bagi siapa pun yang menemukan ini, berikut adalah solusi yang mungkin: https://github.com/boot2docker/boot2docker/issues/824#issuecomment -113904164
DAN
https://github.com/boot2docker/boot2docker/pull/411

Sejauh ini, ini telah memperbaiki masalah saya. Saya dapat melihat bahwa file / var / lib / boot2docker / tls / hostnames tidak memiliki IP VM (yaitu tidak memiliki IP yang Anda lihat saat Anda mengetik: boot2docker ip), jadi ini memungkinkannya untuk ditambahkan (itu muncul di akhir daftar nama host setelah menambahkan penundaan yang mereka sarankan).

Saya menguji boot2docker beberapa waktu lalu, lupa untuk waktu yang lama dan hari ini saya mengunduh versi terbaru dari boot2docker dan menginstalnya. Setelah instalasi, saya mengalami masalah X.509 yang sama yang disebutkan di sini dan saya mengatasinya dengan

1) menghapus direktori .boot2docker (terletak di direktori home saya) beserta isinya dan
2) menghapus semua file mesin virtual boot2docker juga

Semoga ini membantu.

ps. Karena saya hanya menguji boot2docker, saya tidak peduli jika saya kehilangan sesuatu saat menghapus barang itu ...

Saya memperbaiki masalah dengan cara yang sama seperti pasitolonen memperbaikinya. Menghapus dir .boot2docker dan menjalankan boot2docker init. Ini memiliki efek samping menghapus gambar saya (yang saya tidak keberatan).

Ini terjadi pada saya setiap kali wifi berubah. Misalnya ketika saya menggunakannya dari rumah dan kemudian lagi di kantor.

Kesalahan: Terjadi kesalahan saat mencoba menyambung: Dapatkan https://192.168.59.104 : 2376 / v1.19 / versi: x509: sertifikat valid untuk 127.0.0.1, 10.0.2.15, bukan 192.168.59.104

$ versi buruh pelabuhan
Versi klien: 1.7.0
Versi API Klien: 1.19
Go versi (klien): go1.4.2
Git commit (klien): 0baf609
OS / Arch (klien): darwin / amd64

Tampaknya ini memecahkan masalah: https://github.com/boot2docker/boot2docker/issues/938#issuecomment -118211836

alias docker="docker --tlsverify=false"

Saya mengalami ini setelah saya mengalokasikan ulang RAM. sebagai rajaraodv menemukan alias docker="docker --tlsverify=false" diselesaikan

Menonaktifkan keamanan ( --tlsverify=false ) seharusnya tidak pernah menjadi solusi yang disarankan.

Solusi yang berhasil untuk saya adalah boot2docker ssh 'sudo /etc/init.d/docker restart' , yang akan menyebabkan Docker menghasilkan sertifikat x509 baru yang valid untuk boot2docker selain alamat IP lainnya. Silakan coba sebelum mematikan fitur keamanan.

Solusi @indygreg berhasil untuk saya. Terimakasih banyak.

@indygreg menyelamatkan saya juga. Terima kasih!

terima kasih itu berfungsi untuk saya juga :-)

Hai semuanya, jika Anda masih mengalami masalah sertifikat dengan boot2docker pastikan untuk mencoba boot2docker upgrade untuk memperbarui VM Anda ke yang terbaru (1.7.1 memperbaiki masalah ini), dan jika ada yang lain muncul laporkan masalah di github.com/boot2docker/boot2docker-cli. Repo ini untuk masalah Mesin Docker. Terima kasih!

@indygreg, terima kasih

@indygreg terima kasih, ini juga berfungsi untuk saya :-)

@indygreg Bekerja untuk saya juga! Terima kasih.

Bekerja untuk saya, terima kasih!

Terima kasih @indygreg! Saya menambahkan tautan di sini ke komentar sehingga karyawan Google dapat dengan mudah melihat apa yang dia rekomendasikan.

https://github.com/docker/machine/issues/531#issuecomment -120554419

Pukul masalah ini dengan Docker Toolbox 1.9.1 di Windows setelah reboot sehingga VM dialokasikan ke IP yang berbeda, dan ini adalah hit teratas di google.

Jadi bagi siapa pun yang mencapai ini, perbaikan saat ini bahkan lebih mudah. (di mana default adalah mesin buruh pelabuhan Anda)

docker-machine regenerate-certs default

Terima kasih @johnmccabe , bekerja untuk saya dengan Docker Toolbox 1.10.0 di OS X.

Ini sering terjadi pada saya karena berpindah wlan dan terkadang menggunakan VPN. Adakah cara agar ini bisa Otomatis? Atau dapatkah sertifikat tersebut berlaku untuk berbagai alamat ip?

@johnmccabe Catatan, Anda cukup memastikan VM Anda selalu dimulai dengan IP yang sama: http://stackoverflow.com/a/35367277/6309

Saya menggunakan OS X dan lelah menggunakan peretasan ini dan akhirnya rusak.

Gelandangan memiliki opsi untuk mengatur alamat ip dalam konfigurasi. Saya tidak mengerti mengapa parameter atau flag semacam ini belum ada di docker-machine (Hanya membandingkan dengan vagrant karena keduanya menggunakan virtualbox)

@onnimonni : ini sudah lama diselesaikan (hampir setahun). Mesin menyertakan perintah untuk membuat kembali sertifikat jika ip berubah.

Saya baru saja mengalami masalah ini untuk pertama kalinya dan memeriksa semua yang ada di utas ini dengan salah satu opsi berikut berhasil memperbaiki masalah: (pilih satu)

• docker-machine regenerate-certs default2
• docker-machine kill default2 lalu docker-machine create default2 ...
• docker-machine upgrade default2 (jika belum ditingkatkan)

Untuk merepro masalah ini di OSX:

1. Instal Docker Toolbox (v1.10)
2. Buat mesin default yang mendapatkan 192.168.99.100
3. Buat mesin default2 yang mendapatkan 192.168.99.101
4. Matikan keduanya (terkadang membutuhkan reboot juga)
5. docker-compose start default2 yang mendapatkan 192.168.99.100 (dan konflik sertifikat x509)

jadi itu turun ke beberapa mesin yang dimulai dengan urutan berbeda dapat menyebabkan IP berbeda yang merusak sertifikat yang memerlukan pencarian github untuk masalah ini untuk menemukan resolusi pembuatan sertifikat baru untuk memungkinkan Anda menggunakannya lagi ... apakah ada cara untuk MENCEGAH ini terjadi? apakah sangat tidak biasa bagi orang untuk beralih di antara beberapa mesin buruh pelabuhan?

$ alias docker = "docker --tlsverify = false" Bekerja untuk saya!

@ivancarrancho Mengapa tidak docker-machine regenerate-certs -f dan tetap mengaktifkan TLS?

@nathanleclaire ya, itu lebih baik daripada "--tlsveify" banyak terima kasih

@nathanleclaire karena membutuhkan ~ 4 menit ... Bayangkan Anda memiliki sekelompok 6+ node ... Saya harus menulis regenerator sertifikat paralel untuk tidak menghabiskan sepanjang hari dengan meregenerasi beberapa sertifikat .... Selain itu, restart semua kontainer buruh pelabuhan pada mesin target ...

Persyaratan untuk membuat ulang sertifikat setelah perubahan alamat IP sangat merepotkan di cloud aws ... IP Publik berubah sepanjang waktu. Satu-satunya solusi yang saya ketahui adalah membuat instance baru dari instance ec2, tetapi karena alasan tertentu itu tidak berfungsi https://github.com/docker/machine/pull/1453#issuecomment -215371216

Btw ada ide jika docker-machine create --amazonec2-use-private-address seharusnya membuat instance ec2 dari instance ec2 lain?

Ini adalah satu-satunya cara saya mengetahui bagaimana menghindari regenerasi sertifikat yang konstan ...

Btw ada ide jika docker-machine create --amazonec2-use-private-address seharusnya membuat instance ec2 dari instance ec2 lain?

Ya, kecuali jika ada cara lain yang Anda miliki untuk mengakses IP privat dari node pembuatan (mis. Proxy).

Kami sedang mempertimbangkan berbagai solusi, misalnya Elastic IP, untuk menyelesaikan masalah ini secara potensial.

ya, tapi seperti yang saya sebutkan, itu tergantung pada akses ssh bahkan dengan opsi ini
diaktifkan
Pada 2 Mei 2016 20:26, "Nathan LeClaire" [email protected] menulis:

Btw ada ide jika docker-machine create --amazonec2-use-private-address adalah
seharusnya membuat instance ec2 dari instance ec2 lain?

Ya, kecuali jika ada cara lain untuk mengakses IP pribadi dari
node pembuatan (mis. proxy).

Kami sedang mempertimbangkan berbagai solusi, misalnya Elastic IP, hingga berpotensi
selesaikan masalah ini.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/machine/issues/531#issuecomment -216319103

Mungkin grup keamanan tidak dikonfigurasi dengan benar? Saat ini, jika menggunakan --amazonec2-use-private-ip-address , diasumsikan bahwa pengguna ingin memastikan bahwa detail akses jaringan semacam ini telah dikonfigurasi dengan benar sebelumnya.

Saya tidak mengerti mengapa saya harus menjalankan pernyataan $ eval yang jelek itu setiap buruh pelabuhan harus dimulai melalui terminal.

Saya tidak mengerti mengapa masalah ini ada.

Docker tampaknya lebih dan lebih seperti produk rusak parah yang banyak orang tertinggal karena itu adalah barang yang "masuk".

Saya menggunakan versi terbaru docker dan docker-machine , dan saya masih memiliki masalah yang sama, saya membuat beberapa host buruh pelabuhan virtualbox oleh

    docker-machine create -d virtualbox xxxx \
        --engine-opt="cluster-store=${KVSTORE}" \
        --engine-opt="cluster-advertise=eth1:2376" \
        ${NAME}
...

dan hampir setiap kali saya mem-boot ulang VM, atau mem-boot ulang Mac saya, saya akan menghadapi kesalahan seperti certificate is valid for 192.168.99.100, not 192.168.99.101 .

Versi saya adalah:

$ docker --version
Docker version 1.12.0-rc4, build e4a0dbc, experimental
$ docker-machine -v
docker-machine version 0.8.0-rc2, build 4ca1b85
$ vboxmanage -v
5.1.0r108711

Apakah ada solusi untuk mencegah kesalahan tersebut terjadi? atau buat virtualbox host dengan IP tetap?

Solusi: docker-machine provision .

Memperbaiki masalah dengan docker-machine regenerate-certs xxx

$ docker-machine ls
NAME        ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER    ERRORS
xxx   -        virtualbox   Running   tcp://192.168.99.100:2376           Unknown   Unable to query docker version: Get https://192.168.99.100:2376/v1.15/version: x509: certificate is valid for 192.168.99.101, not 192.168.99.100
~$ docker-machine regenerate-certs xxx
Regenerate TLS machine certs?  Warning: this is irreversible. (y/n): y
Regenerating TLS certificates
Waiting for SSH to be available...
Detecting the provisioner...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
~$ docker-machine ls
NAME        ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER    ERRORS
xxx   *        virtualbox   Running   tcp://192.168.99.100:2376           v1.12.6

Mengikuti tautan @VonC, saya menemukan docker-machine-ipconfig https://github.com/fivestars/docker-machine-ipconfig

 $ cd ~ / .docker /
 $ git clone https://github.com/fivestars/docker-machine-ipconfig.git
 # Tambahkan ke ~ / .profile
 $ echo 'alias docker-machine-ipconfig = ~ / .docker / docker-machine-ipconfig / docker-machine-ipconfig' >> ~ / .profile 
 $ source ~ / .profile

Misalnya: Tetapkan nama mesin sebagai IP statis:

 $ docker-machine-ipconfig nama mesin statis
 # atau tentukan IP implisit
 $ docker-machine-ipconfig nama mesin statis 192.168.99.110

Ini menghilangkan kebutuhan docker-machine regenerate-certs -f machine-name pada setiap restart. Cara mudah untuk menyetel IP statis mesin yang berjalan di virtualbox.

Apakah itu mendukung Windows? Maksud saya, "untuk" dan "di".

sepertinya itu masih menjadi masalah. ada cara untuk memperbaikinya?

@bayu_joo
Terima kasih.
bekerja dengan baik. saya baru saja me-restart kotak peralatan saya dan semuanya kembali ke dalam permainan.

bagaimana saya bisa memiliki akun statis kontainer, ini memungkinkan saya untuk mengubah akun setiap kali saya me-restart mesin buruh pelabuhan?

Saya melihat solusi dengan docker-machine-ipconfig tetapi hanya untuk kepentingan dokumentasi, saya melaporkan bahwa ini terjadi dengan Windows 10 Docker Machine dan Hyper-V juga

Mungkin ingin mengubah pesan ini "Mesin yang dijalankan mungkin memiliki alamat IP baru. Anda mungkin perlu menjalankan kembali perintah docker-machine env ." untuk menyebutkan sesuatu seperti "dan juga melakukan regenerasi-mesin buruh pelabuhan-sertifikat ..." FWIW ...

@rdp tangkapan yang bagus, saya mengalami masalah ini setengah jam melihat apa yang terjadi, dan setelah mencoba melakukan beberapa hal dengan kubernetes, menginstal dan mencopot pemasangan ...
docker-machine env
IP yang cocok di envs saya cocok dengan yang menghasilkan kesalahan dengan sertifikat ...
kemudian:
eval $(docker-machine env)
buat konfigurasi di tempat untuk saya ...

minikube stop && minikube start memperbaiki ini untuk saya

minikube stop && minikube start memperbaiki ini untuk saya

@PatMyron Anehnya, ini juga berhasil untuk saya!