Machine: Ответ от демона об ошибке: клиент новее, чем сервер с Docker 1.9 RC3

Созданный на 3 нояб. 2015  ·  72Комментарии  ·  Источник: docker/machine

Вот информация о версии:

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

Создал машину Docker:

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

Настроен как:

eval $(docker-machine env lab2)

docker ps выдает следующую ошибку:

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

Это недавно созданный компьютер с использованием последней версии Docker CLI и Docker Machine.

Самый полезный комментарий

Вы запустили docker-machine upgrade ?

Все 72 Комментарий

Да, UX не очень хорош, но если вы хотите использовать двоичный файл RC Docker, вам нужно указать использование ISO-кандидата на выпуск, например, --virtualbox-boot2docker-url https://github.com/tianon/boot2docker-legacy/releases/download/v1.9.0-rc4/boot2docker.iso

Почему это особое лечение RC?

Это делает его не интуитивно понятным.

Ну, ваш двоичный файл клиента Docker также является RC. Как вы думаете, это должно работать?

RC должен автоматически загрузить boot2docker.iso с RC. --virtualbox-boot2docker-url следует использовать только для замены значения по умолчанию. И значение по умолчанию должно быть таким же, как двоичный файл клиента Docker.

Я действительно думаю, что мы могли бы сделать лучше, позволив upgrade / create использовать новые RC по умолчанию, но в настоящее время RC для boot2docker мы храним в

Сопоставление boot2docker.iso с двоичным файлом клиента Docker кажется разумным и интуитивно понятным подходом. И в любом случае будет возможность отменить.

Никакой магии, просто интуитивно по крайней мере для меня!

Увидеть ту же ошибку с Docker 1.9.0 и Machine 0.5.0:

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

Не вижу возможности снова открыть проблему.

Вы запустили docker-machine upgrade ?

Эта машина только что была создана. Нужно ли мне для этого запускать docker-machine upgrade ?

@ arun-gupta Скорее всего, для обновления кеша и / или в случае, если вы сделали машину до официального выпуска b2d.

@nathanleclaire снова создал машину 30 минут назад и все равно получил ту же ошибку. docker-compose up -d на docker-compose.yml сработало успешно. Но docker ps снова выдает ошибку:

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

Явное обновление машины.

Есть ли сопоставление версий b2d.iso и клиент-серверного API?

docker-machine upgrade name должно работать, я предполагаю, что это "проблема с кешем ISO". Вы пробовали эту команду?

boot2docker.iso всегда сопоставляется с соответствующей версией API выпуска Docker. Вы можете увидеть версию кеша в метаданных, выполнив file $HOME/.docker/machine/cache/boot2docker.iso .

docker-machine upgrade решил проблему.

Спасибо, Арун. Мы собираемся работать над некоторыми проблемами, связанными с процессом обновления на этой итерации, поэтому, надеюсь, в будущем он станет немного более понятным.

: +1: для docker-machine upgrade

+1 для обновления докер-машины - при условии, что единственное, что обновляется, связано с докером;)

: +1: для docker-machine upgrade <machine name>

После обновления с помощью Docker Toolbox компьютер по умолчанию был остановлен, но обновлен.
Остальные машины не останавливали и не модернизировали.

docker-machine upgrade <machine-name> работает и у меня

Я использую Windows 10 и увидел аналогичную проблему, которая странным образом исчезла при втором запуске. Вот что у меня было и последовательность шагов.

  1. Я использовал Docker Toolbox 1.8.3 и решил использовать последнюю версию 1.9.0c, поскольку столкнулся с некоторыми странными проблемами.
  2. Я запустил docker-machine rm default просто в качестве меры безопасности
  3. Скачал и установил тулбокс версии 1.9.0c
  4. Git был единственным, что я не выбрал при появлении запроса и установил все остальное.
  5. Запущен _Docker Quickstart Terminal_
  6. Все выглядело нормально
Creating Machine default...
Running pre-create checks...
Creating machine...
Waiting for machine to be running, this may take a few minutes...
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Provisioning created instance...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
To see how to connect Docker to this machine, run: C:\Program Files\Docker Toolbox\docker-machine.exe env default
Setting environment variables for machine default...



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

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

7. проверил, что машина создана

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

8. Пока все в порядке, но

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

9. Что у меня есть?

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

10. Запустите обновление машины, как было предложено выше, и я получу:

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

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

