Sim, o UX não é ótimo, mas se você quiser usar um binário RC Docker, você precisa especificar o uso de um candidato a lançamento ISO para usar, por exemplo, --virtualbox-boot2docker-url https://github.com/tianon/boot2docker-legacy/releases/download/v1.9.0-rc4/boot2docker.iso

Por que esse tratamento especial para RC?

Isso o torna não intuitivo.

Bem, o binário do cliente Docker também é um RC. Como você acha que deveria funcionar?

O RC deve obter automaticamente o boot2docker.iso do RC. --virtualbox-boot2docker-url deve ser usado apenas para substituir o valor padrão. E o padrão deve ser igual ao binário do cliente Docker.

Acho que poderíamos fazer melhor sobre permitir que upgrade / create usasse novos RCs por padrão, mas atualmente RCs para boot2docker que temos mantido no fork de

Combinar boot2docker.iso com o binário do cliente Docker parece uma abordagem razoável e intuitiva. E haverá uma opção para substituir de qualquer maneira.

Nenhuma mágica, apenas intuitiva, pelo menos para mim!

Vendo exatamente o mesmo erro com Docker 1.9.0 e 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)

Não vejo nenhuma maneira de reabrir o problema agora.

Você executou docker-machine upgrade ?

Esta máquina acaba de ser criada. Eu preciso executar docker-machine upgrade para isso também?

@ arun-gupta Provavelmente, para atualizar seu cache e / ou no caso de você ter feito a máquina antes do lançamento oficial do b2d.

@nathanleclaire criou a máquina 30 minutos atrás novamente e ainda obteve o mesmo erro. docker-compose up -d em um docker-compose.yml funcionou com sucesso. Mas docker ps está apresentando o erro novamente:

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

Atualizando a máquina explicitamente.

Existe um mapeamento de b2d.iso e versão da API Cliente / Servidor?

docker-machine upgrade name deve funcionar, meu palpite é que é um "problema de cache ISO". Você tentou esse comando?

O boot2docker.iso sempre mapeia para a versão correspondente da API de lançamento do Docker. Você pode ver a versão do cache nos metadados fazendo file $HOME/.docker/machine/cache/boot2docker.iso .

docker-machine upgrade resolveu o problema.

Obrigado Arun. Estaremos trabalhando em alguns problemas em torno do fluxo de atualização desta iteração, então esperamos que fique um pouco mais claro no futuro.

: +1: por docker-machine upgrade

+1 para atualização da máquina docker - assumindo que a única coisa que está sendo atualizada esteja relacionada ao docker;)

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

Após a atualização com o Docker Toolbox, a máquina padrão foi interrompida, mas atualizada.
Outra máquina não foi interrompida e não foi atualizada.

docker-machine upgrade <machine-name> também funciona para mim

Estou no Windows 10 e vi um problema semelhante que, estranhamente, simplesmente desapareceu em uma segunda execução. Aqui está o que eu tinha e a sequência de etapas.

1. Eu estava usando o Docker Toolbox 1.8.3 e decidi usar a última versão 1.9.0c porque estava enfrentando alguns problemas estranhos.
2. Eu executei docker-machine rm default apenas como uma etapa de segurança
3. Baixou e instalou a caixa de ferramentas versão 1.9.0c
4. Git foi a única coisa que não escolhi quando solicitado e instalei todo o resto.
5. Lançado no _Docker Quickstart Terminal_
6. Tudo parecia bem

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. Verificado para ver se a máquina foi criada

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

8. Tudo bem até agora, mas

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

9. O que eu tenho?

$ 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. Execute a atualização da máquina conforme sugerido acima e eu obtenho:

$ 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. Tudo bem depois disso. Apenas executar a atualização uma segunda vez pareceu funcionar.

@ arun-gupta @nathanleclaire atualização da máquina docker [nome da máquina] corrigiu o meu !!! Muito obrigado. FWIW, esta sincronização de atualização entre cliente e servidor é realmente um PITA. Todos os ciclos gastos para tornar isso melhor serão muito apreciados!

Isso não está restrito ao RC3 nem à máquina docker. Se o docker cliente for 1.9.xe o servidor estiver executando docker 1.8.x, a mensagem de erro será observada. Isso é muito impraticável em termos de gerenciamento de implantações se você não tiver ou não puder ter a mesma versão do docker engine instalada em todos os servidores e clientes. Sou de opinião que se trata de uma ruptura bastante séria.

