Você pode dar mais detalhes sobre o assunto?

• Qual versão do Machine?
• Qual driver (estou assumindo vbox com base no IP)?
• Linha de comando usada para criar máquina

obrigado

docker-machine versão 0.1.0
caixa virtual
docker-machine create -d virtualbox --virtualbox-disk-size '40000' --virtualbox-memory '4096' devbox

Eu também adicionei um --insecure-registry ao daemon para que eu pudesse falar com nosso registro privado (se isso for importante).

Você se importaria de testar a partir do mestre (você pode usar https://docker-machine-builds.evanhazlett.com/latest/ se não quiser construir localmente). Eu testei isso com VMs mudando IPs e tudo funciona conforme o esperado:

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

Você pode ver que test-vbox trocou IPs.

Ok, aqui está o que eu fiz:

Pare a máquina atual
Comece a usar a nova caixa da máquina
"machine ls" com a nova máquina estava ok e mostra:
"devbox * virtualbox Running tcp: //192.168.99.100 : 2376
devbox2 virtualbox parado "

"docker info" produz:
FATA [0000] Ocorreu um erro ao tentar conectar: ​​Obtenha https://192.168.99.100 : 2376 / v1.16 / info: x509: o certificado é válido para 192.168.99.103, não 192.168.99.100

obrigado. você tentou com a compilação principal acima? Executei o mesmo procedimento que você fez e não tive nenhum problema de certificação.

Eu baixei aquele binário "mais recente".

Hmm ok. @sthulb você pode tentar ver se consegue reproduzir isso?

• Crie uma máquina virtualbox
• Pare a primeira máquina
• Crie uma segunda máquina virtualbox
• Comece a primeira máquina
• Verifique se o primeiro IP da máquina mudou
• Verifique se você pode acessar o docker daemon em ambos

@stephenlawrence esse processo está correto?

obrigado

@ehazlett Tecnicamente não foi assim que começou. Tudo começou quando reiniciei meu Mac e o DM apareceu com um IP diferente na reinicialização. Não sei se isso é diferente de apenas fazer o que você descreve. Mas agora, qualquer tentativa de acessar aquela máquina que funcionava anteriormente resulta na mensagem x509.

@stephenlawrence Não posso recriar isso, pois meu IP sempre muda e a VM permanece. Eu simplesmente emulei a VM obtendo um IP diferente que deve criar a mesma coisa que acredito. Você se importaria de tentar o procedimento acima com o novo binário e um novo conjunto de VMs? Estou me perguntando se os certificados foram criados usando uma compilação antiga não usando o processo correto ou algo assim.

@stephenlawrence Tem certeza de que não há algo em seu bashrc que esteja bagunçando suas configurações, como DOCKER_CERT_PATH?

Já que não vi ninguém referenciar o código relevante, vou apenas apontar que machine está criando um certificado com o endereço IP aqui: https://github.com/docker/machine/ blob / 973b267fec3ec0a900e26557475b387891c0138a / host.go # L123

Se o endereço IP mudar, esse certificado não funcionará mais.

Nos scripts b2d init, há um código que regenera os certificados do servidor se os endereços IP relevantes forem alterados: https://github.com/boot2docker/boot2docker/blob/5db7efbb4e0557f6efefdb56cb0263f80ed55834/rootfs/rootfs/usr/local/etc/init.d / docker # L46

Não estou totalmente certo de por que aquele pedaço de código b2d não é acionado no caso machine , pois pensei que vocês estavam usando ISO b2d.

Sim, obrigado, eu sei que este código está lá, no entanto, quando o IP mudou (como
mostrado acima) não houve problemas durante o teste, então estou tentando pelo menos
obtenha este reproduzível para teste.

No sábado, 14 de fevereiro de 2015 às 12h58, Mike Dillon [email protected]
escrevi:

Como não vi ninguém referindo o código relevante, vou apenas
apontar que a máquina está criando um certificado com o endereço IP em
aqui:
https://github.com/docker/machine/blob/973b267fec3ec0a900e26557475b387891c0138a/host.go#L123

Se o endereço IP mudar, esse certificado não funcionará mais.

Nos scripts de inicialização b2d, há um código que regenera o servidor
certificados se os endereços IP relevantes mudarem:
https://github.com/boot2docker/boot2docker/blob/5db7efbb4e0557f6efefdb56cb0263f80ed55834/rootfs/rootfs/usr/local/etc/init.d/docker#L46

Não tenho certeza de por que esse pedaço de código b2d não é acionado no
caso da máquina já que pensei que vocês estavam usando o ISO b2d.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/machine/issues/531#issuecomment -74363452.

@ md5 @stephenlawrence , você se importaria de verificar se há algo que possa estar usando os certificados b2d por acaso? após a depuração, parece que os certificados b2d estão sendo usados ​​com a máquina.

@ehazlett Não tenho certeza do que você está me pedindo para verificar.

@ md5 desculpe, eu deveria ter sido mais claro. verifique as variáveis ​​de ambiente DOCKER_CERT_PATH e DOCKER_HOST para ver se elas estão apontadas para a máquina correta. Parece que DOCKER_CERT_PATH pode ser configurado para certificados b2d ao acessar uma máquina ou vice-versa.

@ehazlett se este fosse um caso de DOCKER_CERT_PATH incorreto, seria um erro diferente. O problema nessa situação seria que ca.pem não é uma raiz confiável para o certificado apresentado pelo servidor Docker na instância controlada de machine ou que o certificado de cliente cert.pem não é aceito pelo servidor.

O erro que estamos vendo aqui é claramente que o cliente (ou seja, docker exec ) não está aceitando o certificado do servidor. Ele está tentando acessar o servidor em 192.168.99.100 , mas o servidor está apresentando um certificado que é válido apenas para 192.168.99.103 . Isso só pode significar que um servidor que está respondendo em 192.168.99.100 na porta 2376 está configurado para usar um certificado que foi criado para 192.168.99.103 .

@ md5 isso faz sentido. como faço para recriar? como você pode ver acima, mudei o IP das minhas instâncias do virtualbox e não vejo esse problema.

Esta é uma boa pergunta. Eu também não fui capaz de reproduzi-lo.

Fechando como não conseguimos reproduzir. Minha suspeita é que as variáveis ​​de ambiente estão se misturando para a VM boot2docker e a instância da máquina. Eu recomendaria verificar seu .bashrc etc para qualquer coisa que possa estar configurando-os.

Eu tenho esse problema acontecendo novamente. Eu tinha uma docker-machine rodando em 192.168.99.101 e, depois de reiniciar meu Mac, essa máquina agora está rodando em 192.168.99.100.

Parece que é um problema do docker, já que posso fazer "docker-compose run" em um contêiner OK, mas tentar qualquer comando do docker gera este erro:

$ docker ps
FATA [0000] Ocorreu um erro ao tentar conectar: ​​Obtenha https://192.168.99.100 : 2376 / v1.17 / containers / json: x509: o certificado é válido para 192.168.99.101, não 192.168.99.100

Env atual:
DOCKER_CERT_PATH = / Users / myusername / .docker / machines / .client
DOCKER_TLS_VERIFY = sim
DOCKER_HOST = tcp: //192.168.99.100 : 2376

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

@stephenlawrence ugh ok. você usaria b2d por acaso? a única vez que vi isso foi algo entre b2d e máquina. Não posso reproduzir pessoalmente, mas tinha a ver com os certs e env vars.

talvez precisemos do comando "regenerate-certs" mais cedo ou mais tarde :)

