Machine: regenerate-certs لا يعمل على السرب الرئيسي

تم إنشاؤها على ٢١ ديسمبر ٢٠١٥ · 5تعليقات · مصدر: docker/machine

ضع في اعتبارك هذا السيناريو:

docker-machine create -d amazonec2 --swarm --swarm-master (إلخ)
كل شيء يعمل (عقدة سرب واحدة + عقدة سرب)
تغيير IP لمثيل أمازون (في حالتي ، قم بتعيين Elastic IP)
يكتشف عامل الميناء تغيير IP ، عبر _magic_ أعتقد
سيشتكي docker-machine env لعنوان IP الجديد من عدم تطابق عنوان IP لشهادة tls
docker-machine regenerate-certs يعمل عامل الميناء مرة أخرى مع enver-machine env
ومع ذلك ، سيتصرف docker-machine env --swarm كما لو كان الأمر جيدًا ، لكن أي أوامر عامل ميناء أو أمر إنشاء عامل الإرساء لن تفعل شيئًا. لا توجد أخطاء في CLI ، فقط لا شيء. صور عامل الإرساء عند عدم استخدام --swarm IP ستنشئ قائمة صور مناسبة ، ولكن مع --swarm IP ، ستدرج فقط العناوين ولا تحتوي على صور.

هل من المفترض أن يعمل regenerate-certs مع سرب موجود؟

areswarm kinbug

مصدر

BretFisher

👍1

ال 5 كومينتر

عند تشغيل السرب ، فإنه يستمع إلى عنوان IP العام عندما تم تهيئته لأول مرة. docker inspect في عملية swarm manage شيئًا من هذا القبيل.

{
  "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 ولكن باستخدام برنامج التشغيل العام بدلاً من ذلك لإعداد 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 في ٥ يناير ٢٠١٦

👍1

شكرا لهذه النصيحة dustinblackman. هذا الحل يساعدني كثيرا!
هل هناك أي إمكانية لإزالة واحدة من هذه الآلات بعد تجديد سيد السرب؟
يبدو الأمر مؤكدًا بعض الشيء عندما يتم سرد نفس الخادم مرتين بأسماء مختلفة.

rm-jamotion في ٢ فبراير ٢٠١٦

@ rm-jamotion بدون استخدام docker-machine rm ؟ يمكنك حذف مجلد الأجهزة في ~/.docker/machine/machines .

dustinblackman في ٢ فبراير ٢٠١٦

dustinblackman نعم أعرف ، لكن لا بد لي من إزالة الجهاز الأول باستخدام برنامج التشغيل aws. ولكن سيكون من الأفضل إذا كان من الممكن إزالة الجهاز الذي تم إنشاؤه باستخدام برنامج تشغيل عام ونقل المفاتيح إلى آلة AWS. لذلك ستظل ميزات البدء / الإيقاف الخاصة بـ aws متاحة ...

rm-jamotion في ٧ فبراير ٢٠١٦

إصدار آلة الإرساء 0.7.0 ، بناء 783b3a8 ،

لا يتعلق الأمر بعنوان IP فقط ، فحتى بدون تغيير عنوان IP في برنامج تشغيل Virtualbox ، لاحظت أن إعادة إنشاء الشهادات تولد استخدامًا خاطئًا للمفتاح:

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 daemon يمكنك أن تجد:

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

في معلومات عامل الإرساء عند الاتصال بالسرب ، تكون جميع العقد معلقة ، وفي سجلات السرب الرئيسية:

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"