Python | テスト・設計・品質：Docker

Python Python
スポンサーリンク

Dockerって何？一言でいうと「どこでも同じように動く“持ち運べる開発環境”」

Docker は、ざっくり言うと「アプリとその周りの環境を、ひとまとめにして箱に入れて持ち運べるようにする仕組み」です。

Python でよくある悩みとして、

自分のPCでは動くのに、他の人のPCでは動かない
ローカルではテストが通るのに、本番サーバーでは落ちる
Python のバージョンやライブラリのバージョンが人によって違う

みたいな「環境差」があります。

Docker を使うと、

Python のバージョン
インストールされているライブラリ
OS の種類

を含めて「この箱の中ではこういう環境です」と固定できるので、
「どこでも同じように動く」状態に近づけられます。

テスト・設計・品質の観点で言うと、
「環境のせいで壊れる」を減らすための強力な道具です。

Dockerの基本概念をPython目線でかみ砕く

イメージとコンテナ

Docker には「イメージ」と「コンテナ」という2つのキーワードがあります。

イメージは、「アプリと環境をひとまとめにした設計図」です。
Python のバージョン、必要なライブラリ、アプリのコードなどを全部詰め込んだ“ひとかたまり”。

コンテナは、そのイメージを実際に動かした「実行中の箱」です。
同じイメージから、何個でもコンテナを起動できます。

Python で言うと、

イメージ = 仮想環境＋コードを固めたもの
コンテナ = その仮想環境を実際に起動したプロセス

くらいのイメージでOKです。

Dockerfile

Dockerfile は、「このイメージをこうやって作ってね」と書くレシピです。

Python プロジェクトなら、だいたいこんなことを書きます。

どの Python ベースイメージを使うか
依存ライブラリをどうインストールするか
アプリをどこに置くか
起動コマンドは何か

このレシピから、docker build でイメージを作り、
docker run でコンテナを起動します。

具体例：シンプルなPythonアプリをDockerで動かしてみるイメージ

まずは普通のPythonスクリプト

例えば、こんな app.py があるとします。

def main() -> None:
    print("Hello from Docker!")

if __name__ == "__main__":
    main()
Python

ローカルでは、こう動かします。

python app.py

これを Docker で動かすために、Dockerfile を用意します。

Dockerfileの最小例

# どのPythonを使うか
FROM python:3.12-slim

# 作業ディレクトリ
WORKDIR /app

# コードをコンテナ内にコピー
COPY app.py .

# コンテナ起動時に実行するコマンド
CMD ["python", "app.py"]
Dockerfile

この Dockerfile からイメージを作ります。

docker build -t my-python-app .

そしてコンテナを起動します。

docker run --rm my-python-app

コンソールに

Hello from Docker!

と出れば成功です。

ここで重要なのは、「どのマシンで docker run しても、同じ結果になる」ということです。
Python のバージョンやインストール状況に依存しません。

テスト・品質の観点でDockerが効いてくるポイント

「本番と同じ環境でテストできる」

よくある事故として、

ローカルでは SQLite、本番では PostgreSQL
ローカルでは Python 3.12、本番では 3.10

みたいな差が原因で、本番だけバグる、というものがあります。

Docker を使うと、

テスト用コンテナ
本番用コンテナ

を同じ Dockerfile から作れるので、
「環境差」がかなり小さくなります。

例えば、FastAPI + PostgreSQL のアプリなら、

アプリ用コンテナ（Python）
DB用コンテナ（PostgreSQL）

を docker compose でまとめて起動し、
ローカルでも CI でも本番でも、同じ構成で動かせます。

CI / CD と組み合わせると「どこでも同じコンテナ」が動く

GitHub Actions で CI を回すときも、
Docker イメージをビルドしてテストを実行するようにしておけば、

ローカル
CI
ステージング
本番

のすべてで「同じイメージ」が動きます。

これは品質的にかなり強いです。

「本番だけ壊れる」を減らせる
「再現できないバグ」を減らせる

