Können Sie das Problem genauer erläutern?

• Welche Version von Machine?
• Welcher Treiber (ich gehe davon aus, dass vbox auf der IP basiert)?
• Befehlszeile zum Erstellen der Maschine

Vielen Dank

Docker-Maschine Version 0.1.0
Virtualbox
docker-machine create -d virtualbox --virtualbox-disk-size '40000' --virtualbox-memory '4096' devbox

Ich habe dem Daemon auch eine --insecure-Registrierung hinzugefügt, damit ich mit unserer privaten Registrierung sprechen kann (falls dies wichtig ist).

Würde es Ihnen etwas ausmachen, vom Master aus zu testen (Sie können https://docker-machine-builds.evanhazlett.com/latest/ verwenden, wenn Sie nicht lokal erstellen möchten). Ich habe dies mit VMs getestet, die IPs ändern, und alles funktioniert wie erwartet:

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

Sie können sehen, dass test-vbox IPs gewechselt hat.

Ok, hier ist was ich getan habe:

Stoppen Sie die aktuelle Maschine
Starten Sie den neuen Maschinenbehälter
"machine ls" mit neuer Maschine war ok und zeigt:
"devbox * virtualbox Running tcp: //192.168.99.100 : 2376
devbox2 virtualbox gestoppt "

"Docker Info" erzeugt:
FATA Beim Versuch, eine Verbindung herzustellen, ist ein Fehler aufgetreten: Get https://192.168.99.100 : 2376 / v1.16 / info: x509: Zertifikat ist gültig für 192.168.99.103, nicht für 192.168.99.100

Vielen Dank. Hast du es mit dem Master Build oben versucht? Ich habe das gleiche Verfahren wie Sie ausgeführt und hatte keine Zertifizierungsprobleme.

Ich habe diese "neueste" Binärdatei heruntergeladen.

Hmm ok @sthulb kannst du versuchen zu sehen ob du das reproduzieren kannst?

• Erstellen Sie eine Virtualbox-Maschine
• Stoppen Sie die erste Maschine
• Erstellen Sie eine zweite Virtualbox-Maschine
• Starten Sie die erste Maschine
• Überprüfen Sie, ob sich die IP-Adresse des ersten Computers geändert hat
• Überprüfen Sie, ob Sie auf beiden auf den Docker-Daemon zugreifen können

@stephenlawrence ist dieser Prozess korrekt?

Vielen Dank

@ehazlett Technisch gesehen hat es nicht so angefangen. Es begann, als ich meinen Mac neu startete und der DM beim Neustart eine andere IP-Adresse ausgab. Ich weiß nicht, ob das anders ist als nur das zu tun, was Sie beschreiben. Alle Versuche, auf diese zuvor funktionierende Maschine zuzugreifen, führen jetzt zur Meldung x509.

@stephenlawrence Ich kann das nicht neu erstellen, da sich meine IP immer ändert und die VM bleibt. Ich habe einfach emuliert, dass die VM eine andere IP erhält, die meiner Meinung nach dasselbe erzeugen sollte. Würde es Ihnen etwas ausmachen, das oben Genannte mit der neuen Binärdatei und einem neuen Satz von VMs zu versuchen? Ich frage mich, ob die Zertifikate mit einem alten Build erstellt wurden, ohne den richtigen Prozess oder so.

@stephenlawrence Sind Sie sicher, dass Sie nichts in Ihrem Bashrc haben, das mit Ihren Einstellungen in Konflikt gerät, wie DOCKER_CERT_PATH?

Da ich niemanden gesehen habe, der auf den relevanten Code verweist, möchte ich nur darauf hinweisen, dass machine hier ein Zertifikat mit der darin enthaltenen IP-Adresse erstellt: https://github.com/docker/machine/ blob / 973b267fec3ec0a900e26557475b387891c0138a / host.go # L123

Wenn sich die IP-Adresse ändert, funktioniert dieses Zertifikat nicht mehr.

In den b2d-Init-Skripten gibt es Code, der die Serverzertifikate neu generiert, wenn sich die relevanten IP-Adressen ändern: https://github.com/boot2docker/boot2docker/blob/5db7efbb4e0557f6efefdb56cb0263f80ed55834/rootfs/rootfs/usr/local/c / Docker # L46

Ich bin mir nicht ganz sicher, warum dieses Stück b2d-Code im Fall machine nicht ausgelöst wird, da ich dachte, dass Sie die b2d-ISO verwenden.

Ja danke, ich weiß, dass dieser Code vorhanden ist, wenn sich die IP ändert (as
oben gezeigt) Es gab keine Probleme beim Testen, also versuche ich es zumindest
Lassen Sie dieses Reproduzierbare testen.

Am Samstag, den 14. Februar 2015 um 00:58 Uhr meldete Mike Dillon [email protected]
schrieb:

Da ich niemanden gesehen habe, der auf den relevanten Code verweist, werde ich es einfach tun
Weisen Sie darauf hin, dass der Computer ein Zertifikat mit der IP-Adresse in erstellt
hier:
https://github.com/docker/machine/blob/973b267fec3ec0a900e26557475b387891c0138a/host.go#L123

Wenn sich die IP-Adresse ändert, funktioniert dieses Zertifikat nicht mehr.

In den b2d-Init-Skripten gibt es Code, der den Server neu generiert
Zertifikate, wenn sich die relevanten IP-Adressen ändern:
https://github.com/boot2docker/boot2docker/blob/5db7efbb4e0557f6efefdb56cb0263f80ed55834/rootfs/rootfs/usr/local/etc/init.d/docker#L46

Ich bin mir nicht ganz sicher, warum dieses Bit von b2d-Code nicht in der ausgelöst wird
Maschinengehäuse, da ich dachte, ihr benutzt die b2d ISO.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/docker/machine/issues/531#issuecomment -74363452.

@ md5 @stephenlawrence Würde es Ihnen etwas

@ehazlett Ich bin nicht sicher, was Sie mich bitten, zu überprüfen.

@ md5 sorry ich hätte klarer sein sollen. Überprüfen Sie die Umgebungsvariablen DOCKER_CERT_PATH und DOCKER_HOST um festzustellen, ob sie auf den richtigen Computer zeigen. Es hört sich so an, als ob die DOCKER_CERT_PATH beim Zugriff auf eine Maschine für die b2d-Zertifikate konfiguriert werden könnten oder umgekehrt.

@ehazlett Wenn dies ein Fall von einem falschen DOCKER_CERT_PATH , wäre es ein anderer Fehler. Das Problem in dieser Situation wäre entweder, dass ca.pem kein Vertrauensstamm für das Zertifikat ist, das vom Docker-Server auf der machine -gesteuerten Instanz präsentiert wird, oder dass das cert.pem Client-Zertifikat wird vom Server nicht akzeptiert.

Der Fehler, den wir hier sehen, ist eindeutig, dass der Client (dh docker exec ) das Serverzertifikat nicht akzeptiert. Es wird versucht, den Server mit 192.168.99.100 , aber der Server legt ein Zertifikat vor, das nur für 192.168.99.103 gültig ist. Dies kann nur bedeuten, dass ein Server, der mit 192.168.99.100 auf Port 2376 antwortet, so konfiguriert ist, dass er ein Zertifikat verwendet, das für 192.168.99.103 .

@ md5 das macht Sinn. Wie erstelle ich neu? Wie Sie oben sehen können, habe ich die IP meiner Virtualbox-Instanzen geändert und sehe dieses Problem nicht.

Das ist eine gute Frage. Ich konnte es auch nicht selbst reproduzieren.

Schließen, da wir uns scheinbar nicht reproduzieren können. Mein Verdacht ist, dass die Umgebungsvariablen für die boot2docker-VM und die Maschineninstanz gemischt werden. Ich würde empfehlen, Ihre .bashrc usw. auf alles zu überprüfen, was sie möglicherweise einstellt.

Ich habe dieses Problem wieder. Ich hatte einen Docker-Computer unter 192.168.99.101 und nach einem Neustart meines Mac läuft dieser Computer jetzt unter 192.168.99.100.

Dies scheint ein Docker-Problem zu sein, da ich einen Docker-Compose-Lauf in einen Container ausführen kann.

$ docker ps
FATA Beim Verbindungsaufbau ist ein Fehler aufgetreten: https://192.168.99.100 : 2376 / v1.17 / container / json: x509 abrufen: Zertifikat ist gültig für 192.168.99.101, nicht für 192.168.99.100

Aktuelle Umgebung:
DOCKER_CERT_PATH = / Users / myusername / .docker / machine / .client
DOCKER_TLS_VERIFY = ja
DOCKER_HOST = tcp: //192.168.99.100 : 2376

$ ls -l ~ / .docker / machine / .client /
insgesamt 48
-rw-r - r-- 1 myusername staff 1054 Feb 11 10:21 ca.pem
-rw-r - r-- 1 myusername staff 1054 Jan 30 08:53 ca.pem.bak
-rw-r - r-- 1 myusername staff 1094 Feb 11 10:21 cert.pem
-rw-r - r-- 1 myusername staff 1094 Jan 30 08:53 cert.pem.bak
-rw ------- 1 myusername staff 1675 Feb 11 10:21 key.pem
-rw ------- 1 myusername staff 1679 Jan 30 08:53 key.pem.bak

@stephenlawrence ugh ok. Würden Sie b2d auch zufällig verwenden? Das einzige Mal, dass ich das gesehen habe, war etwas zwischen b2d und Maschine. ich kann nicht persönlich reproduzieren, aber es hat mit den certs und env vars zu tun.

Vielleicht brauchen wir den Befehl "regenerate-certs" eher früher als später :)

