🚀 VS Codeでで入手しましょう！

Dev Containersのヒントと秘訣

この記事では、さまざまな環境でDev Containers拡張機能を起動して実行するためのヒントと秘訣を紹介します。

Dockerをインストールする別の方法

Dev Containers拡張機能でDockerを使用するには、次のようないくつかの方法があります。

  • ローカルにインストールされたDocker。
  • リモート環境にインストールされたDocker。
  • ローカルまたはリモートにインストールされた、その他のDocker準拠のCLI。

詳細については、代替Dockerオプションのドキュメントを参照してください。

Docker Desktop for Windowsのヒント

Docker Desktop for Windowsはほとんどのセットアップでうまく動作しますが、問題を引き起こす可能性のあるいくつかの「落とし穴」があります。それらを回避するためのヒントをいくつか紹介します。

  1. Windows 10（2004以降）で新しいDocker WSL 2バックエンドを使用することを検討してください。 Docker DesktopのWSL 2バックエンドを使用している場合、それを使用してWSL内部だけでなくローカルのフォルダも開くことができます。コンテナはWindowsとWSL内部で共有され、この新しいエンジンはファイル共有の問題の影響を受けにくくなっています。詳細については、クイックスタートを参照してください。

  2. 「Windows上のLinuxコンテナ（LCOW）」モードから切り替えます。 デフォルトでは無効になっていますが、最近のバージョンのDockerはWindows上のLinuxコンテナ（LCOW）をサポートしており、WindowsコンテナとLinuxコンテナを同時に使用できます。ただし、これは新しい機能であるため、問題が発生する可能性があり、Dev Containers拡張機能は現在Linuxコンテナのみをサポートしています。 Dockerタスクバー項目を右クリックし、コンテキストメニューからLinuxコンテナに切り替える...を選択することで、いつでもLCOWモードから切り替えることができます。

  3. ファイアウォールがDockerに共有ドライブの設定を許可していることを確認してください。 Dockerは2つのマシンローカルIP間のみを接続する必要がありますが、一部のファイアウォールソフトウェアは、ドライブ共有または必要なポートをブロックする可能性があります。この問題を解決するための次のステップについては、このDocker KB記事を参照してください。

古いバージョンのDocker for Windowsに適用されていたが、現在では解決されているはずのヒントをいくつか紹介します。回帰の可能性による奇妙な動作が発生した場合は、これらのヒントで過去に問題が解決されています。

  1. ドライブを共有する場合は、ADドメインアカウントまたはローカル管理者アカウントを使用してください。 AAD（メールベース）アカウントは使用しないでください。 AAD（メールベース）アカウントには、Docker issue #132およびissue #1352で文書化されているように、既知の問題があります。 AADアカウントを使用する必要がある場合は、ドライブの共有のみを目的とした別のローカル管理者アカウントをマシン上に作成します。 すべてをセットアップするには、このブログ投稿の手順に従ってください。

  2. ドライブ共有の問題を避けるために、英数字のパスワードを使用してください。 Windowsでドライブを共有するように求められたら、マシン上の管理者権限を持つアカウントのユーザー名とパスワードを求められます。ユーザー名またはパスワードが正しくないという警告が表示された場合は、パスワードに特殊文字が含まれていることが原因である可能性があります。たとえば、!、[、および]は問題を引き起こすことが知られています。パスワードを英数字に変更して解決してください。詳細については、Dockerボリュームのマウントに関する問題に関するこの問題を参考にしてください。

  3. （メールではなく）Docker IDを使用してDockerにサインインしてください。 Docker CLIはDocker IDの使用のみをサポートしているため、メールアドレスを使用すると問題が発生する可能性があります。詳細については、Docker issue #935を参照してください。

それでも問題が解決しない場合は、Docker Desktop for Windowsのトラブルシューティングガイドを参照してください。

Docker Desktopでファイル共有を有効にする

VS CodeのDev Containers拡張機能は、コードがDockerと共有されているフォルダまたはドライブにある場合にのみ、ソースコードをコンテナに自動的にマウントできます。共有されていない場所からDev Containerを開くと、コンテナは正常に起動しますが、ワークスペースは空になります。

この手順は、Docker DesktopのWSL 2エンジンでは必要ありません。

Dockerのドライブとフォルダの共有設定を変更するには

Windows

  1. Dockerタスクバー項目を右クリックし、設定を選択します。
  2. リソース > ファイル共有に移動し、ソースコードが配置されているドライブを確認します。
  3. ローカルファイアウォールが共有アクションをブロックしているというメッセージが表示された場合は、次の手順についてこのDocker KB記事を参照してください。

