Machine: Respuesta de error del demonio: el cliente es más nuevo que el servidor con Docker 1.9 RC3

Creado en 3 nov. 2015  ·  72Comentarios  ·  Fuente: docker/machine

Aquí está la información de la versión:

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

Creó una máquina 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

Configurado como:

eval $(docker-machine env lab2)

docker ps da el siguiente error:

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

Esta es una máquina recién creada que utiliza la última versión de Docker CLI y Docker Machine.

Comentario más útil

¿Ejecutaste docker-machine upgrade ?

Todos 72 comentarios

Sí, la UX no es excelente, pero si desea usar un binario RC Docker, debe especificar que se use un ISO candidato de lanzamiento para usar, por ejemplo, --virtualbox-boot2docker-url https://github.com/tianon/boot2docker-legacy/releases/download/v1.9.0-rc4/boot2docker.iso

¿Por qué este tratamiento especial para RC?

Esto lo hace no intuitivo.

Bueno, el binario de su cliente Docker también es un RC. ¿Cómo cree que debería funcionar?

RC debería recoger automáticamente boot2docker.iso de RC. --virtualbox-boot2docker-url solo debe usarse para anular el valor predeterminado. Y el valor predeterminado debería ser el mismo que el binario del cliente Docker.

Creo que podríamos hacerlo mejor para permitir que upgrade / create use nuevos RC de forma predeterminada, pero actualmente los RC para boot2docker los hemos mantenido en la bifurcación de @tianon , por lo que necesitamos cambie nuestro hábito de hacer eso también si vamos a apoyar esto. Me preocupa un poco hacer las cosas demasiado mágicas, ya que todos tienen expectativas realmente diferentes a este respecto.

Hacer coincidir el boot2docker.iso con el binario del cliente Docker parece un enfoque razonable e intuitivo. Y habrá una opción para anular de todos modos.

¡Sin magia, solo intuitivo al menos para mí!

Viendo exactamente el mismo error con Docker 1.9.0 y 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)

No veo ninguna forma de reabrir el problema ahora.

¿Ejecutaste docker-machine upgrade ?

Esta máquina se acaba de crear. ¿Necesito ejecutar docker-machine upgrade para eso también?

@ arun-gupta Lo más probable es que actualice su caché y / o en caso de que haya creado la máquina antes de que ocurriera el lanzamiento oficial de b2d.

@nathanleclaire creó la máquina hace 30 minutos de nuevo y todavía tiene el mismo error. docker-compose up -d en un docker-compose.yml funcionó correctamente. Pero docker ps está dando el error nuevamente:

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

Actualizar la máquina de forma explícita.

¿Existe un mapeo de b2d.iso y la versión de API cliente / servidor?

docker-machine upgrade name debería funcionar, supongo que es un "problema de caché ISO". ¿Intentaste ese comando?

El boot2docker.iso siempre se asigna a la versión de API de lanzamiento de Docker correspondiente. Puede ver la versión de la caché en los metadatos haciendo file $HOME/.docker/machine/cache/boot2docker.iso .

docker-machine upgrade resolvió el problema.

Gracias Arun. Vamos a trabajar en algunos problemas relacionados con el flujo de actualización en esta iteración, por lo que esperamos que sea un poco más claro en el futuro.

: +1: por docker-machine upgrade

+1 para la actualización de la máquina acoplable, asumiendo que lo único que se actualiza está relacionado con la ventana acoplable;)

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

Después de la actualización con Docker Toolbox, la máquina predeterminada se detuvo pero se actualizó.
Otras máquinas no se detuvieron y no se actualizaron.

docker-machine upgrade <machine-name> funciona también para mí