Bem, eu estava usando o b2d sozinho antes de mudar para o DM. DM usa b2d também não?

@stephenlawrence apenas use machine para gerenciar b2d . exclua sua instalação original de b2d e VM

Isso também aconteceu comigo. Usei machine para criar a máquina virtual, não b2d diretamente. Um comando para regenerar certificados parece útil.

Remover b2d não resolve necessariamente meu problema, mas eu o removi.

Eu acrescentaria que isso está tornando a docker-machine inutilizável para mim no momento. Acabei de criar uma nova máquina na esperança de me livrar desse problema, mas tenho o mesmo problema em uma nova máquina.

@stephenlawrence você pode tentar meu PR acima e ver se isso resolve o problema? deve, pois irá regenerar os certificados para a instância.

702 corrigiu isso para mim: smiley: Gerar novamente o certificado após machine start funcionar depois de reiniciar meu Mac.

@jeffdm thx pelo feedback!

Acho que isso ainda é um problema. Posso pensar em duas soluções:

• Suponha que os endereços IP vão mudar. Precisamos verificar o endereço IP no handshake TLS? Não podemos validar o certificado específico que a máquina possui?
• Não confie no DHCP. Talvez possamos dar IPs estáticos às VMs?

Estou tendo um problema semelhante ... o cliente VPN da Cisco que estou usando configura regras de ipfw que praticamente bloqueiam a capacidade de acessar endereços 192.168.x vinculados a vboxnetN.

