Machine: regenerate-certs funktioniert nicht auf swarm-master

Wenn Sie swarm ausführen, lauscht es bei der ersten Initialisierung auf die öffentliche IP. docker inspect im Prozess swarm manage sieht in etwa so aus.

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

Eine schnelle (und etwas faule) Problemumgehung, die ich dafür gefunden habe, besteht darin, den docker-machine-Befehl einfach erneut auszuführen, aber stattdessen den generischen Treiber zu verwenden, um den Schwarm einzurichten.

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"

Danke für diesen Tipp @dustinblackman. Dieser Workaround hilft mir sehr!
Gibt es eine Möglichkeit, eine dieser Maschinen nach dem Regenerieren des Schwarmmeisters zu entfernen?
Es sieht etwas konfisziert aus, wenn derselbe Server zweimal mit unterschiedlichen Namen aufgeführt wird.

@rm-jamotion Ohne docker-machine rm ? Sie können den Maschinenordner in ~/.docker/machine/machines löschen.

@dustinblackman Ja, ich weiß, aber ich muss die erste Maschine mit dem AWS-Treiber entfernen. Aber es wäre besser, wenn es möglich wäre, die mit dem generischen Treiber erstellte Maschine zu entfernen und die Schlüssel auf die AWS-Maschine zu verschieben. Die Start/Stopp-Funktionen von aws bleiben also weiterhin verfügbar...

Docker-Maschine Version 0.7.0, Build 783b3a8,

Es ist nicht nur eine Frage der IP-Adresse. Auch ohne Änderung der IP-Adresse im Virtualbox-Treiber ist mir aufgefallen, dass regenerate-certs eine falsche Schlüsselverwendung generiert:

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

In den Protokollen des Docker-Daemons finden Sie:

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

In den Docker-Infos sind alle Knoten ausstehend, wenn sie mit dem Schwarm verbunden sind, und in den Schwarm-Master-Logs:

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"