Machine: آلة Docker الآن في وضع الصيانة

أوه :(

حسنًا ، كان هذا لطيفًا بينما استمر :)
شكرا للجميع على العمل الجيد!

أود أن أطلب منك أيضًا تحديث الملف التمهيدي

إذا تم إغلاق الدعم الرسمي للآلة ، فما هو احتمال استمرار الدعم الذي يحركه المجتمع في هذا الريبو؟

بالنسبة لأولئك الذين يحتاجون إلى آلة ، هناك بعض النشاط في منظمة https://github.com/machine-drivers ، وقد يكون من المنطقي أن تعمل عليها وتحررها من https://github.com/machine- السائقين / الجهاز ...

لقد نظرنا بالفعل في إضافة تصحيحات إلى هذه المؤسسة ، حيث يبدو أنها ممنوعة من الاندماج هنا: # 4509 (هذا حظر للإصدارات المترجمة من Windows). الأفضل هو المضي قدمًا في بعض أشكال الإصدارات ، ولكن بالنسبة لنا: minikube و minishift ، نحتاج فقط إلى الارتباط بمكتبة.

@ shin- على سبيل الفكر ، لا يزال المستخدم الجديد مستندات "Getting Started" يستخدم docker-machine كجزء أساسي من المقدمة.

بالنسبة للأشخاص المهتمين بتحديث المستندات ، ما الذي يجب أن يرشدوا إليه بدلاً من ذلك؟

• Windows: يبدو مثل Docker Desktop لنظام التشغيل Windows
• Mac: يبدو وكأنه Docker Desktop لنظام macOS
• Linux: هل تريد الاستمرار في استخدام مستندات الآلة؟

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

مرحبا!

هل لدى شخص ما برنامج بديل لنظام التشغيل Linux؟ لا أريد تشغيل عامل الإرساء كجذر على الجهاز المضيف وكان جهاز الرصيف يمنح بعض العزلة في هذا الصدد. هل هناك أي خطة لـ Docker لنظام التشغيل Linux؟

شكر!

gilbsgilbs لا يزال بإمكانك استخدام آلة

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

@ shin- Weelll ... أن تكون مغلقًا أمام وسائل العلاقات العامة التي تستخدمها في مشاريع جديدة ربما يكون فكرة سيئة. :غمزة:

justinclift لا أريد الخوض في الكثير من التفاصيل لأن لدينا المزيد من المعلومات الواردة في بيان مُعد ، ولكن كما حاولت أن أذكر في docker-machine تناسب احتياجاتك ، فلا يوجد سبب للتخلي عنها ، حتى بالنسبة للمشاريع الجديدة.

يبدو أن البنية التحتية ليست نشطة أيضًا. لم تكن هناك إصدارات لأكثر من عام ، ولا تحديث على DockerCon 2018 ، ولا توجد وثائق مستخدم مشابهة لـ https://docs.docker.com/machine/

تقترح وثائق آلة Docker تجربة Docker Cloud التي يتم إغلاقها بدورها لصالح Docker EE (وهو غير متاح بشكل عام)

كل هذا يشجع إما على تفرع المشروع أو البحث في مكان آخر: https://landscape.cncf.io/grouping=landscape&landscape=infrastructure-automation&sort=first-commit

لا أشكو ، فقط وصف وجهة نظري.

مثير للإعجاب. وعند النظر إلى ارتكاب التاريخ ل InfraKit ، على الرغم من أنه لم يرتكب تلقي جديدة كل بضعة أيام، في الغالب يبدو أن هناك رجل واحد الجهد.

يبدو أن النشاط قد توقف في حوالي أبريل / مايو . تم إعادة توجيه تخمين وقت الناس إلى أشياء أخرى.

هل هذه طريقة خاطئة للنظر إلى الأشياء؟

@ shin- لكن العديد من العلاقات العامة (مثل إصلاحات الأخطاء التي أقدمها لجعل التدويل على Hyper-V يعمل) لم يتم دمجها. هذا ليس مؤشرًا جيدًا على "إننا نتطلع ببساطة إلى قصر هذه الإصلاحات على إصلاحات الأخطاء بدلاً من الميزات الجديدة" في ضوء "لا يوجد سبب للتخلي عنها ، حتى بالنسبة للمشاريع الجديدة".

@قصبة-

لا أريد الخوض في الكثير من التفاصيل لأن لدينا المزيد من المعلومات الواردة في بيان مُعد

هل يمكنك الارتباط بهذا البيان الرسمي (متى تم نشره؟) لا يمكنني العثور عليه.

أوصي بشدة بتغيير المستندات حتى تكون محدثة .
كانت ساعتي الأخيرة عبارة عن استكشاف لا معنى له لـ boot2docker ، والذي يشير بوضوح إلى جهاز الرصيف ، الذي يحتوي على تحذير على صفحته الرئيسية ينصح باستخدام سحابة عامل الإرساء كتقنية حديثة. يشير هذا إلى وصف Docker cloud doc (وليس صفحة الترحيل !!!!) ، الأمر الذي تطلب مني بعض البحث على Google لمعرفة أنه تم إيقافه في مايو (ولكن تم الإعلان عنه في مارس ، لذلك قبل 7 أشهر). أتيت الآن إلى هنا لاقتراح إزالة التحذير من مستند آلة عامل الإرساء ، اكتشفت أنه تم أيضًا إيقاف تشغيل جهاز عامل ميناء الإصدار الذي يبلغ 3 أشهر.
هذه ليست الطريقة التي يجب أن تعمل بها الوثائق. سأعود إلى بعض الحلول المخصصة ، لكنني سأتخلى عن عامل الإرساء إذا لم أكن أستخدمه بالفعل.

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