Nun, ich hatte b2d alleine benutzt, bevor ich zu DM wechselte. DM benutzt auch b2d nein?

@stephenlawrence Verwenden machine , um b2d zu verwalten. Löschen Sie Ihre ursprüngliche b2d Installation und VM

Mir ist das auch passiert. Ich habe machine , um die virtuelle Maschine zu erstellen, nicht b2d direkt. Ein Befehl zum Regenerieren von Zertifikaten klingt hilfreich.

Das Entfernen von b2d behebt mein Problem nicht unbedingt, aber ich habe es entfernt.

Ich würde hinzufügen, dass dies die Docker-Maschine im Moment für mich unbrauchbar macht. Ich habe gerade eine neue Maschine erstellt, in der Hoffnung, dieses Problem zu beheben, aber ich habe das gleiche Problem auf einer neuen Maschine.

@stephenlawrence kannst du meine PR oben ausprobieren und sehen, ob das das Problem löst? Es sollte, da es die Zertifikate für die Instanz neu generiert.

702 hat dies für mich behoben: smiley: Das Regenerieren des Zertifikats nach machine start funktioniert nach dem Neustart meines Mac.

@ Jeffdm Danke für das Feedback!

Ich denke, das ist immer noch ein Problem. Zwei mögliche Lösungen, die ich mir vorstellen kann:

• Angenommen, die IP-Adressen werden sich ändern. Müssen wir die IP-Adresse im TLS-Handshake überprüfen? Können wir das spezifische Zertifikat der Maschine nicht validieren?
• Verlassen Sie sich nicht auf DHCP. Vielleicht können wir VMs statische IPs geben?

Ich habe ein ähnliches Problem ... Der von mir verwendete Cisco VPN-Client richtet ipfw-Regeln ein, die die Möglichkeit, an 192.168.x-Adressen zuzugreifen, die an vboxnetN gebunden sind, so gut wie blockieren.

Also habe ich eine Portzuordnungsregel in virtualbox eingerichtet, damit 127.0.0.1:2376 den Docker-Server erreicht. Das Problem ist, dass das Zertifikat des Docker-Servers für 192.168.99.101 und nicht für 127.0.0.1 gilt:

$ export DOCKER_TLS_VERIFY = ""
$ Docker-Bilder
FATA http://127.0.0.1 : 2376 / v1.17 / images / json: Fehlgebildete HTTP-Antwort "\ x15 \ x03 \ x01 \ x00 \ x02 \ x02". Versuchen Sie, eine Verbindung zu einem TLS-fähigen Daemon ohne TLS herzustellen?
$ export DOCKER_TLS_VERIFY = yes
$ Docker-Bilder
FATA Beim Verbindungsversuch ist ein Fehler aufgetreten: Get https://127.0.0.1 : 2376 / v1.17 / images / json: x509: Zertifikat ist gültig für 192.168.99.101, nicht für 127.0.0.1
$ docker --tlsverify = falsche Bilder
(das funktioniert)

Dies ist zwar kein Show-Stopper, da ich "--tlsverify = false" in alle meine Hand-Run-Befehle einfügen kann, aber andere Tools wie fig würden das nicht tun. Auch aus irgendeinem Grund funktioniert DOCKER_OPTS bei mir nicht.