macOS

  1. Dockerメニューバー項目をクリックし、Preferencesを選択します。
  2. Resources > File Sharingに移動します。ソースコードを含むフォルダが、リストされている共有フォルダの1つにあることを確認します。

コンテナでのGitの改行コードの問題を解決する（多数の変更されたファイルが発生する）

WindowsとLinuxは異なるデフォルトの改行コードを使用しているため、Gitは改行コード以外の違いがない多数の変更されたファイルを報告する場合があります。 これが発生するのを防ぐために、.gitattributesファイルを使用するか、Windows側でグローバルに改行コード変換を無効にすることができます。

通常、リポジトリに.gitattributesファイルを追加または変更することが、この問題を解決する最も信頼性の高い方法です。 このファイルをソース管理にコミットすると、他のユーザーの助けになり、必要に応じてリポジトリごとに動作を変化させることができます。 たとえば、リポジトリのルートに次の内容を.gitattributesファイルに追加すると、CRLFを必要とするWindowsバッチファイルを除き、すべてがLFに強制されます。

* text=auto eol=lf
*.{cmd,[cC][mM][dD]} text eol=crlf
*.{bat,[bB][aA][tT]} text eol=crlf

これはGit v2.10以降で動作することに注意してください。問題が発生している場合は、最新のGitクライアントがインストールされていることを確認してください。 CRLFを必要とするリポジトリ内の他のファイルタイプをこの同じファイルに追加できます。

Unixスタイルの改行コード（LF）を常にアップロードしたい場合は、inputオプションを使用できます。

git config --global core.autocrlf input

改行コードの変換を完全に無効にする場合は、代わりに次を実行してください。

git config --global core.autocrlf false

最後に、これらの設定を有効にするには、リポジトリを再度クローンする必要がある場合があります。

Docker Composeを使用する場合、コンテナ内でGitをセットアップすることを避ける

この問題の解決に関する情報については、メインのコンテナに関する記事のGitクレデンシャルをコンテナと共有するを参照してください。

コンテナからGit pushまたは同期を行う際、ハングアップを解決する

SSHを使用してGitリポジトリをクローンし、SSHキーにパスフレーズがある場合、リモートで実行するとVS Codeのプルおよび同期機能がハングアップする可能性があります。

パスフレーズなしでSSHキーを使用するか、HTTPSを使用してクローンするか、コマンドラインからgit pushを実行して問題を回避してください。

Linuxの依存関係が見つからないというエラーを解決する

一部の拡張機能は、特定のDockerイメージにないライブラリに依存しています。 この問題の解決に関するいくつかのオプションについては、コンテナの記事を参照してください。

Docker Desktopでコンテナを高速化する

デフォルトでは、Docker Desktopはコンテナにマシンの容量の一部のみを提供します。 ほとんどの場合、これで十分ですが、より多くの容量を必要とする何かを実行している場合は、メモリ、CPU、またはディスクの使用量を増やすことができます。

まず、使用しなくなった実行中のコンテナを停止してみてください。

これで問題が解決しない場合は、CPU使用率が実際に問題であるかどうか、または他に何か問題が発生しているかどうかを確認する必要があります。 これを確認する簡単な方法は、Resource Monitor拡張機能をインストールすることです。 コンテナにインストールすると、ステータスバーにコンテナの容量に関する情報が表示されます。

Resource use Status bar

この拡張機能を常にインストールしたい場合は、これをsettings.jsonに追加してください。

"dev.containers.defaultExtensions": [
    "mutantdino.resourcemonitor"
]

コンテナにマシンの容量をさらに多く割り当てる必要があると判断した場合は、次の手順に従ってください。

  1. Dockerタスクバー項目を右クリックし、設定/Preferencesを選択します。
  2. 詳細設定に移動して、CPU、メモリ、またはスワップを増やします。
  3. macOSでは、ディスクに移動して、Dockerがマシンで使用できるディスク容量を増やします。 Windowsでは、これは他の設定とともに詳細設定の下にあります。

最後に、コンテナがディスク集中型の操作を実行している場合、または単に高速な応答時間を求めている場合は、ヒントについてコンテナディスクのパフォーマンスの向上を参照してください。 VS Codeのデフォルトは利便性と普遍的なサポートのために最適化されていますが、最適化できます。

未使用のコンテナとイメージをクリーンアップする

Dockerからディスク容量が不足しているというエラーが表示された場合は、通常、未使用のコンテナとイメージをクリーンアップすることで解決できます。 これを行うには、いくつかの方法があります。

オプション1：Remote Explorerを使用する

