Machine: إرفاق الجهاز الموجود من عميل آخر

: +1:

ماذا عن إضافته إلى النظام الثاني باستخدام برنامج التشغيل "العام" ، ثم استخدام نفس الأمر EV هناك؟

clnperez هل هذا اقتراح أو شيء أنت واثق من أنه يعمل (يعني أنه سيعيد استخدام الجهاز البعيد الحالي حتى لو كان قيد التشغيل حاليًا)؟

حسنًا ، بعد فوات الأوان ، لا أعتقد أنه يمكنك القيام بذلك ب / ج ، يجب عليك إعداد مفاتيح ssh مرة أخرى ، أو استيرادها من نظامك الآخر.

أرى حالتك. لا يمكن للمرء إضافة إدخال جهاز الإرساء على النظام الثاني باستخدام برنامج التشغيل العام إلا إذا كنت ترغب في إبطال إعداد جهاز الرصيف الأصلي (على سبيل المثال ، يتم إنشاء أرصدة جديدة). يمكن للمرء تشغيل docker-machine create -d none --url [...] على النظام الثاني ليعكس خيارات مهمة (مثل أعلام السرب) من الإنشاء الأصلي على النظام الأول ثم نسخ ملفات .pem وملف id_rsa يدويًا من الجهاز الأول إلى الجهاز الثاني وقم يدويًا بإضافة أقسام للوصول إلى SSH (وقم بتغيير برنامج التشغيل يدويًا إلى عام من لا شيء). إنها بيتا. سيكون من الجيد أن تسمح وظيفة التصدير / الاستيراد المناسبة بالمشاركة. يمكن للمرء أيضًا مشاركة ملفات الاعتماد اللازمة لتكوين عامل الإرساء يدويًا.

صيح. ستكون الطريقة الحالية الوحيدة هي أخذ الدليل بالكامل ولكن هذا لن يعمل مع بعض برامج التشغيل (على سبيل المثال ، VirtualBox لأنه يسجل VMs والشبكات مع UUIDs التي لا تتطابق). كان هناك نقاش حول ميزة استيراد / تصدير في الماضي (https://github.com/docker/machine/issues/23)

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

+1

أود أن أكون قادرًا على إعادة الاتصال بسرعة بالمثيلات السحابية (أنا أستخدم GCE) الموجودة بالفعل.

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

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

وبالمثل ، عند استخدام برنامج التشغيل aws على سبيل المثال ، (وهو ما لم أفعله بنفسي بعد ، لكنني أفترض) يمكن للمرء الاتصال بمثيل موجود من خلال توفير زوج مفتاح / سري صالح (ربما من خلال متغيرات البيئة المقابلة للسائق المحدد. الإشارات - بافتراض أن العملية ستحدث من خلال بعض الأوامر الفرعية لعامل الإرساء ، بخلاف "إنشاء" ، نظرًا لأن التوقعات مختلفة قليلاً).

أريد فقط أن تتناغم مع أن هذه ستكون ميزة رائعة حقًا. أود حقًا أن أكون قادرًا على مشاركة آلة مع زملائي في الفريق وشعرت بخيبة أمل عندما اكتشفت أنه لا توجد طريقة للقيام بذلك الآن. سيكون أمرًا رائعًا ، على سبيل المثال ، يمكن لبرنامج التشغيل generic اكتشاف ما إذا كان صندوق معين قد تم تزويده بالفعل بـ docker-machine وإعادة استخدام شهادات tls ، وما إلى ذلك عندما قام شخص ما بتشغيل docker-machine create في هذا المربع مرة أخرى.

: +1. أود أن أراها تعمل. نحن حاليًا نشارك في إدارة نفس الأجهزة (على Google Compute Engine) مع شخص آخر والطريقة الوحيدة التي وجدت أنها تعمل هي نسخ الدليل بالكامل (+ تغيير الروابط المطلقة في ملف config.json). هذا عرجاء. أعتقد أن برنامج التشغيل العام لا يمكن استخدامه بسهولة بهذه الطريقة - هناك مشكلة تتعلق بالمصادقة بالطبع (شهادات tls وما إلى ذلك) لا يمكن إعادة استخدامها ببساطة عند تشغيل - إنشاء باستخدام برنامج تشغيل عام (بطريقة ما تحتاج إلى المصادقة وإثبات أنك الوصول إلى الجهاز الذي يختلف لكل سائق - في GCE ، عليك التحقق مما إذا كانت مصادقة gcloud تسمح لك بالوصول إلى الجهاز). هناك أيضًا مشكلة صغيرة تتمثل في أنه ما لم تكن قد أنشأت الجهاز من قبل باستخدام برنامج تشغيل معين ، فإن قطعة المصادقة الخاصة بك مفقودة (الطريقة الوحيدة للمصادقة هي .. إنشاء الجهاز).

أعتقد أن أفضل حل هو أن يكون لديك أمر "استيراد" (مع تنفيذ مختلف لبرامج تشغيل مختلفة). على سبيل المثال ، في GCE ، يمكنك تخزين جميع التفاصيل الضرورية (المفاتيح وما إلى ذلك) في مكان ما في البيانات الوصفية للجهاز: https://cloud.google.com/compute/docs/metadata؟hl=ar#project_and_instance_metadata ثم عبر تحديد اسم المشروع / الجهاز (والمصادقة) ، يمكنك الحصول على جميع المفاتيح اللازمة وإعداد الجهاز.

أنا حقا أقدر هذه الميزة!

potiuk أي دليل تنسخ؟

AlexZeitler ~/.docker/machine/machines/<machinename>

+1!

+1 أرغب في رؤية حل لهذا أيضًا :-)

