Machine: 【تم الحل كيف يمكن لآلة الرصيف إضافة مضيف عامل ميناء موجود؟

هل يضيف دعم جهاز الرصيف مضيف عامل إرساء حالي؟

نظرًا لأنني كنت أبحث في المستندات خلال آخر 5 ساعات ، في الواقع ، هناك خيار "- driver = none" (غير موثق). راجع https://github.com/docker/machine/issues/2270 .

@ tdy218atemerev وأتذكر أنه في --driver none دفن خيارات عمدا (واعتقدت إزالتها من تنفيذ أفرج عنه) لأنه يستخدم فقط لأغراض الاختبار.

قضية ذات صلة: لدي قطيرة على محيط رقمي تم إنشاؤها باستخدام آلة الرصيف. كيف يمكنني إدارة مثيل من كمبيوتر محمول آخر؟

أعاد أحد الزملاء إنشاء الشهادات من جهاز الكمبيوتر المحمول الخاص به باستخدام docker-machine regenerate-certs [name] . والآن لا يمكنني الوصول إلى المثيل الخاص بي بعد الآن. هل يجب علي نسخ الشهادات الجديدة في مكان ما يدويًا؟ التوثيق حول هذا الأمر محير حقًا.

$ docker-machine ls
NAME           ACTIVE   DRIVER         STATE     URL                        SWARM   DOCKER    ERRORS
default        -        virtualbox     Stopped                                      Unknown   
gapp-sandbox   *        digitalocean   Running   tcp://xx.xxx.xxx.xx:2376           Unknown   Unable to query docker version: Get https://xx.xxx.xxx.xx:2376/v1.15/version: x509: certificate signed by unknown authority

لقد وجدت حلاً: https://github.com/docker/machine/issues/2270

قم بتحرير config.json الخاص بالجهاز للإشارة إلى مفاتيح CA والعميل لهذا الجهاز المحدد بدلاً من الأجهزة العامة.

لذلك قمت بنسخ جميع الملفات من مجلد زميلي واستبدلت جميع المسارات بمجلد جهازي. في حالتي ، المسار النهائي هو /Users/mturatti/.docker/machine/machines/gapp-sandbox/ .
حل سيئ ، لكن يبدو أنه يعمل.

ca.pem
cert.pem
config.json
id_rsa
id_rsa.pub
key.pem
server-key.pem
server.pem

dweomer ألا تعتبر إضافة جهاز عامل ميناء موجود من كمبيوتر آخر حالة استخدام أساسية وشائعة جدًا؟

dweomer ألا تعتبر إضافة جهاز عامل ميناء موجود من كمبيوتر آخر حالة استخدام أساسية وشائعة جدًا؟

atemerev : لا ، لا أعتقد ذلك. كما أفهمها ، يوجد Docker Machine لإنشاء / توفير مضيفين تم تمكين Docker عليه.

ومع ذلك ، يوجد برنامج تشغيل أقل من الواضح إلى حد ما generic أعتقد أنه يجب استخدام generic مضيفًا ويعيد توفيره. كل ما يتطلبه الأمر هو مضيف يعمل مع برنامج خفي ssh ومستخدم على هذا المضيف مع وصول بدون كلمة مرور sudo (أو جذر فقط). إعادة التوفير هذه غير مدمرة حيث ستتم ترقية تثبيت Docker الحالي على الأكثر.

تضمين التغريدة
حاولت استخدام برنامج تشغيل عام لإضافة مضيف عامل ميناء موجود في الاختبار التالي.
المضيف المحلي (جهاز الكمبيوتر المحمول) الاسم: Chris-Laptop
تم تثبيت جهاز الإرساء بالفعل ، الإصدار 0.6.0 ، الإصدار e27fb87 ، نظام التشغيل Mac OS X 10.11
اسم المضيف البعيد (VPS الخاص بي): li845-130 (139.162.3.130)
تم تثبيت محرك docker بالفعل ، CentOS 7.0

1. عملية Docker Daemon في المضيف البعيد
[ root @ li845-130 ~] # ps -ef | grep docker |
جذر 12093 1 0 02:09؟ 00:00:00 / usr / bin / docker daemon -H

2. تكوين اتصال ssh بدون كلمة مرور
[ tdy218 @ Chris-Laptop ~] $ ssh [email protected]
آخر تسجيل دخول: الإثنين مارس 28 03:06:07 2016 من 111.193.199.188