لا تختفي آلة docker-machine ، إنها فقط لا تزيد من نطاق الميزات.

لن تختفي Docker Cloud ، فهي لم تعد تُستخدم لتوفير / إدارة الخادم. لا يزال هناك لبناء الصورة. يحتوي Docker على أدوات أخرى لخوادم الإنتاج مثل Docker for AWS و Docker for Azure و DCI for Docker Enterprise.

لقد نسيت تمامًا موقع http://boot2docker.io القديم ولم أدرك الإشعار الذي تمت صياغته بشكل سيء جدًا (أعتذر عن أي ارتباك ساهم في حدوث ذلك!) - لقد قمت الآن بتحديث ذلك (وتقليل حجمه) نأمل أن يوضح المحتوى بشكل أفضل أن boot2docker أداة CLI القديمة هي ما تم إهماله لصالح Docker Machine وأن boot2docker لم يتم إهمال التوزيع ولكنه في وضع الصيانة (مثل Docker Machine).

لوضع ذلك بطريقة أخرى: إصدارات Docker الجديدة ، وتحديثات kernel ، وما إلى ذلك ، ولكن محاولات متضافرة للحفاظ على الميزات / الوظائف الجديدة إلى أدنى حد ممكن لضمان استمرار الصيانة لعدد قليل من الأشخاص الذين لا يمكنهم الانتقال بعد إلى Docker الأنسب لنظام التشغيل Windows / Docker for Mac أو أدوات / حلول خادم الإنتاج المشار إليها أعلاه (مستخدمو Windows 7 الذين لا يستطيعون استخدام Docker لنظام Windows على الإطلاق ، مستخدمو Windows 10 Home الذين لا يستطيعون بالتالي مستخدمي Hyper-V و VirtualBox الذين لا يستطيعون استخدام Hyper- V ، إلخ).

tianon : قد ترغب أيضًا في ذكر مستخدمي Linux الذين لا يريدون الانتقال إلى Mac أو Windows ...

afbjorklund لماذا تحتاج إلى boot2docker إذا كنت تستخدم Linux بالفعل؟

Vanuan : إما لأن

في كلتا الحالتين ، لا يعد الانتقال إلى Docker Desktop خيارًا - فهو إما Docker Engine أو DIY LinuxKit؟

أود أن أشكر صانعي docker-machine و boot2docker ، لجعلهم أكثر قابلية للوصول.

وبجهود سائقي الماكينات (لـ KVM) ، نأمل أن تستمر في العمل لفترة أطول

لماذا أستخدم توزيعة الخادم لسطح المكتب؟ ولماذا لست مسؤولاً عن سطح المكتب الخاص بي؟ لكن بطريقة ما يُسمح لي بالوصول إلى KVM؟

يبدو أنك تبحث عن حل لتشغيل عامل ميناء على خادم KVM؟ إذا كان الأمر كذلك ، فأنا أقوم حاليًا باستكشاف البنية التحتية هنا: https://github.com/docker/infrakit/issues/913

ولكن إذا كنت تبحث فقط عن تشغيل docker على سطح مكتب Linux ، فلا أفهم لماذا لا تقوم بتثبيت أحدث Ubuntu مع Docker CE. إذا كنت تريد تشغيله في VM ، فافعل ذلك. يمكنك تحميل الدليل الرئيسي الخاص بك في VirtualBox واستخدام عامل الإرساء عبر SSH. ما هي المشكلة هنا؟ لا يوجد Docker لـ Linux Desktop لأنه لا معنى له. على الاقل لي.

لماذا أستخدم توزيعة الخادم لسطح المكتب؟ ولماذا لست مسؤولاً عن سطح المكتب الخاص بي؟ لكن بطريقة ما يُسمح لي بالوصول إلى KVM؟

يتعين على بعض الأشخاص استخدام أي نظام تشغيل سطح مكتب يسلمهم لهم صاحب العمل. RHEL6 هو مثال أخبرني به (قبل بضعة أشهر) رجل يعمل في مكان تداول الأسهم. :غمزة:

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

لست متأكدًا مما إذا كان هذا قد تم تطويره بأي عمق ، حيث أن معظم جهود تطوير Libvirt ذهبت نحو أشياء VM "على مستوى النظام" بدلاً من مستوى المستخدم.

إذا كنت تبحث فقط عن تشغيل docker على سطح مكتب Linux ، فلا أفهم لماذا لا تقوم بتثبيت أحدث Ubuntu

عدد غير قليل من الناس يكرهون Ubuntu لسبب أو لآخر. :غمزة:

بدءًا من الإصدار 18.09 ( DOCKER_HOST=ssh:// ) ، يعد إعداد أجهزة Docker عن بُعد بدون docker-machine أمرًا بسيطًا حقًا: https://medium.com/lucjuggery/docker-tips-access-the-docker- الشيطان عبر ssh-97cd6b44a53

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

نعم ، إنها تسمى
يحتوي أحدث GNOME على تطبيق رائع لذلك - الصناديق: https://en.wikipedia.org/wiki/GNOME_Boxes

وضع المستخدم الافتراضي KVM له بعض العيوب في الشبكات المكتوبة. لذلك أعتقد أن برنامج Virtualbox هو الخيار الوحيد في تلك الظروف.

ولكي يكون لديك CLI لـ VirtualBox ، فإن الخيار متشرد. ما عليك سوى بعض توزيعات Linux لتشغيل عامل الإرساء فوقه. وأكثر المعارك التي تم اختبارها هي Ubuntu / Debian. يمكنك تنزيل أي توزيعة أخرى بالرغم من ذلك. ولكن عليك أن تحزمها بنفسك لاستخدامها مع Vagrant: https://www.vagrantup.com/docs/virtualbox/boxes.html

مجرد قول أن docker-machine كان حلاً جيدًا لمستخدمي Linux ، تمامًا كما كان لمستخدمي Mac القديم و Windows القديم ... كل ما تحتاجه هو تشغيل docker على منفذ غير قياسي ، بدلاً من 2376 hardcoded؟ وبرنامج تشغيل qemu جديد لا يتطلب مجموعة libvirt (أي الجذر). ربما سيكون infrakit / hyperkit بديلاً في المستقبل ، لكن في الوقت الحالي (الرابط أعلاه) لا يزال يبدو خشنًا تمامًا حول الحواف.

Vanuan : أعرف خيارات أوبونتو / المتشرد ، لقد أشرت إليها للتو ببساطة باسم " Docker Engine " أعلاه.

justinclift : يحصل كل مستخدم على مفاتيح ssh / شهادات عامل الإرساء ، وبالتالي يتم فصل الآلات بشكل معقول.

تضمين التغريدة لقد مرت سنوات منذ أن عملت في Red Hat ضمن فريق Libvirt. في هذه الأيام ، أستخدمه بشكل عام فقط عند تشخيص المشكلات ، بدلاً من الاستمرار في التعمق فيه. :ابتسامة:

afbjorklund دعونا نوضح هذا الأمر.

قد ترغب أيضًا في ذكر مستخدمي Linux الذين لا يريدون الانتقال إلى Mac أو Windows ...
في كلتا الحالتين ، لا يعد الانتقال إلى Docker Desktop خيارًا - فهو إما Docker Engine أو DIY LinuxKit؟
أنا أعلم عن خيارات أوبونتو / المتشرد ، لقد أشرت إليها للتو ببساطة باسم "محرك Docker" أعلاه.

boot2docker هو توزيع ( boot2docker.iso ) وأداة لإدارة Virtualbox ( boot2docker.iso Docker CE (محرك Docker السابق):

https://github.com/boot2docker/boot2docker/blob/d465167d83310295b5847ba315905f52c3ca1435/Dockerfile#L426 -L435

وسيتم تحديث هذا إلى إصدارات Docker CE الجديدة.

ذهب boot2docker-cli ، لكنه في جوهره مجرد متشرد مع Virtualbox. Vagrant لا يزال موجودًا.

يستخدم Docker-machine with KVM driver boot2docker.iso لتوفير _Docker CE_ لأجهزة libvirt VMs الجديدة.

يستخدم Docker Desktop التوزيعات التي تم إنشاؤها باستخدام linuxkit لتوفير _Docker CE_ إلى Hyper-V و xhyve.

لتصويرها كلها:

كما ترى ، تتضمن جميع الحلول Docker Engine (يسمى حاليًا Docker CE لنظام التشغيل Linux ) بطريقة أو بأخرى.

هناك الكثير من البيئات والحلول الافتراضية / السحابية. وبالتالي ، لا توجد أداة واحدة يمكنها العمل بشكل جيد على نظام التشغيل windows / mac / linux ودعم QEMU / Virtualbox / xhyve / Hyper-v جنبًا إلى جنب مع السحب المختلفة والتزويد عبر SSH. وتحتاج هذه الأداة أيضًا إلى قابلية التكوين: دعم المنافذ المختلفة وإدارة موارد الذاكرة / وحدة المعالجة المركزية والشبكات وما إلى ذلك ، لذا من المحتمل أن تكون أداة الأغراض العامة جنبًا إلى جنب مع بعض ملفات التكوين التي يتم تنزيلها عبر http هي الحل الأفضل.

Vanuan : نعم ، هذا ما قلناه أعلاه. لاستبدال جهاز docker-machine ، تحتاج إلى التبديل إلى Mac أو Windows و Docker Desktop - على الأقل حتى ينشئ شخص ما شيئًا مشابهًا لـ LinuxKit و libvirt ...

لسنا بحاجة إلى التحدث عن boot2docker-cli بعد الآن ، وقد انتقل دعم برامج تشغيل Linux بالفعل إلى مؤسسة "برامج تشغيل الجهاز" - حيث يتوفر VirtualBox فقط مع جهاز الإرساء القياسي.

@ shin- إذا كنت لا تسمح بالميزات الجديدة بعد الآن ، فالرجاء التفكير في إضافة ملاحظة شديدة الوضوح في الجزء العلوي من README.md AND CONTRIBUTING.md .

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

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

لا توجد حتى الآن معلومات واضحة حول وضع الصيانة في README.md و / أو CONTRIBUTING.md . لقد أمضيت نصف وقت إجازتي في اكتشاف حل عملي لإنشاء ProxmoxVE VM ونظام Linux خفيف الوزن لنشر Docker - لقد وجدت مزيجًا من docker-machine + docker-machine-driver-proxmox-ve للعمل جيدًا لهذا الاستخدام قضية. لسوء الحظ ، يعتمد على boot2docker ، والذي يقول إنه تم إهماله لصالح docker-machine ويقترح المشرف على بعض الخيوط Rancher OS. docker-machine الذهاب إلى وضع الصيانة دون تحديد واضح لما يعنيه ذلك (لن يتم قبول سوى إصلاحات الأخطاء والاقتراح بأنه لا بأس به بالنسبة للمشاريع الجديدة هو تناقض IMO). كان هناك أيضًا إعلان رسمي مذكور في أغسطس 2018 ، لكن لا توجد إشارات على أي إشارة هنا.

من منظور خارجي ، الذي يرغب في بناء بنية تحتية معقولة للشركات الصغيرة والمتوسطة ، لا يبدو docker-machine حلًا صحيحًا على المدى الطويل. يمكن لأي شخص أن يقترح ما هو Reasonably Good ™ لتوفير وإدارة ProxmoxVE VM باعتباره برنامج Hypervisor والحد الأدنى من Linux الذي يدعم Docker؟

لسوء الحظ ، فإنه يعتمد على boot2docker ، والذي يقول أنه تم إهماله لصالح آلة الرصيف والمشرف على بعض الخيوط التي تشير إلى Rancher OS.

هل يمكنك أن تكون أكثر تحديدًا فيما يتعلق بالمكان الذي يدعي boot2docker أنه قد تم إهماله لصالح آلة الإرساء حتى أتمكن من توضيح ذلك بشكل مناسب؟ (لأنه ليس صحيحًا إلا إذا كنت تشير على وجه التحديد إلى أداة CLI القديمة boot2docker التي لم يتم صيانتها بنشاط منذ سنوات حتى الآن)

توزيع boot2docker (على وجه التحديد ، القطعة الأثرية boot2docker.iso تم إصدارها مع كل إصدار جديد من Docker CE) لن تختفي في أي وقت قريبًا أعلم به ، على الرغم من تركيزه الضيق جدًا الآن (وبالتالي من غير المحتمل أن يتم النظر في الميزات / الوظائف الجديدة للدمج).

tianon أنت على حق ، أنا آسف للارتباك. تقول الرسالة على الموقع الإلكتروني boot2docker CLI - للوهلة الأولى لم يكن واضحًا بالنسبة لي ما إذا كان هناك أي فرق. أنا متأكد تمامًا من إمكانية الخلط بين المستخدمين الآخرين ، لأنك على الأرجح ستواجه boot2docker.iso . boot2docker CLI شيء لم تسمع به من قبل ومن الصعب تحديد العلاقة بين المشاريع. OTOH boot2docker.iso بيان "maintenance mode" غامض بنفس الطريقة مثل docker-machine ، والتي استنتجها بناءً على هذا الرد .

لتلخيص الارتباك:

1. "maintenance mode" - غير واضح في كلا المشروعين ، هل يمكنني استخدام ذلك للإنتاج في الأعمال الصغيرة؟
2. يقترح كل من المطورين / المشرفين الرئيسيين على المشروعين استخدام مشاريع أخرى يبدو أنها لا تغطي جميع حالات الاستخدام المدعومة مسبقًا

سيكون من الناحية المثالية الحصول على بيان واضح من tianon و @ shin - إذا كان استخدام docker-machine مناسبًا للإنتاج؟

لا يمكنني التحدث عن Docker Machine ، لكن boot2docker لم يكن أبدًا خيارًا جيدًا للإنتاج ؛ هدفها هو التطوير / استخدام محطة العمل الشخصية.

راجع أيضًا الملاحظات المضافة على https://github.com/boot2docker/boot2docker#readme ، حيث حاولت توضيح ما نعنيه بوضع الصيانة وأن b2d ليس مقصودًا ولا موصى به لأحمال عمل الإنتاج.

مثل كثيرين آخرين ، شعرت بالإحباط لمعرفة المزيد عن هذا من Github Issues ، بعد أن بذلت جهدًا في استخدام آلة لعميل SMB

لقد قمت بإنشاء علاقات عامة لتحديث الوثائق الرسمية ، مع إضافة إرشادات حول وضع صيانة الجهاز.

راجع https://github.com/docker/docker.github.io/pull/9239

سيكون من الجيد تغيير عامل الإرساء للبدء أيضًا https://docs.docker.com/get-started/part4/

تحرير: العثور على حل وهو تثبيت docker-ce على مثيل aws ec2 ، ثم يقوم منفذ ssh بإعادة توجيه برنامج Docker daemon.

ssh -NL localhost:23750:/var/run/docker.sock -i ***.pem ubuntu@***.compute.amazonaws.com
docker -H tcp://localhost:23750 run hello-world

🎉

لقد بدأت في استخدام جهاز docker-machine مؤخرًا لأنه تم تثبيته مع Docker Desktop وأدركت أنه كان بإمكاني تشغيل عامل الإرساء على مثيلات aws أقوى بكثير من الجهاز المحلي. الجميل هو أن التطبيقات المحلية التي تستخدم أوامر عامل ميناء ، مثل Visual Studio Code ، يمكن أن تعمل مع حاويات آلة الرصيف كما لو كانت تعمل محليًا.

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

يمكن أن أكون سوء فهم. هل توجد استراتيجية ترحيل للقيام بما وصفته أعلاه؟

نحن نستخدم GitLab ، مع أداة GitLab Runner الخاصة بهم لتوفير مثيلات EC2 Spot بشكل ديناميكي لتشغيل وظائف CI / CD. يستخدم GitLab Runner جهاز Docker لإجراء توفير الجهاز هذا.

لقد قررنا نقل جميع الخدمات من Ubuntu (المتضخمة) لصالح Amazon Linux 2. ومن دواعي سروري أن PR # 3609 سيسمح بذلك.

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

نظرًا لأن الرجال في Gitlab يحتفظون بالفعل بشوكة ، فربما يكونون مهتمين بالعناية بهذا الريبو؟

@ usha-mandya @ Dawn-Wood أي تحديث على Docker / docker.github.io # 9239؟ كتذكير ، فإنه يضيف تحذيرات استشارية على جميع صفحات Docker Machine. تم دمج هذا ، ولكن تم التراجع بعد ذلك أثناء حدوث انقسام المؤسسة حتى يتمكن yall من اتخاذ بعض القرارات بشأن مستقبل DM. سيكون من الجيد الحصول على هذا الاستشارة إذا كانت DM ستستمر في وضع الصيانة

AFAIK ، أحدث إصدار من Docker Desktop لم يعد يتضمن docker-machine

AFAIK ، أحدث إصدار من Docker Desktop لم يعد يتضمن جهاز الإرساء

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

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

نحن نستخدم بشكل كبير آلة الإرساء لإدارة وصيانة آلات الرصيف المشتركة القائمة على booot2docker لبيئات DEV الداخلية وبيئات التدريج باستخدام برنامج التشغيل Hyper-V (لذلك ، نحن نوفر boot2docker hyper-v VMs باستخدام آلة الإرساء). لذلك على الرغم من أن لدينا عملاء لينكس وماك وبالتالي نستخدم عامل الإرساء لنظام التشغيل windows / os x ، ما زلنا نعتمد بشدة على آلة الإرساء لأشياء CI / CD الخاصة بنا.

لست على علم بأي بديل مشابه لهذا الإعداد - هل أفتقد شيئًا واضحًا هنا؟

يمكنك دائمًا تنزيل أحدث برنامج ثنائي مع الشراب (macOS) وبشكل مباشر
من الريبو. لا يزال يتم صيانته (بقع) ولكن يتم ببطء
تم التخلص التدريجي من أدوات مثل Docker Desktop.
https://github.com/docker/machine/releases

يوم الاثنين ، 27 يناير 2020 الساعة 11:47 صباحًا ، كتب sambernet [email protected] :

لم يعد AFAIK ، أحدث إصدار من Docker Desktop يتضمن ملفات
آلة عامل ميناء

لم يعد AFAIK ، أحدث إصدار من Docker Desktop يتضمن ملفات
آلة عامل ميناء

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

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

نحن نستخدم آلة الإرساء بشكل كبير لإدارة وصيانة المشتركة
آلات الرصيف القائمة على booot2docker للتطوير الداخلي والتنظيم المرحلي
البيئات التي تستخدم برنامج التشغيل Hyper-V (لذلك ، نحن نوفر boot2docker hyper-v
الأجهزة الافتراضية التي تستخدم آلة عامل إرساء). لذلك على الرغم من أن لدينا عملاء Linux و mac و
وبالتالي نستخدم عامل الإرساء لنظام التشغيل windows / os x ، ما زلنا نعتمد بشدة على آلة الإرساء
لأشياء CI / CD.

لست على علم بأي بديل مشابه لهذا الإعداد - هل أنا مفقود
شيء واضح هنا؟

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/machine/issues/4537؟email_source=notifications&email_token=AAGBNX2APIHK6CBNGSAMLDDQ74FYPA5CNFSM4FJ53G3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63L ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAGBNXZV7PCYP3TLWSZ7QODQ74FYPANCNFSM4FJ53G3A
.

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

تصدير DOCKER_HOST = ssh: // user @ host قد يعمل من أجلك

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

يمكنك استخدام Vagrant لذلك ربما؟ أو يمكنك الاستمرار في استخدام docker-machine ...

لكن سيتعين عليك المجيء إلى هنا من أجل الثنائيات ، لأنها لم تعد جزءًا من Docker (سطح المكتب)

لست على علم بأي بديل مشابه لهذا الإعداد - هل أفتقد شيئًا واضحًا هنا؟

لا يوجد بديل ، لكن الكثير من الناس مهتمون بالاستمرار في استخدام الآلة والآلة libmachine.

بالطبع هناك _بدائل_ (منتجات مختلفة) ، لكن هذا ليس نفس الشيء (مثل الشوكات).

afbjorklund حسنًا ، آمل أن الإرساء ثابتة ... وأود الحصول عليها مباشرة من هنا ، ولكن لسبب ما ، تكون التنزيلات من جيثب بطيئة بالنسبة لي. يأتي أول 10-12 ميغابايت في بضع ثوانٍ (كما أتوقع مع خطي السريع جدًا) ، ثم ينخفض ​​إلى 1-2 كيلو بايت / ثانية ويفشل في النهاية. أعلم أن هذا نوع من خارج الموضوع ، لكنني واثق من أنه ليس خطي ، فهل يخنق جيثب الأشياء لسبب ما ربما؟

إذا لم يكن الأمر مجرد شيء يحدث لك الآن (فقط) ، فمن الأفضل أن تقوم باختبار اتصال دعم GitHub بشأنه.

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

أعتقد في الأصل أن Docker روج لـ Docker EE ، نسخته المدفوعة ، كطريقة رسمية لنشر الحاويات. لذا فقد ألغوا مبادرات Docker machine و Infrakit لأنها كانت تهدد نموذج أعمالهم.

بالإضافة إلى ذلك ، غيرت k8s المشهد تمامًا وكافح Docker للتكيف.

الآن ، بعد أن استحوذت Mirantis على Docker EE ، تسعى Docker إلى نموذج أعمال آخر. أعتقد أن هناك اتجاهًا جديدًا يحاول حقن حزم التطبيقات في نظام k8s وترك نشر k8s نفسه للمجتمع. خاصة وأن k8s ليس جزءًا من Docker CE (على Linux).

K8s ، تتم إدارة OTOH بواسطة Google ، والتي لديها كل الحافز لجعل نشر K8s معقدًا للغاية بحيث يقول الناس حرفيًا "مرحبًا ، Google ، يرجى تثبيت مجموعة K8s لي". وبالتالي قفل في خدمات جوجل السحابية.

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

NitroBAY لأن "دورة حياة البرمجيات" من رمز الخلق إلى التطبيقات التي تعمل على خوادم (وتحديثها في نهاية المطاف على خوادم) معقدة جدا، مع من نصف طن من الطرق ل"الحصول على صور الحاوية بنيت وتحميلها على خوادم" متفاوتة، فإنه من الصعب القول ما يجب أن يكون الحل الخاص بك.

في الأصل ، كان على آلة الرصيف القيام بثلاثة أشياء:

1. توفير أجهزة افتراضية بسيطة على مزودي الخدمات السحابية الرئيسيين ، أو مدير جهاز VM محلي (VirtualBox ، و Hyper-V ، و VMWare ، و Parallels ، وما إلى ذلك)
2. تثبيت عامل ميناء على هذا الجهاز الظاهري ، بما في ذلك شهادة موقعة ذاتيًا وفتح منفذ API TCP
3. من السهل ssh إلى هذا الخادم ، والتحكم في عامل الإرساء عن بُعد باستخدام Docker cli (docker-machine env)

(دعنا ننسى الميزات القديمة مثل إنشاء سرب كلاسيكي)

باستخدام أول واحد "إنشاء Linux VM": أوصيك باستبداله بأداة السحابة المفضلة لكيفية إنشاء الأجهزة الافتراضية. إذا كان محليًا وتريد شيئًا أسرع ثم تثبيت Linux VM ، تحقق من Multass ، وهي طريقتي المفضلة لتدوير Ubuntu VM جديد في دقائق بأمر واحد.

مع الثانية "تثبيت عامل إرساء على جهاز Linux VM": يمكنك تثبيت عامل إرساء على أي جهاز افتراضي حديث باستخدام نص التثبيت أو المستندات الرسمية لتوزيع نظام التشغيل الخاص بك . تحتوي معظم السحب على صورة رسمية بها عامل إرساء بالفعل ، كخيار.

لم يكن Docker قادرًا أبدًا على حل جميع مشكلات CI / CD الخاصة بك ، وآلة docker هي في الحقيقة مجرد أداة توفير VM وأداة تثبيت أساسية ، لذلك احتاج الكثير من الأشخاص إلى حل أكثر مرونة وقابلية للصيانة (على سبيل المثال ، لا تشارك آلة الإرساء بسهولة تكوينات الخادم بين الأجهزة). لم يقصد فريق Docker مطلقًا أن تحل الأداة الآلية كل هذه المشكلات. لا يزال يعمل حتى اليوم لتلك الأشياء الأصلية ، لذلك لا تتردد في استخدامه طالما أنه يعمل من أجلك. ما زلت أستخدمه شهريًا ، ومنذ عام 2015.

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

على سبيل المثال ، فيما يتعلق بالرقم 3 أعلاه "التحكم في عامل الإرساء عن بُعد" ، كنت دائمًا أحب أن توفر آلة الرصيف شهادة موقعة ذاتيًا لمصادقة واجهة برمجة التطبيقات وتسمح لي بتغيير بيئة عامل الإرساء محليًا حتى تتمكن من التحكم في الخادم البعيد. تم استبدال هذه الطريقة القديمة بطريقة إنشاء نفق SSH الأسهل (والأكثر مرونة وأمانًا) لـ Docker CLI منذ عام 2018. وهذا يعني أن كل ما تحتاجه هو القدرة على SSH إلى الخادم ، ويمكنك إخبارك المحلية docker cli لاستخدام ذلك بدلاً من "مأخذ التوصيل TCP المفتوح" التقليدي. هذا يعطيني القدرة على عدم الاضطرار مطلقًا إلى استخدام SSH يدويًا إلى خادم يقوم بتشغيل عامل الإرساء لمجرد "تشغيل عامل الإرساء". أريد فقط إخبار عامل الإرساء المحلي CLI الخاص بي بمكان الاتصال به عبر إحدى طريقتين: لدي عرض توضيحي سريع له هنا باستخدام طريقة DOCKER_HOST env ، وكان لدينا عرض توضيحي في عرضي المباشر الصيف الماضي لميزة السياق الجديدة ، مما يتيح لك تخزين قائمة بخوادم عامل الإرساء مباشرة في Docker CLI واستخدام SSH أو TCP للتحكم فيها عن بُعد.

أيضًا ، InfraKit هي أداة لمنشئي النظام (ppl الذين قاموا بإنشاء أنظمة تشغيل Linux مخصصة) ، وليس لمستخدمي Linux مثلنا الذين يريدون توزيع Linux عادي تم إنشاؤه باستخدام مضيفنا وتثبيت عامل إرساء عليه.

WowBretFisher شكرا جزيلا على إجابتك التفصيلية للغاية. أنا متأكد من أنها ستعتبر أيضًا هدية ذهبية من قبل الناس في المستقبل الذين سيقرؤون لك.
بالنسبة للسجل ، انتهى بي الأمر بإنشاء نص برمجي يقوم بتحميل config.json الخاص بي على الجهاز البعيد (حتى يتمكن من تنزيل صورتي الخاصة) وملف الإنشاء. ثم تنفيذ "نشر مكدس عامل الإرساء"
يبدو نشر بلدي مثل هذا

#!/bin/bash
ssh -o StrictHostKeyChecking=no -l root "$HOST" root@$HOST "mkdir /opt/app; mkdir /root/.docker"
source ./devops/generate-branch-hostname.sh
scp ./devops/docker-compose-prod.yml root@$HOST:/opt/app/docker-compose-prod.yml
scp $HOME/.docker/config.json root@$HOST:/root/.docker/config.json
echo "BRANCH_HOSTNAME=$BRANCH_HOSTNAME"
ssh root@$HOST "export BRANCH_HOSTNAME=$BRANCH_HOSTNAME; docker stack deploy --compose-file /opt/app/docker-compose-prod.yml webapp --with-registry-auth"

(من الواضح أن BRANCH_HOSTNAME ليست هناك حاجة إلى نطاقات فرعية مختلفة بناءً على فرع Git الذي يقوم بتشغيل البرنامج النصي الخاص بي (أستخدم CI / CD))
وما زلت أستخدم أداة إنشاء عامل الإرساء للحصول على عامل ميناء على خادم ubuntu البعيد VPS.

على أي حال ، فإن آلة الإرساء ليست فكرة جيدة على CI / CD لأن شهادة المشاركة ليست سهلة (إنها مجلد كامل) وقد تؤدي إعادة إنشاء الشهادة إلى إيقاف Docker لذا فهي ليست خيارًا أيضًا.

ما زلت أعتقد أنه يجب أن توجد أداة (من صنع المجتمع أو بواسطة عامل ميناء) توفر DOCKER_HOST وما إلى ذلك وتستخدم ببساطة مفتاح SSH. سيكون أسهل من "scp" و "ssh".

تبين أن آلة Docker لا يمكن تجنبها.

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

ما زلت أعتقد أنه يجب أن توجد أداة (من صنع المجتمع أو بواسطة عامل ميناء) توفر DOCKER_HOST وما إلى ذلك وتستخدم ببساطة مفتاح SSH. سيكون أسهل من "scp" و "ssh".

فقط قم بعمل export DOCKER_HOST=ssh://[email protected]

ملاحظة إذا تم تعطيل تسجيل الدخول إلى ssh لمستخدم root ، فيمكنك استخدام مستخدم غير جذر user عبر
export DOCKER_HOST=ssh://[email protected] بعد إضافة user إلى مجموعة docker باستخدام sudo usermod -aG docker user . (تم اختباره على Ubuntu 18.04)

أي بديل للعب مع Docker Swarm متعدد العقد على Windows؟ يوضح البرنامج التعليمي السرب أن هذا غير ممكن حاليًا على Windows بدون Docker Machine:

حاليًا ، لا يمكنك استخدام Docker Desktop لنظام التشغيل Mac أو Docker Desktop لنظام التشغيل Windows وحده لاختبار سرب متعدد العقد. ومع ذلك ، يمكنك استخدام الإصدار المضمّن من Docker Machine لإنشاء عُقد السرب (انظر بدء استخدام Docker Machine وجهاز افتراضي محلي) ، ثم اتبع البرنامج التعليمي لجميع ميزات العقد المتعددة.

أستخدم https://multipass.run/ لإنشاء العديد من أجهزة Ubuntu VM بسرعة. بنفس سرعة آلة الرصيف. شاهد عرضًا توضيحيًا لكيفية استخدامه لسرب من 3 عقد: https://www.pscp.tv/BretFisher/1mrGmQvNEWBGy؟t=

تم استبدال استخدام سطح المكتب الخاص به في الغالب بواسطة منتج Docker Desktop.

ملاحظة للجميع في هذا الموضوع: Docker Desktop ليس برنامجًا مجانيًا ، وليس مفتوح المصدر ، ويحتوي على الكثير من برامج التجسس المضمنة فيه ، لذلك قد ترغب في التفكير مرتين في اتباع مسار الترقية هذا.

في حال كان هذا مفيدًا لشخص ما ، فإليك نص برمجي لتثبيت عامل الإرساء على مضيف بعيد (تم اختباره على دبيان 10 = باستر):
https://github.com/minireference/sample-book/blob/master/fabfile.py#L213 -L252

يعتمد على إطار عمل أتمتة الخادم المسمى Fabric (على وجه التحديد fab-classic github and docs ]. حتى إذا كنت لا تريد استخدام Fabric ، يمكنك بسهولة قراءة الأوامر وتشغيلها يدويًا وتحويلها إلى نص برمجي bash ، حيث لا يوجد شيء خيالي.

بعد ذلك ، قم بتشغيل export DOCKER_HOST=ssh://[email protected] وستعود إلى ما كانت عليه الأمور عند استخدام آلة الرصيف.

ملاحظة للجميع في هذا الموضوع: Docker Desktop ليس برنامجًا مجانيًا ، وليس مفتوح المصدر ، ويحتوي على الكثير من برامج التجسس المضمنة فيه ، لذلك قد ترغب في التفكير مرتين في اتباع مسار الترقية هذا.

sneak "طن من برامج التجسس" هل تشير إلى إعداد التفضيلات "إرسال إحصائيات الاستخدام" الذي يقول "إرسال تقارير الأخطاء وإصدار النظام واللغة بالإضافة إلى معلومات دورة حياة Docker Desktop (على سبيل المثال ، البدء ، والتوقف ، وإعادة التعيين)." ، التي يمكن إيقافها؟

لست مهتمًا بقضاء الوقت في مناقشة برامج التجسس الخاصة والمغلقة المصدر بشكل أكبر.

قزم منخفض الجودة

يتطلب التصيد حيلة. أنا صادق ، وتصريحاتي دقيقة:

• سطح المكتب عامل الملكية

• docker desktop هو برنامج مغلق المصدر

• يتجسس عامل ميناء سطح المكتب على مستخدميه دون الحصول على موافقة للقيام بذلك (كما يفعل جهاز الرصيف)

من هذه النقاط المذكورة أعلاه ، قد يستنتج الشخص العاقل أن Docker-the-company لا تهتم بحريات البرامج أو خصوصية المستخدم أو موافقة المستخدم على المراقبة.

أنا على GitHub ومواقع أخرى شبيهة للعمل على برمجيات حرة ومفتوحة المصدر ، والمشاريع غير الحرة مثل docker desktop هي ببساطة إلهاء عن العمل على البرمجيات الحرة التي تفيد الجميع ؛ لا أرغب في تحويل وقتي أو انتباهي إلى مثل هذه الأشياء.

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

في حال كان هذا مفيدًا لشخص ما ، فإليك نص برمجي لتثبيت عامل الإرساء على مضيف بعيد (تم اختباره على دبيان 10 = باستر):
https://github.com/minireference/sample-book/blob/master/fabfile.py#L213 -L252

يعتمد على إطار عمل أتمتة الخادم المسمى Fabric (على وجه التحديد fab-classic github and docs ]. حتى إذا كنت لا تريد استخدام Fabric ، يمكنك بسهولة قراءة الأوامر وتشغيلها يدويًا وتحويلها إلى نص برمجي bash ، حيث لا يوجد شيء خيالي.

بعد ذلك ، قم بتشغيل export DOCKER_HOST=ssh://[email protected] وستعود إلى ما كانت عليه الأمور عند استخدام آلة الرصيف.

ivanistheone لا ليس كذلك. docker-machine (كان؟) رائعًا لأنه يستخدم أيضًا جميع واجهات برمجة التطبيقات في مختلف موفري السحابة لإنشاء أجهزة في CLI بطريقة موحدة. بالطبع ، هناك gcloud ، az ، وما إلى ذلك ، لكن لكل منها خيارات ودلالات مختلفة. docker-machine هو CLI واحد لكل منهم. يجعل العمل مع السحب المختلطة أسهل قليلاً ...