Pouvez-vous donner plus de détails sur la question?

• Quelle version de Machine?
• Quel pilote (je suppose vbox basé sur l'IP)?
• Ligne de commande utilisée pour créer la machine

Merci

version 0.1.0 de docker-machine
boîte virtuelle
docker-machine create -d virtualbox --virtualbox-disk-size '40000' --virtualbox-memory '4096' devbox

J'ai également ajouté un registre --insecure au démon pour que je puisse parler à notre registre privé (si cela compte).

Pourriez-vous tester à partir de master (vous pouvez utiliser https://docker-machine-builds.evanhazlett.com/latest/ si vous ne voulez pas construire localement). J'ai testé cela avec des machines virtuelles changeant d'adresses IP et tout fonctionne comme prévu:

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

Vous pouvez voir que test-vbox changé d'adresse IP.

Ok, voici ce que j'ai fait:

Arrêter la machine actuelle
Commencez à utiliser le nouveau bac de la machine
"machine ls" avec la nouvelle machine était ok et montre:
"devbox * virtualbox exécutant tcp: //192.168.99.100 : 2376
devbox2 virtualbox arrêté "

"docker info" produit:
FATA [0000] Une erreur s'est produite lors de la tentative de connexion: Obtenez https://192.168.99.100 : 2376 / v1.16 / info: x509: le certificat est valide pour 192.168.99.103, pas pour 192.168.99.100

Merci. avez-vous essayé avec la version principale ci-dessus? J'ai exécuté la même procédure que vous et je n'ai eu aucun problème de certificat.

J'ai téléchargé ce "dernier" binaire.

Hmm ok. @sthulb pouvez-vous essayer de voir si vous pouvez reproduire cela?

• Créer une machine virtualbox
• Arrêter la première machine
• Créer une deuxième machine virtualbox
• Démarrer la première machine
• Vérifiez que l'adresse IP de la première machine a changé
• Vérifiez si vous pouvez accéder au démon docker sur les deux

@stephenlawrence est-ce que ce processus est correct?

Merci

@ehazlett Techniquement, ce n'est pas comme ça que ça a commencé. Cela a commencé lorsque j'ai redémarré mon Mac et que le DM a proposé une adresse IP différente lors du redémarrage. Je ne sais pas si c'est différent de simplement faire ce que vous décrivez. Mais maintenant, toute tentative d'accès à cette machine qui fonctionnait auparavant entraîne le message x509.

@stephenlawrence je ne peux pas recréer cela car mon IP change toujours et la VM reste. J'ai simplement émulé la VM en obtenant une adresse IP différente, ce qui devrait créer la même chose que je crois. Pourriez-vous essayer ce qui précède avec le nouveau binaire et un nouvel ensemble de machines virtuelles? Je me demande si les certificats ont été créés en utilisant une ancienne version n'utilisant pas le bon processus ou quelque chose.

@stephenlawrence Êtes-vous sûr de ne pas avoir quelque chose dans votre bashrc qui perturbe vos paramètres, comme DOCKER_CERT_PATH?

Comme je n'ai vu personne d'autre référencer le code pertinent, je ferai simplement remarquer que machine crée un certificat avec l'adresse IP ici: https://github.com/docker/machine/ blob / 973b267fec3ec0a900e26557475b387891c0138a / host.go # L123

Si l'adresse IP change, ce certificat ne fonctionnera plus.

Dans les scripts init b2d, il y a du code qui régénère les certificats de serveur si les adresses IP pertinentes changent: https://github.com/boot2docker/boot2docker/blob/5db7efbb4e0557f6efefdb56cb0263f80ed55834/rootfs/rootfs/usr/local/etc/ / docker # L46

Je ne suis pas tout à fait sûr de savoir pourquoi ce morceau de code b2d n'est pas déclenché dans le cas machine puisque je pensais que vous utilisiez l'ISO b2d.

Ouais merci, je sais que ce code est là cependant, quand l'adresse IP a changé (comme
montré ci-dessus) il n'y a eu aucun problème lors du test, donc j'essaye au moins
obtenir ce reproductible pour tester.

Le samedi 14 février 2015 à 00:58, Mike Dillon [email protected]
a écrit:

Puisque je n'ai vu personne d'autre référencer le code pertinent, je vais juste
faites remarquer que la machine crée un certificat avec l'adresse IP
c'est ici:
https://github.com/docker/machine/blob/973b267fec3ec0a900e26557475b387891c0138a/host.go#L123

Si l'adresse IP change, ce certificat ne fonctionnera plus.

Dans les scripts d'initialisation b2d, il y a du code qui régénère le serveur
certificats si les adresses IP pertinentes changent:
https://github.com/boot2docker/boot2docker/blob/5db7efbb4e0557f6efefdb56cb0263f80ed55834/rootfs/rootfs/usr/local/etc/init.d/docker#L46

Je ne suis pas tout à fait sûr de savoir pourquoi ce morceau de code b2d n'est pas déclenché dans le
cas de la machine puisque je pensais que vous utilisiez l'ISO b2d.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/docker/machine/issues/531#issuecomment -74363452.

@ md5 @stephenlawrence est- ce que cela vous dérangerait de vérifier si vous avez quelque chose qui utiliserait les certificats b2d par hasard? après le débogage, il semble que les certificats b2d soient utilisés avec machine.

@ehazlett Je ne suis pas sûr de ce que vous me demandez de vérifier.

@ md5 désolé, j'aurais dû être plus clair. vérifiez les variables d'environnement DOCKER_CERT_PATH et DOCKER_HOST pour voir si elles sont pointées vers la bonne machine. Il semble que le DOCKER_CERT_PATH puisse être configuré sur les certificats b2d lors de l'accès à une machine ou vice versa.

@ehazlett s'il s'agissait d'un cas de DOCKER_CERT_PATH incorrect, ce serait une erreur différente. Le problème dans cette situation serait soit que ca.pem n'est pas une racine de confiance pour le certificat présenté par le serveur Docker sur l'instance contrôlée par machine ou que le certificat client cert.pem n'est pas accepté par le serveur.

L'erreur que nous voyons ici est clairement que le client (c'est- docker exec dire 192.168.99.100 , mais le serveur présente un certificat qui n'est valide que pour 192.168.99.103 . Cela peut seulement signifier qu'un serveur qui répond à 192.168.99.100 sur le port 2376 est configuré pour utiliser un certificat qui a été créé pour 192.168.99.103 .

@ md5 qui a du sens. comment recréer? comme vous pouvez le voir ci-dessus, j'ai changé l'adresse IP de mes instances de virtualbox et je ne vois pas ce problème.

C'est une bonne question. Je n'ai pas pu non plus le reproduire moi-même.

Clôture car nous ne semblons pas pouvoir reproduire. Je soupçonne que les variables d'environnement se mélangent pour la VM boot2docker et l'instance de la machine. Je recommanderais de vérifier votre .bashrc etc pour tout ce qui peut les définir.

J'ai ce problème qui se reproduit. J'avais une machine docker fonctionnant sur 192.168.99.101, et après un redémarrage de mon Mac, cette machine fonctionne maintenant sur 192.168.99.100.

Cela semble être un problème de docker car je peux faire "docker-compose run" dans un conteneur OK, mais essayer n'importe quelle commande docker génère cette erreur:

$ docker ps
FATA [0000] Une erreur s'est produite lors de la tentative de connexion: Obtenez https://192.168.99.100 : 2376 / v1.17 / containers / json: x509: le certificat est valide pour 192.168.99.101, pas pour 192.168.99.100

Env actuel:
DOCKER_CERT_PATH = / Utilisateurs / mon nom d'utilisateur / .docker / machines / .client
DOCKER_TLS_VERIFY = oui
DOCKER_HOST = tcp: //192.168.99.100 : 2376

$ ls -l ~ / .docker / machines / .client /
total 48
-rw-r - r-- 1 personnel myusername 1054 11 février 10:21 ca.pem
-rw-r - r-- 1 personnel myusername 1054 30 janvier 08:53 ca.pem.bak
-rw-r - r-- 1 personnel myusername 1094 11 février 10:21 cert.pem
-rw-r - r-- 1 personnel myusername 1094 30 janvier 08:53 cert.pem.bak
-rw ------- 1 personnel myusername 1675 11 février 10:21 key.pem
-rw ------- 1 personnel myusername 1679 30 janvier 08:53 key.pem.bak

@stephenlawrence ugh ok. utiliseriez-vous également b2d par hasard? la seule fois où j'ai vu cela, c'était quelque chose entre b2d et machine. Je ne peux pas reproduire personnellement mais cela avait à voir avec les certificats et env.

peut-être avons-nous besoin de cette commande "régénérer-certs" le plus tôt possible :)