3.إضافة مضيف عامل ميناء بعيد إلى آلات عامل الإرساء المحلية
[ tdy218 @ Chris-Laptop ~] $ docker-machine -D create - driver generic - generic-ip-address 139.162.3.130 - generic-ssh-user root linodevps
إصدار آلة عامل الإرساء: 0.6.0 ، بناء e27fb87
تم العثور على مسار ثنائي في / usr / local / bin / docker-machine
بدء تشغيل خادم البرنامج المساعد للسائق العام
خادم البرنامج المساعد يستمع على العنوان 127.0.0.1:50319
() استدعاء. GetVersion
باستخدام الإصدار 1 من API
() استدعاء .SetConfigRaw
() استدعاء .GetMachineName
(البحث عن العلم) استدعاء .GetMachineName
(البحث عن العلم) استدعاء .DriverName
(البحث عن العلم) الاتصال GetCreateFlags
تم العثور على مسار ثنائي في / usr / local / bin / docker-machine
بدء تشغيل خادم البرنامج المساعد للسائق العام
خادم البرنامج المساعد يستمع على العنوان 127.0.0.1:50323
() استدعاء. GetVersion
باستخدام الإصدار 1 من API
() استدعاء .SetConfigRaw
() استدعاء .GetMachineName
(linodevps) استدعاء. GetMachineName
(linodevps) استدعاء .DriverName
(linodevps) الاتصال. GetCreateFlags
(linodevps) استدعاء .SetConfigFromFlags
تشغيل عمليات تحقق ما قبل الإنشاء ...
(linodevps) الاتصال
(linodevps) استدعاء .GetConfigRaw
جاري إنشاء آلة ...
(linodevps) الاتصال
(linodevps) استدعاء .GetConfigRaw
(linodevps) لم يتم تحديد مفتاح SSH. سيتطلب الاتصال بهذا الجهاز الآن وفي المستقبل أن يحتوي وكيل ssh على المفتاح المناسب.
(لينوديفبس) DBG | IP: 139.162.3.130
(linodevps) استدعاء .DriverName
(linodevps) استدعاء .DriverName
في انتظار تشغيل الجهاز ، قد يستغرق ذلك بضع دقائق ...
(linodevps) استدعاء .GetState
الكشف عن نظام التشغيل للمثيل الذي تم إنشاؤه ...
في انتظار توفر SSH ...
جاري الحصول على وظيفة WaitForSSH ...
(linodevps) استدعاء .GetSSHHostname
(linodevps) استدعاء .GetSSHPort
(linodevps) استدعاء .GetSSHKeyPath
(linodevps) استدعاء .GetSSHUsername
باستخدام نوع عميل SSH: خارجي
{[-o BatchMode = yes -o PasswordAuthentication = no -o StrictHostKeyChecking = لا -o UserKnownHostsFile = / dev / null -o LogLevel = quiet -o ConnectionAttempts = 3 -o ConnectTimeout = 10 -o ControlMaster = لا -o ControlPath = لا شيء [email protected] -p 22] / usr / bin / ssh}
على وشك تشغيل أمر SSH:
خروج 0
SSH cmd Err ، الإخراج::
جاري الكشف عن الموفر ...
(linodevps) استدعاء .GetSSHHostname
(linodevps) استدعاء .GetSSHPort
(linodevps) استدعاء .GetSSHKeyPath
(linodevps) استدعاء .GetSSHUsername
باستخدام نوع عميل SSH: خارجي
{[-o BatchMode = yes -o PasswordAuthentication = no -o StrictHostKeyChecking = لا -o UserKnownHostsFile = / dev / null -o LogLevel = quiet -o ConnectionAttempts = 3 -o ConnectTimeout = 10 -o ControlMaster = لا -o ControlPath = لا شيء [email protected] -p 22] / usr / bin / ssh}
على وشك تشغيل أمر SSH:
cat / etc / os-release
SSH cmd Err ، الإخراج:: NAME = "CentOS Linux"
الإصدار = "7 (الأساسية)"
المعرف = "centos"
ID_LIKE = "ريل فيدورا"
VERSION_ID = "7"
PRETTY_NAME = "CentOS Linux 7 (Core)"
ANSI_COLOR = "0 ؛ 31"
CPE_NAME = "cpe: / o: centos: centos : 7"
HOME_URL = " https://www.centos.org/ "
BUG_REPORT_URL = " https://bugs.centos.org/ "

CENTOS_MANTISBT_PROJECT = "CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION = "7"
REDHAT_SUPPORT_PRODUCT = "سنتوس"
REDHAT_SUPPORT_PRODUCT_VERSION = "7"

تعذر تعيين مفتاح CPE_NAME ، لم يتم العثور على حقل هيكلي مطابق
تعذر تعيين المفتاح ، ولم يتم العثور على حقل هيكلي مطابق
تعذر تعيين المفتاح CENTOS_MANTISBT_PROJECT ، ولم يتم العثور على حقل هيكلي مطابق
تعذر تعيين المفتاح CENTOS_MANTISBT_PROJECT_VERSION ، لم يتم العثور على حقل هيكلي مطابق
تعذر تعيين المفتاح REDHAT_SUPPORT_PRODUCT ، ولم يتم العثور على حقل هيكلي مطابق
تعذر تعيين المفتاح REDHAT_SUPPORT_PRODUCT_VERSION ، ولم يتم العثور على حقل هيكلي مطابق
تعذر تعيين المفتاح ، ولم يتم العثور على حقل هيكلي مطابق
تم العثور على مضيف متوافق: centos
قسم غير مصنف في الرياض
لم يتم تحديد مشغل مخزن باستخدام أداة رسم الخرائط

(linodevps) استدعاء. GetMachineName
(linodevps) استدعاء .GetSSHHostname
(linodevps) استدعاء .GetSSHPort
(linodevps) استدعاء .GetSSHKeyPath
(linodevps) استدعاء .GetSSHUsername
باستخدام نوع عميل SSH: خارجي
{[-o BatchMode = yes -o PasswordAuthentication = no -o StrictHostKeyChecking = لا -o UserKnownHostsFile = / dev / null -o LogLevel = quiet -o ConnectionAttempts = 3 -o ConnectTimeout = 10 -o ControlMaster = لا -o ControlPath = لا شيء [email protected] -p 22] / usr / bin / ssh}

