WSL2 と Docker (compose)ーその2

Docker WSL2

混乱その2、ネットワークについて。

WindowsホストからWSL2へのNW接続にはホストでport forwardが必要？

という疑問。

手元でdocker-composeで立ち上げている、Docker Desktop for Windows based on WSL2でのJenkins/Rocket.chat/wiki.jsをバックエンドに持つnginx、特にホストでport fowardしなくてもWindowsホスト名のURLでアクセスできている（Windows Defender Firewallでinboudは開けている）のです。

まずは仕組みの情報収集から。

一昨年(2019年)の8、9月頃、Windows 10 Build 18945リリースの記事でホストWindowsからlocalhostでWSL2にNWアクセスできる改良が盛り込まれたという記事がメディアから多数リリースされてました。

WSL2化に伴い、”本物”のLinux KernelをLWUVM（軽量ユーティリティ)で動作させて「WSL 2 と WSL 1 の比較 | Microsoft Docs」の機能比較でWSL1の「❌」を「✅」に改良したわけですが、これによってWSL2側のTCP／IPスタックも本物化されネットワークセグメントがHyer-Vの仮想ネットワークスイッチを使って分離されたことに起因するものとなっています。

確かに我が家も記事通りになっています。

Docker composeでnginx(port:8443)を含むサーバーを立ち上げた状態で、Windowsホストでポートの状態をnetstatで見ると以下のような感じです。わかりやすくする為、関係のない情報は削除しています。

対象プログラムがまちまち([com.docker.backend.exe]/[svchost.exe]/[wslhost.exe)なのが謎ですが、0.0.0.0:8443(IPv4)/[::]:8443/[::1]:8443(IPv6)でlocalhostをListenしているのが、恐らく記事にあるlocalhostで接続できる様になった部分。

すべてがwslhost.exeだと記事の内容と整合してスッキリするのですが、記事はあくまでWSL2に関するものですので、Docker Desktop for Windowsサービスを停止した状態で確認してみるのがいいかもしれません。

Docker コンテナとHost間の通信に関しては、Windows環境ですと”host.docker.internal”が関わっていそうです。

”host.docker.internal”はWindows/Macのみ（Linuxにはない、というか必要性がそもそもない？）にある、コンテナからホストに接続する為のスペシャルDNS名（出所：Docker公式ドキュメント）。

コンテナ起動してChromeでアクセスした状態netstatすると以下のような感じになりました（同じく間引いています）。

6つのポートを使っている理由はわからないのですが、”host.docker.internal”の仕組みを使ってHOST-コンテナ間通信を実現してくれている様です。

冒頭の疑問の自己結論。

HOST→WSL2間のlocalhoost接続とは全く別の仕組み。
Docker Desktop for Windowsを使っていれば、Dockerfile（docker-compose.yml）での定義に沿って適切にDokcerがHOST-コンテナ双方向の通信をセットアップしてくれる。

Ubuntu on WSL2にDebianパッケージでDocker導入するパターンを「WSL2 と Docker (compose)ーその１ - ケ・セラ・セラ」で言及しましたけど、同じ機構は機能しないでしょうし、WSL2によるHOSTとのネットワーク分離と相まって、HOSTのサーバー名で外部からコンテナにアクセスするには、こちらの場合、手動でport fowardが必要そうですね。

※現環境を壊して試すインセンティブが今はないので未検証です。

やはり、Winな環境での通常運用では、素直にWin向けを使うのがベターというありきたりな顛末となりました。

最後に利用しているDocker Desktop for Windows環境情報を。

f:id:kittantan:20210111221537p:plain

2021-01-10

WSL2 と Docker (compose)ーその１

Docker WSL2

WSL2でWindowsでも真っ当なLinux環境が使える！という情報に期待して色々触り始めて時間が経った事で、分かってきたり更に悩みが深くなったりしたことを書いてみます。

仮想マシン上を含むピュアLinuxな環境だと発生しない悩み事が殆どです。

今回は、

Docker (compse）は、「Docke Desktop for Windows based on WSL2」にすべき？WSL2上のUbuntuにUbuntuパッケージで導入すべき？

です。

ネット上の情報、特に個人の記事を見ていると、この2つを比較した上でどちらを使っているっという内容のものは殆ど無く混在しているので、検索結果を通しで見ているとちょっと混乱してしまいます。導入するだけであればどちらも可能。こういう時はまず公式。

docs.docker.com

WindowsであればやはりDocker Desktop for Windows。選択肢としてもUbuntu on WLS2へのパッケージ導入の言及はないですね。

以下のページ、比較ではなく筆者の方ご自身がやりたいことを時系列に実施されている中で両方のパターンを言及されていて分かりやすかったです。

hnakamur.github.io

WSL2で動くUbuntu（MS的にはアプリ）は公式のDesktop版でもServer版でもなく、WSL用ディストリビューションで、initプロセスはデーモン起動する仕組みの部分、今時ですとsystetmdが置き換え（先祖返り？）られていている様です。

故に、任意のサービス系パッケージはインストールはできれども、プート時にサービス起動できない。

なので、Ubuntu on WSL2にDebianパッケージでdocker (compose）を導入すると、Docker Daemonの手動起動が毎回必要になるという不便があるというのが現状の様。

systemdを動かすのも実験的に好奇心を満たす意味では面白そうですが、安定運用観点だとアップデートにも影響がありそうで難あり。

Ubuntu on WLS2にdockerをパッケージインストールすると「動かなかった」で終わっているドキュメントがネット上に多数あったのですが恐らくEngine自体の起動ができていなかったんだろうと推察されます。

Windows 10でDocker (compose)をハック的ではなく、通常運用で使うなら「Docker Desktop for Windows」が良さそうですね。

2020-12-26

Wiki.jsなGraphQLでユーザー作成試行中の続き（タイムゾーン）

graphQL wiki.js

Wiki.jsなGraphqlでユーザー作成試行中その２ - ケ・セラ・セラでやりきった感出してましたGrarphQLでのユーザー作成、出来はしたのですけど、途中いくつか想定外のことがおこったのでその内容を。

Wikiの記事を作成すると時間が過去になる
システム時刻のlocaltimeだろうと踏んで、「Alpine Linux でタイムゾーンを変更する - Qiita」あたりを参考にWiki.js DockerコンテナのAlpine LinuxのタイムゾーンをAsia/Tokyoにするも記事作成時刻は変わらず。

Release Notes | Wiki.jsのtimezoneに関する対応内容をみるとどうも「User Profile」に設定がある（ユーザー毎？）様で、デフォルトはNewYork。（通りでGMTとの時差でもなかったわけです）

UserMutationsスキーマを調べると”update”なるものがあって、ユーザー毎のtimezone要素があり、そこにタイムゾーン文字列（”Asia/Tokyo”）を指定してリクエストすれば変更できそうなことがわかる。

これで無事に編集時間がJSTになるようにJenkinsジョブからユーザー作成できるようになりました。

でも、なぜcreateのパラメータには無いんだろう？

createのレスポンス”uses”が作成成功してもnull
createでtimezone属性設定できないのでupdateを改めて呼ぶわけですが、ユーザー特定のためwiki.jsシステムが割り振るユーザーidをパラメータに指定して呼び出す必要があります。
createのレスポンスにあるから余裕と思っていたのですがどうしてもnullしか返却されない（Wiki.js Ver.2.5.170）。
仕方ないのでcreate後にusers: UserQueryのserchでユーザーIDを取得してupdateのパラメータにしています。
私の使い方の問題なのかシステムのもんだいなのか、いやはや。