Também basicamente o mesmo problema que https://github.com/docker/machine/issues/1839

docker-machine upgrade <machine-name> funcionou também para mim

docker-machine upgrade <machine-name> não funcionou para mim. Tive que atualizar todos os meus servidores para uma versão dev do docker, depois fiz o downgrade novamente e comecei a obter:

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

Após o downgrade manual, executei docker-machine upgrade <machine-name> , mas o erro permanece.

minha culpa ... eu precisava excluir o binário docker mais recente do meu caminho.

atualização da máquina dockerfuncionou para mim também.

Veja como eu o coloquei em execução depois de obter o mesmo erro para o 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

Tive que executar isso 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 foi declarado obsoleto. Essa é realmente a solução pretendida para o problema?

docker-machine ainda usa o ISO boot2docker para construir a VM, isso não é nada incomum.

Parece que há muitas pessoas confirmando a atualização do daemon do docker no servidor (VM), mas isso não resolve o caso em que o daemon do docker não pode ser atualizado imediatamente. A única solução rápida e sensata que encontrei até agora é apenas baixar um binário de cliente apropriado das versões e executar o correto, dependendo da versão do servidor.

boot2docker foi declarado obsoleto. Essa é realmente a solução pretendida para o problema?

Como @superdump observa, o boot2docker CLI (invocado usando boot2docker na linha de comando) se tornou obsoleto, mas o sistema operacional ainda permanece.

Obrigado @nathanleclaire e @superdump pelo esclarecimento!

Consegui (infelizmente apenas temporariamente) resolver o problema instalando dmv e fazendo downgrade via

dmv use 1.8.1

No entanto, ao extrair algumas imagens (mas não todas), docker continua mudando para 1.9.1 e nada é mostrado em docker images mais (mas era antes).

O que está acontecendo aqui? Esta é uma versão com erros / instável?

Há uma versão B para o candidato a lançamento 2

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

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

Acabei de ter esse problema com meu mac local (homebrew) executando 1.10, enquanto a docker-machine - neste caso no google gce, não funcionava mesmo depois de tentar a atualização da docker-machine. Tive que fazer o SSH manualmente nele e adicionar especificamente o repositório deb para forçar uma atualização para 1.10.

Acabei de encontrar aquele no 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 

Resolvi isso após 3 dias de depuração e escrevi a resposta no StackOverflow, você DEVE verificar http://stackoverflow.com/questions/24586573/docker-error-client-and-server-dont-have-same-version / 36298911 # 36298911

Isso ainda é apenas sobre a docker machine / docker toolbox. Todas essas propostas são soluções alternativas e talvez sejam adequadas para uso com a caixa de ferramentas do docker, mas não são adequadas para implantações reais do docker, onde servidores diferentes podem ter versões de servidor diferentes e não podem ser atualizados imediatamente.

O verdadeiro problema é que os clientes docker mais novos não podem se comunicar com servidores mais antigos. Idealmente, isso deve ser corrigido no próprio docker de alguma forma para que os clientes sejam compatíveis com versões anteriores.

Esta é realmente uma falha de design impressionante e impressionante que realmente precisa ser tratada imediatamente se a docker-machine for uma ferramenta confiável. A ideia de que não consigo me conectar a uma instância do servidor agora porque a versão da API é _OLDER_ é simplesmente espantosa.

Infelizmente, os clientes são liberados rapidamente, mas demoram para chegar aos repos.
É por isso que quando você atualiza uma docker-machine (caixa de ferramentas), a nova versão do servidor pode não estar disponível e você fica desconectado de sua máquina.

O que é estranho é que um cliente mais recente não consegue "falar" com APIs mais antigas.

O atraso entre os lançamentos oficiais e a atualização dos repositórios para o novo lançamento é algo que não tem solução. A meu ver, isso torna a atualização de um cliente uma aposta cega. A menos que você tenha certeza de que seu DM pode ser atualizado para a mesma versão do cliente, atualizar o cliente bloqueia você.

Existem apenas duas (outras?) Opções.

1. O cliente deve ser capaz de se comunicar com a API atual e apis com pelo menos 1 ano de idade.
2. A atualização do servidor deve verificar a versão disponível nos repositórios oficiais e, se não corresponder, deve ser compilada a partir da fonte (ou repositório alternativo).

Tudo o que precisamos fazer aqui é fazer com que o cliente suporte versões mais antigas da API. Por que isso não era um requisito de design é estranho.

