タグ: devcontainer

WindowsのVisual Studio Code 1.101.0でdecontainerからSSH-agentが正常に使用できない問題と対策

WindowsのVisual Studio Code 1.101.0でdecontainerを起動し、devcontainer内部からgit fetchを行ったところエラーが発生しました。

ログを見ると、環境変数「GIT_ASKPASS」に設定されている「askpass-main.js」で「Missing or invalid credentials.」エラーが発生するという状況です。

その辺りの状況から、SSHの秘密鍵が正常に読めてないのであろうことは予想できたのですが、以前はホスト機(Windows)のSSH-Agentを使えていたので、何か仕様が変わったのか？と調査しました。

GitHubにissueが登録済みの問題でしたので、ここまでたどり着けば解決します。
https://github.com/microsoft/vscode-remote-release/issues/11043

ただ、私はここへたどり着くのにえらい時間がかかったので、同じ目に遭った人がたどり着く手段を増やそうというのがこの記事の主旨であります。

原因としては、Visual Studio Code version 1.101.0で、内部で使用しているNodeを20から22にした影響により、SSH-Agentの転送が正常に行われないということだそうです。

Workaroundとしてはホスト機(Windows)で、システムの環境変数SSH_AUTH_SOCKに\.\pipe\openssh-ssh-agentを設定となります。

これを設定することで、devcontainer内でホスト機のSSH-Agentを参照することが出来るようになります。(GitがSSHを使うときも参照されるのでエラーが解消される)

WSLに置いたdevcontainer.jsonからJetBrains devcontainerを起動する

弊社ではPHPによる開発で使用するIDEはPhpStormが標準となっています。

PhpStormも今どきの流行かdevcontainer対応されており、されているからには使いたいと思うのですが、欲しい機能が無かったり期待した通り動かなかったりということが稀によくあるため、使う側が気を使って工夫してあげる必要があります。

今回はその中の1つ
「WSL上に配置したファイル(プロジェクト)からのdevcontainer起動が正常に行えない」
という問題の回避方法が分かったので共有しておこうという趣旨です。

公式に対して報告されている不具合としてはこれにあたると思われます。
https://youtrack.jetbrains.com/issue/IJPL-65925

そろそろ直りそうな気配もあり、直ったらこの記事も不要になるのですが、それならそれで喜ばしいということで。
(現時点の最新バージョン2025.1では直っていない)

結論から書きますと「devcontainer.jsonでworkspaceMountを指定する」となります。

以下は結論に至る経緯です。

Jetbrains devcontainerでは以下の2通りの方法でdevcontainerを作ることが出来ます。

  • ローカルプロジェクトから作成
    • ホスト機に置かれたファイル(devcontainer.json)を使って起動。
  • VCSプロジェクトから作成
    • VCS(Git)に置かれたファイル(devcontainer.json)を使って起動。
      • 実際の動作としては、使うファイルだけテンポラリディレクトリにcloneされてそこから起動される
    • 起動時にDocker volumeが作成され、そこにIDEが開く対象としてGit cloneされる

ただ、現状「VCSプロジェクトから作成」が以下のような点により使いにくいです。

  • Git cloneした内容がホスト機から直接見られない
    • HTMLやMicrosfot officeのドキュメントを入れてたりすると見られない
  • Git cloneした内容が複数のコンテナで共有できない
    • 専用のランダムな名前のDocker volumeが作成されるので、予めcompose.ymlで指定しておくということが出来ない
    • 静的なファイルだけWebサーバのコンテナで配布するとか、Javascriptは別コンテナのnodeで動かすといったことが出来ない
  • Dockerで使用する設定ファイルをBind mountしにくい
    • devcontainerが使用するファイルだけテンポラリディレクトリにcloneされるのでローカルで一時的に変更を試すといったことが出来ない

であれば「ローカルプロジェクトから作成」を使おうという話になりますが、この時「ローカルプロジェクト」がWSLに置いてあると正常に動作しないという問題にあたるわけです。(Windowsに置いてあれば問題なく動作するが、Dockerのディスクアクセス速度の都合でWSL上に置きたい)

状況を確認するために、以下のファイルを使用します。

\\wsl.localhost\Ubuntu\home\kurosawa\devtest.devcontainer\devtestdevcontainer.json

\\wsl.localhost\Ubuntu\home\kurosawa\devtest.devcontainer\compose.yml

このdevcontainer.jsonを使いdevcontainerを起動すると、IDEからディレクトリの中身(\\wsl.localhost\Ubuntu\home\kurosawa\devtest)が見えません。

Docker inspectでMountsを確認すると以下のようになっています。

Docker単体であればWSLに置いても特に問題なくマウント出来たはずなので確認します。

compose.ymlにvolumesを追加。

docker composeを使って直接起動します。

問題なくディレクトリ(\\wsl.localhost\Ubuntu\home\kurosawa\devtest)の中身が確認出来ます。

Docker inspectでMountsを確認すると以下のようになっています。

これらを見るに以下のような状況と思われます。

  • Dockerはスラッシュ区切りのパスがうまく認識できない
  • Dockerはバックスラッシュ区切りのパスは正常に認識できる
  • devcontainerから起動するとスラッシュ区切りのパスでマウントされる

compose.ymlを上記のまま、devcontainerから起動すればよいのでは？と思いましたが、スラッシュ区切りのパスでマウントされてしまいます。

それならばとcompose.ymlでバックスラッシュ区切りのフルパスを指定してみますが、相対パスで指定した場合と同じでスラッシュ区切りのパスでマウントされます。

では、バックスラッシュ区切りのパスにするにはどうしたらいいかというと、devcontainer.jsonのworkspaceMountで指定します。

compose.ymlのvolumesは不要なので削除します。(書いてもdevcontainer.jsonの設定で上書きされる)

workspaceMountで指定すると、バックスラッシュのパスでマウントされます。

workspaceMountは相対パスで指定しても大丈夫です。
devcontainer.jsonを共有することを考えるとこちらの方がよいでしょう。
マウント先のパスを変更することも出来ます。

devcontainerは指定したcompose.ymlをそのまま使うわけではなく、devcontainerの動作用に改変して使用します。

挙動からの推測になりますがその改変処理時に、compose.ymlのvolumesに書いたパスはdevcontainerが一旦解釈して、結果スラッシュ区切りのパスになりdevcontainer.jsonのworkspaceMountはdevcontainerが解釈せずそのまま使われる。ということなのだと思います。