はじめに
Windows + WSL環境にてDocker DesktopからDocker CEへ移行した場合、元々WSL内でしか操作利用していなかったとしても幾つかの挙動が存在し、Docker Desktopは便利にできていたと実感することがあるので、できなくなってしまったこととその代替プランをメモとして残します。
loopbackアドレスのマッピング
| Docker Desktop | 127.0.0.1～127.255.255.255までアドレスをマップできる |
|---|---|
| Docker CE | 127.0.0.1しかマップできない |
Docker Destopは127.0.0.0/8が使える。127.1.1.1等もDocker Desktopの中継プロセスがWindowsホストにマッピングしてくれる。
Docker CEも127.1.1.1をマップするとホストにあたるWSLインスタンスにマッピングしてくれる。しかし、WSLからWindowsホストへのマッピングは127.0.0.1のみなのでWindowsホストにはマップされない。
代替プラン
予め決めておいたIPv6 ユニークローカルアドレスをWSLインスタンスに割り振り、そのアドレスに対してマッピングする。リンクローカルの空きプレフィクスを使うとコンテナ起動時にエラーとなるため、ユニークアドレスを使う必要がある。
参考) WSL2のUbuntuに固定のIP(IPv6)アドレスを複数つけてみる
##host.docker.internal
| Docker Desktop | Windowsホスト(デフォルトでは192.168.65.2)を指す |
|---|---|
| Docker CE | host.docker.internal:host-gateway が代替するが、WSLインスタンスを指す |
Docker Desktopでは、host.docker.internalという特別なドメインでWindowsホストに中継する。しかも中継プロセスがローカルアクセスとして中継するためにファイヤーウォールの影響を受けない。
Docker CEにもhost.docker.internalの代替として、host-gatewayというキーワードでextra_hostsに登録する手法が提供されたが、ここでいうホストとはWSLを指すのでDocker Desktopの概念とは意味が異なる。
Visual Studio Code PHPDebug拡張を利用するケース
Remote WSL を使用してソースツリーにアクセスする場合、vscodeがオープンしたWindowsホストのlocalhot:9003をWSLのlocalhost:9003にポートプロキシを行う。
| Windows | localhost:9003 |
|---|---|
| WSL | localhost:9003 |
この場合
| Docker Desktop | host.docker.internal = Windowsの9003へ接続*可能* |
|---|---|
| Docker CE | host.docker.internal = WSLの9003へ接続*可能* |
となりどちらも接続可能となる。
Remote Containerを使う場合でも、WSL経由のリモートコンテナへの接続に関しては双方ともに問題無い。ただし、vscodeの中継プロセスはコンテナ内で起動するのでWindowsとコンテナ内で9003がlistenされる。
| Windows | localhost:9003 |
|---|---|
| WSL | N/A |
| Container | localhost:9003 |
この場合、Remote WSLとは異なり
| Docker Desktop 〇 | host.docker.internal = Windowsの9003へ接続*可能* |
|---|---|
| Docker Desktop 〇 | localhost = Containerの9003へ接続*可能* |
| Docker CE × | host.docker.internal = WSLの9003へ接続*不可能* |
| Docker CE 〇 | localhost = Containerの9003へ接続*可能* |
Docker DesktopではRemote WSL, Containerいずれもhost.docker.internalでよかった設定がDocker CEではどちらのリモート機能を使うかによってxdebugの設定を切り替える必要がある。
##WSL2 + Docker Engine(!=Desktop)でもWindows資格情報を使いたい
認証で警告が出る
Docker Desktopだとdocker loginでレジストリにログインする際に、認証情報の管理はdocker-credential-desktop.exeを介してWindowsにお任せになります。ところがDocker Engineを入れただけではヘルパーがないので警告が出るようになってしまいます。
$ docker login xxxxxx
Username: shigeokamoto
Password: xxxxxxx
WARNING! Your password will be stored unencrypted in /home/shigeokamoto/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
この警告メッセージから辿って、docker/docker-credential-helpersを確認すると、
docker-credential-wincred-v0.6.4-amd64.zipというのがあります。docker-credential-wincred.exe自体はDocker Desktopにも
付属していて、docker-credential-desktop.exeをヘルパーとして使った場合でも最終的にはこのプログラムを呼び出しているようです。
それなら、これを使えば解決できそうです。
-
docker-credential-wincred.exeを/usr/local/bin等パスの通ったディレクトリに保存して、 - Docker Desktopに倣って~/.docker/config.jsonを作成(あるいは追記)します。
config.jsonに記録された認証情報は削除しておけばよいので、認証以外の設定が特になければ以下の部分だけ記述しておけばよいと思います。
{
"credsStore": "wincred.exe"
}
あとは docker login, docker logout を繰り返して、Windows資格情報に資格情報が格納されたり削除されたりしているのを確認できれば完了です。