Portanto, configurei uma regra de mapeamento de porta no virtualbox para que 127.0.0.1:2376 acesse o servidor docker. O problema é que o certificado do servidor docker é para 192.168.99.101 e não 127.0.0.1:

$ export DOCKER_TLS_VERIFY = ""
imagens de $ docker
FATA [0000] Obtenha http://127.0.0.1 : 2376 / v1.17 / images / json: resposta HTTP malformada "\ x15 \ x03 \ x01 \ x00 \ x02 \ x02". Você está tentando se conectar a um daemon habilitado para TLS sem TLS?
$ export DOCKER_TLS_VERIFY = sim
imagens de $ docker
FATA [0000] Ocorreu um erro ao tentar conectar: ​​Get https://127.0.0.1 : 2376 / v1.17 / images / json: x509: o certificado é válido para 192.168.99.101, não 127.0.0.1
$ docker --tlsverify = imagens falsas
(isso funciona)

Embora isso não seja um obstáculo, eu posso colocar "--tlsverify = false" em todos os meus comandos de execução manual, mas outras ferramentas como o fig não fariam isso. Além disso, por algum motivo, DOCKER_OPTS não funciona para mim.

Talvez uma opção ao criar uma instância do virtualbox também torne o certificado válido para outro endereço? Também posso ver que isso é um problema se o servidor tiver um endereço IP interno e um externo que são usados ​​(por exemplo, em ec2, mas então eu usaria o nome DNS).

@cwilkes, existe / houve um problema para permitir que isso seja configurado.

Parece que https://github.com/docker/machine/pull/702 pode me ajudar, e vejo que foi colocado no mestre hoje https://github.com/docker/machine/compare/v0.1.0 .. .mestre . Esperançosamente haverá uma versão 0.1.1 em breve :)

Ok, depois de discutir isso com @sthulb e @nathanleclaire , acho que devemos fazer uma verificação semelhante ao que o b2d faz. Podemos inspecionar o IP no início da máquina e compará-lo com o IP SAN no certificado. Se eles não corresponderem, podemos regenerar. Pensamentos @sthulb @nathanleclaire ?

Acordado.

Sim por favor @ehazlett

+1 tendo o mesmo problema

Eu estou correndo para isso também. Girei uma máquina usando o driver AWS e atribuí um Elastic IP à caixa. Tentei parar e iniciar a máquina por meio da CLI, mas sempre que executo docker ps após ativar o env, recebo:

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

