次の方法で共有


WSL 2 での Docker リモート コンテナーの概要

このステップ バイ ステップ ガイドは、WSL 2 (Linux 用 Windows サブシステム、バージョン 2) で Docker Desktop for Windows を設定して、リモート コンテナーを使用した開発を開始するのに役立ちます。

Docker Desktop for Windows は、Docker でコンテナー化するアプリのビルド、配布、実行のための開発環境を提供します。 WSL 2 ベースのエンジンを有効にすることで、同じコンピューター上の Docker Desktop で Linux と Windows の両方のコンテナーを実行できます。 (Docker Desktop は、個人使用および小規模企業向けの場合は無料です。Pro、Team、または Business の価格については、Docker サイトの FAQ を参照します)。

Note

Windows および Linux 用 Windows サブシステムと統合されるため、Docker Desktop を使用することをお勧めします。 ただし、Docker Desktop では Linux および Windows コンテナーの両方の実行がサポートされていますが、両方を同時に実行することはできません。 Linux および Windows コンテナーを同時に実行するには、WSL に個別の Docker インスタンスをインストールして実行する必要があります。 コンテナーを同時に実行する必要がある場合、あるいは Linux ディストリビューションにコンテナー エンジンを直接インストールしたい場合は、そのコンテナー サービスの Linux インストール手順に従います (Ubuntu に Docker エンジンをインストールするLinux コンテナーを実行するための Podman をインストールするなど)。

Docker コンテナーの概要

Docker は、コンテナーを使用してアプリケーションを作成、展開、および実行するために使用されるツールです。 コンテナーを使用すると、開発者はアプリを必要なすべての部分 (ライブラリ、フレームワーク、依存関係など) とともにパッケージ化し、すべてを 1 つのパッケージとして出荷できます。 コンテナーを使用すると、カスタマイズされた設定や、アプリを実行しているコンピューターに以前にインストールされていたライブラリが、アプリのコードの記述とテストに使用されたマシンと異なる可能性がある場合でも、アプリが同じように実行されることが保証されます。 これにより、開発者は、コードが実行されるシステムの心配をすることなく、コードの記述に集中できます。

Docker コンテナーは仮想マシンに似ていますが、仮想オペレーティング システム全体を作成するわけではありません。 代わりに、Docker により、アプリが実行されているシステムと同じ Linux カーネルを使用することができます。 これにより、アプリ パッケージにはホスト コンピューター上にまだ存在しない部分だけが必要になるため、パッケージ サイズが減り、パフォーマンスを向上させることができます。

Kubernetes などのツールで Docker コンテナーを使用する、継続的な可用性が、コンテナーの人気のもう 1 つの理由です。 これにより、複数のバージョンのアプリ コンテナーを異なるタイミングで作成できます。 更新やメンテナンスのためにシステム全体を停止する必要がなく、各コンテナー (およびその特定のマイクロサービス) を臨機応変に置き換えることができます。 すべての更新プログラムが含まれた新しいコンテナーを準備し、運用環境用にコンテナーを設定して、新しいコンテナーの準備ができたら、それをポイントするだけです。 また、コンテナーを使用して異なるバージョンのアプリをアーカイブし、必要に応じて安全のフォールバックとしてそれらを実行し続けることもできます。

詳細については、「Docker コンテナーの概要」を参照してください。

前提条件

詳細については、「Windows で Docker Desktop をインストールするための Docker ドキュメントのシステム必要条件」を参照してください。

Windows Server に Docker をインストールする方法については、「はじめに: コンテナー用 Windows の準備」を参照してください。

Note

WSL は、WSL バージョン 1 または WSL 2 モードの両方でディストリビューションを実行できます。 これは PowerShell を開き、「wsl -l -v」と入力することによって確認できます。 次のように入力して、ディストリビューションが WSL 2 を使用するように設定されていることを確認します: wsl --set-version <distro> 2<distro> をディストリビューション名 (Ubuntu 18.04 など) に置き換えます。

WSL バージョン 1 では、Windows と Linux の基本的な違いにより、Docker エンジンは WSL 内で直接実行できませんでした。そのため、Docker チームは、Hyper-V VM と LinuxKit を使用して代替ソリューションを開発しました。 ただし、WSL 2 は、すべてのシステム コール能力を使用して Linux カーネルで実行されるようになったため、Docker を WSL 2 で完全に実行できます。 つまり、Linux コンテナーはエミュレーションなしでネイティブに実行できるため、Windows と Linux のツールのパフォーマンスと相互運用性が向上します。

Docker Desktop のインストール

Docker Desktop for Windows でサポートされている WSL 2 バックエンドを使用すると、コードの編集とデバッグに Visual Studio Code を使用し、Windows の Microsoft Edge ブラウザーでコンテナーを実行ながら、Linux ベースの開発環境で作業し、Linux ベースのコンテナーをビルドできます。