11. После этого все в порядке. Казалось, что просто запустить обновление во второй раз сработало.

@ arun-gupta @nathanleclaire апгрейд док -машины [имя-машины] исправил мою !!! Большое спасибо. FWIW, эта синхронизация обновления между клиентом и сервером на самом деле является PITA. Мы будем очень благодарны за любые циклы, потраченные на его улучшение!

Это не ограничивается RC3 или докер-машиной. Если докер-клиент 1.9.x, а на сервере запущен docker 1.8.x, появляется сообщение об ошибке. Это очень непрактично с точки зрения управления развертываниями, если у вас нет или не может быть установлена ​​одна и та же версия движка докеров на всех серверах и всех клиентах. Я считаю, что поломка довольно серьезная.

Также в основном та же проблема, что и https://github.com/docker/machine/issues/1839

docker-machine upgrade <machine-name> также работал у меня

docker-machine upgrade <machine-name> у меня не сработало. Мне пришлось обновить все свои серверы до версии docker для разработчиков, затем я снова понизил версию и начал получать:

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

После ручного перехода на более раннюю версию я запустил docker-machine upgrade <machine-name> , но ошибка осталась.

моя вина ... Мне нужно было удалить новый двоичный файл докера с моего пути.

обновление докер-машинысработало и для меня.

Вот как я запустил его после получения той же ошибки для 1.10.0-rc1:

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

Мне пришлось запустить это для v1.10.0-rc2 / de3bb7a (OS X 10.10.5):
docker-machine create -d=virtualbox -virtualbox-boot2docker-url https://github.com/tianon/boot2docker-legacy/releases/download/v1.10.0-rc2/boot2docker.iso docker

boot2docker объявлен устаревшим. Это действительно предполагаемое решение проблемы?

docker-machine по-прежнему использует ISO-образ boot2docker для создания виртуальной машины, в этом нет ничего необычного.

Похоже, что есть много людей, подтверждающих обновление демона докера на сервере (ВМ), но это не касается случая, когда демон докера не может быть немедленно обновлен. Единственное быстрое и наполовину разумное решение, которое я нашел до сих пор, - это просто загрузить соответствующий клиентский двоичный файл из выпусков и запустить правильный в зависимости от версии сервера.

boot2docker объявлен устаревшим. Это действительно предполагаемое решение проблемы?

Как @superdump ноты, то boot2docker CLI (вызывается с помощью boot2docker в командной строке) является устаревшим, но операционная система все еще остается.

Спасибо @nathanleclaire и @superdump за разъяснения!

Мне удалось (к сожалению, только временно) решить проблему, установив dmv и понизив версию через

dmv use 1.8.1

Однако при извлечении некоторых изображений (но не всех) docker продолжает переключаться на 1.9.1 и под docker images больше ничего не отображается (но это было раньше).

Что здесь происходит? Это глючная / нестабильная версия?

Имеется версия B для релиз-кандидата2

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

использовать
docker-machine create -d=virtualbox -virtualbox-boot2docker-url https://github.com/boot2docker/boot2docker/releases/download/v1.10.0-rc2-b/boot2docker.iso docker

У меня была эта проблема с моим локальным Mac (homebrew), работающим под управлением 1.10, в то время как докер-машина - в данном случае в google gce - не работала даже после попытки обновления докер-машины. Мне пришлось вручную ввести ssh и, в частности, добавить репозиторий deb, чтобы принудительно перейти на 1.10.

Только что столкнулся с этим на Travis CI:

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

Я решил это через 3 дня отладки, и я написал ответ на StackOverflow, вы ДОЛЖНЫ проверить его http://stackoverflow.com/questions/24586573/docker-error-client-and-server-dont-have-same-version / 36298911 # 36298911

Это все еще касается docker machine / docker toolbox. Все эти предложения являются обходными путями и, возможно, подходят для использования с docker toolbox, но совсем не подходят для реальных развертываний docker, где разные серверы могут иметь разные версии серверов и не могут быть обновлены немедленно.

Настоящая проблема в том, что новые клиенты докеров не могут общаться со старыми серверами. В идеале это должно быть исправлено в самом докере, чтобы клиенты были обратно совместимы.

Это действительно потрясающий, потрясающий недостаток дизайна, который действительно необходимо немедленно устранить, если docker-machine должен стать надежным инструментом. Мысль о том, что я не могу подключиться к экземпляру сервера сейчас, потому что версия API _OLDER_, просто ошеломляет.

