Machine: регенерация сертификатов не работает на swarm-master

Созданный на 21 дек. 2015 · 5Комментарии · Источник: docker/machine

Рассмотрим этот сценарий:

docker-machine create -d amazonec2 --swarm --swarm-master (и т. Д.)
все работает (одиночный узел swarm-master + узел swarm)
изменить IP-адрес экземпляра Amazon (в моем случае установить Elastic IP)
докер-машина обнаруживает изменение IP, я думаю, через _magic_
docker-machine env для нового IP будет жаловаться на несоответствие IP сертификата tls
docker-machine regenerate-certs снова заставляет докер работать с env докер-машины
docker-machine env --swarm будет действовать так, как будто все в порядке, но любые команды docker или docker-compose ничего не сделают. Никаких ошибок в cli, просто ничего. docker images, когда не используется --swarm IP, будет сгенерирован правильный список изображений, но с --swarm IP он будет просто перечислять заголовки, а не изображения.

Должен ли regenerate-certs работать с существующим роем?

areswarm kinbug

Источник

BretFisher

👍1

Все 5 Комментарий

Когда вы запускаете swarm, он прослушивает общедоступный IP-адрес при первой инициализации. docker inspect в процессе swarm manage выглядит примерно так.

{
  "Path": "/swarm",
  "Args": [
      "manage",
      "--tlsverify",
      "--tlscacert=/etc/docker/ca.pem",
      "--tlscert=/etc/docker/server.pem",
      "--tlskey=/etc/docker/server-key.pem",
      "-H",
      "tcp://0.0.0.0:3376",
      "--strategy",
      "spread",
      "--advertise",
      "PUBLICIP:2376",
      "--replication",
      "etcd://ectd.host:2379/swarm"
    ]
}

Быстрый (и немного ленивый) обходной путь, который я нашел для этого, - это просто повторно запустить команду docker-machine, но вместо этого использовать общий драйвер для настройки роя.

docker-machine --debug create NEWNAME -d generic \
--generic-ip-address SERVERIP \
--generic-ssh-key KEYPATH \
--generic-ssh-user core \
--engine-label public=false \
--swarm \
--swarm-master \
--swarm-opt replication \
--swarm-discovery=etcd:/URL:PORT/swarm \
--engine-opt "cluster-store=etcd://URL:PORT/store" \
--engine-opt "cluster-advertise=eth0:2376"

dustinblackman 5 янв. 2016

👍1

Спасибо за этот совет @dustinblackman. Этот обходной путь мне очень помогает!
Есть ли возможность удалить одну из этих машин после регенерации мастера роя?
Когда один и тот же сервер дважды указан в списке с разными именами, это выглядит немного конфузным.

rm-jamotion 2 февр. 2016

@ rm-jamotion Без использования docker-machine rm ? Вы можете удалить папку машин в ~/.docker/machine/machines .

dustinblackman 2 февр. 2016

@dustinblackman Да, я знаю, но мне нужно удалить первую машину с помощью драйвера aws. Но было бы лучше, если бы можно было удалить машину, созданную с помощью универсального драйвера, и переместить ключи на машину aws. Таким образом, функции запуска / остановки aws останутся доступными ...

rm-jamotion 7 февр. 2016

докер-машина версии 0.7.0, сборка 783b3a8,

Дело не только в IP-адресе. Даже без изменения IP-адреса в драйвере Virtualbox я заметил, что регенерация сертификатов генерирует неправильное использование ключа:

sudo openssl x509 -in /var/lib/boot2docker/server.pem -noout -text | grep -A8 "X509v3 extensions"
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Alternative Name: 
                DNS:localhost, IP Address:10.10.0.148

В логах docker daemon вы можете найти:

2016-07-29 13:13:58.745094 I | http: TLS handshake error from 10.10.0.60:33214: tls: failed to verify client's certificate: x509: certificate specifies an incompatible key usage

В информации о докере при подключении к рою все узлы находятся в состоянии ожидания, а в основных журналах роя:

time="2016-07-29T13:22:58Z" level=debug msg="Failed to validate pending node: The server probably has client authentication (--tlsverify) enabled. Please check your TLS client certification settings: Get https://10.10.0.60:2376/info: remote error: bad certificate" Addr="10.10.0.60:2376"