に参加して、VS Code の AI 支援開発について学びましょう。

Dev Containers のヒントとコツ

この記事では、Dev Containers 拡張機能をさまざまな環境でセットアップして実行するためのヒントとコツを紹介します。

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

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

  • ローカルにDockerがインストールされている場合。
  • リモート環境にインストールされた Docker。
  • ローカルまたはリモートにインストールされた、他の Docker 準拠 CLI。

代替 Docker オプション ドキュメントで詳細を確認できます。

AI チャットの応答をカスタマイズする

カスタム指示を使用すると、一般的なガイドラインやルールを記述して、特定のコーディングプラクティスや技術スタックに一致する応答を得ることができます。

カスタム指示を開発コンテナで使用して、Copilot に接続している開発コンテナの種類（インストールされている言語やツールチェーンの種類など）に関する詳細情報を提供できます。これにはいくつかの方法があります。

  • devcontainer.json に "github.copilot.chat.codeGeneration.instructions" を直接追加する
    • 私たちは、開発コンテナの作成と接続のプロセスをさらに簡単にするために、開発コンテナのリソース（イメージやFeatureなど）を公開しており、現在これらのファイルにカスタム指示を含めています。
    • こちらは、Python Feature のカスタム指示の例です。
  • ローカルと同じように copilot-instructions.md ファイルを使用する

Windows 版 Docker Desktop のヒント

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

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

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

  3. ファイアウォールが Docker による共有ドライブの設定を許可していることを確認してください。 Docker は 2 つのマシンローカル IP 間で接続するだけで済みますが、一部のファイアウォールソフトウェアは、ドライブ共有または必要なポートをブロックする場合があります。

ここでは、以前のバージョンの Windows 版 Docker に適用されたが、現在は解決されているはずのヒントをいくつか紹介します。潜在的な回帰が原因で奇妙な動作に遭遇した場合は、これらのヒントが過去に問題を解決しています。

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

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

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

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

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

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

この手順は、Docker Desktop の WSL 2 エンジンでは不要であることに注意してください。

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

Windows

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

macOS

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

コンテナでの 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 プッシュまたは同期を行う際のハングアップの解決

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 タスクバー項目を右クリックし、Settings / Preferences を選択します。
  2. Advanced に移動して、CPU、メモリ、またはスワップを増やします。
  3. macOS では、Disk に移動して、Docker がマシンで消費できるディスク量を増やします。Windows では、これは他の設定とともに Advanced の下にあります。

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

使用されていないコンテナとイメージのクリーンアップ

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

オプション 1: リモートエクスプローラーを使用する

リモートエクスプローラーを選択し、削除したいコンテナを右クリックして、Remove Container を選択することで、コンテナを削除できます。

Remote Explorer screenshot

ただし、これではダウンロードしたイメージはクリーンアップされず、システムが散らかる可能性があります。

オプション 2: Container Tools 拡張機能を使用する

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

  2. まだ存在しない場合は、拡張機能ビューから Container Tools 拡張機能をインストールします。

  3. その後、コンテナエクスプローラーに移動して、Containers または Images ノードを展開し、右クリックして Remove Container / Image を選択できます。

    Container Explorer screenshot

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

  1. ローカルターミナル/コマンドプロンプトを開きます（または VS Code のローカルウィンドウを使用します）。
  2. docker ps -a と入力して、すべてのコンテナのリストを表示します。
  3. このリストから docker rm と入力してコンテナを削除します。
  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 ビルド失敗の解決

Debian 8/Jessie ベースのイメージ（node:8 イメージの古いバージョンなど）を使用するコンテナをビルドすると、次のエラーが発生する場合があります。

...
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 使用率

macOS 版 Docker には、高い CPU スパイクを引き起こす可能性のある既知の問題があります。特に、ファイルの監視とビルド中に高い CPU 使用率が発生します。開発コンテナでほとんど何も実行されていないのに、アクティビティモニタで com.docker.hyperkit の CPU 使用率が高い場合は、この問題に遭遇している可能性があります。更新と修正については、Docker issue を参照してください。

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

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

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

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

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

次の手順に従ってください

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

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

    "containers.environment": {
    "DOCKER_HOST": "tcp://:23750"
}

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

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

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

完了したら、ターミナル/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 プロパティを使用して、開発コンテナのユーザープロファイル（シェル履歴などの保持）を再ビルド後も永続化できます。

    "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: Show Container Log で取得できます。

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

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

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

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

10/09/2025
© . This site is unofficial and not affiliated with Microsoft.