К сожалению, клиенты освобождаются быстро, но клиентам нужно время, чтобы добраться до репозиториев.
Вот почему, когда вы обновляете докер-машину (набор инструментов), новая версия сервера может быть недоступна, и вы останетесь отключенным от своей машины.

Что странно, новый клиент не может «разговаривать» со старыми API.

Задержка между официальными выпусками и обновлением репозиториев до нового выпуска - это то, что нельзя решить. На мой взгляд, это делает обновление клиента слепой ставкой. Если вы не уверены, что ваш DM можно обновить до той же версии клиента, обновление клиента заблокирует вас.

Вариантов всего два (другие?).

  1. Клиент должен иметь возможность взаимодействовать с текущим API и API-интерфейсом возрастом не менее 1 года.
  2. Обновление сервера должно проверять версию, доступную в официальных репозиториях, и если она не совпадает, она должна быть собрана из источника (или альтернативного репозитория).

Все, что нам нужно здесь сделать, это заставить клиент поддерживать более старые версии API. Странно, почему это не было требованием к дизайну.

@TheSeanBrady Docker Machine - совершенно новый.
Я уверен, что поддержка ряда API является важной вехой этого проекта.

Это проблема не с докер-машиной, это проблема с докером.

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

Все, что нам нужно здесь сделать, это заставить клиент поддерживать более старые версии API. Странно, почему это не было требованием к дизайну.

Что происходит, когда клиент из будущего отправляет параметр API, которого не существует, демону, который этого не ожидает? Или делает запрос к конечной точке, которой нет в старых версиях? Как демон должен знать обо всех возможных вещах, которые может потребовать от него будущий клиент?

@nathanleclaire
Я не эксперт, но я ожидал, что рукопожатие будет таким же, как и на старых аудиомодемах. Первоначальное рукопожатие было выполнено с использованием самого старого API, который гарантированно будет понят для всех клиентов и серверов и гарантированно будет отвечать, по крайней мере, на основные (важные) вызовы.

Это рукопожатие просто спросит: какую версию API вы используете и список функций API, на которые он может отвечать. Функции клиента и серверов логически объединяются вместе, и общий набор функций (вызовы API) устанавливается для ТАКОЙ конфигурации клиент-сервер.

Исходя из этого, клиент будет знать, какие функции он может вызывать, и выдавать ошибку только на тех, которые не могут.
IE [NotSupported] - К сожалению, сервер не может ответить на _______. Обновите сервер до Docker nn.nnn.nn или измените свой контейнер, чтобы он соответствовал Docker nn.nnn.nn

Идея состоит в том, что если API-интерфейсы отличаются только на 1%, этот 1% не отключает использование остальных 99%, что, скорее всего, является всем, что нужно клиенту.

Считаю, что есть что улучшать. Подтверждение связи и согласование общего протокола не новость и решалась несколько раз. Прежде всего, это значительно улучшит удобство использования.

Всегда помните, что система, какой бы хорошей она ни была, если клиенты ее не используют (или чувствуют себя небезопасными), ничего не значит.

@ctroncoso Я понимаю вашу точку зрения, но если я запустил time docker info общающийся с сервером в amazonec2 / us-east-1 это займет чуть более 300 мс - не будет ли -forth рукопожатие для каждого запроса удваивает это количество времени и вводит нетривиальные накладные расходы?

В любом случае, Machine ничего не может сделать с этой проблемой, поэтому я предлагаю открыть проблему (сначала поискать существующие) на https://github.com/docker/docker, чтобы при желании поделиться своими мыслями с апстримом.

@nathanleclaire уверен, что это так, но не

Проверю по вопросам на docker-engine. Я думаю, у нас здесь есть хорошая особенность. Мне нравится, когда обсуждение проблем заканчивается конструктивной идеей. Спасибо за уделенное время

Клиент уже запрашивает версию у сервера. Не должно быть
причина того, что клиент когда-либо отправит параметр API, которого не существует,
потому что клиент ДОЛЖЕН знать параметры, доступные для этого
версия. То же самое и с конечными точками.

Я полагаю, что этот подход потребует отказа от старых
версия в какой-то момент, возможно, на основе возраста или дельты версии.

Вы просто не можете заставить клиента подавиться старыми версиями, это
не вариант для развертывания на производственном уровне. У меня целых 3 машины
здесь, и у меня возникла эта проблема, представьте, что произойдет на рассредоточенных
развертывания.

