ええ、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は、RCからboot2docker.isoを自動的に取得する必要があります。 --virtualbox-boot2docker-urlは、デフォルト値を上書きするためにのみ使用する必要があります。 また、デフォルトはDockerクライアントバイナリと同じである必要があります。

私たちは許可についてやれることだと思いますupgrade / create我々が必要とするので、boot2dockerのために、我々は、@tianonで保管のフォークしてきた、デフォルトでは、新規のRCを使用するが、現在のRCこれをサポートする場合は、それを行う習慣も変更してください。 誰もがこの点で本当に異なる期待を持っているので、私は物事をあまりにも魔法にすることについて少し心配しています。

boot2docker.isoをDockerクライアントバイナリと一致させること

魔法はありません。少なくとも私には直感的です。

Docker1.9.0とMachine0.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常に対応するDockerリリースAPIバージョンにマップされます。 file $HOME/.docker/machine/cache/boot2docker.iso実行すると、メタデータでキャッシュのバージョンを確認できます。

docker-machine upgradeで問題が解決しました。

ありがとうアルン。 今回のイテレーションでは、アップグレードフローに関するいくつかの問題に取り組む予定ですので、将来的にはもう少し明確になることを願っています。

：+1： docker-machine upgrade

docker-machineアップグレードの+ 1-アップグレードされるのはdocker関連のみであると想定します;）

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

Docker Toolboxでアップグレードした後、デフォルトのマシンは停止しましたが、アップグレードされました。
他のマシンは停止されず、アップグレードされませんでした。

docker-machine upgrade <machine-name>は私にも働きます

私はWindows10を使用していますが、2回目の実行で奇妙なことに消えた同様の問題が発生しました。 これが私が持っていたものと一連のステップです。

1. Docker Toolbox 1.8.3を使用していて、いくつかの奇妙な問題に直面していたため、最新リリース1.9.0cを使用することにしました。
2. 安全手順としてdocker-machine rm defaultしました
3. ツールボックスバージョン1.9.0cをダウンロードしてインストールしました
4. プロンプトが表示され、他のすべてをインストールしたときに、Gitだけを選択しませんでした。
5. _Dockerクイックスタートターミナル_を開始しました
6. すべてがうまく見えた

Creating Machine default...
Running pre-create checks...
Creating machine...
Waiting for machine to be running, this may take a few minutes...
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Provisioning created instance...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
To see how to connect Docker to this machine, run: C:\Program Files\Docker Toolbox\docker-machine.exe env default
Setting environment variables for machine default...



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

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

7.マシンが作成されていることを確認しました

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

8.これまでのところすべて問題ありませんが

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

9.私は何を持っていますか？

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

10.上記のようにマシンのアップグレードを実行すると、次のようになります。

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

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

11.その後は大丈夫です。 アップグレードを2回実行するだけで、うまくいくように見えました。

@ arun -gupta

これは、RC3やDockerマシンに限定されません。 Dockerクライアントが1.9.xで、サーバーがDocker 1.8.xを実行している場合、エラーメッセージが表示されます。 これは、すべてのサーバーとすべてのクライアントに同じバージョンのDockerエンジンをインストールしない、またはインストールできない場合、デプロイメントの管理という点で非常に実用的ではありません。 これはかなり深刻な破損だと思います。

また、基本的にhttps://github.com/docker/machine/issues/1839と同じ問題

docker-machine upgrade <machine-name>は私のためにも働いた

docker-machine upgrade <machine-name>は私にはうまくいきませんでした。 すべてのサーバーをdockerの開発ビルドにアップグレードする必要がありました。その後、再度ダウングレードして、次のようになりました。

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

手動でダウングレードした後、 docker-machine upgrade <machine-name>を実行しましたが、エラーが残ります。

私のせい...新しいdockerバイナリをパスから削除する必要がありました。

docker-machineのアップグレード私のためにも働いた。

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は引き続きboot2dockerISOを使用してVMを構築しますが、これは珍しいことではありません。

サーバー（VM）上のDockerデーモンのアップグレードを確認する人はたくさんいるようですが、これはDockerデーモンをすぐにアップグレードできない場合には対応していません。 私がこれまでに見つけた唯一の迅速で半ば賢明な解決策は、リリースから適切なクライアントバイナリをダウンロードし、サーバーのバージョンに応じて適切なものを実行することです。

boot2dockerは非推奨と宣言されました。 これは本当に問題の意図された解決策ですか？

@superdumpが指摘しているように、boot2docker CLI（コマンドラインでboot2dockerを使用して呼び出される）は非推奨になりましたが、OSはまだ残っています。

明確にしてくれた@nathanleclaireと@superdumpに感謝します！

dmvをインストールし、経由でダウングレードすることで、問題を解決することができました（残念ながら一時的にのみ）

dmv use 1.8.1