Estoy en Windows 10 y vi un problema similar que, extrañamente, desapareció en una segunda ejecución. Esto es lo que tenía y la secuencia de pasos.

  1. Estaba usando Docker Toolbox 1.8.3 y decidí usar la última versión 1.9.0c ya que enfrentaba algunos problemas extraños.
  2. Ejecuté un docker-machine rm default solo como paso de seguridad
  3. Descargó e instaló la versión 1.9.0c de la caja de herramientas
  4. Git fue lo único que no elegí cuando se me solicitó e instalé todo lo demás.
  5. Lanzó la _Docker Quickstart Terminal_
  6. Todo se veía bien
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.Comprueba para ver que se crea la máquina

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

8.Todo bien hasta ahora, pero

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

9. ¿Qué tengo?

$ 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.Ejecute la actualización de la máquina como se sugirió anteriormente y obtengo:

$ 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. Todo bien después de eso. Simplemente ejecutar la actualización por segunda vez pareció funcionar.

@ arun-gupta @nathanleclaire actualización de la máquina acoplable [nombre de la máquina] solucionó la mía !!! Muchas gracias. FWIW, esta actualización-sincronización entre cliente y servidor es realmente un PITA. ¡Cualquier ciclo dedicado a mejorar esto será muy apreciado!

Esto no se limita a RC3 ni a la máquina acoplable. Si el cliente de Docker es 1.9.xy el servidor ejecuta Docker 1.8.x, se observa el mensaje de error. Esto es muy poco práctico en términos de administración de implementaciones si no tiene o no puede tener la misma versión del motor de la ventana acoplable instalada en todos los servidores y todos los clientes. Soy de la opinión de que se trata de una rotura bastante grave.

También básicamente el mismo problema que https://github.com/docker/machine/issues/1839

docker-machine upgrade <machine-name> también funcionó para mí

docker-machine upgrade <machine-name> no funcionó para mí. Tuve que actualizar todos mis servidores a una versión de desarrollo de Docker, luego bajé de categoría nuevamente y comencé a obtener:

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

Después de la degradación manual, ejecuté docker-machine upgrade <machine-name> , pero el error persiste.

mi culpa ... necesitaba eliminar el binario docker más nuevo de mi ruta.

actualización de la máquina acoplableA mi también me sirvió.

Así es como lo hice funcionar después de recibir el mismo error para 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

Tuve que ejecutar esto para 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 ha sido declarado obsoleto. ¿Es esta realmente la solución prevista del problema?

docker-machine todavía usa el ISO boot2docker para construir la VM, eso no es nada inusual.

Parece que hay muchas personas que confirman la actualización del demonio de la ventana acoplable en el servidor (VM), pero esto no resuelve el caso en el que el demonio de la ventana acoplable no se puede actualizar de inmediato. La única solución rápida y medio sensata que he encontrado hasta ahora es simplemente descargar un binario de cliente apropiado de las versiones y ejecutar el correcto dependiendo de la versión del servidor.

boot2docker ha sido declarado obsoleto. ¿Es esta realmente la solución prevista del problema?

Como señala @superdump , la CLI de boot2docker (invocada usando boot2docker en la línea de comando) ha quedado obsoleta, pero el sistema operativo aún permanece.

¡Gracias @nathanleclaire y @superdump por aclarar!

Me las arreglé (lamentablemente solo temporalmente) para resolver el problema instalando dmv y degradando a través de

dmv use 1.8.1

Sin embargo, al extraer algunas imágenes (pero no todas), docker sigue cambiando a 1.9.1 y ya no se muestra nada debajo de docker images (pero era antes).

¿Que esta pasando aqui? ¿Es esta una versión con errores / inestable?

Existe una versión B para la versión candidata2

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

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

Acabo de tener este problema con mi mac local (homebrew) ejecutando 1.10, mientras que la máquina acoplable, en este caso en Google gce, no funcionaría incluso después de intentar la actualización de la máquina acoplable. Tuve que hacer ssh manualmente en él y agregar específicamente el repositorio deb para forzar una actualización a 1.10.

Acabo de encontrar ese en 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 

Lo resolví después de 3 días de depuración, y escribí la respuesta en StackOverflow, DEBE verificarla http://stackoverflow.com/questions/24586573/docker-error-client-and-server-dont-have-same-version / 36298911 # 36298911