Eh bien, j'avais utilisé b2d seul avant de passer à DM. DM utilise b2d aussi non?

@stephenlawrence utilise simplement machine pour gérer les b2d . supprimer votre installation et VM d'origine b2d

Cela m'est arrivé aussi. J'ai utilisé machine pour créer la machine virtuelle, pas b2d directement. Une commande pour régénérer les certificats semble utile.

La suppression de b2d ne résout pas nécessairement mon problème, mais je l'ai supprimé.

J'ajouterais que cela rend la machine docker inutilisable pour le moment. Je viens de créer une nouvelle machine dans l'espoir de me débarrasser de ce problème, mais j'ai le même problème sur une nouvelle machine.

@stephenlawrence pouvez-vous essayer mon PR ci-dessus et voir si cela résout le problème? il devrait car il régénérera les certificats pour l'instance.

702 a corrigé ceci pour moi: smiley: La régénération du certificat après machine start fonctionne après le redémarrage de mon Mac.

@jeffdm merci pour les commentaires!

Je pense que c'est toujours un problème. Deux solutions possibles auxquelles je peux penser:

• Supposons que les adresses IP vont changer. Avons-nous besoin de vérifier l'adresse IP lors de la négociation TLS? Ne pouvons-nous pas valider le certificat spécifique de la machine?
• Ne comptez pas sur DHCP. Peut-être pouvons-nous donner des adresses IP statiques aux VM?