@TheSeanBrady Docker Machine é bastante novo.
Tenho certeza de que o suporte a uma variedade de APIs está em algum marco deste projeto.

Este não é um problema com a docker-machine, é um problema com o 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

Tudo o que precisamos fazer aqui é fazer com que o cliente suporte versões mais antigas da API. Por que isso não era um requisito de design é estranho.

O que acontece quando um cliente do futuro envia um parâmetro API que não existe para um daemon que não o espera? Ou faz uma solicitação a um endpoint que não existe nas versões anteriores? Como o daemon deve saber sobre todas as coisas possíveis que um futuro cliente pode solicitar dele?

@nathanleclaire
Não sou especialista, mas o que eu esperaria é a mesma maneira que o aperto de mão era feito nos modems de áudio antigos. O handshake inicial foi feito usando a API mais antiga, que é garantida para ser entendida por todos os clientes e servidores, e foi garantida para responder pelo menos às chamadas básicas (vitais).

Este handshake pediria apenas: Qual versão da API você está usando e a lista de funções da API às quais ela pode responder. Funções de cliente e servidores são logicamente combinadas com AND e um conjunto comum de funções (chamadas de api) são definidas para AQUELA configuração cliente-servidor.

Com base nisso, o cliente saberia quais funções ele pode chamar e lançar um erro apenas naquelas que não pode.
IE [NotSupported] - Desculpe, o servidor não pode responder a _______. Atualize o servidor para Docker nn.nnn.nn ou modifique seu contêiner para estar em conformidade com Docker nn.nnn.nn

A ideia é que se as APIs diferem apenas em 1%, esse 1% não desativa o uso dos outros 99% que provavelmente é tudo que o cliente precisava.

Acho que há espaço para melhorias. Apertar a mão e concordar em um protocolo comum não é novo e já foi resolvido várias vezes. Acima de tudo, melhoraria muito a usabilidade.

Lembre-se sempre de que um sistema, por melhor que seja, se os clientes não o usarem (ou se sentirem inseguros ao usá-lo), é equivalente a nada.

@ctroncoso Entendo o que você time docker info comunicando com um servidor em amazonec2 / us-east-1 levará um pouco mais de 300ms - não seria um back-e - mais um handshake para cada solicitação dobra essa quantidade de tempo e introduz uma quantidade não trivial de sobrecarga?

De qualquer forma, não há nada que o Machine pode fazer sobre esse problema, então sugiro que um problema seja aberto (pesquise os existentes primeiro) em https://github.com/docker/docker para compartilhar suas ideias com o upstream, se desejar.

@nathanleclaire claro que sim, mas você trocaria 20 x 300 (ou 600) ms por uma atualização que com certeza funcionará? Além disso, seria apenas para a primeira chamada. Talvez uma "chave de sessão" possa ser gerada na primeira chamada que estabeleça que o handshake já foi feito. e usado a seguir sem apertar novamente. Tenho certeza de que existem problemas de segurança que isso pode trazer, mas prefiro ter um sistema não tão rápido à prova de falhas, do que um que possa apresentar uma carga de trabalho insuspeitada só porque ubuntu / fedora / centos não não atualize seus repositórios a tempo. Vejo que se trata de um problema do motor docker, mas a culpa é da máquina.

Vou verificar os problemas no docker-engine. Acho que temos um bom recurso acontecendo aqui. Gosto quando as conversas temáticas terminam em uma ideia construtiva. Obrigado pelo seu tempo @nathanleclaire !!!

O cliente já consulta o servidor para obter a versão. Não deveria haver
motivo pelo qual o cliente enviaria um parâmetro de API que não existe,
porque o cliente DEVE estar ciente dos parâmetros disponíveis para isso
versão. O mesmo vale para terminais.

Eu acredito que essa abordagem exigiria a suspensão de uso de
versão em algum ponto, talvez com base na idade ou delta da versão.

Você simplesmente não pode ter o cliente engasgando com versões mais antigas, é
não é uma opção para implantações de nível de produção. Eu tenho 3 maquinas inteiras
aqui e eu estou tendo esse problema, imagine o que aconteceria em dispersos
implantações.

Na quinta-feira, 21 de abril de 2016 às 14h47, Nathan LeClaire [email protected]
escrevi:

Tudo o que precisamos fazer aqui é fazer com que o cliente suporte versões mais antigas da API.
Por que isso não era um requisito de design é estranho.

