Machine: regenerate-certs no funciona en swarm-master

Creado en 21 dic. 2015  ·  5Comentarios  ·  Fuente: docker/machine

Considere este escenario:

  • docker-machine create -d amazonec2 --swarm --swarm-master (etc.)
  • todo funciona (un solo nodo swarm-master + swarm nodo)
  • cambiar la IP de la instancia de Amazon (en mi caso, configurar la IP elástica)
  • docker-machine detecta el cambio de IP, a través de _magic_ supongo
  • docker-machine env para la nueva IP se quejará de la falta de coincidencia de la IP del certificado tls
  • docker-machine regenerate-certs hace que Docker vuelva a funcionar con docker-machine env
  • docker-machine env --swarm sin embargo, actuará como si estuviera bien, pero cualquier comando de docker o docker-compose no hará nada. Sin errores en cli, simplemente nada. Las imágenes de la ventana acoplable cuando no se usan --swarm IP generarán una lista de imágenes adecuada, pero con --swarm IP solo enumerará los encabezados y no las imágenes.

¿Se supone que regenerate-certs funciona con un enjambre existente?

areswarm kinbug

Todos 5 comentarios

Cuando ejecuta swarm, escucha en la IP pública cuando se inicializó por primera vez. docker inspect en el proceso swarm manage se parece a esto.

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

La solución rápida (y algo perezosa) que he encontrado para esto es simplemente volver a ejecutar el comando docker-machine pero usar el controlador genérico en su lugar para configurar 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"

Gracias por este consejo @dustinblackman. ¡Esta solución me está ayudando mucho!
¿Existe alguna posibilidad de eliminar una de estas máquinas después de regenerar el maestro del enjambre?
Parece un poco confiscado cuando el mismo servidor aparece dos veces con nombres diferentes.

@ rm-jamotion Sin usar docker-machine rm ? Puede eliminar la carpeta de máquinas en ~/.docker/machine/machines .

@dustinblackman Sí, lo sé, pero tengo que eliminar la primera máquina con el controlador aws. Pero sería mejor si fuera posible eliminar la máquina creada con el controlador genérico y mover las claves a la máquina aws. Por lo tanto, las funciones de inicio / parada de AWS seguirán estando disponibles ...

docker-machine versión 0.7.0, compilación 783b3a8,

No es solo cuestión de la dirección IP, incluso sin un cambio de dirección IP en el controlador de Virtualbox, he notado que regenerate-certs genera un uso incorrecto de la clave:

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

En los registros del demonio de la ventana acoplable puede 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

En la información de la ventana acoplable, cuando se conecta al enjambre, todos los nodos están pendientes, y en los registros maestros del enjambre:

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" 
¿Fue útil esta página
0 / 5 - 0 calificaciones