4 سطر أوامر مضيف عامل ميناء بعيد.
[ root @ linodevps ~] # ps -ef | grep docker |
جذر 17079 1 0 03:06؟ 00:00:00 / usr / bin / docker daemon -H
جذر 17185 1 0 03:06؟ 00:00:00 إصدار sudo docker
جذر 17190 17185 0 03:06؟ 00:00:00 إصدار عامل ميناء

تمت إعادة تشغيل عملية docker daemon ، ولكن كانت هناك عمليتان إضافيتان لإصدار docker ، ثم حاولت تنفيذ أمر إصدار docker يدويًا ، وتم تعليقه.

من الصعب جدًا إضافة مضيف عامل ميناء موجود إلى سطر أوامر عامل الإرساء ...

إذا كان المضيف البعيد بدون أي محرك عامل إرساء فيه ، فمن السهل إنشاء مضيف عامل ميناء (تثبيت محرك عامل ميناء) من سطر أوامر جهاز الإرساء ، ولكن نظرًا لأن المشكلة أعلاه ، فإن جهاز الرصيف محدود.

dweomer هذا صحيح ، لكن إذا قمت بتوفير آلة عامل إرساء أو سرب عامل ، كيف يمكنني ، لنقل ، تمكين مطور آخر لنشر الحاويات هناك؟ كيف أقوم بنقل متغيرات التكوين / env بين الأجهزة؟ حتى الآن ، يمكنني فقط استخدام مضيفي آلة الإرساء المزودة بنفسي ، وفقط من جهاز واحد (ماذا لو كان معطلاً؟ كيف يمكنني استعادة التهيئة على جهاز آخر؟).

بالنسبة لي ، فإن آلة الرصيف / عامل الرصيف بعيدة كل البعد عن كونها جاهزة للإنتاج ، ويجب وضع علامة بيتا على الأقل. أو أود أن أسمع من أي شخص يستخدمه بالفعل في الإنتاج ...

FWIW ، إذا قمت بإسقاط ~ / .docker من مضيف محطة العمل هذه على المضيف الجديد (بافتراض أن الدليل الرئيسي هو نفس المسار) ، فسيعمل. إذا كان الدليل الرئيسي مختلفًا ، فستحتاج إلى تحرير ملفات .json في عدة أماكن (مفاتيح وشهادات ، وما إلى ذلك) لتغيير مثل /Users/macuser/.docker إلى /home/linuxuser/.docker .

يبدو أن هذا السؤال قد تم تناوله بدقة و / أو يغطي الأرضية المحددة بالفعل في قضايا أخرى. شكرا لكم جميعا.

nathanleclaire فقط لكي نكون واضحين ، هل الأسلوب الرسمي لإضافة مضيفات عامل الإرساء الحاليين (سواء تم إنشاؤها بواسطة جهاز الرصيف أو غير ذلك) لنسخ مجلد ~ / .docker بين أجهزة العميل؟ إذا كان الأمر كذلك ، فهل هناك أي مجموعة فرعية معينة من الملفات / الملف الذي نحتاج إلى نسخه؟

إذا كان النهج الرسمي هو بدلاً من ذلك استخدام برنامج التشغيل العام ، فسيكون من المفيد معالجة المشكلة @ tdy218 الموضحة في التعليق هنا .

لا أعتقد أنه تم تناول هذا السؤال على الإطلاق. أحاول دفع الكود إلى جهاز جديد وأفضل إجابة يمكن لأي شخص التوصل إليها للعثور على الرجل الذي صنع الجهاز ونسخ ملفاته إلى ملفاتي.

لست متأكدًا مما إذا كان أي شخص قد جرب هذا هنا في العالم الحقيقي ، لكنه سيء.

TheSeanBrady دعنا نواصل المناقشة حول القضايا المدنية. إذا كانت لديك مقترحات للحلول التي ترغب في رؤيتها ، يرجى مشاركتها. دعنا نركز على الحلول أكثر من المشاكل.

أنا فقط أكون صادقة. تحاول إرسال رسائل بريد إلكتروني تطلب ملفات ، لأنها لا تعمل معي حتى الآن. تم إغلاق هذا دون معالجة المشكلة.

أنا فقط أكون صادقة. تحاول إرسال رسائل بريد إلكتروني تطلب ملفات ، لأنها لا تعمل معي حتى الآن. تم إغلاق هذا دون معالجة المشكلة.

لا تشعر أن قول شيء ما "سيء" والإيحاء بأن البقية منا لا يعيشون "في العالم الحقيقي" هو أمر قاس وغير بناء بلا داع؟

نحاول تعزيز مجتمع يتم فيه تشجيع التعاون والإيجابية. أسأل إذا كنت ترغب في المشاركة ، فأنت تتبع هذه المبادئ أيضًا.