Eso es solo sobre la máquina acoplable / caja de herramientas acoplable. Todas esas propuestas son soluciones alternativas y tal vez estén bien para usar con la caja de herramientas de la ventana acoplable, pero no están bien para las implementaciones reales de la ventana acoplable donde diferentes servidores pueden tener diferentes versiones de servidor y no se pueden actualizar de inmediato.

El verdadero problema es que los clientes de Docker más nuevos no pueden hablar con servidores más antiguos. Idealmente, esto debería arreglarse en la propia ventana acoplable de alguna manera para que los clientes sean compatibles con versiones anteriores.

Esta es realmente una falla de diseño impresionante y sorprendente que realmente debe abordarse de inmediato para que la máquina acoplable sea una herramienta creíble. La idea de que no puedo conectarme a una instancia de servidor ahora porque la versión de la API es _OLDER_ es simplemente, bueno, asombrosa.

Desafortunadamente, los clientes se liberan rápidamente, pero los clientes tardan en llegar a los repositorios.
Es por eso que cuando actualiza una máquina acoplable (caja de herramientas), es posible que la nueva versión del servidor no esté disponible y se quede desconectado de su máquina.

Lo extraño es que un cliente más nuevo no puede "hablar" con las API más antiguas.

El retraso entre los lanzamientos oficiales y los repositorios que se actualizan a la nueva versión es algo que no tiene solución. Como yo lo veo, esto hace que actualizar un cliente sea una apuesta ciega. A menos que esté seguro de que su DM se puede actualizar a la misma versión de cliente, actualizar el cliente lo bloquea.

Solo hay dos (¿alguna otra?) Opciones.

  1. El cliente debe poder comunicarse con la API actual y con las apis de al menos 1 año.
  2. La actualización del servidor debe verificar la versión disponible en los repositorios oficiales, y si no coincide, debería compilarse desde la fuente (o repositorio alternativo).

Todo lo que tenemos que hacer aquí es hacer que el cliente admita versiones anteriores de la API. Es extraño por qué eso no fue un requisito de diseño.

@TheSeanBrady Docker Machine es bastante nuevo.
Estoy seguro de que la compatibilidad con una variedad de API es un hito de este proyecto.

Esto no es un problema con docker-machine, es un problema con 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

Todo lo que tenemos que hacer aquí es hacer que el cliente admita versiones anteriores de la API. Es extraño por qué eso no fue un requisito de diseño.

¿Qué sucede cuando un cliente del futuro envía un parámetro de API que no existe a un demonio que no lo espera? ¿O realiza una solicitud a un punto final que no existe en versiones anteriores? ¿Cómo se supone que el demonio debe saber todas las cosas posibles que un cliente futuro podría solicitarle?

@nathanleclaire
No soy un experto, pero lo que esperaría es la misma forma en que se hizo el apretón de manos en los antiguos módems de audio. El apretón de manos inicial se realizó utilizando la API más antigua, que se garantiza que será entendida por todos los clientes y servidores, y que al menos responderá a llamadas básicas (vitales).

Este apretón de manos solo pediría: ¿Qué versión de API está utilizando y la lista de funciones de API a las que puede responder? Las funciones del cliente y los servidores están lógicamente unidas por AND y un conjunto común de funciones (llamadas api) se establecen para ESA configuración cliente-servidor.

Con base en eso, el cliente sabría qué funciones puede llamar y arrojará un error solo en aquellas a las que no puede.
IE [NotSupported] - Lo sentimos, el servidor no puede responder a _______. Actualice el servidor a Docker nn.nnn.nn o modifique su contenedor para que se ajuste a Docker nn.nnn.nn

La idea es que si las API solo difieren en un 1%, ese 1% no deshabilita el uso del otro 99% que probablemente sea todo lo que el cliente necesitaba.

Creo que hay margen de mejora. El apretón de manos y el acuerdo sobre un protocolo común no es nuevo y se ha resuelto varias veces. Sobre todo, mejoraría enormemente la usabilidad.