という意味で、Docker はテスト・品質の土台を固める道具と言えます。

もう少し実戦寄りの例：テストをDockerの中で回す

pytestをコンテナの中で実行する

例えば、src/ と tests/ を持つプロジェクトを Docker 化して、
コンテナの中で pytest を回すイメージを見てみます。

プロジェクト構成はこんな感じだとします。

myapp/
  pyproject.toml
  src/
    myapp/
      __init__.py
      core.py
  tests/
    test_core.py
  Dockerfile

Dockerfile はこう書けます。

FROM python:3.12-slim

WORKDIR /app

# 依存ファイルを先にコピーしてインストール
COPY pyproject.toml .
RUN pip install -U pip && pip install .[dev]

# 残りのコードをコピー
COPY src/ src/
COPY tests/ tests/

# デフォルトはテストを実行
CMD ["pytest"]
Dockerfile

このイメージをビルドして実行すると、
コンテナの中で pytest が走ります。

docker build -t myapp-test .
docker run --rm myapp-test

これで、

「このイメージをどこで動かしても、同じテストが同じように走る」

状態になります。

CI でも本番前チェックでも、
このイメージを使い回せます。

設計の観点：Dockerを前提にすると「環境依存コード」を減らせる

環境変数で設定を切り替える前提になる

Docker を使うときは、
設定値を環境変数で渡すのが定番です。

例えば、DB の URL をこう書きます。

import os

DATABASE_URL = os.environ["DATABASE_URL"]
Python

Docker では、起動時にこう渡します。

docker run -e DATABASE_URL=postgresql://... myapp

これを前提に設計しておくと、

ローカル
テスト環境
本番

で「コードは同じ、設定だけ違う」という状態を作りやすくなります。

これは、テスト・品質の観点でとても重要です。

コードに if 本番なら: ... みたいな分岐を書かなくて済むので、
テストすべきパターンが減り、バグも減ります。

「再現性のあるバグ報告」がしやすくなる

Docker イメージがあると、

「このイメージを docker run するとバグが再現します」

という形でバグ報告ができます。

開発者は、そのイメージを手元で動かして、
まったく同じ環境で調査できます。

これは、チーム開発や運用フェーズでかなり効いてきます。

初心者がDockerを学ぶときの現実的なステップ

ステップ1：まずは「Hello from Docker」レベルを一度やる

さっきの app.py と簡単な Dockerfile を使って、

docker build
docker run

を一度通してみるのがおすすめです。

ここで、

イメージを作る
コンテナを起動する

という感覚を体で覚える。

ステップ2：次に「自分の小さなPythonプロジェクト」をDocker化してみる

例えば、簡単な CLI ツールや小さな FastAPI アプリを、
Docker で動かしてみます。

ローカルで動いているものを、
Docker の中でも同じように動かせるようにする。

ここで「環境を箱に閉じ込める」感覚が掴めてきます。

ステップ3：テストをDockerの中で回すところまで行けると一気に世界が変わる

pytest を Docker の中で回せるようになると、

「このイメージを CI でも本番前チェックでも使い回す」

という世界に入れます。

ここまで行くと、
Docker は単なる「流行りの技術」ではなく、
テスト・設計・品質の土台として見えてくるはずです。

まとめ（Dockerは「環境差で壊れないようにするための、持ち運べる開発・実行箱」）

初心者目線で整理すると、Docker はこういうものです。

Python のバージョンやライブラリ、OS まで含めて「この箱の中ではこう動く」と固定できるので、「自分のPCでは動くのに他では動かない」を減らせる。
Dockerfile でイメージ（設計図）を作り、そのイメージからコンテナ（実行中の箱）を起動する、というシンプルな流れさえ掴めば、テストも本番も「同じ環境」で動かせるようになる。
テストをコンテナの中で回し、設定を環境変数で切り替える前提で設計すると、CI / CD とも自然につながり、「環境のせいで品質がブレる」リスクを大きく下げられる。

スポンサーリンク
タイトルとURLをコピーしました