ただし、一部の画像（すべてではない）をプルすると、 dockerは1.9.1切り替わり続け、 docker images下には何も表示されなくなります（以前は表示されていました）。

ここで何が起こっているのですか？ これはバグのある/不安定なバージョンですか？

リリース候補2にはバージョンBがあります

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

この問題は、1.10を実行しているローカルMac（homebrew）で発生しましたが、docker-machine（この場合はgoogle gce）は、docker-machineのアップグレードを試しても機能しませんでした。 1.10に強制的にアップグレードするには、手動でsshを実行し、特にdebリポジトリを追加する必要がありました。

Travis CIでその1つに遭遇しました：

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

私はデバッグの3日後にhttp://stackoverflow.com/questions/24586573/docker-error-client-and-server-dont-have-same-version / 36298911＃36298911

それはまだdockermachine / dockerツールボックスについてだけです。 これらの提案はすべて回避策であり、docker toolboxでの使用には問題ないかもしれませんが、サーバーごとにサーバーバージョンが異なり、すぐにアップグレードできないDockerの実際の展開にはまったく問題ありません。

本当の問題は、新しいDockerクライアントが古いサーバーと通信できないことです。 これは、クライアントが下位互換性を持つように、Docker自体で何らかの方法で修正するのが理想的です。

これは本当に目を見張るような驚くべき設計上の欠陥であり、docker-machineが信頼できるツールであるためには、すぐに対処する必要があります。 APIのバージョンが_OLDER_であるため、サーバーインスタンスに接続できないという考えは、まあ、驚くべきことです。

残念ながら、クライアントは迅速にリリースされますが、クライアントはリポジトリに到達するまでに時間がかかります。
そのため、Dockerマシン（ツールボックス）をアップグレードすると、新しいバージョンのサーバーが使用できなくなり、マシンから切断されたままになる可能性があります。

奇妙なことに、新しいクライアントは古いAPIと「話す」ことができません。

公式リリースと新しいリリースへのリポジトリの更新の間の遅れは、解決できないものです。 私が見ているように、これはクライアントのアップグレード、盲目的な賭けになります。 DMを同じクライアントバージョンにアップグレードできることが確実でない限り、クライアントをアップグレードするとロックアウトされます。

オプションは2つだけです（他にありますか？）。

1. クライアントは、現在のAPIおよび少なくとも1年前のAPIと通信できる必要があります。
2. サーバーのアップグレードでは、公式リポジトリで利用可能なバージョンを確認する必要があります。一致しない場合は、ソース（または代替リポジトリ）からビルドする必要があります。

ここで行う必要があるのは、クライアントが古いバージョンのAPIをサポートするようにすることだけです。 それが設計要件ではなかった理由は奇妙です。

@TheSeanBrady Docker
さまざまなAPIのサポートは、このプロジェクトのマイルストーンになっていると確信しています。

これはdocker-machineの問題ではなく、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

ここで行う必要があるのは、クライアントが古いバージョンのAPIをサポートするようにすることだけです。 それが設計要件ではなかった理由は奇妙です。

将来のクライアントが、存在しないAPIパラメーターをそれを予期しないデーモンに送信するとどうなりますか？ または、古いバージョンには存在しないエンドポイントにリクエストを送信しますか？ デーモンは、将来のクライアントが要求する可能性のあるすべてのことをどのように知ることになっていますか？

@nathanleclaire
私は専門家ではありませんが、私が期待するのは、古いオーディオモデムでハンドシェイクが行われたのと同じ方法です。 最初のハンドシェイクは、すべてのクライアントとサーバーによって理解されることが保証され、少なくとも基本的な（重要な）呼び出しに応答することが保証されている最も古いAPIを使用して行われました。

このハンドシェイクは、次のことを要求するだけです。使用しているAPIバージョンと、それに応答できるAPI関数のリスト。 クライアントとサーバーの機能は論理的にANDで結合され、そのクライアントサーバー構成に共通の機能セット（API呼び出し）が設定されます。

これに基づいて、クライアントは呼び出すことができる関数を認識し、呼び出せない関数に対してのみエラーをスローします。
IE [サポートされていません]-申し訳ありませんが、サーバーは_______に応答できません。 サーバーをDockernn.nnn.nnに更新するか、Dockernn.nnn.nnに準拠するようにコンテナーを変更してください

APIの違いが1％しかない場合、その1％は、クライアントが必要とする可能性が最も高い他の99％の使用を無効にしないという考え方です。

改善の余地があると思います。 ハンドシェイクと共通プロトコルへの同意は新しいものではなく、何度も解決されています。 何よりも、使いやすさが大幅に向上します。

システムがどんなに優れていても、クライアントがそれを使用しない（または使用するのが安全でないと感じる）場合、システムは何もないことと同等であることを常に覚えておいてください。