Recuerde siempre que un sistema, no importa lo bueno que sea, si los clientes no lo usan (o se sienten inseguros usándolo), no equivale a nada.

@ctroncoso Veo su punto, pero si ejecuto time docker info comunicándome con un servidor en amazonec2 / us-east-1 me tomaría un poco más de 300ms, no sería un retroceso - ¿Apretón de manos para cada solicitud, el doble de tiempo e introducir una cantidad no trivial de gastos generales?

En cualquier caso, no hay nada que Machine pueda hacer sobre este problema, por lo que sugiero que se abra un problema (busque los existentes primero) en https://github.com/docker/docker para compartir sus pensamientos con upstream si lo desea.

@nathanleclaire seguro que sí, pero ¿cambiaría 20 x 300 (o 600) ms por una actualización que esté garantizada para funcionar? Además, sería solo para la primera llamada. Quizás se pueda generar una "clave de sesión" en esa primera llamada que establezca que el protocolo de enlace ya se ha realizado. y se utiliza en lo siguiente sin volver a apretón de manos. Estoy seguro de que hay problemas de seguridad que esto podría plantear, pero prefiero tener un sistema a prueba de fallas no tan rápido, que uno que podría presentar una carga de trabajo insospechada solo porque ubuntu / fedora / centos no lo hizo. No actualice sus repositorios a tiempo. Veo que se trata de un problema del motor acoplable, pero la máquina tiene la culpa.

Verificaré los problemas en Docker-Engine. Creo que tenemos una buena característica aquí. Me gusta cuando las conversaciones temáticas terminan en una idea constructiva. Gracias por tu tiempo @nathanleclaire !!!

El cliente ya consulta la versión del servidor. No debería haber
razón por la que el cliente alguna vez enviaría un parámetro de API que no existe,
porque el cliente DEBE estar al tanto de los parámetros disponibles para eso
versión. Lo mismo ocurre con los puntos finales.

Creo que este enfoque requeriría la desaprobación de los
versión en algún momento, quizás según la edad o la versión delta.

Sin embargo, simplemente no puede hacer que el cliente se ahogue con versiones anteriores, es
no es una opción para implementaciones de nivel de producción. Tengo 3 maquinas enteras
aquí y tengo este problema, imagen de lo que sucedería en dispersos
despliegues.

El jueves 21 de abril de 2016 a las 2:47 p.m., Nathan LeClaire [email protected]
escribió:

Todo lo que tenemos que hacer aquí es hacer que el cliente admita versiones anteriores de la API.
Es extraño por qué eso no fue un requisito de diseño.

¿Qué sucede cuando un cliente del futuro envía un parámetro de API que
no existe para un demonio que no lo espera? O hace una solicitud a un
endpoint que no existe en versiones anteriores? ¿Cómo se supone el demonio?
para conocer todas las cosas posibles que un futuro cliente podría pedirle?

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/machine/issues/2147#issuecomment -213107758

El cliente ya consulta al servidor por la versión

¿Puede indicarme en qué parte del código del cliente de Docker ocurre esto?

Realmente no sé Go, pero estoy bastante seguro de que eso es lo que hace:

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

De cualquier manera, verá un patrón de consulta de la versión de la API en todo el proyecto.

El jueves 21 de abril de 2016 a las 5:25 p.m., Nathan LeClaire [email protected]
escribió:

El cliente ya consulta al servidor por la versión

¿Puede indicarme en qué parte del código del cliente de Docker ocurre esto?

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/machine/issues/2147#issuecomment -213157495

aquí está mi método para resolver este problema:
ayer, cuando hice la versión más reciente de docker de https://github.com/docker/docker.git refiriéndose a https://docs.docker.com/v1.5/contributing/devenvironment/ y modifiqué el antiguo cliente de docker binario con el nuevo.
se produjo "el cliente es más nuevo que el servidor con Docker", y el demonio de Docker no pudo reiniciarse:

  • / bin / systemctl status docker.service
    ● docker.service: motor contenedor de aplicaciones Docker
    Cargado: cargado (/lib/systemd/system/docker.service; habilitado; preajuste del proveedor: habilitado)

