Docker コンテナ

Docker コンテナは、Docker イメージから起動され、マシンの他の部分から隔離されたプロセスです。独自のファイルシステム、ネットワークインターフェース、プロセス一覧を持ちますが、ホストのカーネルは共有します。イメージは読み取り専用のテンプレート（OS のベースレイヤー、ランタイム、アプリ）で、コンテナはその実行中のインスタンスです。1 つのイメージから多数のコンテナを起動でき、用が済んだら破棄できます。

具体例

ローカルでのテスト実行用に、使い捨ての Selenium Chrome ノードと Postgres データベースを起動します。

docker run --rm -d --name chrome -p 4444:4444 --shm-size=2g selenium/standalone-chrome:latest
docker run --rm -d --name db -p 5432:5432 -e POSTGRES_PASSWORD=test postgres:16-alpine

docker ps          # list running containers
docker logs db     # read a container's output
docker stop chrome db

--rm は停止時にコンテナを削除し、-d はバックグラウンドで実行し、-p host:container はポートを公開します。実際のプロジェクトでは latest ではなくイメージのタグを固定し（たとえば postgres:16.4-alpine）、上流の新しいリリースによってテスト環境が一夜にして変わらないようにします。

テスターがコンテナを使う理由

• 再現可能な環境。 すべてのノート PC と CI ランナーで同じイメージが動くため、「自分のマシンでは動く」という類の失敗がまとめてなくなります。
• 使い捨ての依存先。 テスト実行ごとに新しいデータベースを使えば、前日の実行のデータが残りません。
• ブラウザの並列実行。 Selenium Grid とブラウザイメージを使えば、コマンド 1 つでノードを増減できます。
• テストスイート自体の実行。 Playwright はブラウザとシステムライブラリがプリインストールされた公式イメージを公開しており、CI エージェントでの依存関係不足のエラーを避けられます。

仮想マシンとの違い

VM は独自のカーネルを持つマシン全体をエミュレートするため、重く起動も遅くなります。コンテナはホストのカーネルを共有し、数秒で起動し、メモリ使用量もはるかに少なくて済みます。その代わり隔離は弱くなりますが、これはセキュリティ境界では問題になっても、テスト環境ではほとんど問題になりません。

よくある間違い

コンテナ内にテストデータを保存して再起動後も残ると期待する（ボリュームを使います）、latest タグを使う、ブラウザコンテナで --shm-size を指定し忘れて負荷時に Chrome がクラッシュする、といったものです。