نظرًا لاستخدام بيانات اعتماد واجهة برمجة التطبيقات المخزنة ، ومفاتيح SSH ، والشهادات التي تشترك في docker-machine s عبر أجهزة الكمبيوتر هي مشكلة إدارة أسرار كاملة / ACL ، والتي تم اختراع أمثالها من فئات التكنولوجيا الأخرى للتعامل معها. إنها مشكلة كبيرة في النطاق. من المحتمل أن يتم اتخاذ خطوات للتخفيف من ذلك مما يساعد على حالة الاستخدام الخاصة بك ، فلماذا لا تقترح بعض الحلول الاستباقية للتنفيذ؟

إذا كنت ترغب في تقديم اقتراح للتعامل مع هذا ، فلا تتردد. إذا كنت ترغب أيضًا في تقديم اقتراح مدعومًا برمز في طلب سحب ، فأنا أشجعك أيضًا على القيام بذلك. ولكن على أي حال ، يرجى تركيز المناقشة على الحلول والبقاء إيجابيين.

لا تشعر أن قول شيء ما "سيء" والإيحاء بأن البقية منا لا يعيشون "في العالم الحقيقي" هو أمر قاس وغير بناء بلا داع؟

ليس حقًا عند المتابعة ...

يبدو أن هذا السؤال قد تم تناوله بدقة و / أو يغطي الأرضية المحددة بالفعل في قضايا أخرى. شكرا لكم جميعا.

هذا إلى حد كبير ما أسميه الفصل الفوري. وبعبارة "العالم الحقيقي" ، أعني البيئة التي نستخدم فيها هذه الأشياء ، وليس المكان الذي يمكنك فيه المرور بأحد المطورين في القاعة.

كان من الممكن أن تكون هذه إجابة أكثر ملاءمة ...

نظرًا لاستخدام بيانات اعتماد واجهة برمجة التطبيقات المخزنة ومفاتيح SSH والشهادات التي تشارك أجهزة الإرساء عبر أجهزة الكمبيوتر ، فإن مشكلة إدارة الأسرار / قائمة التحكم في الوصول (ACL) الكاملة ، والتي تم اختراع فئات أخرى من التكنولوجيا للتعامل معها.

... على الرغم من اختراع هذه التقنيات ومعظمها مفتوح المصدر.

ومع ذلك ، بما أنك سألت ، ماذا عن docker-machine add <hostname> ، باستخدام مصادقة مفتاح SSH لتمرير الشهادات المطلوبة لاتصال TLS؟

ماذا عن إضافة عامل ميناء، باستخدام مصادقة مفتاح SSH لتمرير الشهادات المطلوبة لاتصال TLS؟

هذا يمكن أن يحل المشكلة ... لبيئات التطوير على الأقل

هناك خيار آخر وهو استخدام مقبس docker على مضيف متاح عبر SSH ، وهو أفضل بكثير بالنسبة لي لأنه يستخدم آلية مصادقة SSH الحالية (والتي في حالتي يتم نسخها احتياطيًا باستخدام HSMs) ولا تتطلب تعديل المنافذ / جدران الحماية إلى دعم TLS.

لقد اخترقت معًا الحل الخاص بي لهذا باستخدام socat ، ولكن سيكون من الجيد جدًا أن تدعمها آلة الرصيف. ليس من الصعب إرسال بريد إلكتروني إلى مضيف ، وتثبيت socat إذا لم يكن مثبتًا بالفعل ، واستخدام socat لتحويل جلسة ssh إلى مقبس محلي للتواصل مع جهاز التحكم عن بعد /var/lib/docker.sock. هذا يعني أيضًا أن جهاز الإرساء لن يكون عليه معرفة أي شيء عن المصادقة أو الشهادات أو TLS في وضع برنامج التشغيل هذا ، على الرغم من أنه يعتمد على socat محليًا لإنشاء المقبس المحلي ...

سيكون من الجيد رؤية وضع برنامج تشغيل يقوم بهذا النوع من إعداد مأخذ التوصيل المحلي بالطريقة التي يقوم بها برنامج تشغيل ssh الحالي بإعداد جميع عناصر TLS. العديد من المؤسسات لديها بالفعل توزيع مفتاح SSH / تم حل إعادة توجيه المنافذ ، ويتوقع أن تقوم الآن بتوزيع / إدارة PKI لـ TLS (وفتح منفذ آخر) أمر مرهق.

tyrell:~▻ cat Library/Local/bin/ber1docker 
#!/bin/bash

DOCKER_REMOTE_HOST="ber1.local"
DOCKER_SOCK="$TMPDIR/docker.sock"
export DOCKER_HOST="unix://$DOCKER_SOCK"
rm $DOCKER_SOCK

socat UNIX-LISTEN:$DOCKER_SOCK,reuseaddr,fork \
   EXEC:"ssh root@$DOCKER_REMOTE_HOST 'socat STDIO UNIX-CONNECT:/var/run/docker.sock'" &

لذا ، لا "إضافة عامل عامل ميناء ..."؟

+1 لـ docker-machine add ...

نريد الحصول على جمال eval $(docker-machine env mymachine) لجميع أعضاء فريقنا (لبيئات التطوير المشتركة بالطبع).