J'ai un problème similaire ... le client VPN Cisco que j'utilise met en place des règles ipfw qui bloquent à peu près la capacité d'aller aux adresses 192.168.x qui sont liées à vboxnetN.

J'ai donc configuré une règle de mappage de port dans virtualbox afin que 127.0.0.1:2376 atteigne le serveur docker. Le problème est que le certificat du serveur docker est pour 192.168.99.101 et non pour 127.0.0.1:

$ export DOCKER_TLS_VERIFY = ""
$ docker images
FATA [0000] Obtenez http://127.0.0.1 : 2376 / v1.17 / images / json: réponse HTTP malformée "\ x15 \ x03 \ x01 \ x00 \ x02 \ x02". Essayez-vous de vous connecter à un démon compatible TLS sans TLS?
$ export DOCKER_TLS_VERIFY = oui
$ docker images
FATA [0000] Une erreur s'est produite lors de la tentative de connexion: Obtenez https://127.0.0.1 : 2376 / v1.17 / images / json: x509: le certificat est valide pour 192.168.99.101, pas pour 127.0.0.1
$ docker --tlsverify = fausses images
(cela marche)

Bien que ce ne soit pas un stopper, je peux mettre "--tlsverify = false" dans toutes mes commandes de course manuelle, mais d'autres outils comme fig ne le feraient pas. Aussi pour une raison quelconque, DOCKER_OPTS ne fonctionne pas pour moi.

