Machine: استجابة خطأ من البرنامج الخفي: العميل أحدث من الخادم المزود بـ Docker 1.9 RC3

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

هنا معلومات الإصدار:

> docker-machine -v
docker-machine version 0.5.0-rc3 (a1e610b)
> docker -v
Docker version 1.9.0-rc3, build 2100b94

إنشاء آلة Docker:

> docker-machine create -d=virtualbox lab2
Running pre-create checks...
Creating machine...
Waiting for machine to be running, this may take a few minutes...
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Provisioning created instance...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
To see how to connect Docker to this machine, run: docker-machine env lab2

تم تكوينه كـ:

eval $(docker-machine env lab2)

يعطي docker ps الخطأ التالي:

> docker ps
Error response from daemon: client is newer than server (client API version: 1.21, server API version: 1.20)

هذه آلة تم إنشاؤها حديثًا باستخدام أحدث إصدار من Docker CLI و Docker Machine.

التعليق الأكثر فائدة

هل قمت بتشغيل docker-machine upgrade ؟

ال 72 كومينتر

نعم ، تجربة المستخدم ليست رائعة ولكن إذا كنت ترغب في استخدام ثنائي RC Docker ، فأنت بحاجة إلى تحديد استخدام مرشح إصدار ISO لاستخدام مثل --virtualbox-boot2docker-url https://github.com/tianon/boot2docker-legacy/releases/download/v1.9.0-rc4/boot2docker.iso

لماذا هذه المعاملة الخاصة لـ RC؟

هذا يجعلها غير بديهية.

حسنًا ، ثنائي عميل Docker الخاص بك هو أيضًا RC. كيف تشعر أنه يجب أن يعمل؟

يجب أن يلتقط RC الملف boot2docker.iso تلقائيًا من RC. --virtualbox-boot2docker-url فقط لتجاوز القيمة الافتراضية. ويجب أن يكون الإعداد الافتراضي هو نفسه ثنائي عميل Docker.

أعتقد أنه يمكننا القيام بعمل أفضل بشأن السماح لـ upgrade / create باستخدام RCs الجديدة افتراضيًا ، لكن حاليًا RCs لـ boot2docker التي نحتفظ بها في

تبدو مطابقة boot2docker.iso مع ثنائي عميل Docker بمثابة نهج معقول وبديهي. وسيكون هناك خيار للتجاوز على أي حال.

لا سحر ، فقط بديهية على الأقل بالنسبة لي!

رؤية نفس الخطأ بالضبط مع Docker 1.9.0 و Machine 0.5.0:

~ > docker ps
Error response from daemon: client is newer than server (client API version: 1.21, server API version: 1.20)
~ > docker -v
Docker version 1.9.0, build 76d6bc9
~ > docker-machine -v
docker-machine version 0.5.0 (04cfa58)

لا ترى أي طريقة لإعادة فتح المشكلة الآن.

هل قمت بتشغيل docker-machine upgrade ؟

تم إنشاء هذه الآلة للتو. هل أحتاج إلى تشغيل docker-machine upgrade لذلك أيضًا؟

@ arun-gupta على الأرجح ، لتحديث ذاكرة التخزين المؤقت و / أو في حالة صنع الجهاز قبل حدوث الإصدار الرسمي لـ b2d.

أنشأ nathanleclaire الجهاز منذ 30 دقيقة مرة أخرى ولا يزال docker-compose up -d على docker-compose.yml بنجاح. لكن docker ps يعطي الخطأ مرة أخرى:

> docker ps
Error response from daemon: client is newer than server (client API version: 1.21, server API version: 1.20)

ترقية الجهاز بشكل صريح.

هل يوجد تعيين لـ b2d.iso وإصدار Client / Server API؟

يجب أن يعمل docker-machine upgrade name ، أعتقد أنها "مشكلة في ذاكرة التخزين المؤقت ISO". هل جربت هذا الأمر؟