لقد قمت بتجميع تطبيق droplet الصغير مع برنامج التشغيل digitalocean وحصلت على موقع وتشغيله باستخدام عامل إنشاء عامل من محطة العمل الخاصة بي.

ثم اضطررت إلى العمل في الموقع ولكن من موقع مختلف تمامًا ، بعيدًا عن محطة العمل الخاصة بي حيث قمت بتنفيذ أوامر آلة الإرساء الأصلية.

أليس هذا موقفًا شائعًا بدرجة كافية؟

إنه حل شائع جدًا. خاصة إذا كنت تعمل في شيء يسمى "فريق". لكنهم تجنبوا هذا الموضوع لمدة 18 شهرًا الآن. كل ما يفعلونه هو إغلاق مشكلات مثل هذه ثم قول شيء مثل "الأمر معقد للغاية لتنفيذ مثل هذه الميزة" وأنه يمكنك القيام بذلك بنفسك واقتراح طلب سحب في أي وقت.
يبدو لي أنهم لم يبدؤوا حتى في العمل على حل خلال الأشهر الثمانية عشر الماضية.

نشكرك على ردك ، على الرغم من عدم وجود طريقة سهلة لتحقيق ذلك حتى الآن.

احتفظ بأوراق الاعتماد وغير ذلك في السحابة.

أعطني تعليمات حول كيفية استخدام صندوق الإسقاط أو google drive لتخزينه.

اسمح لي بالاستعلام عن المعلومات من digitalocean ، نظرًا لأن هذا هو برنامج التشغيل الذي كنت أستخدمه.

هذا حقا لا يمكن أن يكون بهذه الصعوبة.

نعم هذا يبدو آمنًا.
يوم الأربعاء 9 نوفمبر 2016 الساعة 09:28 Michael Schwartz [email protected]
كتب:

احتفظ بأوراق الاعتماد وغير ذلك في السحابة.

أعطني تعليمات حول كيفية استخدام صندوق الإسقاط أو google drive لتخزينه.

هذا حقا لا يمكن أن يكون بهذه الصعوبة.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/machine/issues/3212#issuecomment -259457472 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ABxbKbZQLUfK9ENnWpNKiF207ZGpXFs2ks5q8fSagaJpZM4H07I2
.

لا تقل أمانًا عن إرسال الأوامر وكل التعليمات البرمجية الخاصة بي عبر الإنترنت للقيام بها في المقام الأول.

أو تحميل كل ما عندي من ممتلكات إلى Docker hub أو github ، حتى إعادة شراء خاصة.

بالنسبة لأولئك الذين يحاولون إضافة آلة عامل إرساء إلى بيئة التطوير ، يمكنك القيام بما يلي:

إنشاء جهاز عامل ميناء -d "بلا" - عنوان URL http://192.168.10.100 : 4243 bla

هذا إذا كان لديك HTTP وليس مصادقة TSL ممكّنة على المضيف.

لقد قضيت الكثير من الوقت في العثور على هذه الأشياء غير الموثقة

أعتقد أنه يبدو قصر النظر قليلاً للسماح لآلة واحدة فقط بإدارة مجموعة عامل الميناء أيضًا. أكثر من مجرد مشاركة مسؤولية إدارة المجموعة مع فريقك ، ماذا عن وجود أكثر من نقطة فشل واحدة أو السماح للعديد من الوكلاء الآليين بالتفاعل مع مجموعة عامل الإرساء؟

+1 لأمر التصدير.

يمكنه تصدير جميع الإعدادات والشهادات إلى ملف tar أو zip آمن يمكن استيراده بواسطة جهاز الإرساء بكلمة مرور.

يبدو أنه طلب معقول.

bmmathe هذا الأمر بالفعل tar -c ~/.docker/machine | bzip2 > docker-machine-config.tbz2 .

إليك كيف يتعامل lxd مع هذا. ربما يمكن تكوين كلمة مرور أو مفتاح على الجهاز مما يسمح له بنسخ الشهادات أو إعادة إنشائها.

هذا محزن جدا 😖. تعرض أجهزتي البعيدة الآن حالة timeout محليًا عند تشغيل docker-machine ls ، وهو أمر أفسد تكوينات الجهاز. لا يمكن اكتشاف كيفية إعادة تكوينها / إصلاحها في مجلد أجهزة Docker المحلي. لا مزيد من التزويد المحلي؟ هل يجب أن أحذف الأجهزة الافتراضية وأعيد إنشائها؟

التصويت على خيار إضافة آلات بعيدة إلى أجهزة Docker المحلية:

إضافة عامل ميناء--سائق

⏳🤒

هذه ميزة مهمة حقًا. أنا لا أفهم لماذا هو صعب جدا. حتى ، إذا كنت بحاجة إلى إعادة إنشاء الشهادات ، فلن يمثل ذلك مشكلة بالنسبة لي ، لكني أرغب في الحصول على هذا الموثق وأمر للعمل معه.

إذا كنت أتذكر بشكل صحيح ، فإن مشكلتي كانت بسبب وجود أذونات خاطئة و / أو اسم مستخدم محلي لا يتطابق مع الاسم البعيد (المستخدم الافتراضي هو docker-user ). ربما تكون هذه مشكلة نيابة عنك ، فأنت بحاجة إلى التعمق أكثر.
برنامج التشغيل العام لأمر docker-machine يعمل بشكل جيد لموفري مختلفين مثل google.