21 апреля 2016 г., в 14:47, Натан Леклер [email protected]
написал:

Все, что нам нужно здесь сделать, это заставить клиент поддерживать более старые версии API.
Странно, почему это не было требованием к дизайну.

Что происходит, когда клиент из будущего отправляет параметр API, который
не существует для демона, который этого не ожидает? Или делает запрос в
конечная точка, которой нет в старых версиях? Как предполагается демон
знать обо всем, что может потребовать от нее будущий клиент?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/machine/issues/2147#issuecomment -213107758

Клиент уже запрашивает у сервера версию

Вы можете указать мне, где в коде клиента Docker это происходит?

Я действительно не знаю Go, но я почти уверен, что это то, что он делает:

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

В любом случае вы видите образец запроса версии API по всему проекту.

В чт, 21 апреля 2016 г., в 17:25, Натан Леклер [email protected]
написал:

Клиент уже запрашивает у сервера версию

Вы можете указать мне, где в коде клиента Docker это происходит?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/machine/issues/2147#issuecomment -213157495

вот мой метод решения этой проблемы:
вчера, когда я сделал новейшую версию докера из https://github.com/docker/docker.git со ссылкой на https://docs.docker.com/v1.5/contributing/devenvironment/ и изменил старый клиент докера двоичный файл с новым.
произошло «клиент новее, чем сервер с Docker», и демон докера не смог перезапустить:

  • / bin / systemctl статус docker.service
    ● docker.service - механизм контейнеров приложений Docker.
    Загружено: загружено (/lib/systemd/system/docker.service; включено; предустановка поставщика: включено)

но в каталоге сгенерированы двоичные файлы демонов:
Связки / последний / двоичный-демон
следует добавить каталог в PATH или скопировать dockerd и containerd в / usr / bin /
_copy dockerd / usr / bin / docker
скопировать docker-containerd / usr / bin / containerd
скопировать ../binary-client/docker / usr / bin_

затем я изменяю /etc/init.d/docker, чтобы добавить каталог dockerd в PATH с выделенными строками

ДОКЕРД = / домашний / мастер / github.com / докер / связки / 1.12.0-dev / бинарный-демон
экспорт ПУТЬ = $ ПУТЬ: $ DOCKERD

BASE = dockerd

измените их в / etc / default / $ BASE (/ etc / default / docker)

ДОКЕР = / usr / bin / $ BASE

ДОКЕР = $ ДОКЕРД / $ БАЗА
Это файл pid, управляемый самим докером
DOCKER_PIDFILE = / var / run / $ BASE.pid
Это файл pid, созданный / управляемый start-stop-daemon
DOCKER_SSD_PIDFILE = / var / run / $ BASE-ssd.pid
DOCKER_LOGFILE = / var / log / $ BASE.log
DOCKER_OPTS =
DOCKER_DESC = "Докер"

затем я перезапустил службу dockerd, она запустилась успешно:
_root @ master : ~ # статус докера службы
● docker.service - механизм контейнеров приложений Docker.
Загружено: загружено (/lib/systemd/system/docker.service; включено; предустановка поставщика: включено)
Активен: активен (работает) с среды 04.05.2016, 04:32:01 EDT; 17ч назад
Документы: https: //docs.docker.com_

root @ master : ~ # версия докера
Клиент:
Версия: 1.12.0-dev
Версия API: 1.24
Версия Go: go1.5.4
Git commit: 1c0edf6-неподдерживаемый
Построен: 4 мая 05:05:37 2016
ОС / Arch: Linux / amd64

Сервер:
Версия: 1.12.0-dev
Версия API: 1.24
Версия Go: go1.5.4
Git commit: 1c0edf6-неподдерживаемый
Построен: 4 мая 05:05:37 2016
ОС / Arch: Linux / amd64
корень @ мастер : ~ #

все счастливы

просто для справки

Привет, может кто-нибудь мне помочь?
У меня такая же проблема. Я понимаю, что обновление докер-машины подойдет, но я не использую докер на Windows / MAC. Я использую его в Linux.

Я следую этим инструкциям, чтобы протестировать игру с доверием содержимого докеров
https://docs.docker.com/engine/security/trust/trust_sandbox/