Vielleicht eine Option beim Erstellen einer Virtualbox-Instanz, damit das Zertifikat auch für eine andere Adresse gültig wird? Ich kann sehen, dass dies auch ein Problem ist, wenn der Server eine interne und eine externe IP-Adresse hat, die beide verwendet werden (zum Beispiel in ec2, aber dann würde ich den DNS-Namen verwenden).

@cwilkes Es gibt / gab ein Problem, das die Konfiguration ermöglichte.

Es sieht so aus, als ob https://github.com/docker/machine/pull/702 mir helfen könnte, und ich sehe, dass es heute in den Master verschoben wurde https://github.com/docker/machine/compare/v0.1.0 .. .Meister . Hoffentlich gibt es bald eine Version 0.1.1 :)

Ok, nachdem ich dies mit @sthulb und @nathanleclaire besprochen habe, denke ich, wir sollten eine Überprüfung durchführen, die der von b2d ähnelt. Wir können die IP beim Start des Computers überprüfen und diese mit dem IP-SAN im Zertifikat vergleichen. Wenn sie nicht übereinstimmen, können wir uns regenerieren. Gedanken @sthulb @nathanleclaire ?

Einverstanden.

Ja bitte @ehazlett

+1 mit dem gleichen Problem

Ich stoße auch darauf. Ich habe einen Computer mit dem AWS-Treiber hochgefahren und der Box dann eine elastische IP zugewiesen. Ich habe versucht, den Computer über die CLI zu stoppen und zu starten, aber jedes Mal, wenn ich nach Aktivierung der Umgebung ein docker ps ausführe, erhalte ich:

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

Ich habe versucht, die IP in der Konfiguration "~ / .docker / machine" manuell zu ändern. Das hat nicht funktioniert.

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

Bitte checkout # 770. Dies fügt eine automatische Regeneration im Falle eines Zertifikatfehlers hinzu. Beachten Sie, dass dies nur mit den Befehlen config und env funktioniert. Wenn Sie also ein Problem mit Docker haben (z. B. docker ps usw.), müssen Sie $(docker-machine env <name>) ausführen oder docker $(docker-machine config <name>) ps , um sie reparieren zu lassen. Diese PR bietet auch die Möglichkeit, Zertifikate manuell mit dem Befehl regenerate-certs zu generieren (ich habe die Funktionalität von # 702 verwendet).

Hoffentlich werden dadurch die TLS-Fehler ein für alle Mal behoben :)

Ich erkenne die AWS-IP-Änderung nach dem normalen Neustart der aws-Instanz.
docker-machine ssh amazonec2-03 funktioniert nur, nachdem die IP-Adresse unter /.docker/machine/machines/amazonec2-03/confg.json manuell bearbeitet wurde

Docker-Daemon-Zertifikate funktionieren nicht, ich kann morgen die Nummer 770 überprüfen.

PTAL @nathanleclaire @sthulb

Wenn Sie das gleiche Problem haben, sehen Sie sich bald # 770 an ...

Sie können den aktuellen Kopf verwenden :)

Oder Sie können die RCs verwenden - sie haben das Update.

hatte das gleiche Problem, aber mit der neuesten Meilensteinversion 0.2.0 ist es gelöst! Vielen Dank!

@gschmutz danke für das Feedback!

Ich habe dies seit meinem Upgrade auf 1.7.0.
Ein Neustart von b2d führt zu folgendem Fehler:

$ 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

Vielen Dank

@gravis Wie kommt es, dass Sie boot2docker shellinit mit der Maschine verwenden?

Sorry, ich habe im falschen Repo gepostet :)
Ich dachte, es wäre b2d, ich habe meine Tabs durcheinander gebracht.

Für alle anderen, die darauf stoßen, ist hier eine mögliche Lösung: https://github.com/boot2docker/boot2docker/issues/824#issuecomment -113904164
UND
https://github.com/boot2docker/boot2docker/pull/411