تحقق من هذه:
• https://github.com/docker/machine/issues/3522#issuecomment -280275707
• https://docs.docker.com/machine/drivers/generic/
• لا يمكنني العثور على المحادثات الأخرى التي أجريتها حول هذا الموضوع والتي قادتني إلى الحل.

اليوم ، وجدت سبب إضافة فشل مضيف عامل الإرساء البعيد في حالتي.
[ root @ linodevps ~] # ps -ef | grep docker | grep -v grep
جذر 17079 1 0 03:06؟ 00:00:00 / usr / bin / docker daemon -H

لتصحيحه ، ما عليك سوى تحرير ملف تكوين خدمة عامل الإرساء (الافتراضي هو /usr/lib/systemd/system/docker.service) ، قم بتغيير قيمة معلمة ExecStart من / usr / bin / docker daemon -H tcp: // 0.0.0.0 : 2376 to / usr / bin / docker daemon -H docker daemon -H tcp: //0.0.0.0 : 2376 ،
ثم sudo systemctl daemon-reload && sudo systemctl أعد تشغيل docker ، وأعد تنفيذ أمر إضافة docker-machine ، وانتظر لحظة ، وسوف تضيف بنجاح. أثناء عملية الإضافة ، ستنشئ آلة الإرساء شهادات SSL لمضيف عامل الإرساء الهدف وستنشئ ملف تكوين خدمة عامل الإرساء الجديد 10-machine.conf ضمن دليل جديد يسمى /etc/systemd/system/docker.service.d

tdy218 @ Chris-Laptop $ dm ls
الاسم النشط لدولة السائق URL SWARM DOCKER ERRRORS
docker-vm119 - تشغيل عام tcp: //192.168.135.119: 2376 v17.03.1-ce
docker-vm120 - عام توقف غير معروف

docker-vm119 هو مضيف عامل الإرساء الموجود قبل الإضافة.

من هذه الحالة ، نعلم أن آلة الإرساء مدعومة بإضافة مضيف عامل عامل موجود ، شكرًا

docker-machine create --driver none -url=tcp://123.123.123.123:2376 dockerhost1 هو أفضل شيء تعلمته عن عامل ميناء منذ وقت طويل!

يجب أن يكون من الأسهل حقًا مشاركة آلة التطوير بين المستخدمين.

// ccnathanleclaire

تحديث: لأكون واضحًا: على وجه التحديد ، لا أمانع في مشاركة الشهادات مسبقًا مع أعضاء الفريق الآخرين. هناك مجال للتحسين هناك أيضًا ..

dhrp ما هي العملية التي تتبعها

يا مولاي العزيز ، لا أستطيع أن أصدق الماضي أكثر من عام ونصف ، ولا أحد يريد حل هذه المشكلة 😞 😞 😞

albersthaJeztahAkihiroSudatianon هل تعتقد حقا هذا ليس شرطا شائع جدا وحاسم؟

