その１ この記事
その２ https://qiita.com/ssugimoto/items/1b19083f5045e190e4ae
その３ https://qiita.com/ssugimoto/items/3b4a26711604bb6d56d2
その４ https://qiita.com/ssugimoto/items/a14262fa0bc8f60efee8
Windows 10 wsl2 ＋ Docker Desktopを使った知見とwsl2 とは
- 記事中
wsl2 Ubuntuと記載しているのはマイクロソフトストアからインストールするUbuntuのことです。Ubuntu がdocker-hubから入れるコンテナのUbuntu(例えば、こうゆうコンテナイメージ)なのか、wsl2のもとで動くUbuntu 18.04（Ubuntu 20.04）なのか、docker desktopにより動くLinuxのコンテナ（リモートコンテナも含む）なのか、どれかをわかりやすくするため
知見（ノウハウ）といっても、wsl2の実体・仕組みの理解までは奥が深い
- WSL2がいまだに何なのか理解できない（動きはなんとなくわかっているけど）
- WSL2とはWindows Subsystem for Linux 2の略、Windows内でLinuxを動作させる仕組み。WSL1の仕組みとは異なる。
- WSL2については 以下のうち、２つ目ののサイト（laptrinhx.com/news の記事）がわかりやすい（英語は翻訳すれば良い
過去の類似記事でコンテナ使ってみたケース
- Redmineをコンテナ２つ（docker-composeでRedmine本体のRailsとMySQLのコンテナ）使ってみたり（https://qiita.com/ssugimoto/items/e62472e74fa7b0a1154f#windows-docker%E3%81%A7%E3%81%AE%E8%A9%A6%E3%81%97）
- Amplifyの開発環境をDockerコンテナ（リモートコンテナ）使うようにしてみたり
WSL2を使う場合に気をつけること
コンテナ内からWindowsディレクトリをマウントして使うとめちゃくちゃ遅いです
- https://speakerdeck.com/noriyukitakei/wslvscodedocker?slide=43 と 44ページのスライド参照。測定結果では、0.2秒と105秒の差。
- 自身でも試した時の体感では10倍以上の差
- Macのdocker desktopでもディスクアクセスが遅いと言われていたけど、その遅さと非にならないレベルで遅い（Mac Book Pro 2016 と 2019でローカルをマウントしても、そこまで遅さは感じなかった）
- 構成として、Docker desktop + wsl2有効 + Linuxのコンテナ + LinuxコンテナからWindowsのディレクトリをマウント をしている場合（Linuxのコンテナは、wsl2のUbuntuではない）、下記の図のようなイメージ
回避策
- wsl1を使う（別でwsl2使っていると切替えは容易ではない、複数プロジェクトやっていたり、何らか動かすのにwsl2＋リモートコンテナでの開発、wsl2＋cdkやcfnの環境があったり）、wslの切替え＋ Docker Desktopでも切替えが必要、wsl2 Ubuntuだけ使うなら切替えは共存できるのでできそうな。
- PC2台あるならば、wsl1とwsl2でそれぞれ用意する
- Linuxコンテナ内からWindowsをマウントするのはawsのクレデンシャル情報やsshのkey情報などを共有する場合のみして、プロジェクトで使うソースコードをマウントしない、特にnode_mdulesは量が多くて遅さが際立つ。
- Windows使うのやめる（UbuntuかMacを使う）
- コンテナ使うのを諦める
マイクロソフト公式の情報（WSL1とWSL2での、WSL1を使う方が良いケース）
https://docs.microsoft.com/ja-jp/windows/wsl/compare-versions
以下、引用
例外的に WSL 2 ではなく WSL 1 を使用する場合
-
プロジェクト ファイルを Windows ファイル システムに格納する必要がある。 WSL 1 を使用すると、Windows からマウントされたファイルにより高速にアクセスできます。
-
WSL Linux ディストリビューションを使用して Windows ファイル システム上のプロジェクト ファイルにアクセスする予定で、これらのファイルを Linux ファイル システムに格納できない場合は、WSL 1 を使用することにより、OS ファイル システム間でより高速なパフォーマンスを実現できます。
-
同じファイルに対して Windows と Linux の両方のツールを使用したクロスコンパイルを必要とするプロジェクト。
-
Windows オペレーティング システムと Linux オペレーティング システムの間のファイル パフォーマンスは WSL 1 の方が WSL 2 よりも高速です。そのため、Windows アプリケーションを使用して Linux ファイルにアクセスする場合、現時点では WSL 1 を使用する方がより高速なパフォーマンスを得られます。
-
プロジェクトには、シリアル ポートまたは USB デバイスへのアクセスが必要です。
WSL 2 に関する FAQ によれば、WSL 2 にはシリアル ポートにアクセスするためのサポートは含まれていません。 シリアル ポートに関する未解決のイシューは、サポートがまだ追加されていないことを示しています。 -
厳密なメモリ要件がある
WSL 2 のメモリ使用量は、使用時に拡張および縮小されます。 プロセスによってメモリが解放されると、それは自動的に Windows に返されます。 ただし現在、WSL 2 では、WSL インスタンスがシャットダウンされるまで、メモリ内のキャッシュ ページが解放されて Windows に戻されることはありません。 WSL セッションが長時間実行されている場合、または非常に大量のファイルにアクセスする場合、このキャッシュによって Windows 上のメモリが占有される可能性があります。 WSL の Github リポジトリ イシュー 4166 で、このエクスペリエンスを改善するための作業を追跡しています。