はじめに🐳
Python学習累計 113時間 の現役トラックドライバーが、Flaskアプリの本番運用に向けて取り組んできた記録です。これまで、 Docker化 ・データ永続化 ・ネットワーク名前解決 ・ログ設計 と、ローカル環境の中で地道な検証を重ねてきました。
そして今回、ついに2つのアプリケーションを 本番環境(Render)へデプロイ し、GitHubへのpushだけで 自動的にビルド・公開 が行われる CI/CDパイプラインを構築 しました。
以下のURLから、実際にブラウザ経由でシステムに触れることができます。
🍞 ベーカリー売上管理システム(Flask + PostgreSQL)
https://bakery-salesdata.onrender.com/
🕊 puoppo世論分析システム(Flask + SQLite + RSS + Gemini API)
https://puoppo.onrender.com/
⚠️ アクセス時の注意
上記は無料プラン で運用しているため、しばらく間隔を空けてアクセスした場合、サーバーがスリープ状態から起動する関係で、一時的に黒い画面に白文字の起動ログ が表示されることがあります。
そのまま少し待っていただければ、画面が切り替わりアプリが表示されます。
(起動にかかる時間は使用環境によって変わるため、ここでは具体的な秒数は記載していません)。
本記事では、この自動デプロイ環境を構築する過程で実際に発生した事象を、誇張や脚色を排除し、事実ベースで記録します。
📦 1. 本番デプロイが円滑だった背景 ―― 事前検証というローカルでの下準備
今回のRenderへのデプロイ自体は、大きなトラブルなく完了しました。
その要因は、7月1日に投稿した2本の記事で扱った以下の検証を、デプロイ以前にローカル環境で終えていたことにあります。
- Docker Volumeによるデータ永続化の実機検証
- コンテナ間ネットワーク名前解決の実機検証
-
loggingモジュールによる標準出力ログの設計
これらの検証を通じて、 「コンテナはどう扱えば消えても問題ないか」「エラー発生時に何を手がかりに原因を特定するか」 という土台が、デプロイ作業に入る前の時点ですでに固まっていました。
結果として、Render側での作業は、環境変数の設定とリポジトリの連携という手順に集中でき、想定外の挙動に振り回される場面は最小限で済みました。
🚧 2. 1行目で止まった出荷ライン ―― ModuleNotFoundErrorとの遭遇
bakery_salesdataのデプロイは前章の通り大きな問題なく完了した一方、puoppoのRenderへのデプロイでは、事前検証を済ませていたにもかかわらず、 ビルド直後に処理が停止する事象 が発生しました。
出力されたエラーログ(事実)
Traceback (most recent call last):
File "/app/app.py", line 1, in <module>
from dotenv import load_dotenv
ModuleNotFoundError: No module named 'dotenv'
==> Exited with status 1 while running your code.
原因の特定
puoppoはGemini API連携のため、GEMINI_API_KEYを.envから読み込む目的でpython-dotenvを使用していました。しかし、このdotenvパッケージがrequirements.txtに記載されていませんでした。
ローカル環境 では、過去の検証作業で仮想環境にインストール済みだったpython-dotenvがそのまま残っていたため、アプリケーションは問題なく起動していました。
一方 Render は、requirements.txtに記載されたパッケージのみをクリーンな状態からインストールするため、ローカルでは見えていなかった 記載漏れ が、app.pyの1行目を実行した時点で即座に露呈しました。
修正の実行
git commit -m "fix: requirements.txtにdotenvを追加（軽量デモ仕様）"
requirements.txtにpython-dotenvを追記し、pushしました。
結果に対する考察
この事象は、ローカル環境の「動いている実績」が 本番環境でも通用するとは限らない 、という事実を実機ベースで示しています。
一方で、このModuleNotFoundErrorはビルドの最初の段階で発生し、アプリケーションが不完全な状態のまま公開され続けることはありませんでした。
依存関係の記載漏れ という設定ミスを、システムが起動前の段階で検知して停止した、という意味では、Fail-Fastの設計が意図通りに機能した結果とも言えます。
⚓ 3. データの完全永続化を追わない判断 ―― デモ用としての適正な積載量
puoppoはSQLiteをデータベースとして使用していますが、今回のRenderデプロイでは、PostgreSQLへの移行は行わず、SQLiteのまま公開する判断をしました。
判断の背景
Renderの無料プランでは、ディスクがエフェメラル(一時的)であるため、SQLiteのデータファイルはデプロイやコンテナの再起動のタイミングで初期化されうるという制約があります。bakery_salesdataではこの制約を踏まえ、以前の記事で報告した通りPostgreSQLへの移行を行いました。
一方puoppoは、RSSフィードを取得しGemini APIで要約・感情分析を行うという性質上、表示されるデータが常に最新の記事であることが前提であり、長期的なデータの蓄積や保存を必須としない設計になっています。
結果に対する考察
このため、puoppoについては、稼働の安定性やAPIとの連携部分をデモとして提示することを優先し、 データベースの永続化対応にはコストをかけない 、という判断をしました。
すべての機能に対して一律に堅牢な構成を追求するのではなく、そのアプリケーションが果たす役割から逆算して、 必要な範囲にリソースを配分する 、という考え方です。
🚩 結論
今回、bakery_salesdataとpuoppoの2つのアプリケーションについて、 Renderへの自動デプロイ環境(CI/CD)を構築し、GitHubへのpushのみでシステムが更新される状態まで到達しました。
事前にローカル環境で行ってきた コンテナのライフサイクル ・ データ永続化 ・ ネットワーク名前解決 ・ ログ設計の検証 は、本番環境へのデプロイ作業を円滑に進める土台として機能しました。一方で、puoppo側では 依存パッケージの記載漏れ という実際のエラーに直面し、 Fail-Fastの仕組み がそれを起動前に検知して停止させたこと、またSQLiteのままデモ用として公開する判断を行ったことなど、事前検証だけでは見えてこなかった本番環境特有の事象にも対応してきました。
現在、以下のURLから、実際にブラウザ経由でシステムに触れることができます。
🍞 ベーカリー売上管理システム(Flask + PostgreSQL)
https://bakery-salesdata.onrender.com/
🕊 puoppo(Flask + SQLite + RSS + Gemini API)
https://puoppo.onrender.com/
感傷や推測を排除し、実際に発生した事象とその対応という 「事実」を積み重ねていくアプローチ は、アプリケーションを実際に稼働させ続けるための確実な基盤になると考えています。