🐳学習105時間のトラックドライバーがFlaskアプリをDocker化した話

26.7.8 - 更新(実際書いたコード追加)
「④実際に書いたDockerfile…」セクション参照)

はじめに🐳

物流現場で7年働く現役トラックドライバーが、独学でPythonを学びWebエンジニアへの転身を目指しています。
テキストは一切使用せず、AIとの対話のみでFlaskアプリを2本開発（"🕊️Puoppo"・"🥪sales_data_app"）。
独学105時間目で自分が作ったシステム2つをDocker化し、環境に左右されず誰にでも共有できる状態にした話をシェアします。※6/30時点

---

---

①なぜDocker化したか

前回の記事で、自分のFlaskコードの「積載ミス」を9つ見つけて直した。
「だろうコード」を潰して、変なデータが来ても、設定が漏れていても、システムが自分で自分を守るようになった。

それでも一つだけ、最後まで残っていた課題がある。

「自分のPCでしか動かない」という問題だ。

Pythonのバージョン違い、PostgreSQLの接続設定のズレ。別の環境に持っていった瞬間に「自分のPCでは動いたのに」というトラブルが起きる。
これも結局、「だろう運転の隙」と同じ構造だった。

「この環境でも動くだろう」が、一番危ない。

---

②Dockerとは？🐳

Dockerが何なのか、最初はピンと来なかった。物流目線でも難しい、でも筆者の趣味の例で考えたら腹に落ちた。

2-1. 🏎️ミニ四駆の「初心者セット」🏁
初心者セットは、シャーシ・モーター・ギア・タイヤが全部1箱に揃っている。誰が買っても、同じパーツが同じ組み合わせで手元に来る。
それに合わせて電池やジュニアサーキットも加えれば、まさにDockerそのものだ。

2-2. 🍱コンテナ入りの冷凍食品🍽️
冷凍食品は、容器の中に具材も調味料も全部入っている。レンジで温めるだけで、誰がやっても同じ味が再現できる。

Dockerも同じだ。 Python・Flask・PostgreSQL・必要なライブラリを1つのコンテナに丸ごと詰める。 コマンド1つで、誰の手元でも全く同じ環境が立ち上がる。

「自分のPC専用のシステム」 から**「どこにでも出荷できるプロ仕様のプロダクト」** へ。

---

③実際にやってみたら、拍子抜けするほどスムーズだった

身構えていた。

Docker化は未経験。「絶対どこかでハマる」 と思っていた。
ところが、実際にやってみると詰まる場所がほとんどなかった。

なぜこんなにスムーズだったのか、後から振り返って理由を考えてみた。

---

理由１：積載ミス対策がそのまま効いた
前回直した「環境変数の事前チェック（Fail-Fast）」が、Dockerコンテナ内でもそのまま機能した。設定漏れがあれば起動時に即停止する仕組みを先に作っておいたから、コンテナ化後も迷う場所がなかった。

理由２：不要な荷物を先に降ろしていた
古いExcel処理、使われていないファイル、新旧混在のライブラリ。前回の見直しでこれらを全部削除していたから、コンテナに積み込む荷物自体が最初から少なかった。積む前の整理がそのまま効いた。

理由３：「だろう」を消す癖がついていた
「動くだろう」で進めず、一つひとつ「本当にこの設定で動くか」を確認しながら積み上げた。現場の「かもしれない運転」がそのまま作業の進め方になっていた。

身構えていたほど大きな壁は来なかった。地味な積み重ねが、ちゃんと効いていたということだと思う。

---

④実際に書いたDockerfileとdocker-compose.yml

「拍子抜けするほどスムーズだった」と言っても、それを裏付ける中身がないと説得力に欠ける。
実際に書いたコードを置いておく。

4-1.sales_data_appのDockerfile

# 1. ベースとなる環境に Python 3.12 を指定（軽量な slim 版を採用してリソースを最適化）
FROM python:3.12-slim

# 2. コンテナ内の作業ディレクトリ（部屋）を決める
WORKDIR /app

# 3. 依存ライブラリのリストを先にコンテナ内にコピー
COPY requirements.txt .

# 4. コンテナ内で pip インストールを実行（キャッシュを使わず軽量化）
RUN pip install --no-cache-dir -r requirements.txt