يتم دائمًا تعيين boot2docker.iso لإصدار Docker المقابل لواجهة برمجة التطبيقات. يمكنك رؤية نسخة ذاكرة التخزين المؤقت في البيانات الوصفية بعمل file $HOME/.docker/machine/cache/boot2docker.iso .

docker-machine upgrade حل المشكلة.

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

: +1: مقابل docker-machine upgrade

+1 لترقية جهاز الرصيف - بافتراض أن الشيء الوحيد الذي تتم ترقيته مرتبط بعمال الشحن ؛)

: +1: مقابل docker-machine upgrade <machine name>

بعد الترقية باستخدام Docker Toolbox ، تم إيقاف الجهاز الافتراضي ولكن تمت ترقيته.
لم يتم إيقاف الجهاز الآخر ، ولم يتم ترقيته.

docker-machine upgrade <machine-name> يعمل أيضًا بالنسبة لي

أنا على نظام التشغيل Windows 10 وشاهدت مشكلة مماثلة اختفت بشكل غريب في الجولة الثانية. هذا ما كان لدي وتسلسل الخطوات.

  1. كنت أستخدم Docker Toolbox 1.8.3 وقررت استخدام الإصدار الأخير 1.9.0c حيث كنت أواجه بعض المشكلات الغريبة.
  2. قمت بتشغيل docker-machine rm default فقط كخطوة أمان
  3. تم تنزيل وتثبيت إصدار صندوق الأدوات 1.9.0c
  4. كان Git هو الشيء الوحيد الذي لم أختاره عند المطالبة وتثبيت كل شيء آخر.
  5. تم إطلاق _Docker Quickstart Terminal_
  6. كل شيء بدا على ما يرام
