状態:
私はWSLを使用してDockerを実行しているWindows VDIで開発しており、Red Hatサーバーで実際に実行されているリモートDockerデーモンを使用しています。ローカルでは、DOCKER_HOST
変数を私のdockerデーモン()の正しいパスに設定しましたが、tcp://<userid>@<my server running the remote docker daemon>
この環境変数は設定された直後にのみ認識されます。
つまり、今はdockerコマンドを実行するとエラーが発生しますが、それを自分に割り当てると、今後のCannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
dockerコマンドはその変数を使用して私が指示したリモートデーモンを認識します。DOCKER_HOST
$ export DOCKER_HOST=$DOCKER_HOST
DOCKER_HOST
この割り当てを自分の割り当てに追加し、~/.bashrc
シェルを再起動して実行すると、正しく設定されていることを確認できます$ echo $DOCKER_HOST
。
予想される動作:
DOCKER_HOST
dockerコマンドリファレンスで設定された変数を使用して、~/.bashrc
その変数の存在を確認したいと思います。$ echo $DOCKER_HOST
現実:
Dockerは、アクティブシェルセッション内で設定されていないと、この変数/値を認識しません。実際には、dockerがそれを認識できるように、変数自体に変数を割り当てる必要があります(たとえば、export DOCKER_HOST=$DOCKER_HOST
)、dockerコマンドはリモートデーモンに対してのみ実行されます。
私の質問:
DOCKER_HOST
dockerが変数を認識できるように変数をリセットする必要があるのはなぜですか?
私がこれを間違っているなら、正しい方法は何ですか?
私の質問が間違った場所で要求されたというニュースを聞きたいです。私はこれがLinux / WSLの問題であるか、docker自体の問題であると仮定できます。
答え1
この記事を投稿してすぐに解決策を見つけましたが、少し愚かな感じがしました。
~/.bashrc
問題は、環境変数をエクスポートする代わりにシェル変数を設定したことです。
解決策:
~/.bashrc
使用するように修正export
:
export DOCKER_HOST=tcp://<userid>@<my server running the remote docker daemon>
だけでなく:
DOCKER_HOST=tcp://<userid>@<my server running the remote docker daemon>