Windows+WSL2+Docker+VSCODEで使い捨て開発環境を構築するまで～後編～

1.背景

プログラミング学習を進める中で、PythonやNodeなどのライブラリやツールをローカル環境に導入するたび、煩雑なバージョン管理に悩まされることが多々ありました。バージョン管理ツールの導入も検討しましたが、試しに触れる程度の言語にそこまで手間をかけるのは少し気が進まないというジレンマがあり、モヤモヤしていました。

そのため本記事（および、後編）では、Windows上でLinux環境(WSL)を使い、その上にDockerコンテナを立ち上げ、試したいツールを気軽にインストールする方法を実践してみました。さらに、コンテナ操作をVSCodeでできるようにします。これによりうまくいかなくても、不要になったらそのままコンテナごと捨てられるという使い捨て環境できるあがります。

図：使い捨て開発環境のイメージ図

2.今回記事のゴール

後編である今回は、VSCodeを使って使い捨て環境用のコンテナ（pythonインストール済）を用意して、その中でコーディングを実行するまでを記載します。(WSL2・Dockerの導入などが書かれた前編記事はコチラ)

3.実施した環境

"★"は、前編の手順で導入されたもの
"☆"は、手順を実施した結果インストールしたもの

3-1.ローカルPC

# OS
OS:                     Microsoft Windows 11 Pro
OS バージョン:           10.0.22621 N/A ビルド 22621
# パワーシェル
PS Version:             5.1.22621.4249

# Docker関連
Docker Version ★:         27.3.1
Docker Compose version ★: 2.29.7

# VSCode関連
本体　☆:                   1.96.2
拡張機能 WSL☆
拡張機能 Dev Containers☆
拡張機能 Docker☆

3-2.WSL2(Dockerコンテナを実際に稼働させる母艦になるLinux)

OS ★:                     Ubuntu 24.04.1 LTS
Docker Version ★:         27.3.1
docker-compose version ★: 1.29.2, build unknown

3-3.作った使い捨て環境（コンテナ）

OS ★:                     Debian GNU/Linux 12 (bookworm)
Python ★:3.13.0

4.環境構築手順（インストール）

4-1.前提

• 前編の作業が完了していること

4-2.VSCodeのインストール@ ローカルPC

公式サイトよりダウンロード
https://code.visualstudio.com/

必要に応じて日本語化を実施してください。

4-3.VSCodeのプラグインをインストール@ ローカルPC

マーケットプレイスより、以下のプラグインをインストールしてください。

• WSL
• Dev Containers
• Docker

5.環境構築手順（コンテナ準備）

ここまでで各種必要なソフトウェアはインストールが済みました。ここでは実際にローカルPCに影響しないPython環境（コンテナ）を準備します。

5-1.VSCodeでWSLに接続する

5-2.WSL内のUbuntuにもプライグインを導入する

Docker拡張機能が正常に動作するためには、追加でWSL内のUbuntu環境に拡張機能をインストールする必要があります。WSL接続の初回時にプラグインを見ると警告マークがでていると思うのでインストールを実施してください。

5-2.WLSにフォルダを作成

ここでは試しに/home/${USER_NAME}/testという名称でフォルダを作成しています

私のWSL内のユーザ名がworkにしたのでここは適宜読み替えてください。

5-3.WSLにファイル作成

testフォルダ配下に1つのサブフォルダ及び、２つのファイルを作成します。これらのファイルが使い捨て環境（コンテナ）の設計図となります。

\\wsl$\Ubuntu-20.04\home\${USER}
　└test
　　├docker-compose.yml
　　└.devcontainer
　　　└devcontainer.json

docker-compose.yml

version: '3'
services:
  dev-container:
    image: python:latest
    tty: true

.devcontainer/devcontainer.json

{
  "name": "container",
  "dockerComposeFile": [
    "../docker-compose.yml"
  ],
  "service": "dev-container",
  "workspaceFolder": "/home/"
}

VSCodeだと以下のように見えます。

用語説明

• .devcontainer/devcontainer.json
  VS Code のプラグイン「Remote - Containers」機能が読み取るファイルです。
  今回の場合は、testフォルダ配下の docker-compose.yml を読み取り、docker-composeと連携して使い捨て環境（コンテナ）を起動します。

• docker-compose.yml
  アプリケーション運用や複数のコンテナを一元管理・起動するためのdocker compose用のファイルです。
  今回の用に1つのコンテナの起動ではあまり有益ではないですが勉強もかねてこちらにしてます。
  例：アプリ (app) コンテナと DB (db) コンテナを定義しネットワークも定義、一括起動

前編と、4.環境構築手順（インストール）と5.環境構築手順（コンテナ準備）で使い捨て開発環境の構築は完了です。お疲れ様でした。この後のセクション6では、実際の起動手順となります。

6.使い捨て環境（コンテナ）の利用手順

6-1.VSCodeを起動し、WSLに接続する

6-2.使い捨て環境用のtestフォルダを開く

\\wsl$\Ubuntu-20.04\home\${USER}\testをVSCodeで開くと、プラグインがdevcontainer.jsonを検知して、下記のポップアップが表示されます。