Peut-être une option lors de la création d'une instance de virtualbox pour qu'elle rende également le certificat valide pour une autre adresse? Je peux voir que cela pose également un problème si le serveur a une adresse IP interne et externe qui sont toutes deux utilisées (par exemple dans ec2, mais j'utiliserais alors le nom DNS).

@cwilkes il y a / était un problème pour permettre à cela d'être configuré.

On dirait que https://github.com/docker/machine/pull/702 pourrait m'aider, et je vois qu'il a été poussé dans master aujourd'hui https://github.com/docker/machine/compare/v0.1.0 .. .Maître . Espérons qu'il y aura bientôt une version 0.1.1 :)

Ok après en avoir discuté avec @sthulb et @nathanleclaire, je pense que nous devrions faire une vérification similaire à ce que fait b2d. Nous pouvons inspecter l'IP au démarrage de la machine et la comparer avec l'IP SAN dans le cert. S'ils ne correspondent pas, nous pouvons nous régénérer. Pensées @sthulb @nathanleclaire ?

D'accord.

Oui s'il vous plaît @ehazlett

+1 ayant le même problème

Je rencontre cela aussi. J'ai lancé une machine à l'aide du pilote AWS, puis j'ai attribué une adresse IP Elastic à la boîte. J'ai essayé d'arrêter et de démarrer la machine via la CLI, mais chaque fois que j'exécute un docker ps après avoir activé l'environnement, je reçois:

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

J'ai essayé de changer manuellement l'adresse IP dans la configuration `~ / .docker / machine '. Cela n'a pas fonctionné.

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

s'il vous plaît vérifier # 770. cela ajoute une régénération automatique en cas d'erreur de certificat. notez que cela ne fonctionne qu'avec les commandes config et env donc si vous avez un problème avec docker (ie docker ps etc), vous devrez exécuter $(docker-machine env <name>) ou docker $(docker-machine config <name>) ps pour les faire réparer. Ce PR ajoute également la possibilité de régénérer les certificats manuellement avec la commande regenerate-certs (j'ai utilisé la fonctionnalité de # 702).

Espérons que cela résoudra les erreurs TLS une fois pour toutes :)

Je détecte le changement d'adresse IP AWS après le redémarrage normal de l'instance aws.
docker-machine ssh amazonec2-03 ne fonctionne qu'après avoir modifié manuellement l'adresse IP à /.docker/machine/machines/amazonec2-03/confg.json

Les certificats de démon docker ne fonctionnent pas, je peux vérifier le # 770 demain.

PTAL @nathanleclaire @sthulb

Ayant le même problème, vérifiera bientôt # 770 ...

Vous pouvez utiliser la tête actuelle :)

Ou vous pouvez utiliser les RC - ils ont le correctif.

eu le même problème mais avec la dernière version 0.2.0 de jalon, il est résolu! Merci!

@gschmutz merci pour les commentaires!

J'en ai depuis ma mise à jour vers la 1.7.0.
Le redémarrage de b2d entraînera cette erreur:

$ 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

Merci

@gravis Comment se fait-il que vous utilisiez boot2docker shellinit avec la machine?

Désolé, j'ai posté dans le mauvais repo :)
Je pensais que c'était du b2d, j'ai raté mes onglets.

Pour toute autre personne qui rencontre cela, voici une solution possible: https://github.com/boot2docker/boot2docker/issues/824#issuecomment -113904164
ET
https://github.com/boot2docker/boot2docker/pull/411

Jusqu'à présent, cela a résolu le problème pour moi. Je peux voir que le fichier / var / lib / boot2docker / tls / hostnames n'a pas l'IP de la VM (c'est-à-dire qu'il n'a pas l'IP que vous voyez lorsque vous tapez: boot2docker ip), donc cela lui permet d'être ajouté (il apparaît à la fin de la liste des noms d'hôte après avoir ajouté le délai suggéré).

J'ai testé boot2docker il y a quelque temps, je l'ai oublié pendant longtemps et aujourd'hui j'ai téléchargé la dernière version de boot2docker et l'ai installé. Après l'installation, j'ai rencontré le même problème X.509 mentionné ici et je l'ai résolu en

1) suppression du répertoire .boot2docker (situé dans mon répertoire personnel) et de son contenu et
2) Suppression de tous les fichiers de machine virtuelle boot2docker

J'espère que cela t'aides.

ps. Comme je n'ai testé que boot2docker, je m'en fichais si j'avais perdu quelque chose en supprimant ce truc ...

J'ai résolu le problème de la même manière pasitolonen. Suppression du répertoire .boot2docker et exécution de boot2docker init. Cela a pour effet secondaire de supprimer mes images (ce qui ne me dérangeait pas).

Cela m'arrive à chaque fois que le wifi change. Par exemple lorsque je l'utilise depuis chez moi, puis à nouveau au bureau.

Erreur: Une erreur s'est produite lors de la tentative de connexion: Obtenez https://192.168.59.104 : 2376 / v1.19 / version: x509: le certificat est valide pour 127.0.0.1, 10.0.2.15, pas 192.168.59.104

$ version docker
Version du client: 1.7.0
Version de l'API client: 1.19
Version Go (client): go1.4.2
Git commit (client): 0baf609
OS / Arch (client): darwin / amd64

Apparemment, cela semble résoudre le problème: https://github.com/boot2docker/boot2docker/issues/938#issuecomment -118211836

alias docker="docker --tlsverify=false"

J'ai vécu cela après avoir réaffecté de la RAM. comme rajaraodv a indiqué alias docker="docker --tlsverify=false" résolu

La désactivation de la sécurité ( --tlsverify=false ) ne devrait jamais être une solution de contournement recommandée.

Une solution de contournement qui fonctionne pour moi est boot2docker ssh 'sudo /etc/init.d/docker restart' , ce qui obligera Docker à générer un nouveau certificat x509 valide pour boot2docker en plus d'autres adresses IP. Veuillez essayer cela avant de désactiver les fonctions de sécurité.

La solution

@indygreg m'a aussi sauvé. Merci!

merci ça marche pour moi aussi :-)

Salut à tous, si vous rencontrez toujours le problème de certificat avec boot2docker , assurez-vous d'abord d'essayer boot2docker upgrade pour mettre à jour votre VM à la dernière version (1.7.1 corrige ce problème), et si autre chose vient signaler les problèmes sur github.com/boot2docker/boot2docker-cli. Ce dépôt est destiné aux problèmes de Docker Machine. Merci!

@indygreg génial

@indygreg merci cela fonctionne aussi pour moi :-)

@indygreg a travaillé pour moi aussi! Je vous remercie.

A travaillé pour moi, merci!

Merci @indygreg! J'ajoute ici un lien vers le commentaire afin que le googleur puisse facilement voir ce qu'il a recommandé.

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

Frappez ce problème avec Docker Toolbox 1.9.1 sur Windows après un redémarrage entraînant l'attribution d'une adresse IP différente à la VM, et c'était le principal succès sur Google.

Donc, pour tous les autres, le correctif actuel est encore plus facile. (où default est votre machine docker)

docker-machine regenerate-certs default

Merci @johnmccabe ,

Cela m'arrive souvent à cause du changement de wlans et de l'utilisation de VPN parfois. Y a-t-il un moyen pour que cela soit automatisé? Ou les certificats pourraient-ils être valides pour une plage d'adresses IP à la place?

@johnmccabe Remarque, vous pouvez simplement vous assurer que votre VM démarre toujours avec la même IP: http://stackoverflow.com/a/35367277/6309

J'utilise OS X et j'en ai marre d'utiliser ces hacks et de les casser éventuellement.

Vagrant a la possibilité de définir l'adresse IP dans la configuration. Je ne comprends pas pourquoi ce type de paramètre ou d'indicateur n'existe pas déjà dans docker-machine (juste en comparant à vagrant car les deux utilisent virtualbox)

@onnimonni : cela est résolu depuis longtemps (presque un an). La machine inclut une commande pour régénérer les certificats au cas où l'IP changerait.

Je viens de rencontrer ce problème pour la première fois et j'ai tout vérifié dans ce fil avec l'une des options suivantes résolvant avec succès le problème: (choisissez-en une)

• docker-machine regenerate-certs default2
• docker-machine kill default2 puis docker-machine create default2 ...
• docker-machine upgrade default2 (si pas déjà mis à jour)

Pour reproduire ce problème sur OSX:

1. Installez Docker Toolbox (v1.10)
2. Créez une machine default qui obtient 192.168.99.100
3. Créez une machine default2 qui obtient 192.168.99.101
4. Arrêtez les deux (nécessite parfois un redémarrage aussi)
5. docker-compose start default2 qui obtient 192.168.99.100 (et un conflit de cert x509)

il s'agit donc de plusieurs machines démarrées dans un ordre différent peuvent entraîner une adresse IP différente qui rompt le certificat, ce qui nécessite de rechercher sur github pour ce problème afin de trouver la résolution de créer un nouveau certificat pour vous permettre de les utiliser à nouveau ... existe-t-il un moyen Empêcher que cela se produise? est-il si inhabituel pour les gens de basculer entre plusieurs machines docker?

$ alias docker = "docker --tlsverify = false" Travaillez pour moi!

@ivancarrancho Pourquoi ne pas docker-machine regenerate-certs -f et garder TLS activé?

@nathanleclaire oui, c'est mieux que "--tlsveify" merci beaucoup

@nathanleclaire car cela prend ~ 4 minutes ... Imaginez que vous ayez un cluster de 6+ nœuds ... Je vais devoir écrire un truc de régénérateur de certificat parallèle pour ne pas passer toute la journée à régénérer certains certificats .... De plus il redémarre tout conteneurs Docker sur la machine cible ...

Cette exigence de régénération des certificats après le changement d'adresse IP est une douleur énorme sur le cloud aws ... Les adresses IP publiques changent tout le temps. La seule solution que je connaisse est de créer de nouvelles instances à partir d'une instance ec2, mais pour une raison quelconque, cela ne fonctionne pas https://github.com/docker/machine/pull/1453#issuecomment -215371216

Btw une idée si docker-machine create --amazonec2-use-private-address est censé créer une instance ec2 à partir d'une autre instance ec2?

C'est la seule façon dont je sais comment éviter la régénération constante des certificats ...

Btw une idée si docker-machine create --amazonec2-use-private-address est censé créer une instance ec2 à partir d'une autre instance ec2?

Oui, sauf s'il existe un autre moyen d'accéder à l'adresse IP privée depuis le nœud de création (par exemple proxy).

Nous envisageons diverses solutions, par exemple Elastic IP, pour potentiellement résoudre ce problème.

oui, mais comme je l'ai mentionné, il est suspendu à l'accès ssh même avec cette option
activée
Le 2 mai 2016 à 20h26, "Nathan LeClaire" [email protected] a écrit:

Btw n'importe quelle idée si docker-machine create --amazonec2-use-private-address est
censé créer une instance ec2 à partir d'une autre instance ec2?

Oui, sauf s'il existe un autre moyen d'accéder à l'adresse IP privée depuis
le nœud de création (par exemple proxy).

Nous envisageons une variété de solutions, par exemple Elastic IP, pour potentiellement
résoudre ce problème.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/docker/machine/issues/531#issuecomment -216319103

Peut-être que le groupe de sécurité n'est pas configuré correctement? Actuellement, si vous utilisez --amazonec2-use-private-ip-address , il est supposé que l'utilisateur est prêt à s'assurer que ces types de détails d'accès au réseau sont correctement configurés au préalable.

Je ne comprends pas pourquoi je dois exécuter cette vilaine déclaration $ eval à chaque fois que docker doit être démarré via un terminal.

Je ne comprends même pas pourquoi ce problème existe.

Docker ressemble de plus en plus à un produit horriblement cassé que beaucoup de gens ont soutenu parce que c'était le truc "in".

J'utilise la dernière version de docker et docker-machine , et j'ai toujours le même problème, j'ai créé plusieurs hôtes docker virtualbox par

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

et presque chaque fois que je redémarre les machines virtuelles ou que je redémarre mon Mac, je vais faire face à l'erreur du type certificate is valid for 192.168.99.100, not 192.168.99.101 .

Mes versions sont:

$ 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

Existe-t-il une solution pour éviter que ces erreurs ne se produisent? ou créer un hôte virtualbox avec une adresse IP fixe?

Solution de contournement: docker-machine provision .

Correction du problème de 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

Suite au lien docker-machine-ipconfig https://github.com/fivestars/docker-machine-ipconfig

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

Par exemple: attribuez au nom de la machine une adresse IP statique:

 $ docker-machine-ipconfig nom-machine statique
 # ou spécifiez une adresse IP implicite
 $ docker-machine-ipconfig nom-machine statique 192.168.99.110

Cela élimine le besoin de docker-machine regenerate-certs -f machine-name à chaque redémarrage. Un moyen simple de définir l'adresse IP statique de la machine exécutée sur virtualbox.

Prend-il en charge Windows? Je veux dire à la fois «pour» et «sur».

il semble que ce soit toujours un problème. Un moyen de le réparer?

@johnmccabe ,
Merci.
fonctionne très bien. Je viens de redémarrer ma boîte à outils et tout est de retour dans le jeu.

comment puis-je avoir un compte statique du conteneur, cela me permet de changer de compte à chaque fois que je redémarre la machine docker?

Je vois la solution de contournement avec docker-machine-ipconfig mais juste pour la documentation, je signale que cela se produit également avec Windows 10 Docker Machine et Hyper-V

Peut-être souhaitez-vous modifier ce message "Les machines démarrées peuvent avoir de nouvelles adresses IP. Vous devrez peut-être réexécuter la commande docker-machine env ." pour mentionner quelque chose comme "et aussi faire des régénérations-certs de docker-machine ..." FWIW ...

@rdp belle prise, j'ai eu ce problème une demi-heure à regarder ce qui s'était passé, et après avoir essayé de faire certaines choses avec kubernetes, installer et désinstaller des choses ... en cours d'exécution
docker-machine env
l'adresse IP correspondant dans mes envs correspondait à celle qui produisait l'erreur avec le certificat ...
puis:
eval $(docker-machine env)
faire la configuration en place pour moi ...

minikube stop && minikube start corrigé ça pour moi

minikube stop && minikube start corrigé ça pour moi

@PatMyron Étonnamment, cela a fonctionné pour moi aussi!