pero hay binarios de demonio generados en el directorio:
bundles / latest / binary-daemon
debe agregar el directorio a la RUTA, o copiar dockerd y containerd a / usr / bin /
_copy dockerd / usr / bin / docker
copiar docker-containerd / usr / bin / containerd
copiar ../binary-client/docker / usr / bin_

luego modifico /etc/init.d/docker para agregar el directorio del dockerd a PATH con las líneas resaltadas

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

BASE = dockerd

modificarlos en / etc / default / $ BASE (/ etc / default / docker)

DOCKER = / usr / bin / $ BASE

DOCKER = $ DOCKERD / $ BASE
Este es el archivo pid administrado por docker.
DOCKER_PIDFILE = / var / run / $ BASE.pid
Este es el archivo pid creado / administrado por start-stop-daemon
DOCKER_SSD_PIDFILE = / var / run / $ BASE-ssd.pid
DOCKER_LOGFILE = / var / log / $ BASE.log
DOCKER_OPTS =
DOCKER_DESC = "Docker"

luego reinicié el servicio de dockerd, comenzó con éxito:
_root @ master : ~ # service docker status
● docker.service: motor contenedor de aplicaciones Docker
Cargado: cargado (/lib/systemd/system/docker.service; habilitado; preajuste del proveedor: habilitado)
Activo: activo (en ejecución) desde el miércoles 04/05/2016 04:32:01 EDT; Hace 17h
Documentos: https: //docs.docker.com_

root @ master : ~ # versión de Docker
Cliente:
Versión: 1.12.0-dev
Versión de API: 1.24
Go versión: go1.5.4
Confirmación de Git: 1c0edf6-unsupported
Construido: Mié 4 de mayo 05:05:37 2016
SO / Arch: linux / amd64

Servidor:
Versión: 1.12.0-dev
Versión de API: 1.24
Go versión: go1.5.4
Confirmación de Git: 1c0edf6-unsupported
Construido: Mié 4 de mayo 05:05:37 2016
SO / Arch: linux / amd64
root @ maestro : ~ #

todos corren felices

solo para referencia

Hola, ¿alguien puede ayudarme?
Tengo el mismo problema. Entiendo que la actualización de la máquina acoplable funcionaría, pero no estoy usando la ventana acoplable en Windows / MAC. Lo estoy usando en Linux.

Estoy siguiendo estas instrucciones para hacer una prueba para jugar con la confianza del contenido de la ventana acoplable
https://docs.docker.com/engine/security/trust/trust_sandbox/

En el dockerfile proporcionado, toma la imagen 1.12.0 y luego crea la imagen, por lo que cuando ejecuto el contenedor no se conecta a mi máquina base porque mi máquina base (Linux) tiene la ventana acoplable 1.11.0 y esta tiene 1.12.0 , así que cambié el archivo de la ventana acoplable y le pasé la ruta 1.11.0-dev y volví a generar la imagen. Esta vez, cuando ejecuté el contenedor con este nuevo archivo, la versión de la ventana acoplable es solo 1.11.0-dev, pero la versión de API sigue siendo 1.24 pero mi Linux base tiene la versión de API 1.23.

¿Cómo me deshago de esto? ¿Cómo reduzco la versión de la API de mi contenedor a 1.23 o bien aumento la versión de la API base a 1., 24 para que no haya errores?

PD: Intenté actualizar mi versión base de Linux Docker, pero la versión de API es solo 1.23.

upload

@mkonakan

En Ubuntu, sudo apt-get install -y docker-engine actualizará la versión instalada de forma nativa de Docker (Advertencia: esto solo funcionará si ha instalado Docker usando los canales oficiales)

docker-machine upgrade , como señaló, actualizará cualquier boot2docker.iso que tenga a la última versión

