Не могли бы вы подробнее рассказать о проблеме?

• Какая версия машины?
• Какой драйвер (я предполагаю, что vbox на основе IP)?
• Командная строка, используемая для создания машины

благодаря

докер-машина версии 0.1.0
виртуальный бокс
docker-machine create -d virtualbox --virtualbox-disk-size '40000' --virtualbox-memory '4096' devbox

Я также добавил --insecure-registry к демону, чтобы я мог общаться с нашим частным реестром (если это имеет значение).

Не могли бы вы протестировать с мастера (вы можете использовать https://docker-machine-builds.evanhazlett.com/latest/, если не хотите собирать локально). Я тестировал это с виртуальными машинами, меняющими IP-адреса, и все работает, как ожидалось:

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

Вы можете видеть, что test-vbox переключили IP-адреса.

Хорошо, вот что я сделал:

Остановить текущую машину
Начните использовать новую корзину для машины
"machine ls" с новой машиной было в порядке и показывает:
"devbox * virtualbox Запуск tcp: //192.168.99.100 : 2376
devbox2 virtualbox остановлен "

"docker info" производит:
FATA [0000] Произошла ошибка при попытке подключения: Получите https://192.168.99.100 : 2376 / v1.16 / info: x509: сертификат действителен для 192.168.99.103, а не 192.168.99.100

Благодарю. вы пробовали с основной сборкой выше? Я выполнил ту же процедуру, что и вы, и у меня не было проблем с сертификатами.

Я скачал этот "последний" двоичный файл.

Хмм хорошо. @sthulb, можешь попробовать воспроизвести это?

• Создайте машину virtualbox
• Остановить первую машину
• Создать вторую виртуальную машину
• Запустить первую машину
• Убедитесь, что IP-адрес первой машины изменился
• Проверьте, можете ли вы получить доступ к демону докера на обоих

@stephenlawrence, это правильный процесс?

благодаря

@ehazlett Технически это началось не так. Это началось, когда я перезагрузил свой Mac, и DM при перезагрузке получил другой IP-адрес. Я не знаю, отличается ли это от простого выполнения того, что вы описываете. Но теперь любые попытки доступа к этой ранее работающей машине приводят к сообщению x509.

@stephenlawrence Я не могу воссоздать это, поскольку мой IP-адрес всегда меняется, а виртуальная машина остается. Я просто эмулировал виртуальную машину, получающую другой IP-адрес, который, как я считаю, должен создать то же самое. Не могли бы вы попробовать описанное выше с новым двоичным кодом и новым набором виртуальных машин? Мне интересно, были ли сертификаты созданы с использованием старой сборки, не использующей правильный процесс или что-то в этом роде.

@stephenlawrence Вы уверены, что в вашем bashrc нет чего-то, что мешает вашим настройкам, например DOCKER_CERT_PATH?

Поскольку я не видел, чтобы кто-то еще ссылался на соответствующий код, я просто укажу, что machine создает сертификат с IP-адресом в нем: https://github.com/docker/machine/ blob / 973b267fec3ec0a900e26557475b387891c0138a / host.go # L123

Если IP-адрес изменится, этот сертификат больше не будет работать.

В сценариях инициализации b2d есть код, который восстанавливает сертификаты сервера при изменении соответствующих IP-адресов: https://github.com/boot2docker/boot2docker/blob/5db7efbb4e0557f6efefdb56cb0263f80ed55834/rootfs/rootfs/uscr/inital/ / докер # L46

Я не совсем уверен, почему этот фрагмент кода b2d не запускается в случае machine поскольку я думал, что вы, ребята, используете ISO b2d.

Да, спасибо, но я знаю, что этот код есть, когда IP изменился (как
показано выше) при тестировании проблем не было, поэтому я пытаюсь хотя бы
получить этот воспроизводимый материал для тестирования.

В субботу, 14 февраля 2015 г., в 00:58, Майк Диллон [email protected]
написал:

Поскольку я не видел, чтобы кто-нибудь еще ссылался на соответствующий код, я просто
укажите, что машина создает сертификат с IP-адресом в
это здесь:
https://github.com/docker/machine/blob/973b267fec3ec0a900e26557475b387891c0138a/host.go#L123

Если IP-адрес изменится, этот сертификат больше не будет работать.

В скриптах инициализации b2d есть код, регенерирующий сервер
сертификаты при изменении соответствующих IP-адресов:
https://github.com/boot2docker/boot2docker/blob/5db7efbb4e0557f6efefdb56cb0263f80ed55834/rootfs/rootfs/usr/local/etc/init.d/docker#L46

Я не совсем уверен, почему этот фрагмент кода b2d не запускается в
machine case, так как я думал, что вы, ребята, используете ISO b2d.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/machine/issues/531#issuecomment -74363452.

@ md5 @stephenlawrence Не могли бы вы проверить, есть ли у вас что-нибудь, что могло бы случайно использовать сертификаты b2d? после отладки похоже, что сертификаты b2d используются с машиной.

@ehazlett Я не уверен, что вы просите меня проверить.

@ md5 извини, я должен был быть более ясным. проверьте переменные среды DOCKER_CERT_PATH и DOCKER_HOST чтобы убедиться, что они указывают на правильный компьютер. Похоже, что DOCKER_CERT_PATH можно настроить на сертификаты b2d при доступе к машине или наоборот.

@ehazlett, если бы это был случай неправильного DOCKER_CERT_PATH , это была бы другая ошибка. Проблема в этой ситуации может заключаться либо в том, что ca.pem не является доверительным корнем для сертификата, представленного сервером Docker на управляемом machine экземпляре, либо в том, что сертификат клиента cert.pem не принимается сервером.

Ошибка, которую мы здесь видим, явно заключается в том, что клиент (т.е. docker exec ) не принимает сертификат сервера. Он пытается попасть на сервер по адресу 192.168.99.100 , но сервер представляет сертификат, действительный только для 192.168.99.103 . Это может означать только то, что сервер, который отвечает по адресу 192.168.99.100 на порту 2376 , настроен на использование сертификата, созданного для 192.168.99.103 .

@ md5, что имеет смысл. как мне воссоздать? как вы можете видеть выше, я изменил IP-адреса своих экземпляров виртуальных ящиков и не вижу этой проблемы.

Это хороший вопрос. Сам я тоже не смог воспроизвести это.

Закрытие, поскольку мы не можем воспроизвести. Я подозреваю, что переменные среды для виртуальной машины boot2docker и экземпляра машины смешиваются. Я бы рекомендовал проверить ваши .bashrc т. Д. На предмет того, что может их устанавливать.

У меня снова возникает эта проблема. У меня была докер-машина, работающая на 192.168.99.101, и после перезагрузки моего Mac эта машина теперь работает на 192.168.99.100.

Похоже, это проблема с докером, поскольку я могу выполнить "запуск docker-compose" в контейнере ОК, но попытка любой команды докера вызывает эту ошибку:

$ docker ps
FATA [0000] Произошла ошибка при попытке подключения: Получите https://192.168.99.100 : 2376 / v1.17 / container / json: x509: сертификат действителен для 192.168.99.101, а не 192.168.99.100

Текущее окружение:
DOCKER_CERT_PATH = / Пользователи / myusername / .docker / machines / .client
DOCKER_TLS_VERIFY = да
DOCKER_HOST = tcp: //192.168.99.100 : 2376

$ ls -l ~ / .docker / машины / .client /
всего 48
-rw-r - r-- 1 myusername staff 1054 11 фев, 10:21 ca.pem
-rw-r - r-- 1 myusername staff 1054 30 января 08:53 ca.pem.bak
-rw-r - r-- 1 myusername staff 1094 11 фев, 10:21 cert.pem
-rw-r - r-- 1 myusername staff 1094 30 января 08:53 cert.pem.bak
-rw ------- 1 myusername Staff 1675 11 фев, 10:21 key.pem
-rw ------- 1 myusername staff 1679 30 января 08:53 key.pem.bak

@stephenlawrence тьфу, ок. вы бы случайно использовали и b2d? единственный раз, когда я видел, что это было что-то среднее между b2d и машиной. Я не могу лично воспроизвести, но это было связано с сертификатами и env vars.

может быть, нам нужна эта команда "восстановить-сертификаты" раньше, чем позже :)

