Considere este escenario:
docker-machine create -d amazonec2 --swarm --swarm-master
(etc.)docker-machine env
para la nueva IP se quejará de la falta de coincidencia de la IP del certificado tlsdocker-machine regenerate-certs
hace que Docker vuelva a funcionar con docker-machine envdocker-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?
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"