Docker をインストールするには (WSL のインストールを終えた後):

  1. Docker Desktop をダウンロードし、インストール手順に従います。

  2. インストールが完了したら、Windows の [スタート] メニューから Docker Desktop を起動し、タスク バーの非表示のアイコン メニューから Docker アイコンを選択します。 アイコンを右クリックして Docker コマンド メニューを表示し、[設定] を選択します。 Docker Desktop ダッシュボード アイコン

  3. [設定]>[全般] で、[Use the WSL 2 based engine]\(WSL 2 ベースのエンジンを使用する\) がオンになっていることを確認します。 Docker Desktop の全般設定

  4. [設定]>[リソース]>[WSL Integration]\(WSL 統合\) に移動して、Docker 統合を有効にするインストール済みの WSL 2 ディストリビューションから選択します。 Docker Desktop リソースの設定

  5. Docker がインストールされていることを確認するには、次のように入力して、WSL ディストリビューション (Ubuntu など) を開き、バージョンとビルド番号を表示します: docker --version

  6. 単純な組み込みの Docker イメージを実行して、インストールが正しく機能することをテストします。このとき、次を使用します。docker run hello-world

ヒント

いくつかの便利な Docker コマンドを次に示します。

  • docker を入力して、Docker CLI で使用できるコマンドを一覧表示します。
  • docker <COMMAND> --help を使用して、特定のコマンドの情報を一覧表示します。
  • docker image ls --all を使用して、お使いのマシン上の docker イメージを一覧表示します (この時点では hello world イメージのみ)。
  • docker container ls --all または docker ps -a を使用して、コンピューターのコンテナーを一覧表示します (-a show all フラグを指定しない場合は、実行中のコンテナーのみが表示されます)
  • docker info を使用して、WSL 2 コンテキストで使用可能な統計とリソース (CPU とメモリ) を含む、Docker のインストールに関するシステム全体の情報を一覧表示します。

VS Code を使用したリモート コンテナーでの開発

WSL 2 で Docker を使用してアプリの開発を開始するには、WSL、Dev コンテナー、Docker 拡張機能と共に VS Code を使用することをお勧めします。

  • VS Code WSL 拡張機能をインストールします。 この拡張機能を使用すると、VS Code の WSL で実行されている Linux プロジェクトを開くことができます (パスの問題、バイナリの互換性、またはその他の OS 間の課題について心配する必要はありません)。

  • VS Code Dev コンテナー拡張機能をインストールします。 この拡張機能を使用すると、コンテナー内のプロジェクト フォルダーまたはリポジトリを開くことができます。これにより、Visual Studio Code のすべての機能セットを利用して、コンテナー内で開発作業を行うことができます。

  • VS Code Docker 拡張機能をインストールします。 この拡張機能により、VS Code の内部からコンテナー化されたアプリケーションをビルド、管理、デプロイする機能が追加されます。 (実際に開発環境としてコンテナーを使用するには、Dev コンテナー拡張機能が必要です)。