@nathanleclaire Hola, actualicé mi motor docker en mi ubuntu base y tiene la última versión de cliente 1.11.1 y la versión de API 1.23, pero el contenedor que construí tiene la versión de API 1.24 y, por lo tanto, existe el problema. Entonces, estoy buscando la forma de cómo puedo degradar mi versión de API en el contenedor o, de lo contrario, ¿cómo puedo actualizar mi versión de API en la máquina base de 1.23 a 1.24?

@mkonakan Tu mejor

Resuelto. Copié el archivo binario de mi máquina base al contenedor en lugar del archivo predeterminado en ese dockerfile que está obteniendo la última versión de API. Gracias.

👍

¿Por qué esta cerrado? ¿El último cliente de Docker puede interactuar con demonios de Docker más antiguos?

@megastef No que yo sepa, pero ese es un problema del proyecto ascendente (https://github.com/docker/docker), por lo que sugiero buscar problemas de compatibilidad hacia adelante allí si desea discutir .

Tengo el mismo problema, trato de usar el nombre de actualización de la máquina acoplable , así que lástima que no funcione. No sé si la red although use proxy , pero resolví este problema.
1.Encuentre la caja de herramientas de
2.Descargue e instálelo, luego actualizará su versión.

docker-machine upgrade no funcionó en mi escenario. Parece que CoreOS Docker Host está bloqueado en la versión 1.22. Mi cliente está ejecutando 1.24. ¿Cómo puedo resolver esto?

@ pcgeek86 prueba export DOCKER_API_VERSION=1.23 (ver https://forums.docker.com/t/docker-for-mac-stopped-running-docker-related-commands/16153/6)

También estaba teniendo este problema, con la versión beta de Windows. docker-machine upgrade no ayudó.
Una solución alternativa es agregar --engine-install-url https://test.docker.com a docker-machine create , que inicializará la máquina con la última versión candidata de Docker.

Detalles:

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

¿Se puede arreglar este (o quizás solucionarlo) agregando DOCKER_API_VERSION a la salida de docker-machine env ?

Resolví el problema gracias a @eddieajau.

Mi cliente de Docker (DOCKER_API_VERSION = 1.24) es Ubuntu Linux y el servidor Docker (DOCKER_API_VERSION = 1.23) está en Carina by Rackspace BETA.

Simplemente agregue export DOCKER_API_VERSION=1.23 a su cliente para que funcione.

Gracias.

export DOCKER_API_VERSION=1.23 resolvió mi problema. gracias a @eddieajau

Gracias @ kid1412z , también me funcionó como una solución rápida.

Volver a la versión anterior

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

Dios mio. negociar versiones de protocolo no es algo que todavía deba inventarse. He trabajado con software de los 90 que podía manejar esto. puaj, de verdad.

@FlorianHeigl docker client 1.13 y superior negocia la versión de API con el demonio; la versión mínima del demonio a la que recurrirá es la ventana acoplable 1.12. Para daemons más antiguos, se necesita la anulación DOCKER_API_VERSION

@eddieajau La solución alternativa de la variable de entorno DOCKER_API_VERSION = 1.23 ya no funciona.
Utilizo Docker para Windows y me estoy conectando a un servidor Docker que se ejecuta en un NAS que no puedo actualizar.

Ventanas:

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

¿Alguien tiene alguna idea?

@manuelsalvatori ese es un problema en el docker 17.09 cli; está corregido en 17.10 (ver https://github.com/moby/moby/pull/35008)., aún no se ha actualizado a 17.09.

Sin embargo, tenga en cuenta que la ventana acoplable 1.11 está al final de su vida útil y tiene vulnerabilidades conocidas, entre las cuales un CVE en RunC que permite que los procesos del contenedor salgan del contenedor y obtengan acceso al host (resuelto en la ventana acoplable 1.12.6 y versiones posteriores, que se envían con una versión RunC parcheada https://github.com/moby/moby/releases/tag/v1.12.6)

¿Fue útil esta página
0 / 5 - 0 calificaciones