¿Puede darnos más detalles sobre el tema?

• ¿Qué versión de Machine?
• ¿Qué controlador (supongo que vbox se basa en la IP)?
• Línea de comando utilizada para crear la máquina

Gracias

docker-machine versión 0.1.0
caja virtual
docker-machine create -d virtualbox --virtualbox-disk-size '40000' --virtualbox-memory '4096' devbox

También agregué un --insecure-registry al demonio para poder hablar con nuestro registro privado (si eso importa).

¿Le importaría probar desde el maestro (puede usar https://docker-machine-builds.evanhazlett.com/latest/ si no desea compilar localmente)? He probado esto con máquinas virtuales que cambian de IP y todo funciona como se esperaba:

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

Puede ver que test-vbox cambiaron de IP.

Ok, esto es lo que hice:

Detener la máquina actual
Comience a usar el nuevo contenedor de la máquina
"machine ls" con la nueva máquina estaba bien y muestra:
"devbox * virtualbox Ejecutando tcp: //192.168.99.100 : 2376
devbox2 virtualbox detenido "

"docker info" produce:
FATA [0000] Se produjo un error al intentar conectarse: Obtenga https://192.168.99.100 : 2376 / v1.16 / info: x509: el certificado es válido para 192.168.99.103, no para 192.168.99.100

Gracias. ¿Intentaste con la compilación maestra anterior? Ejecuté el mismo procedimiento que tú y no tuve ningún problema con el certificado.

Descargué ese binario "más reciente".

Mmm, ok. @sthulb, ¿puedes intentar ver si puedes reproducir esto?

• Crea una máquina virtualbox
• Detener la primera máquina
• Crear una segunda máquina virtualbox
• Iniciar la primera máquina
• Compruebe que la primera IP de la máquina haya cambiado
• Compruebe si puede acceder al demonio de la ventana acoplable en ambos

@stephenlawrence, ¿ese proceso es correcto?

Gracias

@ehazlett Técnicamente no es así como empezó. Comenzó cuando reinicié mi Mac y el DM apareció con una IP diferente al reiniciar. No sé si eso es diferente a simplemente hacer lo que usted describe. Pero ahora, cualquier intento de acceder a esa máquina que funcionaba anteriormente da como resultado el mensaje x509.

@stephenlawrence no puedo volver a crear eso ya que mi IP siempre cambia y la máquina virtual permanece. Simplemente emulé la VM obteniendo una IP diferente que debería crear lo mismo que creo. ¿Le importaría probar lo anterior con el nuevo binario y un nuevo conjunto de máquinas virtuales? Me pregunto si los certificados se crearon usando una compilación anterior que no usa el proceso correcto o algo así.

@stephenlawrence ¿Estás seguro de que no tienes algo en tu bashrc que interfiera con tu configuración, como DOCKER_CERT_PATH?

Como no vi a nadie más hacer referencia al código relevante, solo señalaré que machine está creando un certificado con la dirección IP aquí: https://github.com/docker/machine/ blob / 973b267fec3ec0a900e26557475b387891c0138a / host.go # L123

Si la dirección IP cambia, ese certificado ya no funcionará.

En los scripts de inicio b2d, hay un código que regenera los certificados del servidor si cambian las direcciones IP relevantes: https://github.com/boot2docker/boot2docker/blob/5db7efbb4e0557f6efefdb56cb0263f80ed55834/rootfs/rootfs/usr/local/etc/init.d / docker # L46

No estoy del todo seguro de por qué ese fragmento de código b2d no se activa en el caso machine ya que pensé que estaban usando el ISO b2d.

Sí, gracias, sé que este código está allí, sin embargo, cuando la IP cambió (como
se muestra arriba) no hubo problemas durante la prueba, así que estoy tratando de al menos
Consiga este reproducible para probar.

El sábado 14 de febrero de 2015 a las 12:58 a. M., Mike Dillon [email protected]
escribió:

Como no vi a nadie más hacer referencia al código relevante, solo
señalar que la máquina está creando un certificado con la dirección IP en
aquí:
https://github.com/docker/machine/blob/973b267fec3ec0a900e26557475b387891c0138a/host.go#L123

Si la dirección IP cambia, ese certificado ya no funcionará.

En los scripts de inicio b2d, hay un código que regenera el servidor
certificados si las direcciones IP relevantes cambian:
https://github.com/boot2docker/boot2docker/blob/5db7efbb4e0557f6efefdb56cb0263f80ed55834/rootfs/rootfs/usr/local/etc/init.d/docker#L46

No estoy completamente seguro de por qué ese bit de código b2d no se activa en el
caso de la máquina ya que pensé que estaban usando el ISO b2d.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/machine/issues/531#issuecomment -74363452.

@ md5 @stephenlawrence, ¿le importaría verificar si tiene algo que pudiera usar los certificados b2d por casualidad? después de la depuración, parece que los certificados b2d se están utilizando con machine.

@ehazlett No estoy seguro de lo que me estás pidiendo que revise.

@ md5 lo siento, debería haber sido más claro. verifique las variables de entorno DOCKER_CERT_PATH y DOCKER_HOST para ver si apuntan a la máquina correcta. Parece que el DOCKER_CERT_PATH puede configurarse para los certificados b2d al acceder a una máquina o viceversa.

@ehazlett si este fuera el caso de un DOCKER_CERT_PATH incorrecto, sería un error diferente. El problema en esa situación sería que ca.pem no es una raíz de confianza para el certificado presentado por el servidor Docker en la instancia controlada machine o que el certificado de cliente cert.pem no es aceptado por el servidor.

El error que estamos viendo aquí es claramente que el cliente (es decir, docker exec ) no acepta el certificado del servidor. Está intentando llegar al servidor en 192.168.99.100 , pero el servidor presenta un certificado que solo es válido por 192.168.99.103 . Esto solo puede significar que un servidor que responde en 192.168.99.100 en el puerto 2376 está configurado para usar un certificado que se creó para 192.168.99.103 .

@ md5 eso tiene sentido. ¿Cómo vuelvo a crear? como puede ver arriba, he cambiado la IP de mis instancias de virtualbox y no veo este problema.

Buena pregunta. Yo tampoco he podido reproducirlo.

Cerrando porque parece que no podemos reproducirnos. Mi sospecha es que las variables de entorno se están mezclando para la máquina virtual boot2docker y la instancia de la máquina. Recomendaría verificar su .bashrc etc. para cualquier cosa que pueda estar configurando.

Tengo este problema sucediendo nuevamente. Tenía una máquina acoplable ejecutándose en 192.168.99.101, y después de reiniciar mi Mac, esa máquina ahora se ejecuta en 192.168.99.100.

Esto parece como si fuera un problema de la ventana acoplable, ya que puedo hacer una "ejecución de la ventana acoplable-componer" en un contenedor, pero intentar cualquier comando de la ventana acoplable arroja este error:

$ docker ps
FATA [0000] Se produjo un error al intentar conectarse: Obtenga https://192.168.99.100 : 2376 / v1.17 / containers / json: x509: el certificado es válido para 192.168.99.101, no para 192.168.99.100

Env actual:
DOCKER_CERT_PATH = / Usuarios / myusername / .docker / machines / .client
DOCKER_TLS_VERIFY = sí
DOCKER_HOST = tcp: //192.168.99.100 : 2376

$ ls -l ~ / .docker / machines / .client /
total 48
-rw-r - r-- 1 myusername staff 1054 11 de febrero 10:21 ca.pem
-rw-r - r-- 1 myusername staff 1054 30 de enero 08:53 ca.pem.bak
-rw-r - r-- 1 myusername staff 1094 11 de febrero 10:21 cert.pem
-rw-r - r-- 1 myusername staff 1094 30 de enero 08:53 cert.pem.bak
-rw ------- 1 myusername staff 1675 11 de febrero 10:21 key.pem
-rw ------- 1 myusername staff 1679 30 de enero 08:53 key.pem.bak

@stephenlawrence ugh ok. ¿también usaría b2d por casualidad? la única vez que he visto esto fue algo entre b2d y machine. No puedo reproducir personalmente, pero tuvo que ver con los certificados y las vars env.

tal vez necesitemos ese comando "regenerate-certs" más temprano que tarde :)

