हाँ, UX महान नहीं है, लेकिन यदि आप RC Docker बाइनरी का उपयोग करना चाहते हैं, तो आपको एक रिलीज़ कैंडिडेट ISO का उपयोग करने के लिए निर्दिष्ट करने की आवश्यकता है जैसे --virtualbox-boot2docker-url https://github.com/tianon/boot2docker-legacy/releases/download/v1.9.0-rc4/boot2docker.iso

आरसी के लिए यह विशेष उपचार क्यों?

यह इसे गैर-सहज बनाता है।

ठीक है, आपका डॉकटर क्लाइंट बाइनरी भी एक आरसी है। आपको कैसा लगता है यह काम करना चाहिए?

RC से स्वतः RC2docker.iso चुनना चाहिए। --virtualbox-boot2docker-url उपयोग केवल डिफ़ॉल्ट मान को ओवरराइड करने के लिए किया जाना चाहिए। और डिफ़ॉल्ट डॉक ग्राहक बाइनरी के समान होना चाहिए।

मुझे लगता है कि हम डिफ़ॉल्ट रूप से नए RCs का उपयोग करने के लिए upgrade / create अनुमति देने के बारे में बेहतर कर सकते हैं, लेकिन वर्तमान में boot2docker के लिए RC हम @tianon के कांटे पर रख रहे हैं, इसलिए हमें इसकी आवश्यकता है ऐसा करने की हमारी आदत को बदलें अगर हम इसका समर्थन करने जा रहे हैं। मैं चीजों को बहुत अधिक जादू बनाने के बारे में थोड़ा चिंता करता हूं क्योंकि इस संबंध में सभी को वास्तव में अलग-अलग अपेक्षाएं हैं।

डॉकर क्लाइंट बाइनरी के साथ boot2docker.iso मिलान एक उचित और सहज दृष्टिकोण की तरह लगता है। और वैसे भी ओवरराइड करने का विकल्प होगा।

कोई जादू नहीं, बस कम से कम मेरे लिए सहज!

डॉकर 1.9.0 और मशीन 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 और क्लाइंट / सर्वर API संस्करण की मैपिंग है?

docker-machine upgrade name काम करना चाहिए, मेरा अनुमान है कि यह "आईएसओ कैश इश्यू" है। क्या आपने उस आदेश की कोशिश की?

boot2docker.iso हमेशा डॉकियर रिलीज़ एपीआई संस्करण के अनुरूप होता है। आप मेटाडाटा में file $HOME/.docker/machine/cache/boot2docker.iso कर कैश का संस्करण देख सकते हैं।

docker-machine upgrade ने इस मुद्दे को हल किया।

धन्यवाद अरुण। हम उन्नयन प्रवाह के आसपास कुछ मुद्दों पर काम करने जा रहे हैं, इसलिए उम्मीद है कि यह भविष्य में थोड़ा और स्पष्ट होगा।

: +1: docker-machine upgrade

डॉक-मशीन अपग्रेड के लिए +1 - अपग्रेड की जा रही एकमात्र चीज को संभालने से संबंधित है;)

: +1: docker-machine upgrade <machine name>

डॉकर टूलबॉक्स के साथ अपग्रेड करने के बाद, डिफ़ॉल्ट मशीन को बंद कर दिया गया लेकिन अपग्रेड किया गया।
अन्य मशीन को रोका नहीं गया, और अपग्रेड नहीं किया गया।

docker-machine upgrade <machine-name> काम भी मेरे लिए

मैं विंडोज 10 पर हूं और एक समान मुद्दा देखा, जो अजीब तरह से सिर्फ एक दूसरे रन पर गायब हो गया। यहाँ मेरे पास और चरणों का क्रम है।

1. मैं डॉकर टूलबॉक्स 1.8.3 का उपयोग कर रहा था और नवीनतम रिलीज 1.9.0c का उपयोग करने का निर्णय लिया क्योंकि मैं कुछ अजीब मुद्दों का सामना कर रहा था।
2. मैं एक सुरक्षा कदम के रूप में docker-machine rm default भागा
3. डाउनलोड और इंस्टॉल किया गया टूलबॉक्स संस्करण 1.9.0c
4. Git ही एक ऐसी चीज थी जिसे मैंने तब नहीं चुना जब संकेत दिया और बाकी सब कुछ स्थापित किया।
5. _Docker क्विकार्टार्ट टर्मिनल_
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-gupta @nathanleclaire docker- मशीन अपग्रेड [मशीन-नाम] तय खदान !!! बहुत धन्यवाद। FWIW, क्लाइंट और सर्वर के बीच यह अपग्रेड-सिंक वास्तव में PITA है। इसे बेहतर बनाने के लिए खर्च किए गए किसी भी चक्र की बहुत सराहना की जाएगी!

यह RC3 और न ही docker मशीन तक सीमित है। यदि docker क्लाइंट 1.9.x है और सर्वर docker 1.8.x चला रहा है, तो त्रुटि संदेश देखा जाता है। यदि आप सभी सर्वर और सभी क्लाइंट पर एक ही docker इंजन संस्करण स्थापित नहीं करते हैं या नहीं कर सकते, तो यह परिनियोजन के प्रबंधन के मामले में बहुत अव्यावहारिक है। मेरी राय है कि यह काफी गंभीर टूट है।

मूल रूप से https://github.com/docker/machine/issues/1839 जैसा ही अंक

docker-machine upgrade <machine-name> ने भी मेरे लिए काम किया

docker-machine upgrade <machine-name> ने मेरे लिए काम नहीं किया। मुझे अपने सभी सर्वरों को डॉक के निर्माण के लिए अपग्रेड करना था, फिर मैंने फिर से डाउनग्रेड किया और प्राप्त करना शुरू किया:

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> भाग लिया, लेकिन त्रुटि बनी हुई है।

मेरी गलती ... मुझे अपने रास्ते से नए डॉकटर बाइनरी को हटाने की आवश्यकता थी।

docker- मशीन का उन्नयनमेरे लिए भी काम किया।

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- मशीन अभी भी VM को बनाने के लिए boot2docker ISO का उपयोग करती है, यह असामान्य नहीं है।

ऐसा लगता है कि सर्वर (वीएम) पर डॉक डेमन के उन्नयन की पुष्टि करने वाले बहुत से लोग हैं, लेकिन यह उस मामले को संबोधित नहीं करता है जहां डॉक डेमॉन को तुरंत अपग्रेड नहीं किया जा सकता है। अब तक मैंने जो एकमात्र त्वरित और अर्ध-समझदार समाधान खोजा है, वह है केवल रिलीज से एक उपयुक्त क्लाइंट बाइनरी डाउनलोड करना और सर्वर संस्करण के आधार पर सही को चलाना।

boot2docker को पदावनत घोषित किया गया है। क्या यह वास्तव में समस्या का इच्छित समाधान है?

@Superdump नोट के रूप में, boot2docker CLI (कमांड लाइन पर boot2docker का उपयोग करके आह्वान किया गया है) को हटा दिया गया है, लेकिन OS अभी भी बना हुआ है।

शुक्रिया @nathanleclaire और @superdump को स्पष्ट करने के लिए!

मैंने dmv स्थापित करके और डाउनग्रेड करके समस्या को हल करने के लिए (दुख की बात केवल अस्थायी रूप से) प्रबंधित की है

dmv use 1.8.1

हालांकि, जब कुछ छवियों खींच (लेकिन सभी नहीं), docker का उपयोग करने जा रहता है 1.9.1 और कुछ भी नहीं के तहत दिखाया गया है docker images किसी भी अधिक (लेकिन यह पहले था)।

यहाँ क्या हो रहा है? यह एक छोटी गाड़ी / अस्थिर संस्करण है?

रिलीज कैंडिडेट 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

मैं सिर्फ अपने स्थानीय मैक (homebrew) के साथ इस मुद्दे को 1.10 चला रहा था, जबकि docker- मशीन - Google gce पर इस मामले में, docker- मशीन अपग्रेड की कोशिश करने के बाद भी काम नहीं करेगा। मुझे इसमें मैन्युअल रूप से ssh करना था और विशेष रूप से 1.10 में अपग्रेड करने के लिए मजबूर करने के लिए डिब रेपो जोड़ना था।

बस ट्रैविस सीआई पर एक का सामना करना पड़ा:

$ 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 दिनों के बाद http://stackoverflow.com/questions/24586573/docker-error-client-and-server-dont-have-same-version / 36298911 # 36298911

यह अभी भी केवल docker मशीन / docker टूलबॉक्स के बारे में है। उन सभी प्रस्तावों में वर्कअराउंड हैं और हो सकता है कि डॉक टूलबॉक्स के साथ उपयोग करने के लिए ठीक हो, लेकिन डॉक की वास्तविक तैनाती के लिए बिल्कुल भी ठीक नहीं है, जहां अलग-अलग सर्वर के अलग-अलग सर्वर संस्करण हो सकते हैं और तुरंत अपग्रेड करने में सक्षम नहीं होंगे।

असली समस्या यह है कि नए docker क्लाइंट पुराने सर्वर से बात नहीं कर सकते हैं। यह आदर्श रूप से किसी भी तरह docker में तय किया जाना चाहिए ताकि ग्राहक बैकवर्ड संगत हों।

यह वास्तव में एक शो-स्टॉपिंग, आश्चर्यजनक डिजाइन दोष है जिसे वास्तव में तुरंत संबोधित करने की आवश्यकता है यदि डॉक-मशीन एक विश्वसनीय उपकरण है। यह विचार कि मैं अब एक सर्वर उदाहरण से कनेक्ट नहीं कर सकता, क्योंकि API संस्करण _OLDER_ है, ठीक है, अच्छी तरह से flabbergasting है।

दुर्भाग्य से, ग्राहकों को तेजी से जारी किया जाता है, लेकिन ग्राहकों को रिपोज तक पहुंचने में समय लगता है।
इसीलिए जब आप डॉक-मशीन (टूलबॉक्स) को अपग्रेड करते हैं, तो सर्वर का नया संस्करण उपलब्ध नहीं हो सकता है और आपको आपकी मशीन से अलग कर दिया जाता है।

क्या अजीब बात है, यह है कि एक नया क्लाइंट पुराने एपीआई के लिए "बोलने" में असमर्थ है।

नई रिलीज़ के लिए आधिकारिक रिलीज़ और रिपॉज़ अपडेट के बीच अंतराल कुछ ऐसा है जो हल नहीं है। जैसा कि मैंने इसे देखा, यह एक क्लाइंट को अपग्रेड करता है, एक अंधा शर्त। जब तक आपको यकीन न हो कि आपके डीएम को उसी क्लाइंट वर्जन में अपग्रेड किया जा सकता है, तब तक क्लाइंट लॉक अपग्रेड कर सकता है।

केवल दो (कोई अन्य?) विकल्प हैं।

1. क्लाइंट को वर्तमान API और कम से कम 1 वर्ष पुराने एपिस से बात करने में सक्षम होना चाहिए।
2. सर्वर अपग्रेड को आधिकारिक रिपॉजिट पर उपलब्ध संस्करण की जांच करनी चाहिए, और यदि यह मेल नहीं खाता है, तो इसे स्रोत (या वैकल्पिक रेपो) से निर्मित होना चाहिए।

हम सब यहाँ क्या करने की जरूरत है ग्राहक समर्थन पुराने संस्करणों एपीआई है। क्यों कि एक डिजाइन की आवश्यकता विषम नहीं थी।

@ TheSeanBrady डॉकर मशीन सी काफी नई है।
मुझे यकीन है कि एपीआई की एक श्रृंखला का समर्थन इस परियोजना के कुछ मील के पत्थर पर है।

यह docker- मशीन के साथ कोई समस्या नहीं है, यह docker के साथ एक समस्या है।

$ 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

हम सब यहाँ क्या करने की जरूरत है ग्राहक समर्थन पुराने संस्करणों एपीआई है। क्यों कि एक डिजाइन की आवश्यकता विषम नहीं थी।

क्या होता है जब भविष्य का क्लाइंट एपीआई पैरामीटर भेजता है जो डेमॉन के पास नहीं होता है जो इसकी उम्मीद नहीं करता है? या एक समापन बिंदु के लिए एक अनुरोध करता है जो पुराने संस्करणों में मौजूद नहीं है? डेमॉन को उन सभी संभावित चीजों के बारे में कैसे पता होना चाहिए जो भविष्य में ग्राहक उससे अनुरोध कर सकते हैं?

@nathanleclaire
मैं विशेषज्ञ नहीं हूं, लेकिन जो मैं उम्मीद करता हूं वह उसी तरह है जैसे पुराने ऑडियो मॉडेम पर हैंडशेक किया गया था। प्रारंभिक हैंडशेक सबसे पुराने एपीआई का उपयोग करके किया गया था, जिसे सभी क्लाइंट और सर्वर द्वारा समझने की गारंटी दी जाती है, और कम से कम बुनियादी (महत्वपूर्ण) कॉल का जवाब देने की गारंटी दी जाती है।

यह हैंडशेक सिर्फ इस बात के लिए पूछेगा: आप किस एपीआई संस्करण का उपयोग कर रहे हैं और एपीआई कार्यों की सूची इसका जवाब दे सकती है। क्लाइंट और सर्वर के कार्य तार्किक रूप से एक साथ संपन्न होते हैं और सामान्य कार्य (एपीआई कॉल) THAT क्लाइंट-सर्वर कॉन्फ़िगरेशन के लिए सेट किए जाते हैं।

उसके आधार पर, क्लाइंट को पता होगा कि यह किस फ़ंक्शन को कॉल कर सकता है और केवल उन पर त्रुटि कर सकता है जो इसे नहीं कर सकते।
IE [NotSupported] - क्षमा करें, सर्वर _______ का जवाब देने में असमर्थ है। कृपया डॉकर nn.nnn.nn पर सर्वर को अपडेट करें या डॉकनर nn.nnn.nn के अनुरूप अपने कंटेनर को संशोधित करें।

विचार यह है कि यदि एपीआई केवल 1% से भिन्न होता है, तो वह 1% अन्य 99% के उपयोग को अक्षम नहीं करता है, जो कि ग्राहक को सबसे अधिक संभावना है।

मुझे लगता है कि सुधार के लिए जमीन है। एक सामान्य प्रोटोकॉल पर हाथ मिलाना और सहमत होना कोई नई बात नहीं है और इसे कई बार हल किया गया है। सबसे बढ़कर, यह प्रयोज्य में बहुत सुधार करेगा।

हमेशा याद रखें कि एक प्रणाली, चाहे वह कितनी भी अच्छी हो, अगर ग्राहक इसका उपयोग नहीं करते (या इसका उपयोग करने में असुरक्षित महसूस करते हैं), कुछ भी नहीं के बराबर है।

@ctroncoso मैं आपकी बात देख रहा हूं, लेकिन अगर मैं amazonec2 / us-east-1 में एक सर्वर के साथ time docker info संचार करता हूं, तो यह 300ms से थोड़ा अधिक लगता है - बैक-टू नहीं होगा -प्रत्येक अनुरोध के लिए हैंडशेक समय की इस राशि को दोगुना करें और ओवरहेड की गैर-तुच्छ राशि का परिचय दें?

किसी भी दर पर, इस मुद्दे के बारे में कुछ भी नहीं किया जा सकता है, इसलिए मैं सुझाव देता हूं कि एक मुद्दा खोला जाए (मौजूदा लोगों के लिए पहले खोजें) https://github.com/docker/docker पर अपने विचारों को ऊपर की ओर साझा करें यदि वांछित है।

@nathanleclaire यकीन है कि यह होगा, लेकिन क्या आप एक उन्नयन के लिए 20 x 300 (या 600) एमएस का व्यापार करेंगे जो काम करने की गारंटी है? इसके अलावा, यह सिर्फ पहली कॉल के लिए होगा। हो सकता है कि "सत्र कुंजी" उस पहले कॉल पर उत्पन्न हो सकती है जो यह स्थापित करती है कि हैंडशेक पहले ही बनाया जा चुका है। और री-हैंडशेकिंग के बिना निम्नलिखित पर उपयोग किया जाता है। मुझे यकीन है कि सुरक्षा के मुद्दे हैं जो इसे ला सकते हैं, लेकिन मेरे पास एक नहीं-तो-फास्ट-फेल-प्रूफ सिस्टम है, एक की तुलना में जो काम का एक अनसुना भार लोड कर सकता है क्योंकि ubuntu / fedora / centos didn समय पर इसके रिपोज को अपडेट नहीं करना चाहिए। मैं देख रहा हूं कि यह एक डॉक-इंजन मुद्दा है लेकिन मशीन दोष ले रही है।

मैं डॉकटर-इंजन के मुद्दों पर जाँच करूँगा। मुझे लगता है कि हमें यहां जाकर एक अच्छी सुविधा मिली है। मुझे यह पसंद है जब एक रचनात्मक विचार में मुद्दे की वार्ता समाप्त हो जाती है। आपके समय के लिए धन्यवाद @nathanleclaire !!!

क्लाइंट पहले से ही संस्करण के लिए सर्वर से पूछताछ करता है। नहीं होना चाहिए
कारण कि ग्राहक कभी भी ऐसा एपीआई पैरामीटर भेजेगा जो मौजूद नहीं है,
क्योंकि ग्राहक को उस के लिए उपलब्ध परमों के बारे में पता होना चाहिए
संस्करण। एक ही समापन बिंदु के लिए चला जाता है।

मेरा मानना ​​है कि इस दृष्टिकोण को वृद्धों के पदावनति की आवश्यकता होगी
कुछ बिंदु पर संस्करण, शायद उम्र या संस्करण डेल्टा के आधार पर।

आप बस पुराने संस्करणों पर घुट ग्राहक नहीं हो सकता है, यह है
उत्पादन स्तर पर तैनाती का विकल्प नहीं। मेरे पास 3 पूरी मशीनें हैं
यहाँ और मेरे पास यह मुद्दा है, छवि क्या फैलाव पर होगी
तैनाती।

Thu पर, अप्रैल 21, 2016 को 2:47 अपराह्न, नाथन लेक्लेयर नोटिफिकेशन @github.com
लिखा था:

हम सब यहाँ क्या करने की जरूरत है ग्राहक समर्थन पुराने संस्करणों एपीआई है।
क्यों कि एक डिजाइन की आवश्यकता विषम नहीं थी।

क्या होता है जब भविष्य का क्लाइंट एपीआई पैरामीटर भेजता है
एक डेमन के पास मौजूद नहीं है जो इसकी उम्मीद नहीं करता है? या करने के लिए एक अनुरोध करता है
एंडपॉइंट जो पुराने संस्करणों में मौजूद नहीं है? डेमन को कैसे माना जाता है
भविष्य के ग्राहक से अनुरोध करने के लिए सभी संभावित चीजों के बारे में जानना चाहिए?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/docker/machine/issues/2147#issuecomment -213107758

क्लाइंट पहले से ही संस्करण के लिए सर्वर से पूछताछ करता है

क्या आप मुझे बता सकते हैं कि डोकर ग्राहक कोड में ऐसा कहां होता है?

मैं वास्तव में जाना नहीं जानता, लेकिन मुझे पूरा यकीन है कि यह क्या करता है:

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

किसी भी तरह से आप पूरे प्रोजेक्ट में एपीआई संस्करण को क्वेरी करते हुए देखते हैं।

Thu पर, अप्रैल 21, 2016 को 5:25 अपराह्न, नाथन लेक्लेयर नोटिफिकेशन @github.com
लिखा था:

क्लाइंट पहले से ही संस्करण के लिए सर्वर से पूछताछ करता है

क्या आप मुझे बता सकते हैं कि डोकर ग्राहक कोड में ऐसा कहां होता है?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे 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.service
  ● docker.service - डॉकटर अनुप्रयोग कंटेनर इंजन
  भरी हुई: भरी हुई (/lib/systemd/system/docker.service; सक्षम; विक्रेता पूर्व निर्धारित: सक्षम)

लेकिन निर्देशिका में उत्पन्न डेमॉन बायनेरिज़ हैं:
बंडलों / नवीनतम / बाइनरी-डेमॉन
पीएटीएच में निर्देशिका को जोड़ना चाहिए, या डॉकटर और कंटेनर को / usr / bin / में कॉपी करना चाहिए
_copy dockerd / usr / bin / docker
डॉक-कंटेनर-यूएसडी / यूएसआर / बिन / कंटेनर
कॉपी ../binary-client/docker / usr / bin_

तब मैं /etc/init.d/docker को संशोधित करता हूं जिसमें हाइलाइट लाइनों के साथ PATH में डॉकटर की निर्देशिका को जोड़ना है

DOCKERD = / घर / मास्टर / github.com / डोकर / बंडलों / 1.12.0-देव / बाइनरी-डेमॉन
PATH = $ PATH: $ DOCKERD निर्यात करें

आधार = dockerd

/ etc / default / $ BASE (/ etc / default / docker) में इन्हें संशोधित करें

डोकर = / usr / bin / $ आधार

डोकर $ DOCKERD = / $ आधार
यह docker द्वारा प्रबंधित pid फ़ाइल है
DOCKER_PIDFILE = / var / रन / $ BASE.pid
यह स्टार्ट-स्टॉप-डेमॉन द्वारा बनाई / प्रबंधित पिड फ़ाइल है
DOCKER_SSD_PIDFILE = / var / रन / $ BASE-ssd.pid
DOCKER_LOGFILE = / var / लॉग / $ BASE.log
DOCKER_OPTS =
DOCKER_DESC = "डोकर"

फिर मैंने dockerd की सेवा को फिर से शुरू किया, यह सफलता से शुरू होती है:
_root @ मास्टर : ~ # सेवा कर्ता का दर्जा
● docker.service - डॉकटर अनुप्रयोग कंटेनर इंजन
भरी हुई: भरी हुई (/lib/systemd/system/docker.service; सक्षम; विक्रेता पूर्व निर्धारित: सक्षम)
सक्रिय: बुध 2016-05-04 04:32:01 EDT के बाद से सक्रिय (चल रहा); 17 ह पहले
डॉक्स: https: //docs.docker.com_

रूट @ मास्टर : ~ # docker संस्करण
ग्राहक:
संस्करण: 1.12.0-देव
एपीआई संस्करण: 1.24
जाओ संस्करण: go1.5.4
Git प्रतिबद्ध: 1c0edf6-असमर्थित
बिल्ट: बुध 4 मई 05:05:37 2016
OS / Arch: linux / amd64

सर्वर:
संस्करण: 1.12.0-देव
एपीआई संस्करण: 1.24
जाओ संस्करण: go1.5.4
Git कमिट: 1c0edf6-unsupported
बिल्ट: बुध 4 मई 05:05:37 2016
OS / Arch: linux / amd64
रूट @ मास्टर : ~ #

सभी खुश हैं

सिर्फ संदर्भ के लिए

नमस्ते, क्या कोई मेरी मदद कर सकता है?
मुझे भी वही समस्या हो रही है। मैं समझता हूं कि docker- मशीन अपग्रेड काम करेगा लेकिन मैं Windows / MAC पर docker का उपयोग नहीं कर रहा हूं। मैं इसे लिनक्स पर उपयोग कर रहा हूं।

मैं इस निर्देश का अनुसरण कर रहा हूं ताकि डॉकटर कंटेंट ट्रस्ट के साथ खेलने के लिए एक परीक्षण किया जा सके
https://docs.docker.com/engine/security/trust/trust_sandbox/

दिए गए डॉकफाइल में, यह १.१२.० छवि लेता है और फिर छवि बनाता है, इसलिए जब मैं कंटेनर चलाता हूं तो यह मेरे आधार मशीन से कनेक्ट नहीं होता है क्योंकि मेरे आधार मशीन (लिनक्स) में १.११.० docker है और इसमें १.१२.० है। , इसलिए मैंने फिर डॉकटर फ़ाइल को बदल दिया और इसे 1.11.0-देव पथ पर भेज दिया और फिर से छवि उत्पन्न की। इस बार जब मैंने कंटेनर को इस नई फ़ाइल के साथ चलाया, तो docker संस्करण केवल 1.11.0-dev है, लेकिन API संस्करण अभी भी 1.24 है, लेकिन मेरे आधार लिनक्स में 1.23 का API संस्करण है।

मुझे इससे छुटकारा कैसे मिलेगा? मैं अपने कंटेनर API संस्करण को 1.23 तक कैसे कम करूं या अपना आधार एपीआई संस्करण बढ़ाकर 1., 24 कर दूं ताकि कोई त्रुटि न हो?

पुनश्च: मैंने अपने बेस लाइनक्स डॉक वर्जन को अपग्रेड करने की कोशिश की, लेकिन अभी भी एपीआई संस्करण केवल १.२३ है।

@mkonakan

उबंटू पर, sudo apt-get install -y docker-engine डॉकटर के मूल रूप से स्थापित संस्करण को अपडेट करेगा (कैविएट: यह केवल तभी काम करेगा जब आपने आधिकारिक चैनलों का उपयोग करके डॉकर को स्थापित किया हो)

docker-machine upgrade , जैसा कि आपने नोट किया है, आप नवीनतम संस्करण में किसी भी boot2docker.iso को अपडेट करेंगे