لقد واجهت هذه المشكلة بالضبط اليوم لإعطاء حق الوصول إلى زميل.

+1 !!!!!

يبدو أنه نسخة مكررة من رقم 23 ، أليس كذلك؟
منذ ما يقرب من عام واحد منذ أن تحدثنا عن هذه الميزة ، حاول البعض إنشاء علاقات عامة لها ، لكن تم إغلاقها ...
آمل أن تكون هذه الميزة في الإصدار (الرئيسي) التالي :)

هذا مطلوب تمامًا في سيناريوهات التسليم المستمر ، حيث تريد النشر باستخدام تلك المفاتيح من Travis أو Circle CI. أي دليل بخصوص إيتا؟

يجب إعطاء هذا +1 أيضًا

+1

+1

هل هناك أي شيء عليك القيام به غير نسخ المجلد ~/.docker/machine/machines/<name> وتغيير المسارات المطلقة؟ تلقيت رسالة خطأ تتعلق بشهاداتي ، وفشلت محاولة إعادة إنشائها أيضًا.

jbasrai هل تغير عنوان IP الخاص بما تحاول الوصول إليه؟

لقد قدمت https://github.com/docker/machine/issues/2516 لبدء التفكير في الخطوات في الاتجاه الصحيح لتسهيل ذلك.

هذه ميزة حيوية ، وأود أن أراها في إصدار في المستقبل القريب. في رأيي ، يجب أن يظل تكوين الجهاز فريدًا للعميل ، ولا يتم استيراده / تصديره. بدلاً من ذلك (كما ذكر آخرون) docker-machine create يجب أن يكون التشغيل بنفس الوسيطات قادرًا على إنشاء تكوين للجهاز حتى لو كان موجودًا بالفعل عن بُعد بدلاً من الفشل كما هو الحال الآن. عند إعادة تشغيل أمر الإنشاء الخاص بي لجهاز amazonec2 موجود ، يظهر لي هذا الخطأ الذي يخبرني أن المضيف موجود بالفعل:

Error creating machine: Error with pre-create check: There is already a keypair with the name testing-recreate.  Please either remove that keypair or use a different machine name.

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

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