Bueno, había estado usando b2d solo antes de cambiar a DM. DM también usa b2d, ¿no?

@stephenlawrence solo usa machine para administrar b2d . elimine su instalación y máquina virtual b2d

A mí también me ha pasado esto. Usé machine para crear la máquina virtual, no b2d directamente. Un comando para regenerar certificados suena útil.

Eliminar b2d no resuelve necesariamente mi problema, pero lo he eliminado.

Agregaría que esto está haciendo que la máquina acoplable sea inutilizable para mí en este momento. Acabo de crear una nueva máquina con la esperanza de deshacerme de ese problema, pero tengo el mismo problema en una nueva máquina.

@stephenlawrence, ¿puedes probar mi PR anterior y ver si eso resuelve el problema? debería, ya que regenerará los certificados para la instancia.

702 solucionó esto para mí: smiley: Regenerar el certificado después de que machine start funcione después de reiniciar mi Mac.

@jeffdm gracias por los comentarios!

Creo que esto sigue siendo un problema. Se me ocurren dos posibles soluciones:

• Suponga que las direcciones IP van a cambiar. ¿Necesitamos verificar la dirección IP en el protocolo de enlace TLS? ¿No podemos validar el certificado específico que tiene la máquina?
• No confíe en DHCP. ¿Quizás podamos dar direcciones IP estáticas a las VM?

