Machine: regenerate-certs não funciona em swarm-master

Criado em 21 dez. 2015 · 5Comentários · Fonte: docker/machine

Considere este cenário:

docker-machine create -d amazonec2 --swarm --swarm-master (etc)
tudo funciona (nó único swarm-master + nó swarm)
alterar o IP da instância amazon (no meu caso, definir Elastic IP)
docker-machine detecta mudança de IP, via _magic_ eu acho
docker-machine env para novo IP reclamará sobre incompatibilidade de IP do certificado tls
docker-machine regenerate-certs faz o docker funcionar novamente com env docker-machine
docker-machine env --swarm no entanto, funcionará como se estivesse bem, mas os comandos docker ou docker-compose não farão nada. Sem erros no CLI, apenas nada. as imagens do docker quando não estiver usando --swarm IP gerará uma lista de imagens adequada, mas com --swarm IP apenas listará os cabeçalhos e nenhuma imagem.

regenerate-certs deveria funcionar com um enxame existente?

areswarm kinbug

Fonte

BretFisher

👍1

Todos 5 comentários

Quando você executa o swarm, ele escuta no IP público quando foi inicializado pela primeira vez. docker inspect no processo de swarm manage parece algo assim.

{
  "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"
    ]
}

Uma solução alternativa rápida (e meio preguiçosa) que descobri é simplesmente executar novamente o comando docker-machine, mas usar o driver genérico para configurar o swarm.

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 em 5 jan. 2016

👍1

Obrigado por esta dica @dustinblackman. Esta solução alternativa está me ajudando muito!
Existe alguma possibilidade de remover uma dessas máquinas após regenerar o mestre do enxame?
Parece um pouco confuso quando o mesmo servidor é listado duas vezes com nomes diferentes.

rm-jamotion em 2 fev. 2016

@ rm-jamotion Sem usar docker-machine rm ? Você pode excluir a pasta de máquinas em ~/.docker/machine/machines .

dustinblackman em 2 fev. 2016

@dustinblackman Sim, eu sei, mas tenho que remover a primeira máquina usando o driver aws. Mas seria melhor se fosse possível remover a máquina criada com o driver genérico e mover as chaves para a máquina aws. Portanto, os recursos de iniciar / parar do aws permanecerão disponíveis ...

rm-jamotion em 7 fev. 2016

docker-machine versão 0.7.0, build 783b3a8,

Não é apenas uma questão de endereço IP. Mesmo sem a alteração do endereço IP no driver do Virtualbox, percebi que regenerate-certs gera o uso incorreto de chaves:

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

Nos logs do docker daemon, você pode encontrar:

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

Nas informações do docker, quando conectado ao swarm, todos os nós estão pendentes e nos registros mestre do swarm:

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"