+1

+1

صيح. ستكون الطريقة الحالية الوحيدة هي أخذ الدليل بالكامل ولكن هذا لن يعمل مع بعض برامج التشغيل (على سبيل المثال ، VirtualBox لأنه يسجل VMs والشبكات مع UUIDs التي لا تتطابق). كان هناك نقاش حول ميزة الاستيراد / التصدير في الماضي (# 23)

ehazlett لذلك أنا أستخدم برنامج التشغيل

1. ضغط الآلة السحابية ~/.docker/machine/machines/staging
2. شاركها مع أعضاء الفريق ، فسيتم فك الضغط على ~/.docker/machine/machines/
3. سيكون لديهم آلة انطلاق كما لدي؟ docker-machine ls (أو هل يحتاجون إلى القيام بأمر آخر)

leandromoreira أحد العوائق أمام هذا النهج هو أن ملفات تكوين جهاز الرصيف لها مسارات مشفرة محددة للجهاز المضيف:

cat ~/.docker/machine/machines/local/config.json

outputs:

...
        "AuthOptions": {
            "CertDir": "/Users/pretzel/.docker/machine/certs",
            "CaCertPath": "/Users/pretzel/.docker/machine/certs/ca.pem",
            "CaPrivateKeyPath": "/Users/pretzel/.docker/machine/certs/ca-key.pem",
            "CaCertRemotePath": "",
            "ServerCertPath": "/Users/pretzel/.docker/machine/machines/local/server.pem",
            "ServerKeyPath": "/Users/pretzel/.docker/machine/machines/local/server-key.pem",
            "ClientKeyPath": "/Users/pretzel/.docker/machine/certs/key.pem",
            "ServerCertRemotePath": "",
            "ServerKeyRemotePath": "",
            "ClientCertPath": "/Users/pretzel/.docker/machine/certs/cert.pem",
            "ServerCertSANs": [],
            "StorePath": "/Users/pretzel/.docker/machine/machines/local"
        }

لذا فإن نسخ الدير بأكمله ليس حلاً كاملاً

شكرا جزيلا @ bhurlow : ابتسم: ، هل هناك أي أداة للمساعدة في هذا؟ أم يجب علي تحرير config.json يدويًا بنفسي؟ هل هذا هو العائق الوحيد؟

leandromoreira لقد قمت بهذا الشكل ، لم تعد الإصدارات الأحدث من docker-machine مفاتيح تشفير base64 في ملف التكوين. في نهاية اليوم ، يجب على أي شخص يريد استخدام آلة الإرساء عن بُعد _must_ أن يكون لديه شهادات TLS ، لذا فإن بعض التبادل بين الأطراف مطلوب على ما أعتقد

شكرا @ bhurlow

قامbcwalrus بأداة رائعة حتى نحصل على شيء رسمي.

npm install -g machine-share

# export
machine-share export amazon

# import
machine-share import  amazon.tar

# fix locations :D (it seems this is not using base64 anymore)
machine-share driverfix amazon

leandromoreira يبدو رائعًا ، لقد تمكنت من تصدير واستيراد التكوينات بنجاح.

muhammadghazali كان فكرةbhurlow والجهد: stuck_out_tongue:

+1 أي تحديثات بخصوص حل رسمي لهذا؟

مع إصدار docker 1.10.1 ، لاحظت أن ملف config.json يحتوي على مراجع لما يلي من دليل ~ / docker / machine / certs

        "CertDir": "/home/abc/.docker/machine/certs",
        "CaCertPath": "/home/abc/.docker/machine/certs/ca.pem",
        "CaPrivateKeyPath": "/home/abc/.docker/machine/certs/ca-key.pem",
        "ClientKeyPath": "/home/abc/.docker/machine/certs/key.pem",
        "ClientCertPath": "/home/abc/.docker/machine/certs/cert.pem",

تحتاج إلى نسخ مجلد ~ / .docker / machine / certs أيضًا من الجهاز الأصلي حتى يعمل هذا السيناريو.

يبدو أن الحل الحالي لذلك هو (على سبيل المثال ، إذا كنت تريد إنشاء Docker Machine على AWS على أحد أجهزة الكمبيوتر وعرض السجلات أو SSH في الجهاز من جهاز آخر):

1. أنشئ دليلًا جديدًا my-dir و my-dir/machine لأجهزة Docker التي تريد مشاركتها حتى لا تستخدم شهاداتك الافتراضية
2. أنشئ جهاز Docker Machine الخاص بك باستخدام الخيار --storage-path my-dir/machine (تأكد من تحديد المسار المطلق)
3. لمشاركة الجهاز ، قم بتحرير config.json في my-dir/machine/machines/machine-name واستبدل المسار المطلق بـ my-dir/machine بـ $MACHINE_STORAGE_PATH
4. تحميل my-dir مكان ما ، على سبيل المثال إلى Github

عندما يريد شخص ما استيراد هذا الجهاز:

1. استنساخ أو تنزيل my-dir
2. قم بتحرير config.json للجهاز في my-dir/machine/machines/machine-name واستبدل $MACHINE_STORAGE_PATH بالمسار المطلق إلى my-dir/machine على الكمبيوتر المحلي الخاص بك
3. chmod 0600 و id_rsa في my-dir/machine/machines/machine-name

يمكنك الآن استخدام أوامر Docker Machine باستخدام الخيار --storage-path my-dir/machine (تأكد من تحديد المسار المطلق).

يمكن تحسين ذلك من خلال:

• تقوم Docker Machine بتخزين المسارات النسبية في config.json ، لذلك لا يلزم تعديل هذا
• Docker Machine SSH (والأوامر ذات الصلة) chmoding id_rsa إلى 0600 تلقائيًا (إذا كان لديهم إذن بذلك)

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

ومع ذلك ، إذا كان الأشخاص يبحثون عن حل بديل ، فإن أسهل ما وجدته هو:

1. انسخ .docker/machine/certs إلى مكان خاص. لاحظ عدم وضع هذا في الريبو لأنه يحتوي على أسرار تتيح لك الوصول إلى الأجهزة الأخرى. نحن نستخدم متجرًا خاصًا لهذا الغرض
2. على الجهاز المضيف الجديد ، انسخ الشهادات إلى .docker/machine/certs
3. الآن أعد تشغيل جهاز الرصيف الذي أنشأته وستكون لديك القدرة على استخدام هذا دون تغيير جميع التكوينات. يستغرق الأمر وقتًا أطول ، ولكنه أكثر قابلية للنقل ولا يتعين عليك تعديل كل ملفات التكوين هذه.

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

1) قم بإنشاء قطرة صغيرة في DigitalOcean باستخدام آلة الإرساء وبرنامج تشغيل DigitalOcean (مع بعض الرموز التي تحصل عليها من لوحة تحكم DigitalOcean).

