Machine: فشل إنشاء الجهاز باستخدام أحدث Docker

نفس المشكلة هنا

docker-machine create 
    --driver=digitalocean
    --digitalocean-access-token=XXX 
    --digitalocean-size=2gb
    machinename

بالأمس ، عمل نفس الأمر بشكل جيد مع إصدار عامل الإرساء 17.05.0-ce
اليوم لن يبدأ عامل إرساء الجهاز الجديد (17.06.0 م)
لقد حاولت عدة مرات.

يمكنني تأكيد هذا أيضًا:

dm create -d digitalocean \
--digitalocean-access-token XXX \
--digitalocean-size 4gb machine

أنا أستخدم هذا كحل بديل:

إنشاء آلة عامل ميناء \
- سائق amazonec2 \
--engine-install-url = https://web.archive.org/web/20170623081500/https : //get.docker.com

أو
--engine-install-url = https://releases.rancher.com/install-docker/17.05.sh

لدي نفس المشكلة.

إصدار عامل ميناء: إصدار Docker 17.06.0-ce
إصدار آلة عامل الإرساء: 0.12.0 ، بناء 45c69ad

docker-machine create --driver amazonec2 --amazonec2-region eu-west-1 --amazonec2-instance-type t2.small --amazonec2-access-key XXX --amazonec2-secret-key XXX test-create-machine

29 يونيو 12:26:56 ip-172-31-10-149 systemd [1]: بدء تشغيل محرك حاوية تطبيق Docker ...
29 يونيو 12:26:56 ip-172-31-10-149 docker [5234]: docker daemon غير مدعوم على Linux. الرجاء تشغيل dockerd مباشرة

docker daemon غير مدعوم على Linux. الرجاء تشغيل dockerd مباشرة

لقد تمكنت من جعله يعمل مع هذا العلاقات العامة
https://github.com/docker/machine/pull/4128

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

gnomus سوبر ، هذا مثير للاهتمام! أتساءل لماذا كان يعمل في 17.05.0 م.

therealppa haahaha رهيبة! كنت أتساءل كيف يمكنني الحصول على الإصدار القديم من هذا البرنامج النصي ، أو ما إذا كان النص المباشر يأخذ المعلمات لتثبيت الإصدار الأقدم. web.archive.org بالتأكيد لم يحدث لي.

dminkovsky لا أعتقد أنه سيعمل إلى الأبد ، إذا نظرت إلى البرنامج النصي ، فلن يحدد الإصدار في أي مكان ... ومع ذلك ، فهو يعمل الآن.

therealppadminkovsky إصلاح على المدى الطويل هو تغيير خط 457 من البرنامج النصي من

$sh_c 'apt-get install -y -q docker-ce'

إلى

$sh_c "apt-get install -y -q docker-ce=17.05.0~ce-0~$lsb_dist-$dist_version"

نأمل أن يتم إطلاق الإصدار الثابت من آلة الإرساء قريبًا.

نفس الشيء بالنسبة لي
نجعله يعمل باستخدام "dockerd" بدلاً من "docker daemon" في الملف /etc/systemd/system/docker.service.d/10-machine.conf

@ fabio-barile ماذا عن --storage-driver aufs arg؟ لن أبدأ ما لم أتخلص من ذلك أيضًا.

dminkovsky كان لدي نفس المشكلة في قياس تلقائي ci مع gitlab ، حصلت على مشكلة aufs + مشكلة dockerd ، وكان علي حلها بتحديد التراكب في برنامج تشغيل التخزين.

بالإضافة إلى مشكلة برنامج تشغيل التخزين ، أرى أيضًا أخطاء التحقق من الشهادات التي تم إنشاؤها بواسطة gitlab-runner (9.3.0). JustEra هل

http: TLS handshake error from ...:
 tls:
  failed to verify client's certificate: x509:
   certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "unknown")

ERROR: Error creating machine:
 Error checking the host:
  Error checking and/or regenerating the certs:
   There was an error validating certificates for host "...":
    remote error: tls: bad certificate  driver=amazonec2 name=...

مشكلة برنامج تشغيل التخزين الثابتة هذه بالنسبة لي (فقط أزلت تلك المعلمة ؛ لـ systemd فقط). قم بالتقديم أعلى https://github.com/docker/machine/pull/4128 وأعد الإنشاء:

diff --git a/libmachine/provision/systemd.go b/libmachine/provision/systemd.go
index 90d02603..05d63bb5 100644
--- a/libmachine/provision/systemd.go
+++ b/libmachine/provision/systemd.go
@@ -53,7 +53,7 @@ func (p *SystemdProvisioner) GenerateDockerOptions(dockerPort int) (*DockerOptio

        engineConfigTmpl := `[Service]
 ExecStart=
-ExecStart=/usr/bin/` + arg + ` -H tcp://0.0.0.0:{{.DockerPort}} -H unix:///var/run/docker.sock --storage-driver {{.EngineOptions.StorageDriver}} --tlsverify --tlscacert {{.AuthOptions.CaCertRemotePath}} --tlscert {{.AuthOptions.ServerCertRemotePath}} --tlskey {{.AuthOptions.ServerKeyRemotePath}} {{ range .EngineOptions.Labels }}--label {{.}} {{ end }}{{ range .EngineOptions.InsecureRegistry }}--insecure-registry {{.}} {{ end }}{{ range .EngineOptions.RegistryMirror }}--registry-mirror {{.}} {{ end }}{{ range .EngineOptions.ArbitraryFlags }}--{{.}} {{ end }}
+ExecStart=/usr/bin/` + arg + ` -H tcp://0.0.0.0:{{.DockerPort}} -H unix:///var/run/docker.sock --tlsverify --tlscacert {{.AuthOptions.CaCertRemotePath}} --tlscert {{.AuthOptions.ServerCertRemotePath}} --tlskey {{.AuthOptions.ServerKeyRemotePath}} {{ range .EngineOptions.Labels }}--label {{.}} {{ end }}{{ range .EngineOptions.InsecureRegistry }}--insecure-registry {{.}} {{ end }}{{ range .EngineOptions.RegistryMirror }}--registry-mirror {{.}} {{ end }}{{ range .EngineOptions.ArbitraryFlags }}--{{.}} {{ end }}

بالنسبة لأي شخص يريد إصدارًا أقدم معينًا ، فإننا (Rancher) نحتفظ بنصوص get.docker.com معدلة قليلاً لتثبيت كل منها:

http://rancher.com/docs/rancher/v1.6/en/hosts/#supported -docker-version

@ fabio-barile أعلاه صحيح تمامًا. كيف "الاختبار" يسمح بإطلاق مثل هذه الأشياء ، لا يمكن تخيله.

مزيد من المعلومات هنا: https://github.com/docker/for-linux/issues/11#issuecomment -312143765

@ vincent99 ... دائما أحب

+1
أتحقق كل يوم من إصدار جديد لآلة الرصيف ... هذا الخطأ يقتلني :-)

في الوقت الحالي ، أقوم بإضافة /etc/systemd/system/docker.service.d/20-machine.conf الذي يتجاوز 10-machine.conf بسطر الأوامر الصحيح. وبهذه الطريقة ، فإن أمر عامل الإرساء والآلة الذي عادة ما يكسرها ، لا يفعل. بالطبع كلما استغرق الأمر وقتًا أطول لإصلاح هذا في الإصدار ، زاد العمل الذي أعيده إلى كل شيء!

نشكرك على التقسيم الرائع لتفاصيل المشكلة - نحن نبحث في الأمر لمحاولة اكتشاف الخطأ الذي حدث.

المتعلقة بـ https://github.com/docker/for-linux/issues/11#issuecomment -312143765

لذلك لا يتعلق هذا بالبرنامج النصي للتثبيت على get.docker.com ولكنه مرتبط بمقارنة الإصدارات التي لا تعمل بشكل صحيح مع كون 17.06.0-ce أول من قام رسميًا بإيقاف docker daemon ولهذا السبب نحن رؤية الفشل.

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

seemethere يبدو جيدًا ، شكرًا. أحب أن أسمع عن الاختبار.

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

يعمل الإصدار 0.12.1 على إصلاح هذا الخطأ. شكرا للجميع على صبركم ومساعدتكم.

@ shin- شكرا على الإصلاح السريع! نتطلع إلى استخدامه.

@ shin- يعمل هذا التصحيح على إصلاح الجزء docker daemon -> dockerd الجزء ، لكن Docker لا يزال لا يبدأ على الجهاز بسبب

dockerd[6407]: Error starting daemon: error initializing graphdriver: driver not supported

@ shin- لقد تمكنت من التغلب على مشكلة برنامج تشغيل التخزين عن طريق إضافة --engine-storage-driver=overlay (https://github.com/docker/machine/issues/3895#issuecomment-270934728). إذن هذا هو استدعائي بالكامل docker-machine .

docker-machine -D create \
    --driver google \
    --google-project $project \
    --google-zone $zone \
    --google-machine-type $type \
    --google-disk-size $size \
    --google-preemptible \
    --engine-storage-driver=overlay \
    $name

بدون --engine-storage-driver=overlay ما زال فشل مع

dockerd[6407]: Error starting daemon: error initializing graphdriver: driver not supported

كما كان من قبل وكما في # 3895

هل رأيت السجل الذي أوضح سبب تحطمها؟

يوم الجمعة ، 7 يوليو ، 2017 الساعة 9:39 صباحًا ، Seweryn Zeman [email protected]
كتب:

@ shin- https://github.com/shin- للأسف 0.12.1 لم يصلح هذا
لي.

$ عامل ميناء -v
إصدار Docker 17.06.0-ce ، الإصدار 02c1d87
$ آلة عامل ميناء -v
إصدار آلة الإرساء 0.12.1 ، بناء c8b17e8

أنا أقوم بإنشاء آلة amazonec2 مع --amazonec2-region = eu-central-1
مما يخلق لي ami-fe408091.

الناتج من إنشاء آلة الرصيف هو:

تشغيل عمليات تحقق ما قبل الإنشاء ...
جاري إنشاء آلة ...
(test-dm) جاري تشغيل مثيل ...
في انتظار تشغيل الجهاز ، قد يستغرق ذلك بضع دقائق ...
الكشف عن نظام التشغيل للمثيل الذي تم إنشاؤه ...
في انتظار توفر SSH ...
جاري الكشف عن الموفر ...
التزويد مع ubuntu (systemd) ...
تثبيت Docker ...
جاري نسخ الشهادات إلى دليل الجهاز المحلي ...
جاري نسخ الشهادات إلى الآلة البعيدة ...
جارٍ إعداد تكوين Docker في البرنامج الخفي البعيد ...
خطأ في إنشاء الجهاز: خطأ في تشغيل التوفير: خطأ أمر ssh:
الأمر: sudo systemctl -f start docker
err: حالة الخروج 1
الإخراج: فشلت مهمة docker.service بسبب إنهاء عملية التحكم مع وجود رمز خطأ. راجع "systemctl status docker.service" و "journalctl -xe" للحصول على التفاصيل.

الإخراج من الآلة التي تم إطلاقها هو:

$ systemctl status docker.service
● docker.service - محرك حاوية تطبيق Docker
مُحمَّل: تم تحميله (/lib/systemd/system/docker.service ؛ مُمكّن ؛ الإعداد المسبق للمورد: ممكّن)
إسقاط في: /etc/systemd/system/docker.service.d
└─10-machine.conf
نشط: غير نشط (ميت) (النتيجة: رمز الخروج) منذ الجمعة 2017-07-07 13:34:47 UTC ؛ منذ 36 ثانية
المستندات: https://docs.docker.com
العملية: 5522 ExecStart = / usr / bin / dockerd -H tcp: //0.0.0.0 : 2376 -H unix: ///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacer
معرف المنتج الرئيسي: 5522 (الرمز = خرج ، الحالة = 1 / فشل)

Jul 07 13:34:46 test-dm systemd [1]: docker.service: دخلت الوحدة في حالة فاشلة.
Jul 07 13:34:46 test-dm systemd [1]: docker.service: فشل مع النتيجة "كود الخروج".
Jul 07 13:34:47 test-dm systemd [1]: docker.service: انتهى وقت إيقاف الخدمة وجدولة إعادة التشغيل.
Jul 07 13:34:47 test-dm systemd [1]: توقف محرك حاوية تطبيق Docker.
Jul 07 13:34:47 test-dm systemd [1]: docker.service: طلب البدء يتكرر بسرعة كبيرة.
Jul 07 13:34:47 test-dm systemd [1]: فشل بدء تشغيل Docker Application Container Engine.

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

@ dminkovsky شكرا على الحل. قررت استخدام overlay2 نظرًا لأنه أحدث إصدار من برنامج التشغيل بدلاً من ذلك.

هل تعرف ما إذا كان هناك حل بديل لـ docker-machine rm {instance-name} أيضًا؟ أتلقى خطأً متعلقًا بـ EOF ويترك بقايا أزواج رئيسية على سحابة AWS تمنعني من إعادة إنشاء المثيل.

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

بدون --engine-storage-driver=overlay لا يزال فشل مع
dockerd[6407]: Error starting daemon: error initializing graphdriver: driver not supported
كما كان من قبل وكما في # 3895

هل لدينا أي مشكلة لهذه الحالة الخاصة لاستخدام تخزين محرك AUFS؟

تضمين التغريدة

هل لدينا أي مشكلة لهذه الحالة الخاصة لاستخدام تخزين محرك AUFS؟

لقد رأيت https://github.com/docker/machine/issues/3895 ، وهو مفتوح والذي أشرت إليه أيضًا.

ومن المثير للاهتمام ، أنني لم أعد أرى هذا الخطأ. أحصل على --storage-driver overlay

تضمين التغريدة

قررت استخدام overlay2 نظرًا لأنه أحدث إصدار من برنامج التشغيل بدلاً من ذلك.

أوه رائع ، شكرًا ، لم أكن أعرف ذلك.

هل تعرف ما إذا كان هناك حل بديل لـ docker-machine rm {اسم المثيل} أيضًا؟

لست متأكدًا ، لم يكن لدي هذا الخطأ. أستخدم docker-machine rm -f عندما يتم إنهاء الجهاز ولن يستجيب. باستخدام -f ، يزيل docker-machine rm جهاز VM والأقراص المرتبطة به حتى لو لم يتمكن من الوصول إلى الصندوق.

dminkovsky هل يمكنك إنشاء إصدار جديد لهذا؟ لا علاقة لها بمشكلة dockerd / docker daemon ، لذا يجب علينا التعامل معها بشكل منفصل أيضًا. ويرجى الإشارة إلى نظام التشغيل الذي توفره أيضًا :)

@ shin- أنا بخير. تعمل آلة عامل الإرساء 100٪ الآن بالنسبة لي. هل تشير إلى شيء overlay2؟

تمت معالجة مشكلتي الأخرى المتعلقة بإزالة الآلات في رقم 4187. شكرا.

@ dminkovsky آسف - نعم ، الذي هنا

shin - بعد مواجهة المشكلة في https://github.com/docker/machine/issues/4168 ، حاولت إعادة إنشاء خادم التدريج الخاص بي ووجدت سلسلة من المشكلات مع docker-machine create تم الإبلاغ عنها في عدة تذاكر حديثة:

• https://github.com/docker/machine/issues/4156
• https://github.com/docker/machine/issues/4166
• https://github.com/docker/machine/issues/4189
• https://github.com/docker/machine/issues/4197
• https://github.com/docker/machine/issues/4198

هل هذه كلها مرتبطة؟ ابدأ بتتبع هذه هنا؟ أستطيع أن أؤكد أن هذه المشكلة لا تزال تحدث اليوم.

@ shin- docker-machine v0.12.1 يعرض نفس المشكلة

ما زلت أواجه نفس المشكلة مع الإصدار 0.12.1.

الرجاء التحديث إلى أحدث إصدار موجود على جيثب:
https://github.com/docker/machine/releases/tag/v0.12.2

eamontaaffeajwahcosta

شكرًا لك @ dminkovsky لقد 10-machine.conf لا يتم تجاوزه أثناء التحديث

على الرحب و السعة!

أحدد "تراكب" في خيار سطر الأوامر لمحرك التخزين ومنذ ذلك الحين
تمهيد أجهزتي.

ср، 2 авг. 2017 г. в 12:05، Denis [email protected] :

شكرًا لك dminkovsky https://github.com/dminkovsky كنت أتلقى هذا
خطأ في 0.12.2 اليوم كذلك !!! يبدو أن ملف 10-machine.conf لا
الحصول على تجاوز أثناء التحديث

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

إذا كنت تستخدم أنظمة مع kernel> 4.4 ، أقترح استخدام overlay2 .

لم أتمكن من جعل الآلة تستخدم overlay2 ، وحالة الاستخدام لهذا
لحسن الحظ كان مجرد بناء / قرص مضغوط

ср، 2 авг. 2017 г. 12: 36 مخيط زيمان ، إخطارات github.com:

في حالة استخدام أنظمة مع kernel> 4.4 ، أقترح استخدام overlay2.

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

أيضًا الحصول على هذا الخطأ على 0.12.2 :-(

هذا لا يزال مفتوحا!

ما زلت أرى هذه المشكلة مع docker-machine 0.12.2 . انتقلت إلى الأمام عن طريق إلغاء تثبيت عامل الإرساء على الجهاز المزود ( sudo apt purge docker-ce && sudo apt autoremove ) واستخدمت برنامج تثبيت Rancher الصحيح

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

يمكن أن تؤكد ، لا يزال نفس الخطأ

jhartma أعتقد أنه من الضروري الترقية إلى أحدث إصدار (صورة لينكس) ويعمل

يبدو kassanmoor أن AMI الخاص بي لم يدعمه على AWS ، لقد