Remote Explorerを選択し、削除するコンテナを右クリックして、コンテナの削除を選択することで、コンテナを削除できます。

Remote Explorer screenshot

ただし、これはダウンロードした可能性のあるイメージをクリーンアップするわけではなく、システムが乱雑になる可能性があります。

オプション2：Docker拡張機能を使用する

  1. VS Codeでローカルウィンドウを開きます（ファイル > 新しいウィンドウ）。

  2. まだインストールされていない場合は、拡張機能ビューからDocker拡張機能をインストールします。

  3. 次に、Dockerビューに移動して、コンテナまたはイメージノードを展開し、右クリックしてコンテナ/イメージの削除を選択できます。

    Docker Explorer screenshot

オプション3：Docker CLIを使用して削除するコンテナを選択する

  1. ローカルターミナル/コマンドプロンプトを開きます（またはVS Codeでローカルウィンドウを使用します）。
  2. docker ps -aと入力して、すべてのコンテナのリストを表示します。
  3. このリストからdocker rm <Container ID>と入力して、コンテナを削除します。
  4. docker image pruneと入力して、未使用のイメージを削除します。

docker psが削除するコンテナを特定するのに十分な情報を提供しない場合は、次のコマンドは、VS Codeによって管理されているすべての開発コンテナと、それらを生成するために使用されたフォルダをリストします。

docker ps -a --filter="label=vsch.quality" --format "table {{.ID}}\t{{.Status}}\t{{.Image}}\tvscode-{{.Label \"vsch.quality\"}}\t{{.Label \"vsch.local.folder\"}}"

オプション4：Docker Composeを使用する

  1. ローカルターミナル/コマンドプロンプトを開きます（またはVS Codeでローカルウィンドウを使用します）。
  2. docker-compose.ymlファイルのあるディレクトリに移動します。
  3. docker-compose downと入力して、コンテナを停止して削除します。複数のDocker Composeファイルがある場合は、-f引数を使用して追加のDocker Composeファイルを指定できます。

オプション4：実行されていないすべてのコンテナとイメージを削除する

  1. ローカルターミナル/コマンドプロンプトを開きます（またはVS Codeでローカルウィンドウを使用します）。
  2. docker system prune --allと入力します。

Debian 8を使用するイメージのDockerfileビルドの失敗を解決する

node:8イメージの古いバージョンなど、Debian 8/Jessieに基づくイメージを使用するコンテナをビルドすると、次のエラーが発生する可能性があります。

...
W: Failed to fetch http://deb.debian.org/debian/dists/jessie-updates/InRelease  Unable to find expected entry 'main/binary-amd64/Packages' in Release file (Wrong sources.list entry or malformed file)
E: Some index files failed to download. They have been ignored, or old ones used instead.
...

これは、Debian 8が「アーカイブ」されていることが原因で発生する既知の問題です。 より新しいバージョンのイメージは、通常、Debian 9/Stretchにアップグレードすることで、この問題を解決します。

このエラーを解決するには、2つの方法があります。

  • オプション1：イメージに依存するコンテナを削除し、イメージを削除してから、再度ビルドを試みます。 これにより、問題の影響を受けない更新されたイメージがダウンロードされるはずです。 詳細については、未使用のコンテナとイメージのクリーンアップを参照してください。

  • オプション2：コンテナまたはイメージを削除したくない場合は、aptまたはapt-getコマンドの前に、Dockerfileにこの行を追加します。 Jessieに必要なソースリストを追加します。

    # Add archived sources to source list if base image uses Debian 8 / Jessie