@ctroncoso私はあなたの理解していますが、 amazonec2 / us-east-1でサーバーと通信するtime docker infoを実行すると、300ミリ秒強かかります-戻ってこないでしょう-そして-リクエストごとに4回目のハンドシェイクを行うと、この時間が2倍になり、重要なオーバーヘッドが発生しますか？

いずれにせよ、この問題についてMachineができることは何もないので、必要に応じてhttps://github.com/docker/dockerで問題を開いて（既存の問題を最初に検索して）アップストリームと意見を共有することをお勧めします。

@nathanleclaire確かにそうですが、動作が保証されているアップグレードと20 x 300（または600）ミリ秒を交換しますか？ また、それは最初の呼び出しのためだけになります。 おそらく、ハンドシェイクがすでに行われたことを確立する最初の呼び出しで「セッションキー」を生成できます。 そして、再ハンドシェイクなしで以下に使用されます。 これが引き起こす可能性のあるセキュリティの問題があると確信していますが、ubuntu / fedora / centosが行ったという理由だけで予想外の負荷がかかる可能性があるシステムよりも、それほど高速ではないフェイルプルーフシステムが必要です時間通りにリポジトリを更新しません。 これはDockerエンジンの問題であることがわかりますが、マシンが原因です。

docker-engineの問題を確認します。 ここには素晴らしい機能があると思います。 問題の話し合いが建設的なアイデアになってしまうとき、私はそれが好きです。 お時間をいただきありがとうございます@nathanleclaire !!!

クライアントはすでにサーバーにバージョンを照会しています。 あるべきではない
クライアントが存在しないAPIパラメータを送信する理由、
クライアントはそのために利用可能なパラメータを認識している必要があるためです
バージョン。 エンドポイントについても同じことが言えます。

このアプローチでは、古いものを非推奨にする必要があると思います
おそらく年齢またはバージョンデルタに基づいて、ある時点でのバージョン。

古いバージョンでクライアントを窒息させることはできませんが、
本番レベルの展開のオプションではありません。 私は3台のマシン全体を持っています
ここで私はこの問題を抱えています、分散したときに何が起こるかをイメージしてください
展開。