Docker を使用して、既存のアプリ プロジェクトの開発コンテナーを作成しましょう。

  1. この例では、Python 開発環境設定ドキュメントに含まれている、Django 用の Hello World チュートリアルのソース コードを使用します。独自のプロジェクト ソース コードを使用する場合は、この手順を省略できます。 GitHub から HelloWorld-Django Web アプリをダウンロードするには、WSL ターミナル (Ubuntu など) を開き、次のように入力します。git clone https://github.com/mattwojo/helloworld-django.git

    Note

    コードは、ツールを使用しているのと同じファイル システムに常に格納します。 これにより、ファイル アクセスのパフォーマンスが向上します。 この例では、Linux ディストリビューション (Ubuntu) を使用して、WSL ファイル システム \\wsl\ にプロジェクト ファイルを格納します。 Windows ファイル システムにプロジェクト ファイルを格納すると、WSL の Linux ツールを使用してこれらのファイルにアクセスするときに、処理が大幅に遅くなります。

  2. WSL ターミナルから、このプロジェクトのソース コード フォルダーにディレクトリを変更します。

    cd helloworld-django
    
  3. 次のように入力して、ローカル WSL 拡張機能サーバーで実行されている VS Code でプロジェクトを開きます。

    code .
    

    VS Code インスタンスの左下隅にある緑色のリモート インジケーターを確認して、WSL Linux ディストリビューションに接続していることを確認します。

    VS Code の WSL リモート インジケーター

  4. VS Code コマンド パレット (Ctrl + Shift + P) から、WSL 拡張機能を使用して既に開いているフォルダーを使用しているため、「開発コンテナー: コンテナーで再度開く」と入力します。 別の方法として、「開発コンテナー: コンテナーでフォルダーを開く...」を使用して (Windows 側から) ローカルの \\wsl$ 共有を使用して WSL フォルダーを選択します。 詳細については、Visual Studio Code の「クイック スタート: コンテナー内の既存のフォルダーを開く」を参照してください。 入力を開始するときにこれらのコマンドが表示されない場合は、上記でリンクされている Dev Containers 拡張機能がインストールされていることを確認してください。

    VS Code Dev コンテナー コマンド

  5. コンテナー化するプロジェクト フォルダーを選択します。 ここでは、次のようになります。\\wsl\Ubuntu-20.04\home\mattwojo\repos\helloworld-django\

    VS Code Dev コンテナー フォルダー

  6. プロジェクト フォルダー (リポジトリ) に dev コンテナー構成がまだないため、コンテナー定義の一覧が表示されます。 表示されるコンテナー構成定義の一覧は、プロジェクトの種類に基づいてフィルター処理されます。 この例の Django プロジェクトの場合は、Python 3 を選択します。

    VS Code Dev コンテナーの構成定義

  7. VS Code の新しいインスタンスが開き、新しいイメージの構築が開始されます。ビルドが完了すると、コンテナーが開始されます。 新しい .devcontainer フォルダーが、Dockerfile および devcontainer.json ファイル内のコンテナー構成情報と共に表示されます。

    VS Code の .devcontainer フォルダー

  8. プロジェクトが引き続き WSL とコンテナー内の両方に接続されていることを確認するには、VS Code 統合ターミナル (Ctrl + Shift + ~) を開きます。 「uname」と入力してオペレーティング システムを確認し、「python3 --version」と入力して Python のバージョンを確認します。 uname が "Linux" として返されたので、WSL 2 エンジンにまだ接続していることを確認できます。Python のバージョン番号は、WSL ディストリビューションにインストールされている Python のバージョンとは異なる可能性のあるコンテナーの構成に基づきます。

  9. Visual Studio Code を使用してコンテナー内でアプリを実行およびデバッグするには、最初に [実行] メニューを開きます (Ctrl + Shift + D キーを押すか、左端のメニュー バーのタブを選択します)。 次に、[実行とデバッグ] を選択してデバッグ構成を選択し、プロジェクトに最適な構成を選択します (この例では "Django" になります)。 これにより、プロジェクトの .vscode フォルダーに launch.json ファイルが作成され、アプリを実行する手順が表示されます。

    VS Code の実行デバッグの構成

  10. VS Code 内から、[実行]>[デバッグの開始] を選択します (または F5 キーを押します)。 これにより VS Code 内のターミナルが開き、"http://127.0.0.1:8000/ で開発サーバーを起動しています。サーバーを終了するには、Ctrl + C を押します" という内容の結果が表示されます。Ctrl キーを押しながら、表示されるアドレスを選択して、既定の Web ブラウザーでアプリを開き、そのコンテナー内で実行されているプロジェクトを確認します。

    Docker コンテナーを実行している VS Code

これで、WSL 2 バックエンドを利用する Docker Desktop を使用してリモート開発コンテナーが正常に構成されました。このコンテナーで、VS Code を使用してコードの作成、ビルド、実行、デプロイ、デバッグなどを行えます。

トラブルシューティング

非推奨の WSL Docker コンテキスト

WSL 用 Docker の初期 Tech Preview を使用していた場合は、"wsl" という名前の Docker コンテキストが非推奨になり、使用されなくなった可能性があります。 次のコマンドを使用して確認できます: docker context ls。 この "wsl" コンテキストを削除すると、docker context rm wsl コマンドでエラーが発生しないようにすることができます。これは、Windows と WSL2 の両方に既定のコンテキストを使用するためです。

この非推奨の WSL コンテキストで発生する可能性のあるエラーには、docker wsl open //./pipe/docker_wsl: The system cannot find the file specified. または error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_wsl/v1.40/images/json?all=1: open //./pipe/docker_wsl: The system cannot find the file specified. が含まれます。

この問題の詳細については、Windows 10 で Windows System for Linux (WSL2) 内の Docker を設定する方法に関する説明を参照します。

Docker イメージ ストレージ フォルダーの検索に関する問題

Docker では、データを格納するために 2 つのディストリビューション フォルダーが作成されます。

  • \wsl$\docker-desktop
  • \wsl$\docker-desktop-data

これらのフォルダーを見つけるには、WSL Linux ディストリビューションを開き、「explorer.exe .」と入力して、Windows エクスプローラーでフォルダーを表示します。 \\wsl\<distro name>\mnt\wsl<distro name> を目的のディストリビューションの名前 (Ubuntu-20.04) に置き換えて入力し、これらのフォルダーを表示します。

WSL での Docker ストレージの場所の検索の詳細については、WSL リポジトリからの問題 またはこの StackOverflow の投稿を参照してください。

WSL の一般的なトラブルシューティングの問題の詳細については、トラブルシューティングに関するドキュメントを参照します。

その他のリソース