# 5. アプリの全ファイルをコンテナ内にコピー
COPY . .

# 6. Flaskが外部からの接続を受け付けられるようにポート5000を開放
EXPOSE 5000

# 7. コンテナ起動時に Flask アプリを実行するコマンド
CMD ["python", "app.py"]

4-2.puoppoのDockerfile

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 5000
CMD ["python", "app.py"]

見比べると分かる通り、違うのはベースイメージのPythonバージョンだけ。あとの構造は丸ごと使い回した。

「一度型を作れば、2本目は知識の使い回しで一気に終わる」というのは、この2つを並べて初めて伝わる話だと思う。

---

4-3.DB接続まわり：sales_data_appのdocker-compose.yml

sales_data_appはPostgreSQLを使っているので、Dockerfile単体では完結しない。DB用のコンテナを別に立てて繋ぐ必要があった。

services:
  web:
    build: .
    ports:
      - "5000:5000"
    env_file:
      - .env
    environment:
      - DATABASE_URL=postgresql://postgres:postgres@db:5432/sales_db
    volumes:
      - ./:/app
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=sales_db
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

volumes:
  postgres_data:

ここで一番効いたのは depends_on の condition: service_healthy だと思っている。

普通にdepends_on: dbとだけ書くと、「dbコンテナが起動し始めた」時点でwebコンテナが接続をしにいってしまい、PostgreSQL側の準備が間に合わずにエラーになることがある。

healthcheckでpg_isreadyを待ってから起動する形にしたことで、**「DBの準備ができてから接続する」**という順序を保証できた。

これは前回の記事で直した「環境変数のFail-Fastチェック」と同じ発想だと思う。コード側だけでなく、コンテナの起動順序にも「だろう」を残さない。そこまでやって初めて、環境差のトラブルから解放された。

---

4-4.実行コマンド：2つのアプリで手順が違った理由

同じ「Docker化」でも、sales_data_appとpuoppoでは実行コマンドが違う。理由はDB構成の違いにある。

sales_data_app（PostgreSQLと連携するため、複数コンテナが必要）

docker compose up --build

このコマンド1つで、web・db2つのコンテナが同時に立ち上がる。docker-compose.ymlに定義した構成をまとめて解釈してくれるので、複数コンテナの起動順序やネットワーク接続を個別に指定する必要がない。

puoppo（SQLiteのみで完結するため、単体コンテナで十分）

docker build -t puoppo-app .
docker run -p 5000:5000 --env-file .env puoppo-app

puoppoは外部のDBコンテナと繋ぐ必要がないため、docker-compose.ymlを作らず、build→runの2ステップで済んだ。

構成が違えば、必要なコマンドも変わる。
DBを複数コンテナで連携させるか、単体で完結させるか。この設計判断が、そのままコマンドの数に表れた形になる。

⑤もう一本のアプリも、同じ要領でDocker化した

sales_data_app のDocker化は初めてだったので 3時間 かかったが、同じ要領で puoppo をDocker化したら 1時間 で完了した。
READMEに体験方法を記載しているので、気になる方はそちらもどうぞ。

🥪sales_data_appのGitHubはこちら👈

🕊️puoppo_appのGitHubはこちら👈

一度型を作れば、2本目は知識の使い回しで一気に終わる。再現性が出るということだと思う。

---

⑥直して変わったこと

「自分のPCでしか動かない」 が消えた。

コマンド1つで、誰の手元でも同じ環境が立ち上がる。
Pythonのバージョン差、ライブラリの入れ忘れ、設定漏れ。環境差で起きるトラブルから解放された。

「動けばヨシ！☝️」から
「誰の環境でも同じように動く🐳」へ。

---

⑦次にやること

環境差は無くなった。でも、それは「Dockerが分かる人」が再現できる状態に過ぎない。
READMEに手順を書いても、cloneしてビルドして…という工程を踏める人にしか、結局アプリは届かない。
次の課題は、URLをクリックするだけで 「分からない人」でも触れる状態 を作ることだと思っている。
本番デプロイ、将来的にはCI/CDも視野に。それが次のステップになる。

sales_data_app 整備記録シリーズ

「本番出走前・車検三部作」

🚚「出走後メンテナンスシリーズ」

🍞