6-3.使い捨て環境に入ってみる（コンテナにアタッチ）

ポップアップで「Reopen in Container」をクリックすると、VSCodeが自動的にコンテナを起動し、その中にアタッチします。この操作によって、ローカル環境に影響を与えずに、コンテナ内で作業が可能になります。

アタッチが成功すると、VSCodeの左下に「Dev Container: container」と表示されます。この状態になれば、コンテナ内での作業が可能です。

6-4.実際に使い捨て環境でpythonコードを書いて実行してみる

コンテナ内のワークスペースで、pipを使ってPythonライブラリをインストールし、その動作を確認してみます。ここでは例として、requestsライブラリをインストールして簡単なHTTPリクエストを実行します。

まず、ターミナルを開き以下のコマンドでrequestsをインストールします。

pip install requests

成功すると、GitHub APIから取得したデータがターミナルに表示されます。このように、使い捨て環境内では自由にライブラリをインストールし試すことができます。
コンテナ内のお好きな場所をVSCodeで開き、「sample.py」という名前で以下のようなPythonコードを記述し、実行してみます。

sample.py

import requests

response = requests.get("https://api.github.com")
if response.status_code == 200:
    print("GitHub API is accessible!")
    print("Response:", response.json())
else:
    print("Failed to access GitHub API.")

実行結果が以下のようになればrequestライブラリおよびsample.pyの動作確認が完了です。

root@1dc8056a3a95:/usr/src# python sample.py 
GitHub API is accessible!
Response: {'current_user_url': 'https://api.github.com/user', 'current_user_authorizations_html_url': 'https://github.com/settings/connections/applications{/client_id}', 'authorizations_url': 'https://api.github.com/authorizations', 'code_search_url': 'https://api.github.com/search/code?q={query}{&page,per_page,sort,order}', 'commit_search_url': 'https://api.github.com/search/commits?q={query}{&page,per_page,sort,order}', 'emails_url': 'https://api.github.com/user/emails', 'emojis_url': 'https://api.github.com/emojis', 'events_url': 'https://api.github.com/events', 'feeds_url': 'https://api.github.com/feeds', 'followers_url': 'https://api.github.com/user/followers', 'following_url': 'https://api.github.com/user/following{/target}', 'gists_url': 'https://api.github.com/gists{/gist_id}', 'hub_url': 'https://api.github.com/hub', 'issue_search_url': 'https://api.github.com/search/issues?q={query}{&page,per_page,sort,order}', 'issues_url': 'https://api.github.com/issues', 'keys_url': 'https://api.github.com/user/keys', 'label_search_url': 'https://api.github.com/search/labels?q={query}&repository_id={repository_id}{&page,per_page}', 'notifications_url': 'https://api.github.com/notifications', 'organization_url': 'https://api.github.com/orgs/{org}', 'organization_repositories_url': 'https://api.github.com/orgs/{org}/repos{?type,page,per_page,sort}', 'organization_teams_url': 'https://api.github.com/orgs/{org}/teams', 'public_gists_url': 'https://api.github.com/gists/public', 'rate_limit_url': 'https://api.github.com/rate_limit', 'repository_url': 'https://api.github.com/repos/{owner}/{repo}', 'repository_search_url': 'https://api.github.com/search/repositories?q={query}{&page,per_page,sort,order}', 'current_user_repositories_url': 'https://api.github.com/user/repos{?type,page,per_page,sort}', 'starred_url': 'https://api.github.com/user/starred{/owner}{/repo}', 'starred_gists_url': 'https://api.github.com/gists/starred', 'topic_search_url': 'https://api.github.com/search/topics?q={query}{&page,per_page}', 'user_url': 'https://api.github.com/users/{user}', 'user_organizations_url': 'https://api.github.com/user/orgs', 'user_repositories_url': 'https://api.github.com/users/{user}/repos{?type,page,per_page,sort}', 'user_search_url': 'https://api.github.com/search/users?q={query}{&page,per_page,sort,order}'}
root@1dc8056a3a95:/usr/src# 

7.使い捨て環境(コンテナ）を破棄する

使い捨て環境は一時的に試すためのものなので、不要になったら破棄しましょう。WSL内のUbuntuで以下のコマンドで簡単に削除できます。

警告
ただし、コンテナを停止（down）するとコンテナ内の環境（例: sample.pyファイル）はすべて消えてしまいます。再度、sample利用する場合は、バックアップを取ってない場合は、ゼロからコーディングする必要が生じます。これを防ぐために、コンテナの作業フォルダをWSL内のホスト側ディレクトリにマウントしておくとよいでしょう。

VSCodeをWSLに接続した状態で、testフォルダを開き、ターミナルを開く。

docker-compose down

まとめ

本記事では、WSLとDockerを使用した使い捨て開発環境の構築から運用、破棄までを解説しました。この環境を使えば、ローカルPC環境に手を加えることなく、自由にツールやライブラリを試すことができます。（今回の例だとpythonのrequestライブラリを試すことができました。）また、不要になれば簡単に削除できるため、気軽に新しい技術や言語を学ぶ際の障壁を下げることができるかなと思います。少しでも皆さんの役に立てば幸いです。