docker-machine create --driver digitalocean --digitalocean-access-token \
    [token_goes_here] --digitalocean-image ubuntu-16-04-x64 --digitalocean-size \
    1gb [host_name_goes_here]

2) انتقل إلى جهاز كمبيوتر مختلف ، واحصل على رمز مميز آخر من DigitalOcean وقم بإرفاقه بالجهاز الحالي باستخدام أمر إرفاق سحري ، مثل هذا:

docker-machine **attach** --driver digitalocean --digitalocean-access-token \
    [token_goes_here]  [host_name_goes_here]

ما هي العوائق التي تحول دون إنجاح هذا العمل؟ أعتقد أن رمز الوصول الرقمي DigitalOcean يمنح امتيازات كافية لإرفاقه بمضيف حالي وإعداد جميع الاتصالات الآمنة.

في الوقت الحالي ، سأحاول مشاركة الآلة بواسطة bhurlow : https://github.com/bhurlow/machine-share

+1 Bump على هذا - هل لدى أي شخص تحديث حول هذا؟

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

ملخص للجوهر: هناك وظيفتان - store_machine و load_machine. يخزن store_machine جميع المعلومات حول الجهاز داخل المخزن الآمن (مشفر في مخزن بيانات القرص). سيكون عليك تقديم كلمة مرور. تقوم وظيفة load_machine بتحميل جهاز من مخزن بيانات القرص.