Bisher hat dies das Problem für mich behoben. Ich kann sehen, dass die Datei / var / lib / boot2docker / tls / hostnames nicht die IP der VM hat (dh sie hat nicht die IP, die Sie sehen, wenn Sie Folgendes eingeben: boot2docker ip), so dass sie hinzugefügt werden kann (es wird am Ende der Liste der Hostnamen angezeigt, nachdem die von ihnen vorgeschlagene Verzögerung hinzugefügt wurde.

Ich habe boot2docker vor einiger Zeit getestet, es für eine lange Zeit vergessen und heute habe ich die neueste Version von boot2docker heruntergeladen und installiert. Nach der Installation bin ich auf dasselbe hier erwähnte X.509-Problem gestoßen und habe es durch gelöst

1) Entfernen des .boot2docker-Verzeichnisses (in meinem Home-Verzeichnis) und seines Inhalts und
2) Entfernen aller Dateien der virtuellen boot2docker-Maschine

Hoffe das hilft.

ps. Da ich nur boot2docker getestet habe, war es mir egal, ob ich beim Löschen etwas verloren habe ...

Ich habe das Problem genauso behoben, wie Pasitolonen es behoben hat. Löschen des .boot2docker-Verzeichnisses und Ausführen von boot2docker init. Dies hat den Nebeneffekt, dass meine Bilder gelöscht werden (was mir nichts ausmachte).

Dies passiert mir immer dann, wenn sich das WLAN ändert. Zum Beispiel, wenn ich es von zu Hause aus und dann wieder im Büro benutze.

Fehler: Beim Versuch, eine Verbindung herzustellen, ist ein Fehler aufgetreten: Get https://192.168.59.104 : 2376 / v1.19 / version: x509: Zertifikat ist gültig für 127.0.0.1, 10.0.2.15, nicht für 192.168.59.104

$ Docker-Version
Client-Version: 1.7.0
Client-API-Version: 1.19
Go-Version (Client): go1.4.2
Git Commit (Client): 0baf609
OS / Arch (Client): darwin / amd64

Anscheinend scheint dies das Problem zu lösen: https://github.com/boot2docker/boot2docker/issues/938#issuecomment -118211836

alias docker="docker --tlsverify=false"

Ich habe dies erlebt, nachdem ich RAM neu zugewiesen habe. als rajaraodv metnuled alias docker="docker --tlsverify=false" gelöst

Das Deaktivieren der Sicherheit ( --tlsverify=false ) sollte niemals eine empfohlene Problemumgehung sein.

Eine Problemumgehung, die für mich funktioniert, ist boot2docker ssh 'sudo /etc/init.d/docker restart' Dadurch generiert Docker zusätzlich zu anderen IP-Adressen ein neues x509-Zertifikat, das für boot2docker gültig ist. Bitte versuchen Sie dies, bevor Sie die Sicherheitsfunktionen deaktivieren.

@indygreg Lösung hat bei mir funktioniert. Danke vielmals.

@indygreg hat mich auch gerettet. Vielen Dank!

danke es funktioniert auch bei mir :-)

Hallo zusammen, wenn Sie immer noch auf das Zertifikatsproblem mit boot2docker stoßen, versuchen Sie bitte zuerst boot2docker upgrade , um Ihre VM auf den neuesten Stand zu bringen (1.7.1 behebt dieses Problem), und wenn überhaupt etwas anderes Melden Sie die Probleme unter github.com/boot2docker/boot2docker-cli. Dieses Repo ist für Probleme mit Docker-Maschinen gedacht. Vielen Dank!

@indygreg super thx

@indygreg danke es funktioniert auch bei mir :-)

@indygreg Hat auch für mich gearbeitet! Vielen Dank.

Hat für mich gearbeitet, danke!

Danke @indygreg! Ich füge hier einen Link zum Kommentar hinzu, damit Googler leicht sehen kann, was er empfohlen hat.

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

Treffen Sie dieses Problem mit Docker Toolbox 1.9.1 unter Windows nach einem Neustart, der dazu führte, dass der VM eine andere IP zugewiesen wurde. Dies war der Top-Hit bei Google.

Für alle anderen, die dies tun, ist die aktuelle Korrektur noch einfacher. (wobei default Ihre Docker-Maschine ist)

docker-machine regenerate-certs default

Danke @johnmccabe , habe für mich mit Docker Toolbox 1.10.0 unter OS X gearbeitet.

Das passiert mir sehr oft, weil ich manchmal die Wlans wechsle und VPN benutze. Gibt es eine Möglichkeit, dies zu automatisieren? Oder könnten die Zertifikate stattdessen für einen Bereich von IP-Adressen gültig sein?