Ну, я использовал только b2d до того, как переключился на DM. DM тоже использует b2d, нет?

@stephenlawrence просто использует machine для управления b2d . удалите исходную установку b2d и виртуальную машину

Со мной такое тоже случалось. Я использовал machine для создания виртуальной машины, а не b2d напрямую. Команда для восстановления сертификатов кажется полезной.

Удаление b2d не обязательно решает мою проблему, но я удалил ее.

Я бы добавил, что в настоящий момент это делает докер-машину для меня непригодной. Я только что создал новую машину, надеясь избавиться от этой проблемы, но у меня такая же проблема на новой машине.

@stephenlawrence, можете ли вы попробовать мой PR выше и посмотреть, решит ли это проблему? он должен, поскольку он будет регенерировать сертификаты для экземпляра.

702 исправил это для меня: smiley: Повторное создание сертификата после того, как machine start работает после перезагрузки Mac.

@jeffdm спасибо за отзыв!

Я думаю, это все еще проблема. Я могу придумать два возможных решения:

• Предположим, что IP-адреса изменятся. Нужно ли нам проверять IP-адрес в рукопожатии TLS? Разве мы не можем проверить конкретный сертификат, который есть на машине?
• Не полагайтесь на DHCP. Возможно, мы можем дать виртуальным машинам статические IP-адреса?

