Machine: regenerate-certsはswarm-masterでは機能しません

作成日 2015年12月21日  ·  5コメント  ·  ソース: docker/machine

このシナリオを検討してください。

  • docker-machine create -d amazonec2 --swarm --swarm-master (など)
  • すべてが機能します(単一ノードの群れ-マスター+群れノード)
  • AmazonインスタンスのIPを変更します(私の場合、Elastic IPを設定します)
  • docker-machineは_magic_を介してIPの変更を検出します
  • 新しいIPのdocker-machine envは、tls certIPの不一致について文句を言います
  • docker-machine regenerate-certsは、docker-machineenvでdockerを再び動作させます
  • docker-machine env --swarmは問題ないように動作しますが、dockerまたはdocker-composeコマンドは何もしません。 CLIにエラーはなく、何もありません。 --swarm IPを使用していない場合のdockerイメージは、適切なイメージリストを生成しますが、-swarm IPを使用すると、ヘッダーのみがリストされ、イメージはリストされません。

regenerate-certsは既存の群​​れで機能することになっていますか?

areswarm kinbug

全てのコメント5件

swarmを実行すると、最初に初期化されたときにパブリックIPをリッスンします。 docker inspect swarm manageプロセスのdocker inspectは、次のようになります。

{
  "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。 この回避策は私を大いに助けています!
スウォームマスターを再生成した後、これらのマシンの1つを削除する可能性はありますか?
同じサーバーが異なる名前で2回リストされていると、少し混乱しているように見えます。

@ rm-jamotion docker-machine rmを使用せずに? ~/.docker/machine/machinesのmachinesフォルダを削除できます。

@dustinblackmanはい、わかっていますが、awsドライバーを使用して最初のマシンを削除する必要があります。 ただし、汎用ドライバーで作成されたマシンを削除して、キーをawsマシンに移動できるとよいでしょう。 したがって、awsの開始/停止機能は引き続き利用できます...

docker-machineバージョン0.7.0、ビルド783b3a8、

それはIPアドレスの問題だけではありません.VirtualboxドライバーでIPアドレスを変更しなくても、regenerate-certsが間違ったキーの使用法を生成することに気づきました:

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デーモンのログで見つけることができます:

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

スウォームに接続されている場合のDocker情報では、すべてのノードが保留中です。スウォームマスターログでは、次のようになります。

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" 
このページは役に立ちましたか?
0 / 5 - 0 評価