В предоставленном файле докеров он берет образ 1.12.0, а затем создает образ, поэтому, когда я запускаю контейнер, он не подключается к моей базовой машине, потому что моя базовая машина (Linux) имеет докер 1.11.0, а у него 1.12.0 , поэтому я затем изменил файл докера, передал ему путь 1.11.0-dev и снова сгенерировал образ. На этот раз, когда я запустил контейнер с этим новым файлом, версия докера - только 1.11.0-dev, но версия API по-прежнему 1,24, но моя базовая версия Linux имеет версию API 1,23.

Как мне от этого избавиться? Как уменьшить версию API контейнера до 1.23 или увеличить базовую версию API до 1., 24, чтобы не было ошибок?

PS: Я попытался обновить свою базовую версию докеров Linux, но все же версия API - только 1.23.

upload

@mkonakan

В Ubuntu sudo apt-get install -y docker-engine обновит изначально установленную версию Docker (Предостережение: это будет работать, только если вы установили Docker, используя официальные каналы)

docker-machine upgrade , как вы заметили, обновит все имеющиеся у вас boot2docker.iso до последней версии.

@nathanleclaire Привет, обновил мой движок

@mkonakan Лучше всего скомпилировать Docker из исходного кода,

Решено. Я скопировал двоичный файл со своей базовой машины в контейнер вместо файла по умолчанию в этом файле докеров, который получает последнюю версию API. Благодарю.

👍

Почему это закрыто? Может ли последний клиент докеров взаимодействовать со старыми демонами докеров?

@megastef Насколько мне известно, это проблема восходящего проекта (https://github.com/docker/docker), поэтому я бы посоветовал поискать там проблемы прямой совместимости, если вы хотите обсудить .

У меня такая же проблема, я пытаюсь использовать имя обновления докер-машины , так что жаль, что это не работает. Я не знаю, есть ли сеть although use proxy , но я решил эту проблему.
1. найти набор инструментов из
2. загрузите и установите его, тогда он обновит вашу версию.

docker-machine upgrade не сработало в моем сценарии. Похоже, что CoreOS Docker Host застрял на версии 1.22. Мой клиент работает под управлением 1.24. Как я могу это решить?

@ pcgeek86 попробуйте export DOCKER_API_VERSION=1.23 (см. https://forums.docker.com/t/docker-for-mac-stopped-running-docker-related-commands/16153/6)

У меня тоже была эта проблема с бета-версией Windows. docker-machine upgrade не помогло.
Одним из альтернативных решений является добавление --engine-install-url https://test.docker.com к docker-machine create , что инициализирует машину последней версией кандидата Docker.

Детали:

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

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

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

Можно ли это исправить (или, возможно, обойти), добавив DOCKER_API_VERSION к выходу docker-machine env ?

Решил проблему благодаря @eddieajau.

Мой докер-клиент (DOCKER_API_VERSION = 1.24) - это Ubuntu linux, а докер-сервер (DOCKER_API_VERSION = 1.23) находится в Carina от Rackspace BETA.

Просто добавьте export DOCKER_API_VERSION=1.23 к своему клиенту, чтобы он заработал.

Благодарю.

export DOCKER_API_VERSION=1.23 решил мою проблему. спасибо @eddieajau

Спасибо @ kid1412z, у меня тоже сработало как быстрое решение.

Вернуться к старой версии

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

О, мой бог. согласование версий протокола - это не вещь, которую еще нужно изобретать. Я работал с программным обеспечением 90-х, которое могло справиться с этим. фу, правда.

@FlorianHeigl docker client 1.13 и выше выполняет согласование версии API с демоном; минимальная версия демона, к которой он вернется, - это docker 1.12. Для старых демонов требуется переопределение DOCKER_API_VERSION

@eddieajau Обходной путь переменной окружения DOCKER_API_VERSION = 1.23 больше не работает.
Я использую докер для Windows и подключаюсь к док-серверу на NAS, который я не могу обновить.

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

НАС:

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 это проблема в докере 17.09 cli; это исправлено в 17.10 (см. https://github.com/moby/moby/pull/35008)., еще не перенесено на 17.09.

Однако имейте в виду, что docker 1.11 - это конец жизни и имеет известные уязвимости, среди которых CVE в RunC, которая позволяет процессам контейнера выходить из контейнера и получать доступ к хосту (решено в докере 1.12.6 и выше, который поставляется с исправленной версией RunC https://github.com/moby/moby/releases/tag/v1.12.6)

Была ли эта страница полезной?
0 / 5 - 0 рейтинги