لاحظ أن كود python هذا يفترض أن لديك sstash (Python Secure Stash) مثبتًا. يمكنك تثبيته عن طريق التشغيل

pip install sstash

+1

على محمل الجد - ما فائدة Docker-Machine ما لم تتمكن من الوصول إليها من جهاز آخر محدد مسبقًا ...

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

تعال - أين مسؤول Docker للتناغم في هذا؟! هذه حالة استخدام يمكن للجميع تقديرها ..

realcr هل حاولت مشاركة الآلة ؟

أرفض استخدام المزيد من التبعيات :) نسخ مجلد .docker إلى كل من أجهزة OSX يعمل بشكل مثالي بالنسبة لي. كانت مساراتي وأسماء المستخدمين الخاصة بي هي نفسها على كلا الجهازين حتى يكون هذا هو المفتاح دون تحرير المسارات يدويًا.

براندون تام
أرسلت من الجوال

في 4 نوفمبر 2016 ، الساعة 3:36 صباحًا ، كتب Sébastien Boulet [email protected] :

realcr هل حاولت مشاركة الآلة؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

+1

+1

+1

+1

لقد كتبت docker_machinator لمحاولة حل هذه المشكلة.
هذه أداة بيثون تسمح لك بحفظ جميع بيانات اعتماد جهاز الرصيف والتهيئة في مخزن مشفر يمكنك تخزينه في مزود السحابة ، على سبيل المثال. يمكنك بعد ذلك تنزيل هذا من مضيف آخر وإعادة تحميل أجهزتك من المخزن.
هذه أداة بيثون ، لذا يجب أن تكون pip install واحدًا من استخدامها.

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

يا رفاق ، يجب أن تعلموا أن مشاركة الآلة تصدر مفتاح ssh الخاص بك الذي استخدمته في إنشاء مضيف عامل إرساء عبر جهاز عامل إرساء مع برنامج تشغيل عام. لذلك سيتمكن كل من ترسله إلى أرشيف مُصدَّر من الوصول إلى الخادم الذي يقوم بتشغيل عامل الإرساء.

يوفرmxl docker -machine ssh والذي سيمنحك الوصول إلى الخادم ، وبالتالي فإن الموقف الذي تصفه لا مفر منه إذا كان لديك أداة تنشئ تكوينًا كاملاً كملف قابل للاستيراد.

➜ docker-machine
Usage: docker-machine [OPTIONS] COMMAND [arg...]
...
Commands:
...
  ssh                   Log into or run a command on a machine with SSH.

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

إن القدرة على التحكم في آلة الإرساء من مضيف واحد فقط هو قيد غير مريح.
أود أيضًا أن أرى شيئًا مثل docker-machine config-from <otherhost> .

لذا +1 مني أيضًا.

/ تحرير: أقوم حاليًا بحل المشكلة عن طريق مزامنة .docker من "خادم رئيسي" لجميع الخوادم الأخرى التي تحتاج إلى نفس التكوينات - عبر cron و rsync. هذا مطلوب على سبيل المثال للعبيد البناء المتعدد. ليس حلا لطيفا جدا.

+1

إليك سيناريو مختلف يقودني إلى هنا.

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

السؤال هو كيف يمكنني إرفاق مثيل جهاز الإرساء الذي تمت استعادته من اللقطة التي تعمل على المضيف الجديد؟