Tengo un problema similar ... el cliente VPN de Cisco que estoy usando configura reglas ipfw que prácticamente bloquean la capacidad de ir a direcciones 192.168.x que están vinculadas a vboxnetN.

Así que configuré una regla de mapeo de puertos en virtualbox para que 127.0.0.1:2376 llegue al servidor Docker. El problema es que el certificado del servidor Docker es para 192.168.99.101, no para 127.0.0.1:

$ exportar DOCKER_TLS_VERIFY = ""
$ imágenes de docker
FATA [0000] Obtenga http://127.0.0.1 : 2376 / v1.17 / images / json: respuesta HTTP con formato incorrecto "\ x15 \ x03 \ x01 \ x00 \ x02 \ x02". ¿Está intentando conectarse a un demonio habilitado para TLS sin TLS?
$ export DOCKER_TLS_VERIFY = sí
$ imágenes de docker
FATA [0000] Se produjo un error al intentar conectarse: Obtenga https://127.0.0.1 : 2376 / v1.17 / images / json: x509: el certificado es válido para 192.168.99.101, no para 127.0.0.1
$ docker --tlsverify = imágenes falsas
(esto funciona)

Si bien esto no es un impedimento para el espectáculo, puedo poner "--tlsverify = false" en todos los comandos de ejecución manual, pero otras herramientas como fig no harían eso. Además, por alguna razón, DOCKER_OPTS no funciona para mí.

¿Quizás una opción al crear una instancia de virtualbox para que también haga que el certificado sea válido para otra dirección? Puedo ver que eso también es un problema si el servidor tiene una dirección IP interna y externa que se usan (por ejemplo, en ec2, pero luego usaría el nombre DNS).

@cwilkes hay / hubo un problema para permitir que se configure.

Parece que https://github.com/docker/machine/pull/702 podría ayudarme, y veo que se introdujo en el maestro hoy https://github.com/docker/machine/compare/v0.1.0 .. .Maestro . Con suerte, pronto habrá una versión 0.1.1 :)

Bien, después de discutir esto con @sthulb y @nathanleclaire , creo que deberíamos hacer una comprobación similar a la que hace b2d. Podemos inspeccionar la IP al inicio de la máquina y compararla con la IP SAN en el certificado. Si no coinciden, podemos regenerarnos. Pensamientos @sthulb @nathanleclaire ?

Convenido.

Sí, por favor @ehazlett

+1 tiene el mismo problema

También me estoy encontrando con esto. Hice girar una máquina usando el controlador AWS y luego asigné una IP elástica a la caja. Intenté detener e iniciar la máquina a través de la CLI, pero cada vez que ejecuto un docker ps después de activar el env, obtengo:

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