Creating Machine default...
Running pre-create checks...
Creating machine...
Waiting for machine to be running, this may take a few minutes...
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Provisioning created instance...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
To see how to connect Docker to this machine, run: C:\Program Files\Docker Toolbox\docker-machine.exe env default
Setting environment variables for machine default...



                        ##         .
                  ## ## ##        ==
               ## ## ## ## ##    ===
           /"""""""""""""""""\___/ ===
      ~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ /  ===- ~~~
           \______ o           __/
             \    \         __/
              \____\_______/

docker is configured to use the default machine with IP 192.168.99.100
For help getting started, check out the docs at https://docs.docker.com

7. تم فحصه لمعرفة أنه تم إنشاء الجهاز

$ docker-machine ls
NAME      ACTIVE   DRIVER       STATE     URL                         SWARM
default   *        virtualbox   Running   tcp://192.168.99.100:2376

8. كل شيء بخير حتى الآن ، ولكن

$ docker ps
Error response from daemon: client is newer than server (client API version: 1.21, server API version: 1.20)

9. ماذا لدي؟

$ docker-machine -v
C:\Program Files\Docker Toolbox\docker-machine.exe version 0.5.0 (04cfa58)
$ docker -v
Docker version 1.9.0, build 76d6bc9

10- شغّل ترقية الجهاز كما هو مقترح أعلاه وأحصل على:

$ docker-machine upgrade default
Stopping machine to do the upgrade...
C:\Program Files\Oracle\VirtualBox\VBoxManage.exe showvminfo default --machinereadable failed:
VBoxManage.exe: error: The object is not ready
VBoxManage.exe: error: Details: code E_ACCESSDENIED (0x80070005), component ConsoleWrap, interface IConsole, callee IUnknown
VBoxManage.exe: error: Context: "COMGETTER(SharedFolders)(ComSafeArrayAsOutParam(folders))" at line 2306 of file VBoxManageInfo.cpp
$ docker-machine ls
NAME      ACTIVE   DRIVER       STATE     URL   SWARM
default   -        virtualbox   Stopped
$ docker-machine upgrade default
Error: machine must be running to upgrade.
$ docker-machine start default
Started machines may have new IP addresses. You may need to re-run the `docker-machine env` command.
$ docker-machine ls
NAME      ACTIVE   DRIVER       STATE     URL                         SWARM
default   *        virtualbox   Running   tcp://192.168.99.100:2376
$ docker-machine upgrade default
Stopping machine to do the upgrade...
Upgrading machine default...
Latest release for github.com/boot2docker/boot2docker is v1.9.0

Downloading https://github.com/boot2docker/boot2docker/releases/download/v1.9.0/boot2docker.iso to C:\Users\ssluser\.docker\machine\cache\boot2docker.iso...
Starting machine back up...

11- كل شيء بخير بعد ذلك. يبدو أن مجرد تشغيل الترقية للمرة الثانية يعمل.

@ arun- guptanathanleclaire ترقية عامل تشغيل الآلة [اسم الجهاز] منجم ثابت !!! شكرا جزيلا. FWIW ، هذه الترقية-المزامنة بين العميل والخادم هي في الحقيقة بيتا. أي دورات يتم إنفاقها على تحسين هذا الأمر ستكون محل تقدير كبير!

لا يقتصر هذا على RC3 ولا لآلة الرصيف. إذا كان عميل عامل الإرساء 1.9.x وكان الخادم يقوم بتشغيل docker 1.8.x ، فسيتم ملاحظة رسالة الخطأ. هذا غير عملي للغاية من حيث إدارة عمليات النشر إذا لم يكن لديك أو لا يمكنك تثبيت نفس إصدار محرك عامل الإرساء على جميع الخوادم وجميع العملاء. أنا من رأيي أن هذا كسر خطير للغاية.

أيضًا نفس المشكلة مثل https://github.com/docker/machine/issues/1839

docker-machine upgrade <machine-name> عملت أيضًا بالنسبة لي

docker-machine upgrade <machine-name> لم يعمل معي. اضطررت إلى ترقية جميع الخوادم الخاصة بي إلى إصدار مطور من Docker ، ثم رجعت إلى إصدار سابق مرة أخرى وبدأت في الحصول على:

docker: Error response from daemon: client is newer than server (client API version: 1.22, server API version: 1.21).

بعد الرجوع إلى إصدار أقدم يدويًا ، قمت بتشغيل docker-machine upgrade <machine-name> ، لكن الخطأ لا يزال قائمًا.

خطأي ... كنت بحاجة إلى حذف ثنائي عامل الإرساء الأحدث من طريقي.

ترقية عامل ميناء-آلةعملت معي أيضًا.

إليك كيفية تشغيله بعد تلقي نفس الخطأ لـ 1.10.0-rc1:

docker-machine create -d=virtualbox -virtualbox-boot2docker-url https://github.com/tianon/boot2docker-legacy/releases/download/v1.10.0-rc1/boot2docker.iso docker

اضطررت إلى تشغيل هذا الإصدار v1.10.0-rc2 / de3bb7a (OS X 10.10.5):
docker-machine create -d=virtualbox -virtualbox-boot2docker-url https://github.com/tianon/boot2docker-legacy/releases/download/v1.10.0-rc2/boot2docker.iso docker

boot2docker مهمل. هل هذا حقا هو الحل المقصود للمشكلة؟

لا تزال آلة docker-machine تستخدم boot2docker ISO لبناء الجهاز الظاهري ، وهذا ليس بالأمر غير المعتاد.

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

تم إعلان أن boot2docker مهمل. هل هذا حقا هو الحل المقصود للمشكلة؟

كما يلاحظ superdump ، فإن boot2docker CLI (تم استدعاؤه باستخدام boot2docker في سطر الأوامر) قد تم إهماله ، لكن نظام التشغيل لا يزال قائمًا.

شكرا nathanleclaire و @ superdump للتوضيح !

لقد تمكنت (للأسف مؤقتًا فقط) من حل المشكلة عن طريق تثبيت dmv والتراجع عن طريق

dmv use 1.8.1

ومع ذلك ، عند سحب بعض الصور (ولكن ليس كلها) ، يستمر التبديل إلى docker إلى 1.9.1 ولا يظهر أي شيء تحت docker images (لكن كان من قبل).

ما الذي يجري هنا؟ هل هذه نسخة عربات التي تجرها الدواب / غير مستقرة؟

هناك نسخة B للإصدار المرشح 2

https://github.com/boot2docker/boot2docker/releases/tag/v1.10.0-rc2-b

استعمال
docker-machine create -d=virtualbox -virtualbox-boot2docker-url https://github.com/boot2docker/boot2docker/releases/download/v1.10.0-rc2-b/boot2docker.iso docker

لقد واجهت للتو هذه المشكلة مع جهاز mac المحلي (homebrew) الذي يعمل على 1.10 ، في حين أن آلة الإرساء - في هذه الحالة على google gce ، لن تعمل حتى بعد محاولة ترقية جهاز الإرساء. اضطررت إلى إدخاله يدويًا وإضافة deb repo تحديدًا لفرض الترقية إلى 1.10.

لقد واجهت للتو هذا الشخص على Travis CI:

$ export PATH=/opt/docker:$PATH
$ docker version
Client:
 Version:      1.10.2
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   c3959b1
 Built:        Mon Feb 22 22:37:33 2016
 OS/Arch:      linux/amd64
Error response from daemon: client is newer than server (client API version: 1.22, server API version: 1.20)
The command "docker version" failed and exited with 1 during 

لقد قمت بحلها بعد 3 أيام من التصحيح ، وكتبت الإجابة على StackOverflow ، يجب عليك التحقق منها http://stackoverflow.com/questions/24586573/docker-error-client-and-server-dont-have-same-version / 36298911 # 36298911

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

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

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

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

والغريب في الأمر أن العميل الجديد غير قادر على "التحدث" إلى واجهات برمجة التطبيقات القديمة.

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

لا يوجد سوى خيارين (أي خيار آخر؟).

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

كل ما نحتاج إلى القيام به هنا هو جعل دعم العميل للإصدارات الأقدم API. لماذا لم يكن ذلك أحد متطلبات التصميم أمر غريب.

theSeanBrady Docker Machine si جديد تمامًا.
أنا متأكد من أن دعم مجموعة من واجهات برمجة التطبيقات يمثل إنجازًا مهمًا لهذا المشروع.

هذه ليست مشكلة في آلة الإرساء ، إنها مشكلة في عامل الإرساء.

$ docker --version
Docker version 1.11.0, build 4dc5990
╰$ docker ps
Error response from daemon: client is newer than server (client API version: 1.23, server API version: 1.22)
╰$ brew switch docker 1.10.3
╰$ docker --version
Docker version 1.10.3, build 20f81dd
╰$ docker ps
CONTAINER ID        IMAGE                 COMMAND                  CREATED             STATUS              PORTS                    NAMES

كل ما نحتاج إلى القيام به هنا هو جعل دعم العميل للإصدارات الأقدم API. لماذا لم يكن ذلك أحد متطلبات التصميم أمر غريب.

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

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

ستطلب هذه المصافحة فقط: ما هو إصدار API الذي تستخدمه وقائمة وظائف API التي يمكنها الاستجابة لها. يتم تشغيل وظائف العميل والخوادم معًا بشكل منطقي ويتم تعيين مجموعة مشتركة من الوظائف (مكالمات api) لتكوين خادم العميل.

بناءً على ذلك ، سيعرف العميل الوظائف التي يمكنه الاتصال بها ويرمي خطأً فقط على من لا يمكنه ذلك.
IE [NotSupported] - عذرًا ، الخادم غير قادر على الاستجابة لـ _______. يرجى تحديث الخادم إلى Docker nn.nnn.nn أو تعديل الحاوية الخاصة بك لتتوافق مع Docker nn.nnn.nn

الفكرة هي أنه إذا كانت واجهات برمجة التطبيقات تختلف بنسبة 1٪ فقط ، فإن 1٪ لا يعطل استخدام الـ 99٪ الأخرى التي هي على الأرجح كل ما يحتاجه العميل.

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

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

ctroncoso أرى وجهة نظرك ، لكن إذا قمت بتشغيل time docker info التواصل مع خادم في amazonec2 / us-east-1 يستغرق الأمر ما يزيد قليلاً عن

على أي حال ، لا يوجد شيء يمكن للآلة فعله بشأن هذه المشكلة ، لذا أقترح فتح مشكلة (ابحث عن المشكلات الموجودة أولاً) على https://github.com/docker/docker لمشاركة أفكارك مع المنبع إذا رغبت في ذلك.

nathanleclaire متأكد من أنه سيكون كذلك ، ولكن هل

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

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

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

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

يوم الخميس ، 21 أبريل 2016 الساعة 2:47 مساءً ، ناثان ليكلاير [email protected]
كتب:

كل ما نحتاج إلى القيام به هنا هو جعل دعم العميل للإصدارات الأقدم API.
لماذا لم يكن ذلك أحد متطلبات التصميم أمر غريب.

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/docker/machine/issues/2147#issuecomment -213107758

يقوم العميل بالفعل بالاستعلام عن الإصدار من الخادم

هل يمكنك توجيهي إلى مكان حدوث هذا في رمز عميل Docker؟

لا أعرف حقًا Go ، لكنني متأكد تمامًا أن هذا ما يفعله هذا:

https://github.com/docker/docker/blob/eab65e438ecc406baf935c8df544982164cff72f/integration-cli/docker_api_test.go

في كلتا الحالتين ، ترى نمطًا للاستعلام عن إصدار API في جميع أنحاء المشروع.

يوم الخميس ، 21 أبريل 2016 ، الساعة 5:25 مساءً ، ناثان ليكلاير [email protected]
كتب:

يقوم العميل بالفعل بالاستعلام عن الإصدار من الخادم

هل يمكنك توجيهي إلى مكان حدوث هذا في رمز عميل Docker؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/docker/machine/issues/2147#issuecomment -213157495

ها هي طريقتي لحل هذه المشكلة:
بالأمس ، عندما صنعت أحدث إصدار من عامل الإرساء من https://github.com/docker/docker.git بالإشارة إلى https://docs.docker.com/v1.5/contributing/devenvironment/ وقم بتعديل عميل docker القديم ثنائي مع الجديد.
حدث "العميل أحدث من الخادم مع Docker" ، وفشل برنامج Docker daemon في إعادة التشغيل:

  • / bin / systemctl status docker.service
    ● docker.service - محرك حاوية تطبيق Docker
    مُحمَّل: تم تحميله (/lib/systemd/system/docker.service ؛ مُمكّن ؛ الإعداد المسبق للمورد: ممكّن)

ولكن هناك ثنائيات خفية تم إنشاؤها في الدليل:
الحزم / الأحدث / البرنامج الثنائي
يجب إضافة الدليل إلى المسار ، أو نسخ dockerd و containerd إلى / usr / bin /
_copy dockerd / usr / bin / docker
نسخ docker-containerd / usr / bin / containerd
نسخ ../binary-client/docker / usr / bin_

ثم أقوم بتعديل /etc/init.d/docker لإضافة دليل dockerd إلى PATH مع الخطوط المميزة

DOCKERD = / home / master / github.com / docker / bundles / 1.12.0-dev / binary-daemon
تصدير PATH = $ PATH: $ DOCKERD

BASE = dockerd

تعديلها في / etc / default / $ BASE (/ etc / default / docker)

DOCKER = / usr / bin / $ BASE

DOCKER = DOCKERD دولار / قاعدة دولار
هذا هو ملف pid الذي يديره عامل التحميل نفسه
DOCKER_PIDFILE = / var / run / $ BASE.pid
هذا هو ملف pid الذي تم إنشاؤه / إدارته بواسطة برنامج start-stop-daemon
DOCKER_SSD_PIDFILE = / var / run / $ BASE-ssd.pid
DOCKER_LOGFILE = / var / log / $ BASE.log
DOCKER_OPTS =
DOCKER_DESC = "عامل إرساء"

ثم أعدت تشغيل خدمة dockerd ، وبدأت بنجاح:
_root @ master : ~ # حالة عامل إرساء الخدمة
● docker.service - محرك حاوية تطبيق Docker
مُحمَّل: تم تحميله (/lib/systemd/system/docker.service ؛ مُمكّن ؛ الإعداد المسبق للمورد: ممكّن)
نشط: نشط (قيد التشغيل) منذ الأربعاء 2016-05-04 04:32:01 EDT؛ قبل 17 ساعة
المستندات: https: //docs.docker.com_

الجذر @ الرئيسي : ~ # نسخة عامل ميناء
عميل:
الإصدار: 1.12.0-dev
إصدار API: 1.24
إصدار Go: go1.5.4
Git الالتزام: 1c0edf6-unsupported
تاريخ البناء: الأربعاء 4 مايو 05:05:37 2016
OS / Arch: لينكس / amd64

الخادم:
الإصدار: 1.12.0-dev
إصدار API: 1.24
إصدار Go: go1.5.4
Git الالتزام: 1c0edf6-unsupported
تاريخ البناء: الأربعاء 4 مايو 05:05:37 2016
OS / Arch: لينكس / amd64
الجذر @ الرئيسي : ~ #

الجميع يركضون سعداء

فقط للرجوع اليها

مرحبا ، هل يمكن لأحد أن يساعدني؟
أواجه نفس المشكلة. أنا أفهم أن ترقية جهاز الإرساء ستنجح لكنني لا أستخدم عامل الإرساء على نظامي التشغيل Windows / MAC. أنا أستخدمه على لينكس.

أنا أتبع هذه التعليمات لإجراء اختبار للعب بثقة محتوى عامل الإرساء
https://docs.docker.com/engine/security/trust/trust_sandbox/

في ملف dockerfile المقدم ، يأخذ الصورة 1.12.0 ثم ينشئ الصورة ، لذلك عندما أقوم بتشغيل الحاوية ، لا يتصل بجهازي الأساسي لأن جهازي الأساسي (Linux) به 1.11.0 docker وهذا به 1.12.0 ، لذلك قمت بعد ذلك بتغيير ملف docker ومررت مسار 1.11.0-dev إليه وقمت بإنشاء الصورة مرة أخرى. هذه المرة عندما قمت بتشغيل الحاوية مع هذا الملف الجديد ، إصدار docker هو 1.11.0-dev فقط ولكن إصدار API لا يزال 1.24 لكن إصدار Linux الأساسي الخاص بي يحتوي على إصدار API 1.23.

كيف يمكنني التخلص من هذا؟ كيف أقوم بتقليل إصدار حاوية API إلى 1.23 أو زيادة إصدار API الأساسي الخاص بي إلى 1. ، 24 بحيث لا توجد أخطاء؟

ملاحظة: لقد حاولت ترقية إصدار عامل إرساء Linux الأساسي الخاص بي ولكن لا يزال إصدار API هو 1.23 فقط.

upload

mkonakan

على Ubuntu ، سيقوم sudo apt-get install -y docker-engine بتحديث الإصدار المثبت أصلاً من Docker (تنبيه: لن يعمل هذا إلا إذا قمت بتثبيت Docker باستخدام القنوات الرسمية)

docker-machine upgrade ، كما لاحظت ، سيقوم بتحديث أي boot2docker.iso لديك إلى أحدث إصدار

nathanleclaire مرحبًا ، قمت بترقية محرك

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

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

👍

لماذا هذا مغلق؟ هل أحدث عميل عامل ميناء قادر على التفاعل مع شياطين عامل الإرساء الأقدم؟

megastef ليس هذا على

لدي نفس المشكلة ، أحاول استخدام اسم ترقية جهاز الرصيف ، لذا من المؤسف أن هذا لا يعمل. لا أعرف ما إذا كانت الشبكة although use proxy ، لكنني قمت بحل هذه المشكلة.
1.ابحث عن صندوق الأدوات من
2- قم بتنزيله وتثبيته ، ثم يقوم بترقية نسختك.

docker-machine upgrade في السيناريو الخاص بي. يبدو أن CoreOS Docker Host عالق في الإصدار 1.22. يعمل عميلي 1.24. كيف يمكنني حل هذا؟

@ pcgeek86 جرب export DOCKER_API_VERSION=1.23 (انظر https://forums.docker.com/t/docker-for-mac-stopped-running-docker-related-commands/16153/6)

كنت أواجه هذه المشكلة أيضًا ، مع الإصدار التجريبي من Windows. docker-machine upgrade لم يساعد.
أحد الحلول البديلة هو إضافة --engine-install-url https://test.docker.com إلى docker-machine create ، والذي سيقوم بتهيئة الجهاز بأحدث إصدار مرشح من Docker.

تفاصيل:

> docker -v
Docker version 1.12.0-rc4, build e4a0dbc, experimental
> docker-machine -v
docker-machine version 0.8.0-rc2, build 4ca1b85

> docker-machine create --driver amazonec2 aws01
> <strong i="12">@FOR</strong> /f "tokens=*" %i IN ('docker-machine env aws01') DO @%i
> docker ps
Error response from daemon: client is newer than server (client API version: 1.24, server API version: 1.23)
(Here we could have used SET DOCKER_API_VERSION=1.23)

> docker-machine create --driver amazonec2 --engine-install-url https://test.docker.com aws02
> <strong i="13">@FOR</strong> /f "tokens=*" %i IN ('docker-machine env aws02') DO @%i
> docker ps
(Works!)

هل يمكن إصلاح هذا (أو ربما حل المشكلة) عن طريق إضافة DOCKER_API_VERSION إلى ناتج docker-machine env ؟

لقد حللت المشكلة بفضلeddieajau.

عميل Docker (DOCKER_API_VERSION = 1.24) هو Ubuntu linux وخادم عامل الإرساء (DOCKER_API_VERSION = 1.23) موجود في Carina بواسطة Rackspace BETA.

فقط أضف export DOCKER_API_VERSION=1.23 إلى عميلك لجعله يعمل.

شكر.

export DOCKER_API_VERSION=1.23 حل مشكلتي. بفضل eddieajau

شكرًا لك @ kid1412z ، لقد

العودة إلى الإصدار الأقدم

brew uninstall docker
brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/ba2a4f0358395010e84346d2224378c74d76c527/Formula/docker.rb
brew pin docker

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

FlorianHeigl docker client 1.13 وما DOCKER_API_VERSION

eddieajau الحل البديل لمتغير البيئة DOCKER_API_VERSION = 1.23 لم يعد يعمل.
أستخدم عامل إرساء لنظام التشغيل Windows وأنا أتصل بخادم عامل ميناء يعمل على NAS لا يمكنني تحديثه.

شبابيك:

Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:09 2017
 OS/Arch:      windows/amd64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:45:38 2017
 OS/Arch:      linux/amd64
 Experimental: true

ناس:

Client:
 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   781516c
 Built:        Thu Aug  3 16:04:05 2017
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   781516c
 Built:        Thu Aug  3 16:04:05 2017
 OS/Arch:      linux/amd64

هل يوجد عندكم اي فكرة؟

manuelsalvatori هذه مشكلة في عامل

كن على علم بأن عامل الإرساء 1.11 قد انتهى عمره ، ولديه نقاط ضعف معروفة ، من بينها CVE في RunC التي تسمح لعمليات الحاوية بالخروج من الحاوية والوصول إلى المضيف (تم حلها في Docker 1.12.6 وما بعده ، أي السفينة بإصدار مصحح من RunC https://github.com/moby/moby/releases/tag/v1.12.6)

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات