Ja, die UX ist nicht großartig, aber wenn Sie eine RC Docker-Binärdatei verwenden möchten, müssen Sie angeben, dass ein Release Candidate ISO verwendet werden soll, um z. B. --virtualbox-boot2docker-url https://github.com/tianon/boot2docker-legacy/releases/download/v1.9.0-rc4/boot2docker.iso

Warum diese spezielle Behandlung für RC?

Dies macht es nicht intuitiv.

Nun, Ihre Docker-Client-Binärdatei ist auch eine RC. Wie denkst du sollte es funktionieren?

RC sollte die Datei boot2docker.iso automatisch von RC abholen. --virtualbox-boot2docker-url sollte nur verwendet werden, um den Standardwert zu überschreiben. Die Standardeinstellung sollte mit der Docker-Client-Binärdatei identisch sein.

Ich denke, wir könnten es besser machen, wenn wir upgrade / create erlauben, standardmäßig neue RCs zu verwenden, aber derzeit haben wir RCs für boot2docker an @tianons Gabel gehalten, also müssen wir Ändern Sie auch unsere Gewohnheit, dies zu tun, wenn wir dies unterstützen wollen. Ich mache mir ein bisschen Sorgen, dass die Dinge zu magisch werden, da jeder in dieser Hinsicht wirklich unterschiedliche Erwartungen hat.

Das Abgleichen von boot2docker.iso mit der Docker-Client-Binärdatei scheint ein vernünftiger und intuitiver Ansatz zu sein. Und es wird sowieso eine Option zum Überschreiben geben.

Keine Magie, nur intuitiv, zumindest für mich!

Genau denselben Fehler mit Docker 1.9.0 und Machine 0.5.0 sehen:

~ > 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)

Sie sehen keine Möglichkeit, das Problem jetzt erneut zu öffnen.

Haben Sie docker-machine upgrade ?

Diese Maschine wurde gerade erstellt. Muss ich auch dafür docker-machine upgrade ausführen?

@ arun-gupta Höchstwahrscheinlich, um Ihren Cache zu aktualisieren und / oder falls Sie den Computer vor der offiziellen Veröffentlichung von b2d erstellt haben.

@nathanleclaire hat die Maschine vor 30 Minuten erneut erstellt und immer noch den gleichen Fehler erhalten. docker-compose up -d auf einem docker-compose.yml hat erfolgreich funktioniert. Aber docker ps gibt den Fehler erneut aus:

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

Computer explizit aktualisieren.

Gibt es eine Zuordnung von b2d.iso und der Client / Server-API-Version?

docker-machine upgrade name sollte funktionieren, ich vermute, es ist ein "ISO-Cache-Problem". Hast du diesen Befehl ausprobiert?

Das boot2docker.iso immer der entsprechenden Docker-Release-API-Version zugeordnet. Sie können die Version des Caches in den Metadaten anzeigen, indem Sie file $HOME/.docker/machine/cache/boot2docker.iso .

docker-machine upgrade das Problem behoben.

Danke Arun. Wir werden in dieser Iteration an einigen Problemen im Zusammenhang mit dem Upgrade-Ablauf arbeiten. Hoffentlich wird dies in Zukunft etwas klarer.

: +1: für docker-machine upgrade

+1 für Docker-Maschinen-Upgrade - vorausgesetzt, das einzige, was aktualisiert wird, ist Docker-bezogen;)

: +1: für docker-machine upgrade <machine name>

Nach dem Upgrade mit Docker Toolbox wurde der Standardcomputer gestoppt, aber aktualisiert.
Andere Maschinen wurden nicht angehalten und nicht aktualisiert.

docker-machine upgrade <machine-name> arbeiten auch für mich

Ich bin unter Windows 10 und habe ein ähnliches Problem gesehen, das seltsamerweise bei einem zweiten Durchgang verschwunden ist. Hier ist was ich hatte und die Abfolge der Schritte.

1. Ich habe die Docker Toolbox 1.8.3 verwendet und mich für die neueste Version 1.9.0c entschieden, da ich mit einigen seltsamen Problemen konfrontiert war.
2. Ich habe nur aus Sicherheitsgründen ein docker-machine rm default
3. Die Toolbox Version 1.9.0c wurde heruntergeladen und installiert
4. Git war das einzige, was ich nicht ausgewählt habe, als ich dazu aufgefordert wurde, und alles andere installiert habe.
5. Startete das _Docker Quickstart Terminal_
6. Alles sah gut aus

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.Überprüft, ob der Computer erstellt wurde

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

8. Alles in Ordnung, aber

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

9.Was habe ich?

$ 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. Führen Sie das Computer-Upgrade wie oben vorgeschlagen aus und ich erhalte:

$ 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. Danach alles in Ordnung. Nur das Upgrade ein zweites Mal auszuführen, schien zu funktionieren.

@ arun-gupta @nathanleclaire Docker-Maschine Upgrade [Maschinenname] behoben meine !!! Vielen Dank. FWIW, diese Upgrade-Synchronisierung zwischen Client und Server ist wirklich eine PITA. Alle Zyklen, die dafür aufgewendet werden, dies zu verbessern, werden sehr geschätzt!

Dies ist weder auf RC3 noch auf Docker beschränkt. Wenn der Docker-Client 1.9.x ist und auf dem Server Docker 1.8.x ausgeführt wird, wird die Fehlermeldung angezeigt. Dies ist im Hinblick auf die Verwaltung von Bereitstellungen sehr unpraktisch, wenn nicht auf allen Servern und Clients dieselbe Docker-Engine-Version installiert ist oder nicht installiert werden kann. Ich bin der Meinung, dass dies ein ziemlich schwerwiegender Bruch ist.

Auch im Grunde das gleiche Problem wie https://github.com/docker/machine/issues/1839

docker-machine upgrade <machine-name> hat auch bei mir funktioniert

docker-machine upgrade <machine-name> hat bei mir nicht funktioniert. Ich musste alle meine Server auf einen Entwickler-Build von Docker aktualisieren, dann führte ich erneut ein Downgrade durch und bekam:

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

Nach dem manuellen Downgrade habe ich dann docker-machine upgrade <machine-name> , aber der Fehler bleibt bestehen.

Mein Fehler ... Ich musste die neuere Docker-Binärdatei aus meinem Pfad löschen.

Docker-Maschine-Upgradearbeitete auch für mich.

Hier ist, wie ich es zum Laufen gebracht habe, nachdem ich den gleichen Fehler für den 1.10.0-rc1 erhalten habe:

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

Ich musste dies für v1.10.0-rc2 / de3bb7a (OS X 10.10.5) ausführen:
docker-machine create -d=virtualbox -virtualbox-boot2docker-url https://github.com/tianon/boot2docker-legacy/releases/download/v1.10.0-rc2/boot2docker.iso docker

boot2docker wurde für veraltet erklärt. Ist das wirklich die beabsichtigte Lösung des Problems?

Docker-Maschine verwendet immer noch die boot2docker ISO, um die VM zu erstellen, das ist nichts Ungewöhnliches.

Es scheint, dass viele Leute das Upgrade des Docker-Daemons auf dem Server (VM) bestätigen. Dies gilt jedoch nicht für den Fall, dass der Docker-Daemon nicht sofort aktualisiert werden kann. Die einzige schnelle und halbwegs vernünftige Lösung, die ich bisher gefunden habe, besteht darin, einfach eine entsprechende Client-Binärdatei aus den Releases herunterzuladen und je nach Serverversion die richtige auszuführen.

boot2docker wurde für veraltet erklärt. Ist das wirklich die beabsichtigte Lösung des Problems?

Wie @superdump feststellt, ist die boot2docker-CLI (aufgerufen mit boot2docker in der Befehlszeile) veraltet, aber das Betriebssystem bleibt bestehen.

Vielen Dank an @nathanleclaire und @superdump für die Klarstellung!

Ich habe es (leider nur vorübergehend) geschafft, das Problem zu lösen, indem ich dmv installiert und ein Downgrade über durchgeführt habe

dmv use 1.8.1

Wenn Sie jedoch einige Bilder (aber nicht alle) docker , wechselt 1.9.1 und unter docker images nichts mehr angezeigt (aber es war vorher).

Was geht hier vor sich? Ist das eine fehlerhafte / instabile Version?

Es gibt eine Version B für den Release Candidate2

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

verwenden
docker-machine create -d=virtualbox -virtualbox-boot2docker-url https://github.com/boot2docker/boot2docker/releases/download/v1.10.0-rc2-b/boot2docker.iso docker

Ich hatte gerade dieses Problem mit meinem lokalen Mac (Homebrew), auf dem 1.10 ausgeführt wurde, während der Docker-Computer - in diesem Fall auf Google Gce - selbst nach dem Versuch eines Docker-Computer-Upgrades nicht funktionierte. Ich musste manuell ssh hinein und speziell das Deb-Repo hinzufügen, um ein Upgrade auf 1.10 zu erzwingen.

Ich bin gerade auf Travis CI gestoßen:

$ 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 

Ich habe es nach 3 Tagen Debugging Http://stackoverflow.com/questions/24586573/docker-error-client-and-server-dont-have-same-version / 36298911 # 36298911

Hier geht es immer noch nur um Docker-Maschine / Docker-Toolbox. Alle diese Vorschläge sind Problemumgehungen und möglicherweise für die Verwendung mit der Docker-Toolbox geeignet, jedoch nicht für echte Bereitstellungen von Docker, bei denen verschiedene Server möglicherweise unterschiedliche Serverversionen haben und nicht sofort aktualisiert werden können.

Das eigentliche Problem ist, dass neuere Docker-Clients nicht mit älteren Servern kommunizieren können. Dies sollte idealerweise irgendwie im Docker selbst behoben werden, damit Clients abwärtskompatibel sind.

Dies ist wirklich ein atemberaubender, atemberaubender Designfehler, der wirklich sofort behoben werden muss, wenn die Docker-Maschine ein glaubwürdiges Werkzeug sein soll. Die Idee, dass ich jetzt keine Verbindung zu einer Serverinstanz herstellen kann, weil die API-Version _OLDER_ ist, ist einfach verblüffend.

Leider werden Clients schnell freigegeben, aber Clients brauchen Zeit, um die Repos zu erreichen.
Aus diesem Grund ist beim Upgrade eines Docker-Computers (Toolbox) möglicherweise die neue Version des Servers nicht verfügbar und Sie bleiben von Ihrem Computer getrennt.

Seltsam ist, dass ein neuerer Client nicht mit älteren APIs "sprechen" kann.

Die Verzögerung zwischen offiziellen Releases und Repos-Updates auf das neue Release ist nicht lösbar. Aus meiner Sicht ist das Upgrade eines Kunden eine blinde Wette. Wenn Sie nicht sicher sind, dass Ihr DM auf dieselbe Clientversion aktualisiert werden kann, werden Sie durch ein Upgrade des Clients gesperrt.

Es gibt nur zwei (andere?) Optionen.

1. Der Client muss in der Lage sein, mit der aktuellen API und mindestens 1 Jahr alten APIs zu sprechen.
2. Das Server-Upgrade muss die auf offiziellen Repos verfügbare Version überprüfen. Wenn sie nicht übereinstimmt, sollte sie aus dem Quellcode (oder einem alternativen Repo) erstellt werden.

Alles, was wir hier tun müssen, ist, den Client dazu zu bringen, ältere Versionen der API zu unterstützen. Warum das keine Designanforderung war, ist seltsam.

@ TheSeanBrady Docker Machine ist ziemlich neu.
Ich bin sicher, dass die Unterstützung einer Reihe von APIs ein Meilenstein dieses Projekts ist.

Dies ist kein Problem mit Docker-Maschine, es ist ein Problem mit 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

Alles, was wir hier tun müssen, ist, den Client dazu zu bringen, ältere Versionen der API zu unterstützen. Warum das keine Designanforderung war, ist seltsam.

Was passiert, wenn ein Client aus der Zukunft einen nicht vorhandenen API-Parameter an einen Daemon sendet, der ihn nicht erwartet? Oder eine Anfrage an einen Endpunkt stellen, der in älteren Versionen nicht vorhanden ist? Wie soll der Dämon über alle möglichen Dinge Bescheid wissen, die ein zukünftiger Client möglicherweise von ihm verlangt?

@ Nathanleclaire
Ich bin kein Experte, aber was ich erwarten würde, ist die gleiche Art und Weise, wie der Handshake mit den alten Audiomodems durchgeführt wurde. Der erste Handshake wurde mit der ältesten API durchgeführt, die garantiert von allen Clients und Servern verstanden wird und zumindest auf grundlegende (wichtige) Aufrufe reagiert.

Bei diesem Handshake wird nur gefragt: Welche API-Version verwenden Sie und die Liste der API-Funktionen, auf die er reagieren kann. Die Funktionen von Client und Servern werden logisch UND-verknüpft, und für DIESE Client-Server-Konfiguration werden allgemeine Funktionen (API-Aufrufe) festgelegt.

Auf dieser Grundlage würde der Client wissen, welche Funktionen er aufrufen kann, und einen Fehler nur auf diejenigen auslösen, die er nicht kann.
IE [NotSupported] - Der Server kann leider nicht auf _______ antworten. Bitte aktualisieren Sie den Server auf Docker nn.nnn.nn oder ändern Sie Ihren Container so, dass er Docker nn.nnn.nn entspricht

Die Idee ist, dass, wenn sich APIs nur um 1% unterscheiden, 1% die Verwendung der anderen 99% nicht deaktiviert, was höchstwahrscheinlich alles ist, was der Client benötigt.

Ich denke, dass es Grund zur Verbesserung gibt. Das Händeschütteln und die Vereinbarung eines gemeinsamen Protokolls ist nicht neu und wurde mehrfach gelöst. Vor allem würde es die Benutzerfreundlichkeit erheblich verbessern.

Denken Sie immer daran, dass ein System, egal wie gut es ist, wenn Clients es nicht verwenden (oder sich unsicher fühlen), nichts entspricht.

@ctroncoso Ich time docker info mit einem Server in amazonec2 / us-east-1 kommuniziere, dauert es etwas mehr als 300 ms - wäre kein Back-and - Vierter Handschlag für jede Anfrage verdoppeln Sie diese Zeit und führen Sie einen nicht trivialen Overhead ein?

Auf jeden Fall kann Machine nichts gegen dieses Problem unternehmen. Ich empfehle daher, unter https://github.com/docker/docker ein Problem zu eröffnen (zuerst nach vorhandenen zu suchen), um Ihre Gedanken bei Bedarf mit Upstream zu teilen.

@ Nathanleclaire sicher, aber würden Sie 20 x 300 (oder 600) ms gegen ein Upgrade

Ich werde die Probleme bei der Docker-Engine überprüfen. Ich denke, wir haben hier eine nette Funktion. Ich mag es, wenn Themengespräche zu einer konstruktiven Idee führen. Danke für deine Zeit @nathanleclaire !!!

Der Client fragt den Server bereits nach der Version ab. Es sollte keine geben
Grund, warum der Client jemals einen API-Parameter senden würde, der nicht existiert,
weil der Client die dafür verfügbaren Parameter kennen sollte
Ausführung. Gleiches gilt für Endpunkte.

Ich würde glauben, dass dieser Ansatz eine Abwertung älterer Menschen erfordern würde
Version irgendwann, vielleicht basierend auf Alter oder Versionsdelta.

Sie können den Client jedoch einfach nicht an älteren Versionen ersticken lassen
Keine Option für Bereitstellungen auf Produktionsebene. Ich habe 3 ganze Maschinen
Hier und ich habe dieses Problem, Bild, was auf verstreut passieren würde
Bereitstellungen.

Am Do, 21. April 2016, um 14:47 Uhr, Nathan LeClaire [email protected]
schrieb:

Alles, was wir hier tun müssen, ist, den Client dazu zu bringen, ältere Versionen der API zu unterstützen.
Warum das keine Designanforderung war, ist seltsam.

Was passiert, wenn ein Client aus der Zukunft einen API-Parameter sendet, der
existiert nicht für einen Daemon, der es nicht erwartet? Oder macht eine Anfrage an eine
Endpunkt, der in älteren Versionen nicht existiert? Wie soll der Dämon sein?
über alle möglichen Dinge Bescheid wissen, die ein zukünftiger Kunde von ihm verlangen könnte?

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/docker/machine/issues/2147#issuecomment -213107758

Der Client fragt den Server bereits nach der Version ab

Können Sie mich darauf hinweisen, wo im Docker-Clientcode dies auftritt?

Ich kenne Go nicht wirklich, aber ich bin mir ziemlich sicher, dass dies das ist:

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

In beiden Fällen wird im gesamten Projekt ein Muster für die Abfrage der API-Version angezeigt.

Am Do, 21. April 2016, um 17:25 Uhr, Nathan LeClaire [email protected]
schrieb:

Der Client fragt den Server bereits nach der Version ab

Können Sie mich darauf hinweisen, wo im Docker-Clientcode dies auftritt?

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/docker/machine/issues/2147#issuecomment -213157495

Hier ist meine Methode, um dieses Problem zu beheben:
gestern, als ich die neueste Version von Docker von https://github.com/docker/docker.git unter Bezugnahme auf https://docs.docker.com/v1.5/contributing/devenvironment/ erstellt und den alten Docker-Client geändert habe binär mit dem neuen.
Es ist "Client ist neuer als Server mit Docker" aufgetreten, und der Docker-Daemon konnte nicht neu gestartet werden:

• / bin / systemctl status docker.service
  ● docker.service - Docker Application Container Engine
  Geladen: geladen (/lib/systemd/system/docker.service; aktiviert; Hersteller-Voreinstellung: aktiviert)

Im Verzeichnis werden jedoch Daemon-Binärdateien generiert:
Bundles / Neueste / Binär-Daemon
sollte das Verzeichnis zum PATH hinzufügen oder Dockerd und Containerd in das Verzeichnis / usr / bin / kopieren
_copy dockerd / usr / bin / docker
Kopieren Sie Docker-Containerd / usr / bin / Containerd
copy ../binary-client/docker / usr / bin_

dann ändere ich /etc/init.d/docker, um das Verzeichnis des Dockerd mit den hervorgehobenen Zeilen zu PATH hinzuzufügen

DOCKERD = / home / master / github.com / docker / bundles / 1.12.0-dev / binary-daemon
export PATH = $ PATH: $ DOCKERD

BASE = Dockerd

Ändern Sie diese in / etc / default / $ BASE (/ etc / default / docker).

DOCKER = / usr / bin / $ BASE

DOCKER = $ DOCKERD / $ BASE
Dies ist die PID-Datei, die vom Docker selbst verwaltet wird
DOCKER_PIDFILE = / var / run / $ BASE.pid
Dies ist die PID-Datei, die vom Start-Stopp-Dämon erstellt / verwaltet wird
DOCKER_SSD_PIDFILE = / var / run / $ BASE-ssd.pid
DOCKER_LOGFILE = / var / log / $ BASE.log
DOCKER_OPTS =
DOCKER_DESC = "Docker"

dann habe ich den service von dockerd neu gestartet, es startet erfolgreich:
_root @ master : ~ # Service Docker Status
● docker.service - Docker Application Container Engine
Geladen: geladen (/lib/systemd/system/docker.service; aktiviert; Hersteller-Voreinstellung: aktiviert)
Aktiv: aktiv (läuft) seit Mi 2016-05-04 04:32:01 EDT; Vor 17h
Dokumente :

root @ master : ~ # Docker-Version
Klient:
Version: 1.12.0-dev
API-Version: 1.24
Go-Version: go1.5.4
Git Commit: 1c0edf6-nicht unterstützt
Gebaut: Mi 4. Mai 05:05:37 2016
OS / Arch: Linux / AMD64

Server:
Version: 1.12.0-dev
API-Version: 1.24
Go-Version: go1.5.4
Git Commit: 1c0edf6-nicht unterstützt
Gebaut: Mi 4. Mai 05:05:37 2016
OS / Arch: Linux / AMD64
root @ master : ~ #

alle laufen glücklich

nur als Referenz

Hallo, kann mir bitte jemand helfen?
Ich habe das gleiche Problem. Ich verstehe, dass ein Docker-Computer-Upgrade funktionieren würde, aber ich verwende Docker unter Windows / MAC nicht. Ich benutze es unter Linux.

Ich folge diesen Anweisungen, um einen Test für das Spielen mit Docker-Inhaltsvertrauen zu erstellen
https://docs.docker.com/engine/security/trust/trust_sandbox/

In der bereitgestellten Docker-Datei wird das 1.12.0-Image verwendet und anschließend das Image erstellt. Wenn ich den Container ausführe, wird keine Verbindung zu meinem Basismaschinen hergestellt, da mein Basismaschinen (Linux) über das Docker 1.11.0 und dieses über 1.12.0 verfügt Also habe ich dann die Docker-Datei geändert und den 1.11.0-dev-Pfad an sie übergeben und das Image erneut generiert. Dieses Mal, als ich den Container mit dieser neuen Datei ausgeführt habe, ist die Docker-Version nur 1.11.0-dev, aber die API-Version ist immer noch 1.24, aber mein Basis-Linux hat die API-Version 1.23.

Wie werde ich das los? Wie reduziere ich meine Container-API-Version auf 1.23 oder erhöhe meine Basis-API-Version auf 1., 24, damit keine Fehler auftreten?

PS: Ich habe versucht, meine Basis-Linux-Docker-Version zu aktualisieren, aber die API-Version ist immer noch nur 1.23.

@mkonakan

Unter Ubuntu aktualisiert sudo apt-get install -y docker-engine die nativ installierte Version von Docker (Achtung: Dies funktioniert nur, wenn Sie Docker über die offiziellen Kanäle installiert haben).

docker-machine upgrade aktualisiert, wie Sie bemerkt haben, alle boot2docker.iso Sie haben, auf die neueste Version

@nathanleclaire Hallo, ich habe meine Docker-Engine auf meinem Basis-Ubuntu aktualisiert und sie hat die neueste 1.11.1-Client-Version und API-Version 1.23, aber der von mir erstellte Container hat die 1.24-API-Version und daher gibt es das Problem. Ich suche also nach einer Möglichkeit, wie ich meine API-Version im Container herunterstufen kann oder wie ich meine API-Version auf dem Basismaschinen von 1.23 auf 1.24 aktualisieren kann.

@mkonakan Am besten kompilieren Sie Docker aus dem Quellcode, legen die Binärdatei an der entsprechenden Stelle ab und starten den Daemon neu. Wenn der von Ihnen erstellte Container eine solche Version von Docker verwendet, ist es wahrscheinlich, dass eine Zeile in der Docker-Datei etwas Ähnliches tut.

Gelöst. Ich habe die Binärdatei von meinem Basismaschinen in den Container kopiert, anstatt die Standarddatei in dieser Docker-Datei, die die neueste API-Version erhält. Vielen Dank.

👍

Warum ist das geschlossen? Kann der neueste Docker-Client mit älteren Docker-Daemons kommunizieren?

@megastef Nicht, dass ich es

Ich habe das gleiche Problem, ich versuche, Docker-Maschine Upgrade-Namen zu verwenden , so schade, dass das nicht funktioniert. Ich weiß nicht, ob das Netzwerk although use proxy , aber ich habe dieses Problem gelöst.
1.Finden Sie die Toolbox von
2. Laden Sie es herunter und installieren Sie es. Anschließend wird Ihre Version aktualisiert.

Verwenden Sie $ env: DOCKER_API_VERSION = 1.23 , um die Umgebungsvariable

Ich hatte auch dieses Problem mit der Windows-Beta. docker-machine upgrade hat nicht geholfen.
Eine alternative Lösung besteht darin , --engine-install-url https://test.docker.com zu docker-machine create hinzuzufügen , wodurch die Maschine mit dem neuesten Release-Kandidaten von Docker initialisiert wird.

Einzelheiten:

> 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!)

Kann dieses Problem behoben (oder möglicherweise umgangen) werden, indem DOCKER_API_VERSION zur Ausgabe von docker-machine env hinzugefügt wird?

Ich habe das Problem dank @eddieajau gelöst.

Mein Docker-Client (DOCKER_API_VERSION = 1.24) ist Ubuntu Linux und der Docker-Server (DOCKER_API_VERSION = 1.23) befindet sich bei Carina by Rackspace BETA.

Fügen Sie Ihrem Kunden einfach export DOCKER_API_VERSION=1.23 , damit es funktioniert.

Vielen Dank.

export DOCKER_API_VERSION=1.23 mein Problem gelöst. danke an @eddieajau

Danke @ kid1412z, es hat auch bei mir als schnelle Lösung funktioniert.

Zurück zur älteren Version

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

Oh mein Gott. Das Aushandeln von Protokollversionen muss noch nicht erfunden werden. Ich habe mit Software aus den 90ern gearbeitet, die damit umgehen konnte. igitt, wirklich.

@FlorianHeigl Docker Client 1.13 und höher führt die Aushandlung der API-Version mit dem Daemon durch. Die minimale Daemon-Version, auf die zurückgegriffen wird, ist Docker 1.12. Für ältere Dämonen wird die Überschreibung DOCKER_API_VERSION benötigt

@eddieajau Die
Ich verwende Docker für Windows und stelle eine Verbindung zu einem Docker-Server her, der auf einem NAS ausgeführt wird, den ich nicht aktualisieren kann.

Windows:

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

Nas:

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

Hat jemand eine Idee?

@manuelsalvatori das ist ein Problem im Docker 17.09 cli; Es wurde in 17.10 behoben (siehe https://github.com/moby/moby/pull/35008) und noch nicht auf 17.09 zurückportiert.

Beachten Sie jedoch, dass Docker 1.11 nicht mehr verfügbar ist und bekannte Schwachstellen aufweist, darunter ein CVE in RunC, mit dem Containerprozesse aus dem Container ausbrechen und auf den Host zugreifen können (behoben in Docker 1.12.6 und höher, die ausgeliefert werden) mit einer gepatchten RunC-Version https://github.com/moby/moby/releases/tag/v1.12.6)