في يوم الجمعة ، 10 آذار (مارس) 2017 الساعة 6:16 صباحًا ، كتب exjimsk [email protected] :

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

إذا لم تتغير الشهادات ، يجب أن تكون قادرًا فقط على تغيير ملفك المحلي
تكوين جهاز عامل ميناء لتوجيهه إلى عنوان IP الجديد. ستجد ملف
ملف في ~ / .docker / machine / machines / your-machine-name / config.json.

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

+1

+1

+1

+1

+1

+1

+1

+1

docker-machine attach فضلك

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

في حالتي ، أنا سعيد جدًا بإرفاق المضيف الحالي ${HOST} مع

docker-machine --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem create \
    --drive none --url tcp://${HOST}:2376

ولكن يلزم نسخ الشهادات ( ca.pem، cert.pem، key.pem ) إلى DOCKER_CERT_PATH يدويًا.

أي خطط لهذا؟ إن تسجيل المسارات الكاملة في config.json أمر محبط.

حالة الاستخدام الخاصة بي: لديّ git repo مع تكوينات الجهاز فيه (أستخدم -s لتوجيه آلة الإرساء إليه) يتم تخزين الأسرار بـ git encrypt والفكرة هي أن تكون وظائف CI قادرة على الاستفادة من هذه التكوينات لمعالجة الأجهزة التي يحتاجون إليها للوصول.

لمعلوماتك: # 3212

lyda نحن نستخدم مثل هذا الأسلوب مع https://github.com/dmstr/docker-roj - ولكن بدون تشفير ، والتي ستكون ميزة رائعة جدًا في الواقع!

بينما تعمل roj دائمًا بنفس المسارات ، نظرًا لوجودها في حاوية ، فهناك حلول أخرى مثل:

• https://github.com/bhurlow/machine-share
• https://gist.github.com/realcr/2363c699e893c66ac7ed72da29804b0a

الذي يغير بشكل أساسي بعض المسارات في config.json .
إنه ليس سحرًا كبيرًا ، إلا إذا كنت أفتقد شيئًا تمامًا هنا.

هل يتم تطوير docker-machine بشكل نشط بواسطة عامل ميناء؟ أسأل لأنه مضى أكثر من شهر على الالتزام بإتقانه: https://github.com/docker/machine/commits/master

+1

+1

+1

يا إلهي الرعب! هذا الخيط لا يزال حيا بعد ما يقرب من ثلاث سنوات؟!؟ هذه حالة استخدام يصطدم بها الجميع أو يبدو أنها كذلك. ماذا ينقصني؟

حسنًا ، أفترض أن docker-machine قد مات (على الأقل بالنسبة لي: D). لقد تحولت إلى kubernetes . حتى أن kubeadm في إصدار alfa الذي يتم استضافته بنفسك يعمل بشكل أفضل من هذا في الواقع. يمكنني أن أوصي به :)

الرجاء دعم هذا :(

أضف "~ / .docker" إلى مجلد rsynced أو ربما مرتبط بشكل رمزي بالمجلد السحابي على كلا الجهازين. هناك بعض الحلول المعدة مسبقًا. ليسوا صعبين للغاية ، ما عليك سوى إجراء بعض الأبحاث - لم تواجهك مشكلة بعد الإعداد مرة واحدة لمدة 30 ثانية.

+1

+1

كيف لا يتم تنفيذ هذه الميزة ، بالإضافة إلى تحديد عنوان IP ثابت - أهم ميزتين مطلوبتين في تاريخ مشروع آلة الرصيف - هو أمر بعيد عني.

مر ما يقرب من 4 سنوات 😮 هل هناك أي تحديث لهذا؟

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

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

ماذا عن تشغيل docker-machine create من داخل حاوية عامل إرساء؟ يمكن بعد ذلك تصدير هذه الحاوية واستيرادها على كمبيوتر آخر ثم تشغيلها هناك.

مازلت ليس لديها ملحق ، يا إلهي