14:47の木、2016年4月21日には、ネイサンLeClaire [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バージョンをクエリするパターンが表示されます。

17:25の木、2016年4月21日には、ネイサンLeClaire [email protected]
書きました：

クライアントはすでにサーバーにバージョンを照会しています

Dockerクライアントコードのどこでこれが発生するかを教えていただけますか？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/machine/issues/2147#issuecomment -213157495

この問題を解決するための私の方法は次のとおりです。
昨日、 https： //docs.docker.com/v1.5/contributing/devenvironment/を参照してhttps://github.com/docker/docker.gitから最新バージョンのdockerを作成し、古いdockerクライアントを変更したとき新しいものとのバイナリ。
「クライアントはDockerを搭載したサーバーよりも新しい」が発生し、dockerデーモンを再起動できませんでした。

• / bin / systemctl status 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に追加し、行を強調表示します

DOCKERD = /home/master/github.com/docker/bundles/1.12.0-dev/binary-daemon
PATH = $ PATH：$ DOCKERDをエクスポートします

BASE = dockerd

/ etc / default / $ BASE（/ etc / default / docker）でこれらを変更します

DOCKER = / usr / bin / $ BASE

DOCKER = $ DOCKERD / $ BASE
これは、docker自体によって管理されるpidファイルです。
DOCKER_PIDFILE = / var / run / $ BASE.pid
これは、start-stop-daemonによって作成/管理されるpidファイルです。
DOCKER_SSD_PIDFILE = / var / run / $ BASE-ssd.pid
DOCKER_LOGFILE = /var/log/$BASE.log
DOCKER_OPTS =
DOCKER_DESC = "Docker"

それから私はdockerdのサービスを再開しました、それは首尾よく始まります：
_root @ master ：〜＃サービスDockerステータス
●docker.service-Dockerアプリケーションコンテナエンジン
ロード済み：ロード済み（/lib/systemd/system/docker.service;有効;ベンダープリセット：有効）
アクティブ：水2016-05-04 04:32:01 EDT以降アクティブ（実行中）。 17時間前
ドキュメント： https：//docs.docker.com_

root @ master ：〜＃dockerバージョン
クライアント：
バージョン：1.12.0-dev
APIバージョン：1.24
Goバージョン：go1.5.4
Gitコミット：1c0edf6-サポートされていません
構築：2016年5月4日水曜日05:05:37
OS / Arch：linux / amd64

サーバ：
バージョン：1.12.0-dev
APIバージョン：1.24
Goバージョン：go1.5.4
Gitコミット：1c0edf6-サポートされていません
構築：2016年5月4日水曜日05:05:37
OS / Arch：linux / amd64
root @ master ：〜＃

すべてが幸せに走る

参考までに

こんにちは、誰か助けてくれませんか？
私は同じ問題を抱えています。 docker-machineのアップグレードが機能することは理解していますが、Windows / MACでdockerを使用していません。 Linuxで使用しています。

私はこの指示に従って、Dockerコンテンツの信頼で遊ぶためのテストを行います
https://docs.docker.com/engine/security/trust/trust_sandbox/

提供されているdockerfileでは、1.12.0イメージを取得してからイメージを作成します。したがって、コンテナーを実行すると、ベースマシン（Linux）には1.11.0 dockerがあり、これには1.12.0があるため、ベースマシンに接続されません。 、それで私はdockerファイルを変更し、それに1.11.0-devパスを渡して、イメージを再度生成しました。 今回、この新しいファイルでコンテナーを実行したとき、dockerバージョンは1.11.0-devのみですが、APIバージョンは1.24のままですが、ベースLinuxのAPIバージョンは1.23です。

どうすればこれを取り除くことができますか？ コンテナAPIバージョンを1.23に減らす、またはベースAPIバージョンを1.、24に増やして、エラーが発生しないようにするにはどうすればよいですか？

PS：ベースのLinux Dockerバージョンをアップグレードしようとしましたが、それでもAPIバージョンは1.23のみです。

@mkonakan

Ubuntuでは、 sudo apt-get install -y docker-engineはネイティブにインストールされたバージョンのDockerを更新します（警告：これは、公式チャネルを使用してDockerをインストールした場合にのみ機能します）

docker-machine upgrade 、ご指摘のとおり、必要なboot2docker.isoを最新バージョンに更新します

@nathanleclaireこんにちは、ベースのubuntuでDockerエンジンをアップグレードしました。これには、最新の1.11.1クライアントバージョンとAPIバージョン1.23がありますが、作成したコンテナーには1.24 APIバージョンがあるため、問題があります。 だから、コンテナ内のAPIバージョンをダウングレードする方法や、ベースマシンのAPIバージョンを1.23から1.24にアップグレードする方法を探していますか？

@mkonakan最善の策は、Dockerをソースからコンパイルし、バイナリを適切な場所にドロップして、デーモンを再起動することです。 構築したコンテナーがそのようなバージョンのDockerを使用している場合、Dockerfileに同様のことを行う行がある可能性があります。

解決しました。 最新のAPIバージョンを取得しているdockerfileのデフォルトファイルではなく、バイナリファイルをベースマシンからコンテナにコピーしました。 ありがとう。

👍

なぜこれが閉鎖されているのですか？ 最新のDockerクライアントは古いDockerデーモンとインターフェースできますか？

@megastef私が知っていることではありませんが、それはアップストリームプロジェクト（https://github.com/docker/docker）の問題なので、議論したい場合は、そこで上位互換性の問題を探すことをお勧めします。

私は同じ問題を抱えています、私はdocker -machineアップグレード名を使おうとしているので、それはうまくいきません。ネットワークがalthough use proxyかどうかはわかりませんが、私はこの問題を解決しました。
1.ツールボックスを
2.ダウンロードしてインストールすると、バージョンがアップグレードされます。

これがWindowsで同じ問題を抱えていることに気付いた人は、$

Windowsベータ版でもこの問題が発生していました。 docker-machine upgradeは役に立ちませんでした。
別の解決策の1つは、 --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-machine env出力にDOCKER_API_VERSIONを追加することで、これを修正（またはおそらく回避）できますか？

@eddieajauのおかげで問題を解決しました。

私のDockerクライアント（DOCKER_API_VERSION = 1.24）はUbuntu linuxであり、Dockerサーバー（DOCKER_API_VERSION = 1.23）はCarina by RackspaceBETAにあります。

クライアントに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バージョンネゴシエーションを行います。 フォールバックするデーモンの最小バージョンはdocker1.12です。 古いデーモンの場合、 DOCKER_API_VERSIONオーバーライドが必要です

@eddieajau環境変数DOCKER_API_VERSION = 1.23の回避策は機能しなくなりました。
Docker for Windowsを使用していて、更新できないNASで実行されているDockerサーバーに接続しています。

ウィンドウズ：

Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:09 2017
 OS/Arch:      windows/amd64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:45:38 2017
 OS/Arch:      linux/amd64
 Experimental: true

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

誰かアイデアがありますか？

@manuelsalvatoriは、

ただし、docker 1.11はサポート終了であり、既知の脆弱性があることに注意してください。その中には、コンテナープロセスがコンテナーから抜け出し、ホストにアクセスできるようにするRunCのCVEがあります（docker 1.12.6以降で解決され、出荷されます）。パッチが適用されたRunCバージョンhttps://github.com/moby/moby/releases/tag/v1.12.6）