@nathanleclaire हाय, ने मेरे आधार ubuntu पर मेरे

@mkonakan आपका सबसे अच्छा दांव संभवतः स्रोत से डॉकर को संकलित करना है, संबंधित स्थान पर बाइनरी को छोड़ना और डेमॉन को पुनरारंभ करना है। यदि आपके द्वारा बनाया गया कंटेनर डॉकियर के ऐसे संस्करण का उपयोग कर रहा है, तो यह संभावना है कि डॉकरीफाइल में एक रेखा कुछ ऐसा ही कर रही हो।

हल किया। मैंने उस डॉकटर में डिफ़ॉल्ट फ़ाइल के बजाय अपने बेस मशीन से बाइनरी फ़ाइल को कंटेनर में कॉपी किया जो नवीनतम एपीआई संस्करण प्राप्त कर रहा है। धन्यवाद।

👍

यह बंद क्यों है? क्या नवीनतम docker क्लाइंट पुराने docker डेमॉन के साथ इंटरफेस करने में सक्षम है?

@megastef नहीं है कि मुझे पता है, लेकिन यह अपस्ट्रीम प्रोजेक्ट (https://github.com/docker/docker) का एक मुद्दा है, इसलिए मैं सुझाव

मैं एक ही समस्या है, मैं docker- मशीन अपग्रेड नाम का उपयोग करने की कोशिश करता हूं, इसलिए दया नहीं है जो काम नहीं कर रहा है। मुझे नहीं पता कि नेटवर्क although use proxy , लेकिन मैंने इस समस्या को हल किया।
1. टूलबॉक्स से चुनें
2. डाउनलोड करें और इसे स्थापित करें, फिर यह उर संस्करण को अपग्रेड करेगा।

Windows पर समान समस्या वाले लोगों के लिए, पर्यावरण चर सेट करने के लिए $ env: DOCKER_API_VERSION = 1.23 का उपयोग करें।

मैं Windows बीटा के साथ भी इस समस्या को ले रहा था। docker-machine upgrade मदद नहीं की।
एक वैकल्पिक समाधान --engine-install-url https://test.docker.com से docker-machine create जोड़ना है , जो डॉकर की नवीनतम रिलीज़ उम्मीदवार के साथ मशीन को इनिशियलाइज़ करेगा।

विवरण:

> 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 DOCKER_API_VERSION जोड़कर निश्चित किया जा सकता है (या शायद काम किया है)?

मैंने @eddieajau की बदौलत समस्या का समाधान किया।

मेरा docker क्लाइंट (DOCKER_API_VERSION = 1.24) Ubuntu linux है और docker सर्वर (DOCKER_API_VERSION = 1.23) 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

हे भगवान। प्रोटोकॉल संस्करणों पर बातचीत करना एक ऐसी चीज़ नहीं है जिसे अभी भी आविष्कार करने की आवश्यकता है। मैंने 90 के दशक के सॉफ्टवेयर के साथ काम किया है जो इसे संभाल सकता है। हाँ, वास्तव में।

@FlorianHeigl डॉक क्लाइंट 1.13 और उच्चतर डेमन के साथ एपीआई संस्करण बातचीत करता है; न्यूनतम डेमन संस्करण है कि यह वापस गिर जाएगा 1.12 docker है। पुराने डेमों के लिए, DOCKER_API_VERSION ओवरराइड की आवश्यकता है

@eddieajau पर्यावरण चर DOCKER_API_VERSION = 1.23 का समाधान अब काम नहीं करता है।
मैं Windows के लिए docker का उपयोग करता हूं और मैं एक NAS पर चलने वाले docker सर्वर से जुड़ रहा हूं जिसे मैं अपडेट नहीं कर सकता।

खिड़कियाँ:

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 हालांकि जीवन का अंत है, और ज्ञात कमजोरियां हैं, जिसके बीच रनसी में एक सीवीई है जो कंटेनर प्रक्रियाओं को कंटेनर से बाहर निकलने और मेजबान तक पहुंच प्राप्त करने की अनुमति देता है (डॉकटर 1.12.6 और ऊपर, जो जहाज में हल किया गया है) पैक्ड रनसी संस्करण के साथ https://github.com/moby/moby/releases/tag/v1.12.6)