はじめに
Linuxとコンテナ技術の学習として、Windows 11上にDocker DesktopとWSL2を使った環境を用意し、Ubuntu 24.04コンテナを実行します。
今回は単にコンテナを起動するだけでなく、次の項目を検証します。
- WSL2とDocker Engineが正常に動作するか
- UbuntuコンテナにログインしてLinuxコマンドを実行できるか
- コンテナ停止・再起動でファイルが保持されるか
- コンテナ削除でファイルがどうなるか
- Docker Volumeを使用すると削除後もデータを保持できるか
検証日：2026年10月30日。Windows 11の実機でコマンドを実行して確認しました。掲載画像のうち図1〜7は保存した実行ログの抜粋を画像化したもので、端末のスクリーンショットではありません。Docker Desktopの画面は実際のスクリーンショットです。
検証環境
| 項目 | 使用環境 |
|---|---|
| ホストOS | Windows 11 Home（64-bit） |
| CPU | AMD Ryzen 7 5700X |
| メモリ | 64GB |
| 仮想化基盤 | WSL2 |
| コンテナ環境 | Docker Desktop（WSL2バックエンド） |
| Linuxイメージ |
ubuntu:24.04（Ubuntu 24.04.5 LTS） |
| 端末 | Windows PowerShell / Ubuntuコンテナ内のBash |
| WSLバージョン | 3.0.3.0（カーネル 6.18.54.1） |
| Dockerバージョン | Desktop 4.97.0 / Client・Engine 29.9.2 |
Windows 11 HomeではWSL2をバックエンドにLinuxコンテナを利用できます。Docker Desktopのインストール要件や使用条件はバージョンによって変わるため、最新の公式インストールガイドを確認します。
実機検証での実行方法とログについて
以下の本文は学習用の対話操作を説明しています。今回の実機検証では、ログを保存するため、最初のコンテナをdocker run -dit --name linux-study ubuntu:24.04 bashで起動し、コンテナ内のコマンドをdocker exec linux-study bash -c '...'で実行しました。本文の対話型Bashへの接続そのものを撮影した画像ではありません。
停止・再起動の実測はdocker stop linux-study、docker start linux-study、docker exec linux-study cat /work/test.txtの順で確認しました。停止時はタイムアウト後の強制終了によりExited (137)となりましたが、再起動後にファイルを読み出せました。本文のexitによる終了と実測の停止方法は異なります。
パッケージ導入の実測にはapt-get updateとapt-get install -y curlを使いました。curlは8.5.0でした。非対話実行に伴うdebconfのフロントエンド警告は出ましたが、インストールは完了しています。図4ではAPTの長い出力を省略し、省略を画像内に明記しています。
Volume検証ではdocker run --name linux-volume-test --mount type=volume,source=linux-data,target=/data ubuntu:24.04 bash -c 'echo "Persistent Data Test" > /data/test.txt; cat /data/test.txt'を実行しました。コンテナ終了後に削除し、本文と同じ一時コンテナから読み出しています。
使用したイメージのdigestは以下です。タグは更新されるため、後日同じタグを取得すると異なるイメージになる場合があります。
ubuntu@sha256:fe81560990fae86dc4743202b2cb4d3df98d0bcf949173cecef15ce1127ef852
Dockerコンテナと仮想マシンの違い
仮想マシン（VM）は一般にゲストOSのカーネルを個別に実行します。一方、LinuxコンテナはLinuxカーネルを共有しつつ、プロセスやファイルシステムなどを分離して実行します。
Windows上ではLinuxカーネルを直接利用できないため、今回の構成ではWSL2側でLinuxカーネルを動かし、その上でDockerがLinuxコンテナを管理します。「Ubuntuコンテナ」を作る操作は、Ubuntuの仮想マシンを1台新設することとは異なります。
Windows 11
└─ WSL2（Linuxカーネルを実行する基盤）
└─ Docker Engine（Docker Desktopから利用）
├─ Ubuntuコンテナ
└─ その他のLinuxコンテナ
1. WSL2を導入・確認する
まず、PowerShellでWSLの状態を確認します。
wsl --status
wsl --version
wsl -l -v
-
wsl --status：WSLの設定状態を確認 -
wsl --version：WSL本体とカーネルなどのバージョンを確認 -
wsl -l -v：インストール済みディストリビューションとWSL 1/2の区別を確認
WSL未導入の場合は、管理者として起動したPowerShellで次を実行します。
wsl --install --no-distribution
環境によっては再起動が必要です。ここでは--no-distributionを指定し、ユーザー用のUbuntuディストリビューションを追加せずにWSLを導入します。ただし、Docker DesktopのLinuxコンテナ実行だけが目的であれば、ユーザー用のUbuntuディストリビューションを別途用意する必要はありません。
必要に応じてWSLを更新します。
wsl --update
確認ポイント
- WSLコマンドが正常に実行できる
- WSL2が利用可能になっている
- Docker Desktopの要求するWSLバージョンを満たす
- タスクマネージャーのCPU画面で「仮想化：有効」を確認できる
図1：実機で取得したログの抜粋。端末画面の撮影ではなく、読みやすく画像化したものです。
2. Docker Desktopをインストールする
- Docker Desktop公式インストールページからWindows用インストーラーを取得します。
- インストールを実行し、利用可能な場合はWSL2バックエンドを選択します。
- Docker Desktopを起動して初期設定を完了します。
- 必要に応じて Settings → General でWSL2バックエンドを確認します（環境によっては選択項目が表示されない場合もあります）。
Docker Desktop起動後、PowerShellで次を実行します。
docker --version
docker info
docker --versionはDocker CLIのバージョン、docker infoは接続先のDocker Engineを含む情報を表示します。docker infoがEngineに接続できることを確認してください。
最後に公式の動作確認コンテナを起動します。
docker run --rm hello-world
期待される出力（一部）
Hello from Docker!
--rmは実行終了後にそのコンテナを自動削除するオプションです。
図2：実機で取得したログの抜粋。端末画面の撮影ではなく、読みやすく画像化したものです。
3. Ubuntu 24.04イメージを取得・コンテナを起動する
以降、コマンド実行場所を区別して説明します。
まずPowerShellでUbuntuイメージを取得します。
docker pull ubuntu:24.04
docker image ls
ubuntu:24.04が一覧に表示されれば、イメージの取得は完了です。
続いて、対話型のUbuntuコンテナを作成・起動します。
docker run -it --name linux-study ubuntu:24.04 bash
| オプション | 意味 |
|---|---|
run |
イメージからコンテナを新規作成・起動する |
-it |
標準入力と擬似端末を利用して対話操作する |
--name linux-study |
コンテナに名前を付ける |
ubuntu:24.04 |
使用するイメージ |
bash |
コンテナ内で起動するプロセス |
成功すると、次のようなBashプロンプトが表示されます。xxxxxxxxxxxxの部分は実際のコンテナIDなどにより異なります。
root@xxxxxxxxxxxx:/#
ここから先のコマンドはUbuntuコンテナ内（Bash）で実行します。
cat /etc/os-release
uname -a
hostname
whoami
確認ポイント
-
/etc/os-releaseにUbuntu 24.04に相当する情報が含まれる -
uname -aでLinuxカーネル情報が表示される -
hostnameでコンテナのホスト名が表示される -
whoamiで既定の実行ユーザーrootが表示される
図3：実機で取得したログの抜粋。端末画面の撮影ではなく、読みやすく画像化したものです。
4. Linux基本操作とパッケージ導入を検証する
Ubuntuコンテナ内（Bash）でディレクトリとファイルを作成します。
pwd
ls -la
mkdir -p /work
cd /work
echo "Docker Linux Test" > test.txt
cat test.txt
ls -l test.txt
期待される出力
Docker Linux Test
続いて、APTによるパッケージ管理を試します。
apt update
apt install -y curl
curl --version
確認ポイント
-
/work/test.txtを作成できた -
catで保存内容を読み出せた -
apt updateとapt installが成功した -
curl --versionでcurlのバージョンを確認できた
Ubuntuの公式コンテナイメージは最小構成です。通常のUbuntu Serverのように、SSHサーバーやsystemdによるサービス管理が初期状態で一通り用意されているわけではありません。
図4：実機で取得したログの抜粋。端末画面の撮影ではなく、読みやすく画像化したものです。
5. コンテナ停止・再起動後のデータを確認する
Ubuntuコンテナ内でBashを終了します。
exit
起動時のメインプロセスであるBashが終了するため、このコンテナも停止します。
PowerShellに戻り、停止状態を確認します。
docker ps -a
linux-studyの状態がExitedであることを確認します。
再び起動し、Bashに接続します。
docker start linux-study
docker exec -it linux-study bash
Ubuntuコンテナ内で、以前作成したファイルを読み込みます。
cat /work/test.txt
期待される出力
Docker Linux Test
この実験から、同じコンテナを停止・再起動するだけなら、そのコンテナ内で作成したファイルは保持されることがわかります。
図5：実機で取得したログの抜粋。端末画面の撮影ではなく、読みやすく画像化したものです。
6. コンテナ削除後にデータがどうなるかを検証する
次は新しいコンテナを作成した場合の違いを確認します。
Ubuntuコンテナ内（Bash）で次を実行して抜けます。
exit
PowerShellで先ほどのコンテナを削除します。
docker stop linux-study
docker rm linux-study
docker execで開いたBashを終了しても、メインプロセスは動作し続けます。そのため、docker stopで停止してから削除します。
次に同じUbuntuイメージから新しいコンテナを作成します。
docker run -it --name linux-study2 ubuntu:24.04 bash
Ubuntuコンテナ内（Bash）で以前のファイルを確認します。
ls /work/test.txt
期待される出力（例）
ls: cannot access '/work/test.txt': No such file or directory
コンテナが作成したファイルは、通常はコンテナ固有の書き込みレイヤーに保存されます。コンテナを削除するとそのレイヤーも失われるため、同じイメージから別のコンテナを作ってもファイルは引き継がれません。
図6：実機で取得したログの抜粋。端末画面の撮影ではなく、読みやすく画像化したものです。
ここでコンテナから退出します。
exit
7. Docker Volumeでデータ永続化を検証する
コンテナを削除してもデータを残したい場合は、Docker Volumeを使用できます。
まずPowerShellで名前付きVolumeを作成します。
docker volume create linux-data
docker volume ls
Volumeを/dataにマウントしてコンテナを起動します。
docker run -it --name linux-volume-test --mount type=volume,source=linux-data,target=/data ubuntu:24.04 bash
Ubuntuコンテナ内（Bash）でファイルを作成します。
echo "Persistent Data Test" > /data/test.txt
cat /data/test.txt
exit
PowerShellでコンテナを削除します。
docker rm linux-volume-test
別の一時コンテナに同じVolumeをマウントし、ファイルを読み出します。
docker run --rm --mount type=volume,source=linux-data,target=/data ubuntu:24.04 cat /data/test.txt
期待される出力
Persistent Data Test
コンテナは削除しても、名前付きVolume linux-dataは別途削除しない限り残ります。そのため、別のコンテナからもファイルを読み込めます。
| 操作 | 通常のコンテナ内ファイル | 名前付きVolume内のファイル |
|---|---|---|
| 停止・再起動 | 保持される | 保持される |
| 元のコンテナ削除 | 失われる | 保持される |
| 新しいコンテナから読み込む | 自動的には引き継がれない | 同じVolumeをマウントすれば読み込める |
※Volumeそのものを削除した場合は、この永続化の対象外です。
図7：実機で取得したログの抜粋。端末画面の撮影ではなく、読みやすく画像化したものです。
Docker Desktopの実際の管理画面です。左下のEngine runningと、検証で作成したlinux-study2を確認できます。
8. 検証環境の後片付け
以下は任意の後片付け手順です。今回は追加確認に使えるよう、停止済みのlinux-study2と名前付きVolume linux-dataを残しています。以下は検証用の名前に限定した削除コマンドです。必要なデータを保存してから実行してください。
PowerShell
docker rm linux-study2
docker volume rm linux-data
docker ps -a
docker volume ls
Ubuntuイメージubuntu:24.04は次の学習で再利用できるため、今回は残します。
9. よくあるトラブルと確認方法
dockerコマンドでEngineに接続できない
Docker Desktopが起動しているか確認します。また、Linuxコンテナ用のバックエンドが有効か確認します。
docker info
今回発生した導入時のエラーと対処
WSLの導入では、最初に管理者権限不足（0x80073d28）で失敗しました。管理者としてPowerShellを開いて導入を進め、その後のWindows再起動でWSL2が利用可能になりました。導入完了後も、再起動して利用できる状態になったことを確認する必要がありました。
wsl関連のエラーが出る
WSLと仮想化の状態を確認します。
wsl --status
wsl --version
wsl --update
必要に応じてWindowsを再起動します。BIOS/UEFIの仮想化設定が有効かも確認対象です。
Conflict. The container name ... is already in useと表示される
同名のコンテナが残っています。
docker ps -a
既存コンテナを再利用するか、名前を変えて新規作成します。削除する際は中のデータが不要であることを確認してください。
イメージ取得に失敗する
インターネット接続、プロキシやDNS設定、Docker Hubへのアクセス可否を確認します。エラー本文と発生コマンドを記録しておくと、記事のトラブルシューティングに役立ちます。
10. まとめ
実機検証で確認した結果を整理します。
| 検証内容 | 実機確認結果 |
|---|---|
| WSL2が正常に動作する | 確認済み |
| DockerからHello Worldを起動できる | 確認済み |
| Ubuntu 24.04コンテナを起動できる | 確認済み |
| コンテナ内でLinuxコマンドを実行できる | 確認済み |
| 同じコンテナの停止・再起動後もファイルが残る | 確認済み |
| 新規コンテナに元の書き込みデータは引き継がれない | 確認済み |
| Docker Volumeによってデータを永続化できる | 確認済み |
Dockerの基本として、イメージはコンテナの元になるもの、コンテナはそこから作成される実行環境、Volumeはコンテナとは別のライフサイクルでデータを保持する仕組みであることを学べます。
次回はNginxコンテナを利用したWebサーバーの起動、ポートマッピング、WindowsのブラウザからのHTTPアクセスを検証したいと考えています。