Intenté cambiar manualmente la IP en la configuración `~ / .docker / machine '. Eso no funcionó.

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

por favor revise # 770. esto agrega regeneración automática en caso de un error de certificado. tenga en cuenta que solo funciona con los comandos config y env , por lo que si tiene un problema con la ventana acoplable (es decir, docker ps etc.) deberá ejecutar $(docker-machine env <name>) o docker $(docker-machine config <name>) ps para arreglarlos. Ese PR también agrega la capacidad de regenerar certificados manualmente con el comando regenerate-certs (utilicé la funcionalidad de # 702).

Con suerte, esto resolverá los errores de TLS de una vez por todas :)

Detecto el cambio de IP de AWS después del reinicio normal de la instancia de aws.
docker-machine ssh amazonec2-03 solo funciona después de editar manualmente la dirección IP en /.docker/machine/machines/amazonec2-03/confg.json

Los certificados de demonio de Docker no funcionan, puedo comprobar el # 770 mañana.

PTAL @nathanleclaire @sthulb

Teniendo el mismo problema, verificaremos # 770 pronto ...

Puedes usar la cabeza actual :)

O puede usar los RC, tienen la solución.

Tuve el mismo problema, pero con la última versión de hito 0.2.0 ¡está resuelto! ¡Gracias!

@gschmutz ¡ gracias por los comentarios!

Tengo esto desde mi actualización a 1.7.0.
Reiniciar b2d dará lugar a este error:

$ 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

Gracias

@gravis ¿ boot2docker shellinit con la máquina?

Lo siento, publiqué en el repositorio incorrecto :)
Pensé que era b2d, me equivoqué con mis pestañas.

Para cualquier otra persona que se encuentre con esto, aquí hay una posible solución: https://github.com/boot2docker/boot2docker/issues/824#issuecomment -113904164
Y
https://github.com/boot2docker/boot2docker/pull/411

Hasta ahora, esto me ha solucionado el problema. Puedo ver que el archivo / var / lib / boot2docker / tls / hostnames no tiene la IP de la VM (es decir, no tiene la IP que ve cuando escribe: boot2docker ip), por lo que esto permite que se agregue ( aparece al final de la lista de nombres de host después de agregar el retraso que sugirieron).

Probé boot2docker hace algún tiempo, lo olvidé durante mucho tiempo y hoy descargué la última versión de boot2docker y la instalé. Después de la instalación, encontré este mismo problema X.509 mencionado aquí y lo resolví

1) eliminar el directorio .boot2docker (ubicado en mi directorio de inicio) y su contenido y
2) eliminar también todos los archivos de la máquina virtual boot2docker

Espero que esto ayude.

PD. Como solo probé boot2docker, no me importaba si perdía algo al eliminar esas cosas ...

Solucioné el problema de la misma manera que lo solucionó pasitolonen. Eliminando .boot2docker dir y ejecutando boot2docker init. Esto tiene el efecto secundario de eliminar mis imágenes (lo cual no me importó).

Esto me pasa cada vez que cambia el wifi. Por ejemplo, cuando lo uso desde casa y luego de nuevo en la oficina.

Error: se produjo un error al intentar conectarse: obtenga https://192.168.59.104 : 2376 / v1.19 / versión: x509: el certificado es válido para 127.0.0.1, 10.0.2.15, no para 192.168.59.104

$ versión docker
Versión del cliente: 1.7.0
Versión de API de cliente: 1.19
Go versión (cliente): go1.4.2
Git commit (cliente): 0baf609
OS / Arch (cliente): darwin / amd64

Aparentemente, esto parece resolver el problema: https://github.com/boot2docker/boot2docker/issues/938#issuecomment -118211836

alias docker="docker --tlsverify=false"

Experimenté esto después de reasignar RAM. como mencionó rajaraodv alias docker="docker --tlsverify=false" resuelto

Desactivar la seguridad ( --tlsverify=false ) nunca debería ser una solución alternativa recomendada.

Una solución alternativa que me funciona es boot2docker ssh 'sudo /etc/init.d/docker restart' , que hará que Docker genere un nuevo certificado x509 válido para boot2docker además de otras direcciones IP. Inténtelo antes de desactivar las funciones de seguridad.

La solución

@indygreg también me salvó. ¡Gracias!

gracias, también funciona para mí :-)

Hola a todos, si todavía tiene el problema del certificado con boot2docker , asegúrese de probar primero boot2docker upgrade para actualizar su VM a la última versión (1.7.1 soluciona este problema), y si hay algo más aparece un informe de los problemas en github.com/boot2docker/boot2docker-cli. Este repositorio es para problemas de la máquina Docker. ¡Gracias!

@indygreg increíble gracias

@indygreg gracias, también funciona para mí :-)

@indygreg ¡También me funcionó! Gracias.

¡Funcionó para mí, gracias!

¡Gracias @indygreg! Estoy agregando un enlace aquí al comentario para que Google pueda ver fácilmente lo que recomendó.

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

Resuelva este problema con Docker Toolbox 1.9.1 en Windows después de un reinicio que resultó en la asignación de una IP diferente a la máquina virtual, y este fue el principal éxito en Google.

Entonces, para cualquier otra persona que tenga esto, la solución actual es aún más fácil. (donde default es su máquina acoplable)

docker-machine regenerate-certs default

Gracias @johnmccabe , funcionó para mí con Docker Toolbox 1.10.0 en OS X.

Esto me pasa mucho por cambiar de wlans y usar VPN a veces. ¿Hay alguna forma de que esto se pueda automatizar? ¿O los certificados podrían ser válidos para un rango de direcciones IP?

@johnmccabe Nota, simplemente puede asegurarse de que su VM siempre comience con la misma IP: http://stackoverflow.com/a/35367277/6309

Estoy usando OS X y estoy cansado de usar estos trucos y que finalmente se rompan.

Vagrant tiene la opción de establecer la dirección IP en la configuración. No puedo entender por qué este tipo de parámetro o bandera no existe ya en docker-machine (solo comparando con vagrant porque ambos usan virtualbox)

@onnimonni : esto se ha resuelto durante mucho tiempo (casi un año). La máquina incluye un comando para regenerar certificados en caso de que cambie la ip.

Me encontré con este problema por primera vez y verifiqué todo en este hilo con cualquiera de las siguientes opciones para solucionar el problema con éxito: (elija una)

• docker-machine regenerate-certs default2
• docker-machine kill default2 luego docker-machine create default2 ...
• docker-machine upgrade default2 (si aún no se actualizó)

Para reproducir este problema en OSX:

1. Instalar Docker Toolbox (v1.10)
2. Cree una máquina default que obtenga 192.168.99.100
3. Cree una máquina default2 que obtenga 192.168.99.101
4. Apague ambos (a veces también requiere reiniciar)
5. docker-compose start default2 que obtiene 192.168.99.100 (y conflicto de certificado x509)

por lo que se reduce a que varias máquinas iniciadas en un orden diferente pueden causar una IP diferente que rompe el certificado, lo que requiere buscar en github este problema para encontrar la resolución de crear un nuevo certificado que le permita usarlos nuevamente ... para EVITAR que esto suceda? ¿Es tan inusual que la gente cambie entre varias máquinas acoplables?

$ alias docker = "docker --tlsverify = false" ¡Trabaja para mí!

@ivancarrancho ¿ docker-machine regenerate-certs -f y mantener TLS habilitado?

@nathanleclaire sí, eso es mejor que "--tlsveify" muchas muchas gracias

@nathanleclaire porque toma ~ 4 minutos ... Imagine que tiene un clúster de más de 6 nodos ... Tendré que escribir un regenerador de certificados paralelo para no pasar todo el día regenerando algunos certificados ... Además, reinicia todos contenedores Docker en la máquina de destino ...

Este requisito de regenerar certificados después de un cambio de dirección IP es un gran problema para la nube de AWS ... Las IP públicas cambian todo el tiempo. La única solución que conozco es crear nuevas instancias a partir de una instancia ec2, pero por alguna razón no funciona https://github.com/docker/machine/pull/1453#issuecomment -215371216

Por cierto, ¿alguna idea si se supone que docker-machine create --amazonec2-use-private-address debe crear una instancia ec2 a partir de otra instancia ec2?

Esta es la única forma que conozco de cómo evitar la regeneración constante de certificados ...

Por cierto, ¿alguna idea si docker-machine create --amazonec2-use-private-address debe crear una instancia ec2 a partir de otra instancia ec2?

Sí, a menos que haya alguna otra forma de acceder a la IP privada desde el nodo de creación (por ejemplo, proxy).

Estamos considerando una variedad de soluciones, por ejemplo, Elastic IP, para resolver potencialmente este problema.

sí, pero como mencioné, se cuelga del acceso ssh incluso con esta opción
habilitado
El 2 de mayo de 2016 a las 20:26, "Nathan LeClaire" [email protected] escribió:

Por cierto, cualquier idea si la máquina docker crea --amazonec2-use-private-address es
se supone que debe crear una instancia ec2 a partir de otra instancia ec2?

Sí, a menos que haya alguna otra forma de acceder a la IP privada desde
el nodo de creación (por ejemplo, proxy).

Estamos considerando una variedad de soluciones, por ejemplo, Elastic IP, para potencialmente
resolver este problema.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/machine/issues/531#issuecomment -216319103

¿Quizás el grupo de seguridad no está configurado correctamente? Actualmente, si usa --amazonec2-use-private-ip-address , se supone que el usuario está dispuesto a asegurarse de que este tipo de detalles de acceso a la red se configuren correctamente de antemano.

No entiendo por qué tengo que ejecutar esa declaración $ eval fea cada vez que se debe iniciar Docker a través de una terminal.

No entiendo por qué existe este problema.

Docker se parece cada vez más a un producto horriblemente roto que mucha gente aceptó porque estaba de moda.

Estoy usando la última versión de docker y docker-machine , y todavía tengo el mismo problema, creé varios host de docker virtualbox por

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

y casi cada vez que reinicio las máquinas virtuales o reinicio mi Mac, enfrentaré el error como certificate is valid for 192.168.99.100, not 192.168.99.101 .

Mis versiones son:

$ 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 alguna solución para evitar que ocurran esos errores? o crear un host virtualbox con una IP fija?

Solución alternativa: docker-machine provision .

Se solucionó el problema por 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

Siguiendo el enlace de @VonC me encontré con docker-machine-ipconfig https://github.com/fivestars/docker-machine-ipconfig

 $ cd ~ / .docker /
 $ git clon https://github.com/fivestars/docker-machine-ipconfig.git
 # Agregar a ~ / .profile
 $ echo 'alias docker-machine-ipconfig = ~ / .docker / docker-machine-ipconfig / docker-machine-ipconfig' >> ~ / .profile 
 $ fuente ~ / .profile

Por ejemplo: asignar nombre de máquina a una IP estática:

 $ docker-machine-ipconfig estático nombre-máquina
 # o especificar IP implícita
 $ docker-machine-ipconfig estático nombre de máquina 192.168.99.110

Esto elimina la necesidad de docker-machine regenerate-certs -f machine-name en cada reinicio. Una manera fácil de configurar la IP estática de la máquina que se ejecuta en virtualbox.

¿Es compatible con Windows? Me refiero a "para" y "en".

parece que todavía es un problema. ¿Alguna manera de arreglarlo?

@johnmccabe ,
Gracias.
funciona bien. Acabo de reiniciar mi caja de herramientas y todo está de vuelta en el juego.

¿Cómo puedo tener una cuenta estática del contenedor, me permite cambiar la cuenta cada vez que reinicio la máquina acoplable?

Veo la solución con docker-machine-ipconfig pero solo por el bien de la documentación, estoy informando que esto sucede con Windows 10 Docker Machine e Hyper-V también

Es posible que desee modificar este mensaje "Las máquinas iniciadas pueden tener nuevas direcciones IP. Es posible que deba volver a ejecutar el comando docker-machine env ". para mencionar algo como "y también hacer docker-machine regenerate-certs ..." FWIW ...

@rdp nice catch, tuve este problema fue media hora mirando lo que había pasado, y después de intentar hacer algunas cosas con kubernetes, instalando y desinstalando cosas ... corriendo
docker-machine env
la IP coincidente en mis envs coincidió con la que estaba produciendo el error con el certificado ...
luego:
eval $(docker-machine env)
hacer la configuración en su lugar para mí ...

minikube stop && minikube start arregló esto por mí

minikube stop && minikube start arregló esto por mí

@PatMyron ¡ Sorprendentemente, esto también funcionó para mí!