@johnmccabe Hinweis: Sie können einfach sicherstellen, dass Ihre VM immer mit derselben IP- http://stackoverflow.com/a/35367277/6309

Ich benutze OS X und habe es satt, diese Hacks zu benutzen und sie irgendwann kaputt zu machen.

Vagrant hat die Möglichkeit, die IP-Adresse in der Konfiguration festzulegen. Ich kann nicht verstehen, warum diese Art von Parameter oder Flag in Docker-Machine noch nicht vorhanden ist (nur im Vergleich zu Vagrant, da beide Virtualbox verwenden).

@onnimonni : Dies wurde für eine lange lange Zeit (fast ein Jahr) behoben. Die Maschine enthält einen Befehl zum Regenerieren von Zertifikaten, falls sich die IP-Adresse ändert.

Ich bin gerade zum ersten Mal auf dieses Problem gestoßen und habe alles in diesem Thread mit einer der folgenden Optionen überprüft, um das Problem erfolgreich zu beheben: (Wählen Sie eine aus)

• docker-machine regenerate-certs default2
• docker-machine kill default2 dann docker-machine create default2 ...
• docker-machine upgrade default2 (falls nicht bereits aktualisiert)

So wiederholen Sie dieses Problem unter OSX:

1. Installieren Sie die Docker Toolbox (v1.10).
2. Erstellen Sie eine default Maschine, die 192.168.99.100 erhält
3. Erstellen Sie eine default2 Maschine, die 192.168.99.101 erhält
4. Beenden Sie beide (manchmal erfordert auch ein Neustart)
5. docker-compose start default2 erhält 192.168.99.100 (und x509-Zertifikatskonflikt)

Es kommt also darauf an, dass mehrere Computer, die in unterschiedlicher Reihenfolge gestartet wurden, eine andere IP verursachen können, wodurch das Zertifikat beschädigt wird. Dies erfordert die Suche in Github nach diesem Problem, um die Lösung für die Erstellung eines neuen Zertifikats zu finden, damit Sie sie wieder verwenden können um dies zu verhindern? Ist es so ungewöhnlich, dass Leute zwischen mehreren Docker-Maschinen wechseln?

$ alias docker = "docker --tlsverify = false" Arbeite für mich!

@ivancarrancho Warum nicht docker-machine regenerate-certs -f und TLS aktiviert lassen?

@ Nathanleclaire Ja, das ist besser als "--tlsveify". Vielen, vielen Dank

@nathanleclaire, weil es ~ 4 Minuten dauert ... Stellen Sie sich vor, Sie haben einen Cluster von mehr als 6 Knoten ... Ich muss ein paralleles Zertifikat-Regenerator-Ding schreiben, um nicht den ganzen Tag damit zu verbringen, einige Zertifikate neu zu generieren ... Außerdem werden alle neu gestartet Docker-Container auf dem Zielcomputer ...

Diese Anforderung, Zertifikate nach einer Änderung der IP-Adresse neu zu generieren, ist ein großer Schmerz in der aws-Cloud ... Öffentliche IPs ändern sich ständig. Die einzige mir bekannte Lösung ist das Erstellen neuer Instanzen aus einer ec2-Instanz, aber aus irgendeinem Grund funktioniert sie nicht unter https://github.com/docker/machine/pull/1453#issuecomment -215371216

Übrigens, ob docker-machine create --amazonec2-use-private-address eine ec2-Instanz aus einer anderen ec2-Instanz erstellen soll?

Nur so ist mir bewusst, wie eine ständige Neuerstellung von Zertifikaten vermieden werden kann ...

Übrigens, ob Docker-Maschine create --amazonec2-use-private-address eine ec2-Instanz aus einer anderen ec2-Instanz erstellen soll?

Ja, es sei denn, Sie müssen auf andere Weise vom Erstellungsknoten (z. B. Proxy) auf die private IP zugreifen.

Wir erwägen eine Vielzahl von Lösungen, z. B. Elastic IP, um dieses Problem möglicherweise zu beheben.

Ja, aber wie ich bereits erwähnt habe, hängt es auch mit dieser Option am SSH-Zugriff
aktiviert
Am 2. Mai 2016 um 20:26 Uhr schrieb "Nathan LeClaire" [email protected] :