У меня аналогичная проблема ... Клиент Cisco VPN, который я использую, устанавливает правила ipfw, которые в значительной степени блокируют возможность перехода на адреса 192.168.x, привязанные к vboxnetN.

Поэтому я устанавливаю правило сопоставления портов в виртуальном боксе, чтобы 127.0.0.1:2376 попадало на сервер докеров. Проблема в том, что сертификат докер-сервера предназначен для 192.168.99.101, а не для 127.0.0.1:

$ export DOCKER_TLS_VERIFY = ""
$ docker images
FATA [0000] Получить http://127.0.0.1 : 2376 / v1.17 / images / json: неверный HTTP-ответ «\ x15 \ x03 \ x01 \ x00 \ x02 \ x02». Вы пытаетесь подключиться к демону с поддержкой TLS без TLS?
$ export DOCKER_TLS_VERIFY = да
$ docker images
FATA [0000] Произошла ошибка при попытке подключения: Получите https://127.0.0.1 : 2376 / v1.17 / images / json: x509: сертификат действителен для 192.168.99.101, а не для 127.0.0.1
$ docker --tlsverify = ложные изображения
(это работает)

Хотя это не ограничитель показа, я могу поставить «--tlsverify = false» во все мои команды ручного запуска, но другие инструменты, такие как fig, этого не сделают. Также почему-то у меня не работает DOCKER_OPTS.

Возможно, есть вариант при создании экземпляра виртуального бокса, чтобы он также делал сертификат действительным для другого адреса? Я вижу, что это также является проблемой, если у сервера есть внутренний и внешний IP-адрес, которые используются оба (например, в ec2, но тогда я бы использовал имя DNS).

@cwilkes существует / была проблема, позволяющая настроить это.

Похоже, https://github.com/docker/machine/pull/702 может мне помочь, и я вижу, что сегодня он был отправлен в мастер https://github.com/docker/machine/compare/v0.1.0 .. .мастер . Надеюсь, скоро выйдет 0.1.1 :)

Хорошо, после обсуждения этого с @sthulb и @nathanleclaire, я думаю, нам следует провести проверку, аналогичную той, что делает b2d. Мы можем проверить IP-адрес при запуске машины и сравнить его с IP-адресом SAN в сертификате. Если они не совпадают, мы можем регенерировать. Мысли @sthulb @nathanleclaire ?

Согласовано.

Да, пожалуйста @ehazlett

+1 с такой же проблемой

Я тоже сталкиваюсь с этим. Я развернул машину с помощью драйвера AWS, а затем назначил ей эластичный IP-адрес. Пытался остановить и запустить машину через CLI, но каждый раз, когда я запускаю docker ps после активации env, я получаю:

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