RUN cat /etc/*-release | grep -q jessie && printf "deb http://archive.debian.org/debian/ jessie main\ndeb-src http://archive.debian.org/debian/ jessie main\ndeb http://security.debian.org jessie/updates main\ndeb-src http://security.debian.org jessie/updates main" > /etc/apt/sources.list

メールアドレスが使用されている場合のDocker Hubサインインエラーを解決する

Docker CLIはDocker IDの使用のみをサポートしているため、メールアドレスを使用してサインインすると問題が発生する可能性があります。 詳細については、Docker issue #935を参照してください。

回避策として、メールアドレスではなくDocker IDを使用してDockerにサインインしてください。

macOSでのHyperkitの高CPU使用率

Docker for Macに関する既知の問題があり、CPUスパイクが高くなる可能性があります。 特に、ファイルを監視およびビルドするときにCPU使用率が高くなります。 Dev Containerでほとんど何も起こっていないのに、アクティビティモニターでcom.docker.hyperkitのCPU使用率が高い場合は、この問題に遭遇している可能性があります。 更新と修正については、Docker issueに従ってください。

リモートDockerホストに接続するためにSSHトンネルを使用する

リモートDocker MachineまたはSSHホスト上のコンテナ内で開発するの記事では、リモートDockerホストで作業する場合のVS Codeのセットアップ方法について説明しています。 これは多くの場合、Docker拡張機能のdocker.environmentプロパティをsettings.jsonで設定するか、DOCKER_HOST環境変数をssh://またはtcp:// URIに設定するのと同じくらい簡単です。

ただし、SSH構成の複雑さやその他の制限により、環境内でこれが機能しない状況が発生する場合があります。 この場合、SSHトンネルをフォールバックとして使用できます。

フォールバックオプションとしてSSHトンネルを使用する

SSHトンネルを設定し、リモートホストからローカルマシンにDockerソケットを転送できます。

次の手順に従います。

  1. OpenSSH互換のSSHクライアントをインストールします。

  2. ユーザーまたはワークスペースのsettings.jsonで、Docker拡張機能のdocker.environmentプロパティを次のように更新します。

    "docker.environment": {
    "DOCKER_HOST": "tcp://localhost:23750"
}

  3. ローカルターミナル/PowerShellから次のコマンドを実行します（user@hostnameをリモートユーザーとサーバーのホスト名/IPに置き換えます）。

    ssh -NL localhost:23750:/var/run/docker.sock user@hostname

これで、VS Codeはリモートホスト上の実行中のコンテナにアタッチできるようになります。 また、特殊なローカルdevcontainer.jsonファイルを使用して、リモートDev Containerを作成/接続することもできます。

完了したら、ターミナル/PowerShellでCtrl+Cを押してトンネルを閉じます。

注： sshコマンドが失敗した場合は、SSHホストでAllowStreamLocalForwardingが必要になる場合があります。

  1. SSHホスト（ローカルではなく）でエディター（Vim、nano、Picoなど）で/etc/ssh/sshd_configを開きます。
  2. AllowStreamLocalForwarding yes設定を追加します。
  3. SSHサーバーを再起動します（Ubuntuでは、sudo systemctl restart sshdを実行します）。
  4. 再試行してください。

ユーザープロファイルを永続化する

mountsプロパティを使用して、ユーザープロファイル（シェル履歴など）を再構築間でDev Containerに永続化できます。

    "mounts": [
        "source=profile,target=/root,type=volume",
        "target=/root/.vscode-server,type=volume"
    ],

上記のコードは、最初にprofileという名前のボリュームを作成し、/rootにマウントします。これは再構築後も存続します。 次に、再構築時に破棄される/root/.vscode-serverにマウントされた匿名ボリュームを作成します。これにより、VS Codeは拡張機能とドットファイルを再インストールできます。

高度なコンテナ構成のヒント

次のトピックに関する情報については、高度なコンテナ構成の記事を参照してください。

拡張機能のヒント

多くの拡張機能は変更なしで動作しますが、特定の機能が期待どおりに動作しなくなる可能性のある問題がいくつかあります。 場合によっては、別のコマンドを使用して問題を回避できますが、場合によっては、拡張機能を変更する必要がある場合があります。 リモート拡張機能のヒントセクションでは、一般的な問題と解決策のヒントに関するクイックリファレンスを提供します。 リモート拡張機能ホストをサポートするように拡張機能を変更する方法の詳細なガイドについては、拡張機能に関するメインの記事リモート開発のサポートを参照することもできます。

質問とフィードバック

問題の報告

Dev Containers拡張機能で問題が発生した場合は、問題を診断できるように、正しいログを収集することが重要です。 Dev Containers: コンテナログを表示を使用して、Dev Containers拡張機能のログを取得できます。

他の拡張機能をリモートで使用しているときに問題が発生した場合（たとえば、他の拡張機能がリモートコンテキストで正しくロードまたはインストールされない場合）、リモート拡張機能ホスト出力チャネル（出力: 出力ビューにフォーカス）からログを取得し、ドロップダウンからログ（リモート拡張機能ホスト）を選択すると役立ちます。

注：ログ（拡張機能ホスト）のみが表示される場合、これはローカル拡張機能ホストであり、リモート拡張機能ホストは起動していません。 これは、ログチャネルがログファイルが作成された後にのみ作成されるため、リモート拡張機能ホストが起動しない場合、リモート拡張機能ホストのログファイルは作成されず、出力ビューに表示されないためです。 これは、問題に含めるのに役立つ情報です。

リモートに関する質問とフィードバックのリソース

さまざまなリモートリソースがあります。

04/03/2025