لقد حاولت إعادة توفير مضيف عامل الإرساء الحالي ( docker-machine create --driver=generic --generic-ip-address <ip> <name> ويبدو أنه يعمل بدون إبطال الشهادات الحالية. تم إجراء ذلك من نفس الجهاز الذي قدم في الأصل مضيف عامل الإرساء ... هل هذه نتيجة متوقعة؟

هل يمكنك إعادة فتح هذه المشكلة؟ لا أعتقد أن هذا قد تم حله بعد.

عثر عليها بالصدفة.

حسنًا ، أوضحتnathanleclaire النقطة: هذه ليست نقطة إضافة ميزة تعمل بآلة عامل الإرساء ، بل هي نقطة مشاركة المفاتيح التي لا يُفترض تخزينها في أي مكان آخر غير جهاز العميل الأصلي. هذه هي بالضبط الطريقة التي يُفترض أن يتم القيام بها ويغضب بعض الناس هنا دون بذل تفكير كافٍ في الموضوع.

إذا كنت ترغب حقًا في مشاركة المفاتيح مع فريق ما ، فما عليك سوى المضي قدمًا في أي ريبو خاص للتحكم في المصدر وقبول المخاطر التي تتعرض لها. لتصدير المفاتيح المطلوبة ، يوجد نص برمجي قام به شخص ما بالفعل: https://gist.github.com/schickling/2c48da462a7def0a577e

"لا يوجد سبب يمنعنا من أن نكون مدنيين" - ليونيداس

ما زلت أعتقد أن آلة الرصيف يجب أن تتصرف مثل scp. ما الذي يمنع إضافة دعم لمفاتيح متعددة؟

حل واحد لهذا ، والذي وجدته للتو.
إذا كان لديك جهاز إرساء حالي على نفس النظام الأساسي (ملكي هو google) ويمكنك ssh / scp إلى هذا الجهاز دون الحاجة إلى آلة الإرساء ، يمكنك نسخ الجهاز الآخر وتشغيله.
فعلت:

mkdir ~/.docker/machine/machines/new-machine
cp -r ~/.docker/machine/machines/old-machine/* ~/.docker/machine/machines/new-machine/

#then replace all instances of "old-machine" with "new-machine" in ~/.docker/machine/machines/new-machine/config.json

#then add the public key from your new-machine folder into the authorized_keys file for the docker-user on the new machine, e.g.
scp ~/.docker/machine/machines/new-machine/id_rsa.pub docker-user<strong i="8">@new_machine</strong>:/home/docker-user
ssh docker-user<strong i="9">@new_machine</strong> -c "cat ~/id_rsa.pub >>~/.ssh/authorized_keys"

(لا تنسخ أوامر ssh حرفيًا ، ابحث عن كيفية القيام بذلك بشكل صحيح - https://encrypted.google.com/search؟hl=ar&q=ssh٪20copy٪20public٪20key)

+1 لأمر التصدير / الاستيراد.
+1 لدعم متعدد المفاتيح.

عدم القدرة على نقل محطات عمل الإدارة هو ببساطة غير مقبول ويخلق نقطة فشل واحدة هائلة.

على سبيل المثال الكمبيوتر المفقود والسرقة والحريق وفشل الأجهزة وفشل البرامج ومشكلات وصول الفريق والمشكلات الإدارية وما إلى ذلك

لم يتم تصميم Docker-machine مع أخذ ذلك في الاعتبار - إنها أداة وجبات سريعة لتوفير مطور واحد. هذا هو ، سهل وبسيط ، وهو يعمل - وهو مجاني!

يتم تنفيذ بعض الميزات المذكورة هنا في عرض Docker EE (مثل الفرق و RBAC).

إذا كان الناس لا يستطيعون أن يكونوا شاكرين ، حاول على الأقل أن تكون عقلانيًا.

لا أعتقد أنه قد تم ذكر مشاركة الآلة في هذا الموضوع حتى الآن:

machine-export <machine-name>
>> exported to <machine-name>.zip
machine-import <machine-name>.zip
>> imported

يا andrevtg

آسف إذا بدت جاحد. أنا حقًا أحب آلة الرصيف واعتقدت أن هذا سيجعلها أفضل.
أعتقد أن قدرة المطورين الفرديين على التنقل بسهولة بين أجهزة الكمبيوتر ستكون مفيدة حقًا.

إذا تم تحرير الجدول الزمني الخاص بي ، فقد أقوم بتجربة تعلم GO ومحاولة إضافة هذه الميزة.

يا @ dmitrym0

أعتقد أن هذه التذكرة كانت أكثر تركيزًا على عدم القدرة على الاتصال بمضيفي عامل الإرساء البعيدين الحاليين.
يبدو أن مشاركة الآلة مفيدة عند نقل مضيفي عامل ميناء محلي.
شكرا على اقتراحك.

@ Jared-Harrington-Gibbs machine-share تحل على وجه التحديد مشكلة "إضافة مضيفي آلة الرصيف الحالية_". ننشر العديد من التطبيقات عبر إنشاء عامل ميناء ، وهي تعمل بشكل جيد بالنسبة لنا. نقوم بتصدير مجموعة الشهادات بـ machine-share وتوزيعها على جميع أعضاء الفريق الذين يحتاجون إليها. إنها ليست مثالية ولكنها تعمل بشكل جيد.

حاولت استخدام برنامج تشغيل عام لإضافة مضيف عامل ميناء موجود ، وسيُضاف بنجاح بعد إعادة المحاولة عدة مرات.

sneak لا يبدو أن هذا الحل يعمل بالنسبة لي ، لأن المسارات الموجودة في config.json لن تشير إلى الملفات الصحيحة. أفترض أن docker-machine يعتمد على ملف config.json ، لكن قد أكون مخطئًا ، فلم أختبره بعد.

يمثل هذا مشكلة بالنسبة لي ، لأنني ربما أقوم بالتنفيذ من بيئة قد لا أعرف فيها المسار الدقيق لتخزين الملفات. ربما يمكن أن يكون هناك خيار لمسار نسبي؟

إذا كانت المشكلة هي القوة البشرية ، فيمكنني تخصيص بضعة أيام لمحاولة توفير حل للمجتمع. يفضل الحصول على بعض التوجيه من المشرفين بالرغم من ذلك. هل يشير [Resolved] في هذه الحالة إلى قرار بعدم دعم هذه الميزة محليًا ، أم أنها مدعومة بالفعل في مكان ما لا أراه؟

هذه ميزة لا يقصد تنفيذها على الإطلاق. ليس من المنطقي توقع قيام الآلة البعيدة بتخزين المفاتيح الخاصة التي لا يُفترض وجودها في أي مكان باستثناء جهاز المطور الأصلي.

حتى Docker EE يتأكد من إنشاء "حزمة عميل" مختلفة في كل مرة يتم طلبها ، ولا يخزنها على المضيف.

يطلب الأشخاص هنا ميزة يسهل تنفيذها ، ولكن لا معنى لذلك على الإطلاق ليتم تنفيذها بسبب قيود أمنية معقولة.

andrevtg الطلب ليس أن يقوم الجهاز الافتراضي نفسه بتخزين المفاتيح (مما يجعل المفاتيح عديمة الفائدة تمامًا) ، ولكن بالنسبة لعميل جهاز الإرساء (الذي يتكون من رمز ، إنه تطبيق فعلي) ، لتوفير وسيلة للمستخدمين لنقل المفاتيح طواعية من عميل إلى آخر.

قد تكون إحدى الطرق البسيطة للقيام بذلك هي توفير أمر docker-machine export بتجميع المفاتيح في أرشيف ، وأمر docker-machine import مقابل لمتلقي هذا الأرشيف لاستيراد الأجهزة الموضحة في الأرشيف. يعد التشفير / فك التشفير عند حدود نقل المفاتيح هو عمل المستخدمين (يمكنهم استخدام بريد PGP أو SFTP أو أي شيء يريدون).

يقوم docker-machine create بالضبط بإنشاء ملف تكوين ضخم ومفاتيح لا يفهمها المبتدئون أو يعرفون كيفية تكرارها. ربما يكون إنشاء مفتاح ssh بسيطًا مثل إضافة مفتاح إلى ملف المضيفين ، ولكن هذا غير موثق. إلى أي حاوية نضيفها؟ وكيف نقوم بإعداده على جهاز مختلف وإخطار docker-machine به؟ هل لا يزال بإمكاننا استخدام docker-machine use أم علينا تعيين جميع المتغيرات البيئية يدويًا.

من الناحية المثالية ، يجب أن يكون هناك docker-machine add [name] لإضافة مفتاح ، و docker-machine export لتصدير ملفات التكوين ، و docker-machine import لاستيراد ملفات التكوين هذه على جهاز آخر. سيكون من الجيد أيضًا أن يكون لديك docker-machine rm [name] لإلغاء الوصول إلى المفاتيح.

@ dhrp لدي خادم عامل ميناء يعمل على rpi. أرغب في الوصول إليه من مضيفي المحلي باستخدام جهاز عامل الإرساء. لذلك كل ما علي فعله هو:
docker-machine create --driver none -url=tcp://raspberry.local:22 rpihost
هل هذا فعال؟

لذا @ 360disrupt ، أليس كذلك؟ أنا أعاني من نفس حالة الاستخدام.

لذا @ 360disrupt ، أليس كذلك؟ أنا أعاني من نفس حالة الاستخدام.

لا ليس بعد.

مرحباً بالجميع. هذا لم يحل بعد؟ نستخدم عامل الإرساء لكل التطبيقات في الشركة التي أعمل بها. تتعلق أكبر مشكلة لدينا بمشاركة الآلات. حاولت استخدام برنامج التشغيل العام عدة مرات ، لكن المشكلة في هذا النهج هي أنه عند إنشاء جهاز باستخدام برنامج تشغيل عام وتوصيله بخادم موجود ، فإن الإنشاء يسقط الحاويات التي تعمل حاليًا في الخادم.

كانت الطريقة الوحيدة التي وجدناها هي إنشاء نص برمجي بسيط في Python يقوم فقط باستيراد وتصدير الجهاز الذي يريد المطور الوصول إليه. هذا البرنامج النصي مسؤول عن نسخ جميع ملفات التكوين والشهادات من مالك الجهاز إلى المصدر الجديد. إنه يعمل بشكل جيد ولا نواجه أي مشاكل مع ذلك ، إنه فقط لا أصدق أنه لا توجد طريقة رسمية لمشاركة الأجهزة دون الحاجة إلى مشاركة شهاداتنا الخاصة.

أنا أعمل في مشروع وسوف أنشره في GitHub لحل هذه المشكلة بطريقة مختلفة. في الأساس ، أقوم فقط ببناء PaaS التي ستركز جميع شهادات جميع الآلات الموجودة لدينا هنا في شركتنا. وعندما يريد شخص ما النشر أو القيام بشيء من هذا القبيل ، فأنت تحتاج فقط إلى الاتصال بـ PaaS ، وليس بالخادم. إنه مثل النفق. سأصدر قريبًا الإصدار الأول من PaaS.

+1 لـ docker-machine add أو docker-machine create --existing

هذا حل مشكلتي: مشاركة الآلة : الكمبيوتر:: rabbit2:

dweomer ألا تعتبر إضافة جهاز عامل ميناء موجود من كمبيوتر آخر حالة استخدام أساسية وشائعة جدًا؟

atemerev : لا ، لا أعتقد ذلك. كما أفهمها ، يوجد Docker Machine لإنشاء / توفير مضيفين تم تمكين Docker عليه.

ومع ذلك ، يوجد برنامج تشغيل أقل من الواضح إلى حد ما generic أعتقد أنه يجب استخدام generic مضيفًا ويعيد توفيره. كل ما يتطلبه الأمر هو مضيف يعمل مع برنامج خفي ssh ومستخدم على هذا المضيف مع وصول بدون كلمة مرور sudo (أو جذر فقط). إعادة التوفير هذه غير مدمرة حيث ستتم ترقية تثبيت Docker الحالي على الأكثر.

أعلم أن هذا يبدو أنه مشكلة تمت تسويتها ، لكنني أردت فقط أن أوضح أنه يجب أن أتفق مع متوفرة على أساس أسبوعي تقريبًا .

هذا حل مشكلتي: مشاركة الآلة 💻 🐇

يمكنني أن أؤكد أن حزمة npm هذه تعمل.