O que acontece quando um cliente do futuro envia um parâmetro de API que
não existe para um daemon que não espera isso? Ou faz um pedido a um
endpoint que não existe em versões mais antigas? Como o daemon é suposto
saber sobre todas as coisas possíveis que um futuro cliente pode solicitar dele?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/machine/issues/2147#issuecomment -213107758

O cliente já consulta o servidor para a versão

Você pode me apontar onde isso ocorre no código do cliente Docker?

Eu realmente não conheço Go, mas tenho quase certeza de que é isso que ele faz:

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

De qualquer maneira, você vê um padrão de consulta da versão da API em todo o projeto.

Na quinta-feira, 21 de abril de 2016 às 17:25, Nathan LeClaire [email protected]
escrevi:

O cliente já consulta o servidor para a versão

Você pode me apontar onde isso ocorre no código do cliente Docker?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/machine/issues/2147#issuecomment -213157495

aqui está meu método para resolver esse problema:
ontem, quando fiz a versão mais recente do docker de https://github.com/docker/docker.git referindo-se a https://docs.docker.com/v1.5/contributing/devenvironment/ e modifiquei o cliente docker antigo binário com o novo.
ocorreu "o cliente é mais novo que o servidor com Docker" e o daemon do docker falhou ao reiniciar:

• / bin / systemctl status docker.service
  ● docker.service - Docker Application Container Engine
  Carregado: carregado (/lib/systemd/system/docker.service; ativado; predefinição do fornecedor: ativado)

mas existem binários daemon gerados no diretório:
bundles / Latest / binary-daemon
deve adicionar o diretório ao PATH, ou copiar dockerd e containerd para / usr / bin /
_copy dockerd / usr / bin / docker
copiar docker-containerd / usr / bin / containerd
copiar ../binary-client/docker / usr / bin_

então eu modifico /etc/init.d/docker para adicionar o diretório do dockerd ao PATH com as linhas destacadas

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

BASE = dockerd

modifique-os em / etc / default / $ BASE (/ etc / default / docker)

DOCKER = / usr / bin / $ BASE

DOCKER = $ DOCKERD / $ BASE
Este é o arquivo pid gerenciado pelo próprio docker
DOCKER_PIDFILE = / var / run / $ BASE.pid
Este é o arquivo pid criado / gerenciado por start-stop-daemon
DOCKER_SSD_PIDFILE = / var / run / $ BASE-ssd.pid
DOCKER_LOGFILE = / var / log / $ BASE.log
DOCKER_OPTS =
DOCKER_DESC = "Docker"

então eu reiniciei o serviço do dockerd, ele começou com sucesso:
_root @ master : ~ # status do service docker
● docker.service - Docker Application Container Engine
Carregado: carregado (/lib/systemd/system/docker.service; ativado; predefinição do fornecedor: ativado)
Ativo: ativo (em execução) desde qua 2016-05-04 04:32:01 EDT; 17h atrás
Docs: https: //docs.docker.com_

root @ master : ~ # versão docker
Cliente:
Versão: 1.12.0-dev
Versão API: 1.24
Versão Go: go1.5.4
Git commit: 1c0edf6-unsupported
Construído: Quarta, 4 de maio, 05:05:37 2016
OS / Arch: linux / amd64

Servidor:
Versão: 1.12.0-dev
Versão API: 1.24
Versão Go: go1.5.4
Git commit: 1c0edf6-unsupported
Construído: Quarta, 4 de maio, 05:05:37 2016
OS / Arch: linux / amd64
root @ master : ~ #

todos correm felizes

Somente para referência

Olá, alguém pode me ajudar?
Estou tendo o mesmo problema. Eu entendo que a atualização da máquina docker funcionaria, mas não estou usando docker no Windows / MAC. Estou usando no Linux.

Estou seguindo estas instruções para fazer um teste para jogar com docker content trust
https://docs.docker.com/engine/security/trust/trust_sandbox/

No dockerfile fornecido, ele pega a imagem 1.12.0 e, em seguida, cria a imagem, então quando eu executo o contêiner, ele não se conecta à minha máquina base porque minha máquina base (Linux) tem docker 1.11.0 e esta tem 1.12.0 , então mudei o arquivo docker, passei o caminho 1.11.0-dev para ele e gerei a imagem novamente. Desta vez, quando executei o contêiner com este novo arquivo, a versão do docker é 1.11.0-dev apenas, mas a versão da API ainda é 1.24, mas meu Linux base tem a versão da API 1.23.