Я пытался вручную изменить IP в конфигурации `~ / .docker / machine '. Это не сработало.

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

пожалуйста, оформляйте заказ №770. это добавляет автоматическую регенерацию в случае ошибки сертификата. обратите внимание, что он работает только с командами config и env поэтому, если у вас есть проблема с докером (например, docker ps т. д.), вам нужно будет запустить $(docker-machine env <name>) или docker $(docker-machine config <name>) ps чтобы их исправить. Этот PR также добавляет возможность регенерировать сертификаты вручную с помощью команды regenerate-certs (я использовал функциональность из # 702).

Надеюсь, это устранит ошибки TLS раз и навсегда :)

Я обнаружил изменение IP-адреса AWS после обычной перезагрузки экземпляра aws.
docker-machine ssh amazonec2-03 работает только после ручного редактирования IP-адреса в /.docker/machine/machines/amazonec2-03/confg.json

Сертификаты демона докеров не работают, завтра я могу проверить # 770.

PTAL @nathanleclaire @sthulb

Имея ту же проблему, скоро проверю # 770 ...

Можно использовать текущую голову :)

Или вы можете использовать RC - у них есть исправление.

была та же проблема, но в последней вехе версии 0.2.0 она решена! Благодаря!

@gschmutz благодарим за отзыв!

У меня это с момента обновления до 1.7.0.
Перезапуск b2d приведет к этой ошибке:

$ 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

благодаря

@gravis Почему вы используете boot2docker shellinit с машиной?

Извините, я разместил не в том репо :)
Думал, что это b2d, с вкладками напутал.

Для всех, кто сталкивается с этим, вот возможное решение: https://github.com/boot2docker/boot2docker/issues/824#issuecomment -113904164
И
https://github.com/boot2docker/boot2docker/pull/411

Пока это решило проблему для меня. Я вижу, что файл / var / lib / boot2docker / tls / hostnames не имеет IP-адреса виртуальной машины (т.е. у него нет IP-адреса, который вы видите, когда вы набираете: boot2docker ip), поэтому это позволяет добавить его (он появляется в конце списка имен хостов после добавления предложенной задержки).

Некоторое время назад я тестировал boot2docker, надолго забыл, а сегодня я скачал последнюю версию boot2docker и установил ее. После установки я столкнулся с той же проблемой X.509, упомянутой здесь, и решил ее с помощью

1) удаление каталога .boot2docker (находящегося в моем домашнем каталоге) и его содержимого и
2) удаление всех файлов виртуальной машины boot2docker

Надеюсь это поможет.

пс. Поскольку я тестировал только boot2docker, мне было все равно, если я что-то потеряю при удалении этого материала ...

Я решил проблему так же, как и Pasitolonen. Удаление каталога .boot2docker и запуск boot2docker init. Это имеет побочный эффект в виде удаления моих изображений (что я не возражал).

Это происходит со мной всякий раз, когда меняется Wi-Fi. Например, когда я использую его дома, а затем снова в офисе.

Ошибка: произошла ошибка при подключении: получить https://192.168.59.104 : 2376 / v1.19 / версия: x509: сертификат действителен для 127.0.0.1, 10.0.2.15, а не 192.168.59.104

версия $ docker
Версия клиента: 1.7.0
Версия клиентского API: 1.19
Версия Go (клиент): go1.4.2
Git commit (клиент): 0baf609
ОС / Arch (клиент): darwin / amd64

По-видимому, это решает проблему: https://github.com/boot2docker/boot2docker/issues/938#issuecomment -118211836

alias docker="docker --tlsverify=false"

Я испытал это после того, как перераспределил RAM. как rajaraodv metnioned alias docker="docker --tlsverify=false" решено

Отключение безопасности ( --tlsverify=false ) никогда не должно быть рекомендуемым обходным путем.

Для меня работает обходной путь boot2docker ssh 'sudo /etc/init.d/docker restart' , который заставит Docker сгенерировать новый сертификат x509, действительный для boot2docker в дополнение к другим IP-адресам. Пожалуйста, попробуйте это перед отключением функций безопасности.

Решение @indygreg сработало для меня. Большое спасибо.

@indygreg меня

спасибо, у меня тоже работает :-)

Привет всем, если вы все еще сталкиваетесь с проблемой сертификата с boot2docker пожалуйста, сначала попробуйте boot2docker upgrade чтобы обновить вашу виртуальную машину до последней версии (1.7.1 устраняет эту проблему), и если что-то еще появляется сообщение о проблемах на github.com/boot2docker/boot2docker-cli. Это репо для проблем с Docker Machine. Благодаря!

@indygreg здорово,

@indygreg спасибо, у меня тоже работает :-)

@indygreg У меня тоже

У меня сработало, спасибо!

Спасибо @indygreg! Я добавляю сюда ссылку на комментарий, чтобы гуглер мог легко увидеть, что он рекомендовал.

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

Решите эту проблему с помощью Docker Toolbox 1.9.1 в Windows после перезагрузки, в результате которой виртуальной машине был выделен другой IP-адрес, и это было самым популярным в Google.

Так что для всех, кто сталкивается с этим, текущее исправление еще проще. (где default - ваша докер-машина)

docker-machine regenerate-certs default

Спасибо @johnmccabe , у меня работал с Docker Toolbox 1.10.0 на OS X.

Это часто случается со мной из-за переключения wlan и иногда использования VPN. Есть ли способ, которым это можно автоматизировать? Или сертификаты могут быть действительны для диапазона IP-адресов?

@johnmccabe Обратите внимание, вы можете просто убедиться, что ваша виртуальная машина всегда запускается с одного и того же IP- http://stackoverflow.com/a/35367277/6309

Я использую OS X и устал от использования этих хаков, и в конечном итоге они сломаются.

Vagrant имеет возможность установить IP-адрес в конфигурации. Я не могу понять, почему этот тип параметра или флага еще не существует в докер-машине (просто по сравнению с бродягой, потому что оба используют виртуальный бокс)

@onnimonni : это решается очень давно (почти год). Машина включает команду для регенерации сертификатов в случае изменения IP.

Я впервые столкнулся с этой проблемой и проверил все в этом потоке с помощью любого из следующих вариантов, успешно решающих проблему: (выберите один)

• docker-machine regenerate-certs default2
• docker-machine kill default2 затем docker-machine create default2 ...
• docker-machine upgrade default2 (если еще не обновлен)

Чтобы воспроизвести эту проблему в OSX:

1. Установите Docker Toolbox (v1.10)
2. Создайте машину default которая получает 192.168.99.100
3. Создайте машину default2 которая получает 192.168.99.101
4. Завершение работы обоих (иногда требуется перезагрузка)
5. docker-compose start default2 который получает 192.168.99.100 (и конфликт сертификатов x509)

таким образом, это сводится к тому, что несколько машин, запущенных в разном порядке, могут вызвать другой IP-адрес, который нарушает сертификат, который требует поиска github для этой проблемы, чтобы найти решение создания нового сертификата, чтобы вы могли использовать их снова ... есть ли способ ПРЕДОТВРАТИТЬ это? Неужели люди так необычно переключаются между несколькими докерными машинами?

$ alias docker = "docker --tlsverify = false" Работай для меня!

@ivancarrancho Почему бы не docker-machine regenerate-certs -f и оставить TLS включенным?

@nathanleclaire да, это лучше, чем "--tlsveify" большое спасибо

@nathanleclaire, потому что это занимает ~ 4 минуты ... Представьте, что у вас есть кластер из 6+ узлов ... Мне придется написать параллельный регенератор сертификатов, чтобы не тратить целый день на восстановление некоторых сертификатов .... Более того, он перезапускает все Docker-контейнеры на целевой машине ...

Требование регенерировать сертификаты после изменения IP-адреса является огромной проблемой для облака aws ... Общедоступные IP-адреса постоянно меняются. Единственное известное мне решение - создание новых экземпляров из экземпляра ec2, но по какой-то причине он не работает https://github.com/docker/machine/pull/1453#issuecomment -215371216

Кстати, есть идеи, если docker-machine create --amazonec2-use-private-address должен создать экземпляр ec2 из другого экземпляра ec2?

Это единственный способ избежать постоянной регенерации сертификатов ...

Кстати, есть ли идея, если docker-machine create --amazonec2-use-private-address должен создавать экземпляр ec2 из другого экземпляра ec2?

Да, если нет другого способа получить доступ к частному IP с узла создания (например, прокси).

Мы рассматриваем множество решений, например Elastic IP, чтобы потенциально решить эту проблему.

да, но, как я уже упоминал, он зависает при доступе по ssh даже с этой опцией
включен
2 мая 2016 г. в 20:26 «Натан Леклер» [email protected] написал:

Кстати, если docker-machine create --amazonec2-use-private-address есть
предполагается создать экземпляр ec2 из другого экземпляра ec2?

Да, если нет другого способа получить доступ к частному IP из
узел создания (например, прокси).

Мы рассматриваем различные решения, например Elastic IP, чтобы потенциально
решить эту проблему.

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/machine/issues/531#issuecomment -216319103

Может группа безопасности настроена неправильно? В настоящее время при использовании --amazonec2-use-private-ip-address предполагается, что пользователь желает заранее убедиться, что такого рода детали доступа к сети правильно настроены.

Я не понимаю, почему я должен запускать этот уродливый оператор $ eval каждый раз, когда нужно запустить докер через терминал.

Я не понимаю, почему эта проблема вообще существует.

Docker становится все более и более похожим на ужасно сломанный продукт, за которым многие люди отказались, потому что это было «в».

Я использую последнюю версию docker и docker-machine , и у меня все еще та же проблема, я создал несколько хостов докеров virtualbox

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

и почти каждый раз, когда я перезагружаю виртуальные машины или перезагружаю свой Mac, я сталкиваюсь с ошибкой типа certificate is valid for 192.168.99.100, not 192.168.99.101 .

Мои версии:

$ 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

Есть ли какое-нибудь решение, чтобы предотвратить эту ошибку? или создать хост виртуального бокса с фиксированным IP?

Решение: docker-machine provision .

Исправлена ​​проблема с помощью 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

Следуя ссылке @VonC, я наткнулся на docker-machine-ipconfig https://github.com/fivestars/docker-machine-ipconfig

 $ cd ~ / .docker /
 $ git clone https://github.com/fivestars/docker-machine-ipconfig.git
 # Добавить в ~ / .profile
 $ echo 'псевдоним docker-machine-ipconfig = ~ / .docker / docker-machine-ipconfig / docker-machine-ipconfig' >> ~ / .profile 
 $ source ~ / .profile

Например: назначьте имени машины статический IP-адрес:

 $ docker-machine-ipconfig статическое имя машины
 # или укажите неявный IP
 $ docker-machine-ipconfig статическое имя машины 192.168.99.110

Это устраняет необходимость в docker-machine regenerate-certs -f machine-name при каждом перезапуске. Простой способ установить статический IP-адрес машины, работающий на виртуальном ящике.

Поддерживает ли он Windows? Я имею в виду и «за», и «на».

похоже, это все еще проблема. любой способ исправить это?

@johnmccabe ,
Благодарю.
работает отлично. Я только что перезапустил свой набор инструментов, и все снова в игре.

как я могу иметь статическую учетную запись контейнера, это позволяет мне изменять учетную запись каждый раз, когда я перезапускаю докер-машину?

Я вижу обходной путь с помощью docker-machine-ipconfig но просто для документации я сообщаю, что это также происходит с Windows 10 Docker Machine и Hyper-V

Возможно, вы захотите изменить это сообщение: «На запущенных машинах могут быть новые IP-адреса. Возможно, вам придется повторно запустить команду docker-machine env ». чтобы упомянуть что-то вроде "а также docker-machineгенерировать-сертификаты ..." FWIW ...

@rdp хороший улов, у меня была эта проблема, полчаса смотрел, что произошло, и после попытки сделать некоторые вещи с kubernetes, установки и удаления вещей ... запуск
docker-machine env
IP, сопоставленный в моих envs, соответствует тому, который вызывал ошибку с сертификатом ...
тогда:
eval $(docker-machine env)
сделайте конфигурацию для меня на месте ...

minikube stop && minikube start исправил это для меня

minikube stop && minikube start исправил это для меня

@PatMyron Удивительно, но у меня это тоже сработало!