Eu tentei alterar manualmente o IP na configuração `~ / .docker / machine '. Isso não funcionou.

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

por favor, verifique # 770. isso adiciona regeneração automática no caso de um erro de certificado. note que ele só funciona com os comandos config e env então se você tiver um problema com o docker (ou seja, docker ps etc), você precisará executar $(docker-machine env <name>) ou docker $(docker-machine config <name>) ps para consertá-los. Esse PR também adiciona a capacidade de regenerar certificados manualmente com o comando regenerate-certs (usei a funcionalidade de # 702).

Esperamos que isso resolva os erros de TLS de uma vez por todas :)

Detecto a mudança de IP da AWS após a reinicialização normal da instância do aws.
docker-machine ssh amazonec2-03 só funciona depois de editar manualmente o endereço IP em /.docker/machine/machines/amazonec2-03/confg.json

Certs do daemon do docker não funcionam, posso verificar o # 770 amanhã.

PTAL @nathanleclaire @sthulb

Tendo o mesmo problema, iremos verificar # 770 em breve ...

Você pode usar o cabeçote atual :)

Ou você pode usar os RCs - eles têm a solução.

tive o mesmo problema, mas com a última versão do milestone 0.2.0 está resolvido! Obrigado!

@gschmutz, obrigado pelo feedback!

Estou tendo isso desde minha atualização para 1.7.0.
Reiniciar o b2d levará a este erro:

$ 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

obrigado

@gravis Por que você está usando boot2docker shellinit com a máquina?

Desculpe, postei no repositório errado :)
Achei que fosse b2d, baguncei minhas guias.

Para qualquer pessoa que se depare com isso, aqui está uma solução possível: https://github.com/boot2docker/boot2docker/issues/824#issuecomment -113904164
E
https://github.com/boot2docker/boot2docker/pull/411

Até agora, isso corrigiu o problema para mim. Eu posso ver que o arquivo / var / lib / boot2docker / tls / hostnames não tem o IP da VM (ou seja, não tem o IP que você vê ao digitar: boot2docker ip), então isso permite que seja adicionado (ele aparece no final da lista de nomes de host após adicionar o atraso sugerido).

Eu testei o boot2docker há algum tempo, esqueci por muito tempo e hoje baixei a última versão do boot2docker e instalei. Após a instalação, encontrei o mesmo problema do X.509 mencionado aqui e resolvi

1) remover o diretório .boot2docker (localizado no meu diretório inicial) e seu conteúdo e
2) remover todos os arquivos da máquina virtual boot2docker também

Espero que isto ajude.

ps. Como só testei o boot2docker, não me importei se perdesse algo ao deletar esse material ...

Corrigi o problema da mesma forma que o pasitolonen o corrigiu. Excluindo o diretório .boot2docker e executando o boot2docker init. Isso tem o efeito colateral de excluir minhas imagens (o que eu não me importei).

Isso acontece comigo sempre que o wi-fi muda. Por exemplo, quando eu uso em casa e novamente no escritório.

Erro: ocorreu um erro ao tentar conectar-se: obtenha https://192.168.59.104 : 2376 / v1.19 / versão: x509: o certificado é válido para 127.0.0.1, 10.0.2.15, não 192.168.59.104

versão $ docker
Versão do cliente: 1.7.0
Versão da API do cliente: 1.19
Versão Go (cliente): go1.4.2
Git commit (cliente): 0baf609
OS / Arch (cliente): darwin / amd64

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

alias docker="docker --tlsverify=false"

Eu experimentei isso depois de realocar a RAM. como rajaraodv metnioned alias docker="docker --tlsverify=false" resolvido

Desativar a segurança ( --tlsverify=false ) nunca deve ser uma solução alternativa recomendada.

Uma solução alternativa que funciona para mim é boot2docker ssh 'sudo /etc/init.d/docker restart' , que fará com que o Docker gere um novo certificado x509 válido para boot2docker além de outros endereços IP. Por favor, tente isso antes de desligar os recursos de segurança.

A solução

@indygreg também me salvou. obrigado!

obrigado, funciona para mim também :-)

Olá a todos, se você ainda está encontrando o problema de certificação com boot2docker , certifique-se de primeiro tentar boot2docker upgrade para atualizar sua VM para a última (1.7.1 corrige esse problema) e, se mais alguma coisa aparece relatar os problemas em github.com/boot2docker/boot2docker-cli. Este repo é para problemas da máquina Docker. Obrigado!

@indygreg incrível thx

@indygreg obrigado, também funciona para mim :-)

@indygreg funcionou para mim também! Obrigado.

Funcionou para mim, obrigado!

Obrigado @indygreg! Estou adicionando um link aqui para o comentário para que o googler possa ver facilmente o que ele recomendou.

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

Atingiu esse problema com o Docker Toolbox 1.9.1 no Windows após uma reinicialização, resultando na alocação de um IP diferente para a VM, e este foi o principal hit no google.

Portanto, para qualquer outra pessoa que acertar isso, a correção atual é ainda mais fácil. (onde default é sua máquina docker)

docker-machine regenerate-certs default

Obrigado @johnmccabe , trabalhou para mim com Docker Toolbox 1.10.0 no OS X.

Isso acontece muito comigo por causa da troca de wlans e uso de VPN às vezes. Existe uma maneira que isso poderia ser automatizado? Ou os certificados poderiam ser válidos para uma variedade de endereços IP?

@johnmccabe Observação, você pode simplesmente garantir que sua VM sempre comece com o mesmo IP: http://stackoverflow.com/a/35367277/6309

Estou usando o OS X e cansado de usar esses hacks e tê-los quebrado eventualmente.

O Vagrant tem a opção de definir o endereço IP na configuração. Não consigo entender porque esse tipo de parâmetro ou sinalizador ainda não existe no docker-machine (apenas comparando com o vagrant porque ambos usam o virtualbox)

@onnimonni : isso está resolvido há muito, muito tempo (quase um ano). A máquina inclui um comando para regenerar certificados caso o ip mude.

Acabei de encontrar esse problema pela primeira vez e verifiquei tudo neste tópico com qualquer uma das seguintes opções, corrigindo o problema com êxito: (escolha uma)

• docker-machine regenerate-certs default2
• docker-machine kill default2 depois docker-machine create default2 ...
• docker-machine upgrade default2 (se ainda não tiver feito upgrade)

Para reproduzir este problema no OSX:

1. Instale o Docker Toolbox (v1.10)
2. Crie uma máquina default que obtém 192.168.99.100
3. Crie uma máquina default2 que obtém 192.168.99.101
4. Desligue ambos (às vezes requer uma reinicialização também)
5. docker-compose start default2 que obtém 192.168.99.100 (e conflito de certificado x509)

então se trata de várias máquinas iniciadas em ordem diferente pode causar um IP diferente que quebra o certificado que requer pesquisar no github para este problema para encontrar a resolução de criar um novo certificado para permitir que você os use novamente ... há uma maneira EVITAR que isso aconteça? é tão incomum que as pessoas alternem entre várias máquinas docker?

$ alias docker = "docker --tlsverify = false" Trabalhe para mim!

@ivancarrancho Por que não docker-machine regenerate-certs -f e manter o TLS ativado?

@nathanleclaire sim, isso é melhor do que "--tlsveify" muito obrigado

@nathanleclaire porque leva ~ 4 minutos ... Imagine que você tem um cluster de 6+ nós ... Terei que escrever um regenerador de certificado paralelo para não passar o dia inteiro regenerando alguns certificados ... Além disso, ele reinicia todos contêineres docker na máquina de destino ...

Esse requisito para regenerar certificados após a alteração do endereço IP é uma grande dor na nuvem aws ... IPs públicos mudam o tempo todo. A única solução que conheço é a criação de novas instâncias de uma instância ec2, mas por algum motivo não funciona https://github.com/docker/machine/pull/1453#issuecomment -215371216

A propósito, alguma idéia se docker-machine create --amazonec2-use-private-address deve criar uma instância ec2 de outra instância ec2?

Esta é a única maneira que conheço de como evitar a regeneração constante de certificados ...

A propósito, alguma ideia se docker-machine create --amazonec2-use-private-address deve criar uma instância ec2 de outra instância ec2?

Sim, a menos que haja outra maneira de acessar o IP privado a partir do nó de criação (por exemplo, proxy).

Estamos considerando uma variedade de soluções, por exemplo, Elastic IP, para potencialmente resolver esse problema.

sim, mas como mencionei, ele está travando no acesso ssh mesmo com essa opção
ativado
Em 2 de maio de 2016 20:26, "Nathan LeClaire" [email protected] escreveu:

Qualquer ideia se docker-machine create --amazonec2-use-private-address é
deveria criar uma instância ec2 de outra instância ec2?

Sim, a menos que haja alguma outra maneira de acessar o IP privado de
o nó de criação (por exemplo, proxy).

Estamos considerando uma variedade de soluções, por exemplo, Elastic IP, para potencialmente
resolver este problema.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/machine/issues/531#issuecomment -216319103

Talvez o grupo de segurança não esteja configurado corretamente? Atualmente, se estiver usando --amazonec2-use-private-ip-address , presume-se que o usuário deseja garantir que esses tipos de detalhes de acesso à rede sejam configurados adequadamente de antemão.

Não entendo por que tenho que executar aquela instrução $ eval feia sempre que o docker precisa ser iniciado por meio de um terminal.

Eu não entendo por que esse problema ainda existe.

O Docker está parecendo cada vez mais com um produto horrivelmente quebrado que muitas pessoas ficaram para trás porque era a coisa "na moda".

Estou usando a versão mais recente de docker e docker-machine e ainda tenho o mesmo problema, criei vários host docker virtualbox por

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

e quase toda vez que eu reinicio as VMs ou reinicio meu Mac, vou enfrentar o erro como certificate is valid for 192.168.99.100, not 192.168.99.101 .

Minhas versões são:

$ 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 alguma solução para evitar que esses erros aconteçam? ou criar um host virtualbox com um IP fixo?

Solução alternativa: docker-machine provision .

O problema foi corrigido 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

Seguindo o link de @VonC, encontrei docker-machine-ipconfig https://github.com/fivestars/docker-machine-ipconfig

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

Ex: Atribua o nome da máquina a um IP estático:

 $ docker-machine-ipconfig static machine-name
 # ou especifique IP implícito
 $ docker-machine-ipconfig static machine-name 192.168.99.110

Isso elimina a necessidade de docker-machine regenerate-certs -f machine-name em cada reinicialização. Uma maneira fácil de definir o IP estático da máquina em execução no virtualbox.

Suporta Windows? Quero dizer tanto "para" quanto "ligado".

parece que ainda é um problema. alguma maneira de consertar isso?

@johnmccabe ,
obrigado.
funciona bem. Acabei de reiniciar minha caixa de ferramentas e tudo está de volta ao jogo.

como posso ter uma conta estática do contêiner, isso me permite alterar a conta toda vez que reiniciar a docker-machine?

Vejo a solução alternativa com docker-machine-ipconfig mas apenas para fins de documentação, estou relatando que isso também acontece com o Windows 10 Docker Machine e o Hyper-V

Pode querer ajustar esta mensagem "Máquinas iniciadas podem ter novos endereços IP. Você pode precisar executar novamente o comando docker-machine env ." para mencionar algo como "e também fazer docker-machine regenerate-certs ..." FWIW ...

@rdp nice catch, tive esse problema em meia hora olhando o que tinha acontecido, e depois de tentar fazer algumas coisas com o kubernetes, instalando e desinstalando coisas ... executando
docker-machine env
o IP correspondido em meus envs correspondia ao que estava produzindo o erro com o certificado ...
então:
eval $(docker-machine env)
faça a configuração no lugar para mim ...

minikube stop && minikube start consertou isso para mim

minikube stop && minikube start consertou isso para mim

@PatMyron Surpreendentemente, isso funcionou para mim também!