Como faço para me livrar disso? Como reduzo minha versão da API do contêiner para 1.23 ou aumentarei minha versão da API base para 1., 24 para que não haja erros?

PS: Eu tentei atualizar minha versão base do Linux docker, mas ainda a versão API é apenas 1.23.

@mkonakan

No Ubuntu, sudo apt-get install -y docker-engine atualizará a versão nativamente instalada do Docker (advertência: isso só funcionará se você tiver instalado o Docker usando os canais oficiais)

docker-machine upgrade , como você observou, atualizará qualquer boot2docker.iso você tiver para a versão mais recente

@nathanleclaire Oi, atualizei meu docker engine no ubuntu base e ele tem a versão de cliente 1.11.1 mais recente e a versão de API 1.23, mas o contêiner que construí tem a versão de API 1.24 e, portanto, há o problema. Portanto, estou procurando uma maneira de fazer o downgrade da minha versão da API no contêiner ou então como fazer o upgrade da minha versão da API na máquina base de 1.23 para 1.24?

@mkonakan Sua melhor aposta provavelmente é compilar o Docker a partir da fonte, colocar o binário no local relevante e reiniciar o daemon. Se o contêiner que você construiu estiver usando essa versão do Docker, é provável que haja uma linha no Dockerfile fazendo algo semelhante.

Resolvido. Copiei o arquivo binário da minha máquina base para o contêiner em vez do arquivo padrão naquele dockerfile que está obtendo a versão mais recente da API. Obrigado.

👍

Por que está fechado? O cliente docker mais recente é capaz de interagir com daemons docker mais antigos?

@megastef Não que eu saiba, mas isso é um problema do projeto upstream (https://github.com/docker/docker), então eu sugiro procurar problemas de compatibilidade de encaminhamentos lá se você quiser discutir .

Eu tenho o mesmo problema, tento usar o nome de atualização da máquina docker , então pena que não funciona.Não sei se a rede although use proxy , mas resolvi esse problema.
1. encontre a caixa de ferramentas de
2. baixe e instale-o, então ele atualizará sua versão.

Para as pessoas que acham que isso tem o mesmo problema no Windows, use $ env: DOCKER_API_VERSION = 1.23 para definir a variável de ambiente.

Eu também estava tendo esse problema com o Windows beta. docker-machine upgrade não ajudou.
Uma solução alternativa é adicionar --engine-install-url https://test.docker.com a docker-machine create , que inicializará a máquina com o candidato a lançamento mais recente do Docker.

Detalhes:

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

Este pode ser corrigido (ou talvez contornado) adicionando DOCKER_API_VERSION à saída de docker-machine env ?

Resolvi o problema graças a @eddieajau.

Meu cliente docker (DOCKER_API_VERSION = 1.24) é Ubuntu Linux e o servidor docker (DOCKER_API_VERSION = 1.23) está na Carina pela Rackspace BETA.

Basta adicionar export DOCKER_API_VERSION=1.23 ao seu cliente para que funcione.

Obrigado.

export DOCKER_API_VERSION=1.23 resolveu meu problema. obrigado a @eddieajau

Obrigado @ kid1412z funcionou para mim também como uma solução rápida.

Voltar para a versão anterior

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

AMD. negociar versões de protocolo não é algo que ainda precise ser inventado. trabalhei com softwares dos anos 90 que podiam lidar com isso. eca, realmente.

@FlorianHeigl docker client 1.13 e superior faz negociação de versão da API com o daemon; a versão mínima do daemon para a qual ele recorrerá é docker 1.12. Para daemons mais antigos, a substituição DOCKER_API_VERSION é necessária

@eddieajau A solução alternativa da variável de ambiente DOCKER_API_VERSION = 1.23 não funciona mais.
Eu uso o docker para Windows e estou me conectando a um servidor docker em execução em um NAS que não consigo atualizar.

Janelas:

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

Alguém tem alguma ideia?

@manuelsalvatori isso é um problema no docker 17.09 cli; está corrigido em 17.10 (consulte https://github.com/moby/moby/pull/35008)., ainda não foi retroativo para 17.09.

Esteja ciente de que o docker 1.11 está em fim de vida e tem vulnerabilidades conhecidas, entre as quais um CVE no RunC que permite que os processos do contêiner saiam do contêiner e tenham acesso ao host (resolvido no docker 1.12.6 e superior, que envia com uma versão RunC corrigida https://github.com/moby/moby/releases/tag/v1.12.6)