Übrigens jede Idee, ob Docker-Maschine erstellen --amazonec2-use-private-Adresse ist
soll eine ec2-Instanz aus einer anderen ec2-Instanz erstellen?

Ja, es sei denn, Sie müssen auf eine andere Weise auf die private IP zugreifen
der Erstellungsknoten (zB Proxy).

Wir erwägen eine Vielzahl von Lösungen, z. B. Elastic IP, um potenziell
beheben Sie dieses Problem.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/docker/machine/issues/531#issuecomment -216319103

Möglicherweise ist die Sicherheitsgruppe nicht richtig konfiguriert? Derzeit wird bei Verwendung von --amazonec2-use-private-ip-address davon ausgegangen, dass der Benutzer bereit ist, sicherzustellen, dass diese Art von Netzwerkzugriffsdetails im Voraus ordnungsgemäß konfiguriert wurden.

Ich verstehe nicht, warum ich diese hässliche $ eval-Anweisung jedes Mal ausführen muss, wenn Docker über ein Terminal gestartet werden muss.

Ich verstehe nicht, warum dieses Problem überhaupt existiert.

Docker scheint immer mehr ein schrecklich kaputtes Produkt zu sein, das viele Leute hinter sich gelassen haben, weil es das "In" war.

Ich verwende die neueste Version von docker und docker-machine und habe immer noch das gleiche Problem. Ich habe mehrere Docker-Hosts von virtualbox

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

und fast jedes Mal, wenn ich die VMs neu starte oder meinen Mac neu starte, wird der Fehler wie certificate is valid for 192.168.99.100, not 192.168.99.101 .

Meine Versionen sind:

$ 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

Gibt es eine Lösung, um diesen Fehler zu verhindern? oder einen Virtualbox-Host mit einer festen IP erstellen?

Problemumgehung: docker-machine provision .

Das Problem wurde um 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

Nach dem @ VonC- Link stieß ich auf docker-machine-ipconfig https://github.com/fivestars/docker-machine-ipconfig

 $ cd ~ / .docker /
 $ git-Klon https://github.com/fivestars/docker-machine-ipconfig.git
 # Zu ~ / .profile hinzufügen
 $ echo 'alias docker-machine-ipconfig = ~ / .docker / docker-machine-ipconfig / docker-machine-ipconfig' >> ~ / .profile 
 $ source ~ / .profile

Beispiel: Weisen Sie dem Computernamen eine statische IP zu:

 $ docker-machine-ipconfig statischer Maschinenname
 # oder implizite IP angeben
 $ docker-machine-ipconfig statischer Maschinenname 192.168.99.110

Dadurch entfällt docker-machine regenerate-certs -f machine-name jedem Neustart die Notwendigkeit von

Unterstützt es Windows? Ich meine sowohl "für" als auch "an".

es sieht so aus, als wäre es immer noch ein Problem. Wie kann man das beheben?

@ Johnmccabe ,
Vielen Dank.
funktioniert gut. Ich habe gerade meine Toolbox neu gestartet und alles ist wieder im Spiel.

Wie kann ich ein statisches Konto des Containers haben, das es mir ermöglicht, das Konto jedes Mal zu ändern, wenn ich die Docker-Maschine neu starte?

Ich sehe die Problemumgehung mit docker-machine-ipconfig aber nur zur Dokumentation berichte ich, dass dies auch mit Windows 10 Docker Machine und Hyper-V passiert

Möglicherweise möchten Sie diese Meldung optimieren. "Gestartete Computer haben möglicherweise neue IP-Adressen. Möglicherweise müssen Sie den Befehl docker-machine env erneut ausführen." um so etwas wie "und docker-machine regenerate-certs ..." zu erwähnen FWIW ...

@rdp netter Fang, ich hatte dieses Problem eine halbe Stunde lang zu schauen, was passiert war, und nachdem ich versucht hatte, einige Dinge mit Kubernetes zu tun, Dinge zu installieren und zu deinstallieren ... lief
docker-machine env
Die IP-Adresse in meiner Umgebung stimmte mit der IP-Adresse überein, die den Fehler mit dem Zertifikat verursacht hat ...
dann:
eval $(docker-machine env)
Nehmen Sie die Konfiguration für mich vor ...

minikube stop && minikube start das für mich behoben

minikube stop && minikube start das für mich behoben

@PatMyron Überraschenderweise hat das auch bei mir funktioniert!