uwsgi nginx flask docker
2.1.0
Dockerfileリンクpython3.12 、 latest （dockerfile）python3.11 、 （dockerfile）python3.10 （dockerfile）python3.9 、 （dockerfile） これらのタグはサポートまたは維持されなくなり、GitHubリポジトリから削除されますが、誰かがそれらを引っ張っている場合は、Docker Hubでプッシュされた最後のバージョンはまだ利用できる可能性があります。
python3.8python3.8-alpinepython3.7python3.6python2.7これらのバージョンの最後の日付タグは次のとおりです。
python3.8-2024-10-28python3.8-alpine-2024-03-11python3.7-2024-10-28python3.6-2022-11-25python2.7-2022-11-25注：ビルド日ごとにタグがあります。使用するDocker画像バージョンを「ピン留め」する必要がある場合は、それらのタグのいずれかを選択できます。たとえば、 tiangolo/uwsgi-nginx-flask:python3.7-2019-10-14 。
1つのコンテナで実行されているPythonのFlask Webアプリケーション用のUWSGIとNGINXを備えたDocker画像。
このDocker画像を使用すると、 PythonでFlask Webアプリケーションを作成し、1つのコンテナでUWSGIとNginxで実行されます。
UWSGIとNginxの組み合わせは、Python Flask Webアプリケーションを展開する一般的な方法です。
新しいプロジェクトを開始している場合は、私が作成したFastapiを試してみたいと思うかもしれません。また、カスタムベース画像は必要ありません。独自のDockerfileを構築するためのドキュメントには指示があります。
Github Repo ：https：//github.com/tiangolo/uwsgi-nginx-flask-docker
Docker Hub画像：https：//hub.docker.com/r/tiangolo/uwsgi-nginx-flask/
おそらくKubernetesまたは同様のツールを使用しています。その場合、おそらくこの画像（または他の同様のベース画像）は必要ありません。おそらく、 Docker画像をゼロから作成したほうがよいでしょう。
Kubernetes 、Docker Swarm Mode、Nomad、または複数のマシン上の分散コンテナを管理するための他の同様の複雑なシステムを備えたマシンのクラスターがある場合、複数のワーカープロセスを開始するプロセスマネージャーを使用する代わりに、クラスターレベルで複製を処理する必要があります。
そのような場合（たとえば、Kubernetesの使用）、おそらくDocker画像をゼロから作成し、依存関係をインストールし、この画像の代わりに単一のプロセスを実行することをお勧めします。
たとえば、Gunicornを使用すると、ファイルapp/gunicorn_conf.pyを使用できます。
# Gunicorn config variables
loglevel = "info"
errorlog = "-" # stderr
accesslog = "-" # stdout
worker_tmp_dir = "/dev/shm"
graceful_timeout = 120
timeout = 120
keepalive = 5
threads = 3そして、あなたは次のようなDockerfileを持つことができます：
FROM python:3.12
WORKDIR /code
COPY ./requirements.txt /code/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt
COPY ./app /code/app
CMD [ "gunicorn" , "--conf" , "app/gunicorn_conf.py" , "--bind" , "0.0.0.0:80" , "app.main:app" ]これらのアイデアの詳細については、FASTAPIドキュメントで詳しく読むことができます。コンテナのFASTAPI -Dockerは、コンテナ内の他のWebアプリケーションにも同じアイデアが適用されるためです。
プロセスの数を微調整するために（少なくともまだ）必要としないほど単純である場合、コンテナ内で複数のワーカープロセスを実行するプロセスマネージャーが必要になり、自動化されたデフォルトを使用するだけで、クラスターではなく単一のサーバーで実行できます。
Docker Composeを使用して単一のサーバー（クラスターではなく）に展開する可能性があるため、共有ネットワークとロードバランスを保存しながらコンテナの複製（Docker Compose）を簡単に管理する簡単な方法はありません。
次に、このDockerイメージがそうであるように、プロセスマネージャーが内部で複数のワーカープロセスを開始する1つのコンテナを使用することができます。
また、それぞれに単一のプロセスを持つ複数のコンテナを持つ代わりに、複数のプロセスを備えた単一のコンテナを簡単に持つことができる他の理由を持つこともできます。
たとえば（セットアップに応じて）、同じコンテナにPrometheus Exporterのようなツールがあり、それぞれのリクエストにアクセスできるようにすることができます。
この場合、デフォルトで複数のコンテナがある場合、プロメテウスがメトリックを読むようになったときに、すべての複製された容器の蓄積されたメトリックを取得する代わりに、毎回1つのコンテナ用（その特定のリクエストを処理したコンテナ用）を取得します。
その場合、その場合、複数のプロセスを備えた1つのコンテナと、すべての内部プロセスのプロメテウスメトリックを収集し、その単一の容器にそれらのメトリックを公開する同じ容器にローカルツール（プロメテウス輸出業者）を使用する方が簡単になる可能性があります。
詳細については、Fastapiのドキュメントをご覧ください。コンテナのFastapi -Docker、同じ概念がコンテナ内の他のWebアプリケーションに適用されるためです。
このレポをクローンする必要はありません。
この画像を他の画像のベース画像として使用できます。
ファイルrequirements.txtがあると仮定すると、txtは次のようなDockerfileを持つことができます。
FROM tiangolo/uwsgi-nginx-flask:python3.12
COPY ./requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt
COPY ./app /appいくつかの画像タグがありますが、新しいプロジェクトでは、利用可能な最新バージョンを使用する必要があります。
このDocker画像は、Tiangolo/UWSGI-Nginxに基づいています。そのDocker画像には、同じ容器にUWSGIとNGINXがインストールされており、この画像のベースになっています。
Dockerfileを作成します： FROM tiangolo/uwsgi-nginx-flask:python3.12
COPY ./app /appappディレクトリを作成し、入力しますmain.pyファイル（そのように名前が付けられている必要があり、 appディレクトリにある必要があります）を作成します。 from flask import Flask
app = Flask ( __name__ )
@ app . route ( "/" )
def hello ():
return "Hello World from Flask"
if __name__ == "__main__" :
# Only for debugging while developing
app . run ( host = '0.0.0.0' , debug = True , port = 80 )この例のように、メインアプリケーションオブジェクトは（コード内）という名前のappに名前を付ける必要があります。
注： main()関数のセクションは、デバッグ目的です。詳細については、以下の高度な指示をお読みください。
.
├── app
│ └── main.py
└── Dockerfile
Dockerfileがある場所に、 appディレクトリが含まれています）docker build -t myimage .docker run -d --name mycontainer -p 80:80 myimage...そして、Dockerコンテナに最適化されたフラスコサーバーがあります。
http：//192.168.99.100またはhttp://127.0.0.1など、DockerコンテナのURLで確認できるはずです。
最新のフロントエンドアプリケーション（VUE、React、Angularなど）を構築している場合、おそらく、JavaScript（ES2015、TypeScriptなど）の最新バージョンを、より近代的で互換性のないバージョンにコンパイルするでしょう。
同じバックエンド（フラスコ）Dockerコンテナで（コンパイルされた）フロントエンドコードを提供する場合は、コンパイル後にコードをコンテナにコピーする必要があります。
つまり、すべてのフロントエンドツールを建物マシンにインストールする必要があることを意味します（コンピューター、リモートサーバーなど）。
それはまた、どういうわけか、Docker画像を構築する直前にフロントエンドコードをコンパイルすることを常に忘れないでください。
また、コンパイルされたフロントエンドコードをgitリポジトリに追加する必要があることを意味する場合があります（うまくいけば、既にGITを使用しているか、 git使用方法を学習しています）。
コンパイルされたコードをgitに追加することは、いくつかの理由で非常に悪い考えです。それらのいくつかは次のとおりです。
これらの理由により、同じバックエンド（フラスコ）ドッカーコンテナからフロントエンドコードを提供することはお勧めしません。
同じバックエンド（フラスコ）Dockerコンテナからフロントエンドコードを提供することには、より良い代替手段があります。
すべてのフロントエンドツールがインストールされている別のDockerコンテナ（node.jsなど）を使用できます。
Dockerのフロントエンドビルのこのプロセスの詳細を学ぶには、次のことを読むことができます。
バックエンド（フラスコ）容器とフロントエンドコンテナを1つ持っていた後、両方を提供する必要があります。
そして、あなたは同じドメインの下で、別のパスの下でそれらを提供したいと思うかもしれません。たとえば、パス/apiのバックエンド（フラスコ）アプリと「root」パス/のフロントエンド。
その後、Traefikを使用してそれを処理できます。
また、Let's Encryptを使用してアプリケーションのHTTPS証明書を自動的に生成することもできます。非常に簡単なセットアップで、すべて無料で。
この代替品を使用したい場合は、上記のプロジェクトジェネレーターを確認してください。これらはすべてこのアイデアを使用します。
このシナリオでは、3つのDockerコンテナがあります。
上記の「 QuickStart 」セクションと同じ指示に従うことができるはずです。
app/ディレクトリに配置する代わりに、ディレクトリapp/app/に配置します。__init__.pyそのapp/app/ディレクトリの内側に。app/ディレクトリ内にファイルuwsgi.iniを追加します（コンテナ内の/app/uwsgi.iniにコピーされます）。uwsgi.iniファイルで、追加してください。 [uwsgi]
module = app.main
callable = app uwsgi.iniの説明は次のとおりです。
app.mainです。したがって、パッケージapp （ /app/app ）で、 mainモジュール（ main.py ）を取得します。appオブジェクト（ app = Flask(__name__) ）です。ファイル構造は次のようになります。
.
├── app
│ ├── app
│ │ ├── __init__.py
│ │ ├── main.py
│ └── uwsgi.ini
└── Dockerfile
...の代わりに：
.
├── app
│ ├── main.py
└── Dockerfile
同じコンテナで静的ファイルを使用している場合は、それに応じてSTATIC_PATH環境変数が設定されていることを確認してください。たとえば、 /app/static to /app/app/staticのデフォルト値を変更するには、この行をDockerfileに追加できます。
ENV STATIC_PATH /app/app/static...その後、すべてが期待どおりに機能するはずです。他のすべての指示は正常に適用されます。
.
├── app
│ ├── app
│ │ ├── api
│ │ │ ├── api.py
│ │ │ ├── endpoints
│ │ │ │ ├── __init__.py
│ │ │ │ └── user.py
│ │ │ ├── __init__.py
│ │ │ └── utils.py
│ │ ├── core
│ │ │ ├── app_setup.py
│ │ │ ├── database.py
│ │ │ └── __init__.py
│ │ ├── __init__.py
│ │ ├── main.py
│ │ └── models
│ │ ├── __init__.py
│ │ └── user.py
│ └── uwsgi.ini
└── Dockerfile
モジュールのインポート中に公式ドキュメントに従ってください。
たとえば、 app/app/main.pyにいて、 app/app/core/app_setup.pyでモジュールをインポートしたい場合は、次のように書きます。
from . core import app_setupまたは
from app . core import app_setupapp/app/api/endpoints/user.pyに参加していて、 app/app/core/database.pyからusersオブジェクトをインポートする場合は、次のように書きます。 from ... core . database import usersまたは
from app . core . database import users 環境変数を使用していくつかのものをカスタマイズできます。
index.html直接提供します注意：この手法は、最新のフロントエンドフレームワークにいくつかの問題を作成できるため、非推奨です。詳細とより良い代替案については、上記のセクションをお読みください。
環境変数STATIC_INDEX 1に設定すると、 / forが要求されたときにurl /static/index.htmlでファイルを提供するようにnginxを構成できます。
UWSGIやPythonは関与しないため、速度が向上します。 nginxはファイルを直接提供します。詳細については、上記のセクション「 QuickStart for Spas 」をフォローしてください。
たとえば、それを有効にするために、これをDockerfileに追加できます。
ENV STATIC_INDEX 1デフォルトでは、画像は2つのUWSGIプロセスが実行されてから始まります。サーバーが高い負荷を発生している場合、最大16のUWSGIプロセスを作成してオンデマンドで処理します。
これらの数値を構成する必要がある場合は、環境変数を使用できます。
UWSGIプロセスの開始数は、変数UWSGI_CHEAPERによって制御され、デフォルトでは2に設定されています。
UWSGIプロセスの最大数は、デフォルトでは16に設定された変数UWSGI_PROCESSESによって制御されます。
UWSGI_CHEAPER UWSGI_PROCESSESよりも低くなければならないことに留意してください。
したがって、たとえば、4つのプロセスから始めて最大64に成長する必要がある場合、 Dockerfileは次のようになります。
FROM tiangolo/uwsgi-nginx-flask:python3.12
ENV UWSGI_CHEAPER 4
ENV UWSGI_PROCESSES 64
COPY ./app /app環境変数NGINX_MAX_UPLOADを使用してカスタムの最大アップロードファイルサイズを設定できます。デフォルトでは、ファイルサイズを0にアップロードできる値があります。これは、Nginxのデフォルト値の1 MBとは異なります。これは、Nginxの経験の浅い開発者が期待する最も単純なエクスペリエンスであるため、このように構成されています。
たとえば、最大アップロードファイルサイズが1 MB（NGINXのデフォルト）を使用するには、次のようにDockerfileにラインを追加します。
ENV NGINX_MAX_UPLOAD 1mデフォルトでは、この画像から作られたコンテナはポート80で聞きます。
この動作を変更するには、 LISTEN_PORT環境変数を設定します。また、それぞれのEXPOSE Docker命令を作成する必要があるかもしれません。
あなたはあなたのDockerfileでそれを行うことができます、それは次のようになります：
FROM tiangolo/uwsgi-nginx-flask:python3.12
ENV LISTEN_PORT 8080
EXPOSE 8080
COPY ./app /appuwsgi.ini構成APP固有の構成を備えた/app/uwsgi.iniにデフォルトファイルがあります（グローバルuwsgi構成の上に）。
含まれているだけです：
[uwsgi]
module = main
callable = appmodule = mainは、ファイルmain.pyを指します。callable = app 、変数appのFlask 「アプリケーション」を指します。すべての構成を含め、そのファイルを独自のファイルに置き換えることにより、 uwsgiをカスタマイズできます。
たとえば、上記のデフォルトのデフォルトを拡張してスレッドを有効にするには、ファイルを使用できます。
[uwsgi]
module = main
callable = app
enable-threads = trueuwsgi.iniファイルの場所環境変数UWSGI_INIを使用して、画像がアプリuwsgi.iniファイルを探す場所をオーバーライドできます。
これにより、アプリのデフォルトディレクトリを/app /application他のものに変更することができます。
たとえば、画像に/application/uwsgi.iniでファイルを使用するには、これをDockerfileに追加できます。
ENV UWSGI_INI /application/uwsgi.ini
COPY ./application /application
WORKDIR /application注： WORKDIRは重要です。そうでなければ、UWSGIはアプリで/appを実行しようとします。
注：また、 staticファイルパスを構成する必要があります。以下をお読みください。
./static/ Path nginxがファイルを使用してカスタムディレクトリパスを使用して、環境変数STATIC_PATHで直接（UWSGIが関与しないことを伴うことなく）提供することができます。
たとえば、nginxを作成するには/app/custom_static/のファイルを使用して静的コンテンツを提供するには、これをDockerfileに追加できます。
ENV STATIC_PATH /app/custom_static次に、ブラウザがたとえばhttp://example.com/static/index.htmlなどのファイルを要求すると、nginxはpath /app/custom_static/index.html custom_static/index.htmlのファイルを使用して直接回答します。
注：それをstaticディレクトリとして使用するようにフラスコを構成する必要があります。
別の例として、アプリケーションコードを別のディレクトリに配置する必要がある場合は、その異なるディレクトリからこれらの静的ファイルを提供するようにnginxを構成できます。
/application/static/に静的ファイルを入力する必要がある場合は、これをDockerfileに追加できます。
ENV STATIC_PATH /application/static/static URLまた、nginxを別のURLで静的ファイルを提供することもできます。そのため、環境変数STATIC_URLを使用できます。
たとえば、URL /static to /contentを変更したい場合は、これをDockerfileに追加できます。
ENV STATIC_URL /content次に、ブラウザがたとえばhttp://example.com/content/index.htmlなどのファイルを要求した場合、nginxはPath /app/static/index.html index.htmlのファイルを使用して直接回答します。
/app/prestart.shアプリを起動する前に何かを実行する必要がある場合は、ファイルprestart.shディレクトリ/appに追加できます。すべてを起動する前に、画像は自動的に検出して実行されます。
たとえば、Alembic SQLの移行（SQLalchemyを使用）を追加する場合は、コードディレクトリに./app/prestart.shファイルを作成できます（ Dockerfileがコピーします）。
#! /usr/bin/env bash
# Let the DB start
sleep 10 ;
# Run migrations
alembic upgrade headそして、データベースに開始する時間を与えてから、そのalembicコマンドを実行するのに10秒待っています。
アプリを起動する前にPythonスクリプトを実行する必要がある場合は、 /app/prestart.shファイルをPythonスクリプトを実行することができます。
#! /usr/bin/env bash
# Run custom Python script before starting
python /app/my_custom_prestart_script.py注：画像はsourceを使用してスクリプトを実行するため、たとえば環境変数が持続します。前の文を理解していない場合は、おそらく必要ないでしょう。
デフォルトでは、Nginxは1つの「ワーカープロセス」を開始します。
異なる数のnginxワーカープロセスを設定する場合は、環境変数NGINX_WORKER_PROCESSESを使用できます。
特定の単一番号を使用できます。
ENV NGINX_WORKER_PROCESSES 2または、キーワードautoに設定すると、利用可能なCPUの数を自動検出し、労働者の数に使用しようとします。
たとえば、 autoを使用すると、DockerFileは次のようになります。
FROM tiangolo/uwsgi-nginx-flask:python3.12
ENV NGINX_WORKER_PROCESSES auto
COPY ./app /appデフォルトでは、Nginxは労働者あたり1024接続の最大制限から開始されます。
別の番号を設定する場合は、環境変数NGINX_WORKER_CONNECTIONSを使用できます。
ENV NGINX_WORKER_CONNECTIONS 2048オープンファイルの最大数の現在の制限を超えることはできません。次のセクションで構成する方法を参照してください。
Nginxワーカーごとの数の接続は、オープンファイルの最大数の制限を超えることはできません。
環境変数NGINX_WORKER_OPEN_FILESでオープンファイルの制限を変更できます。
ENV NGINX_WORKER_OPEN_FILES 2048Nginxをさらに構成する必要がある場合は、 Dockerfileに/etc/nginx/conf.d/に*.confファイルを追加できます。
/etc/nginx/conf.d/nginx.confおよび/etc/nginx/conf.d/upload.confのファイルの起動中にデフォルトの構成が作成されることに留意してください。したがって、それらを上書きするべきではありません。 nginx.confまたはupload.confとは異なるものを使用して、 *.confファイルに名前を付ける必要があります。たとえば、 custom.conf 。
注：nginxをカスタマイズしている場合は、ブログまたはスタックフローの回答から構成をコピーする場合は、たとえば他のモジュールの代わりに、 ngx_http_fastcgi_moduleなどの他のモジュールの代わりに、uwsgiに固有の構成を使用する必要があることに留意してください。
Nginxをさらに構成する必要がある場合、デフォルトを完全に上書きする必要がある場合は、Custom Nginx構成を/app/nginx.confに追加できます。
/etc/nginx/nginx.confにコピーされ、生成されたものの代わりに使用されます。
その場合、この画像はnginx構成のいずれも生成されないため、構成ファイルのみをコピーして使用することに留意してください。
つまり、nginxに固有の上記のすべての環境変数は使用されません。
また、カスタムファイルに明示的にセクションがある場合を除き、 /etc/nginx/conf.d/*.conf conf.d /app/nginx.confのファイルから追加の構成を使用しないことも意味します。
include /etc/nginx/conf.d/*.conf;
custom /app/nginx.confファイルを追加したいが、どこから始めればよいかわからない場合は、テストに使用されるnginx.confを使用してカスタマイズするか、さらに変更できます。
UWSGIとNginxの組み合わせは、Python Flask Webアプリケーションを展開する一般的な方法です。
だいたい：
NginxはWebサーバーであり、HTTP接続を処理し、静的ファイルを直接かつより効率的に提供することもできます。
UWSGIはアプリケーションサーバーであり、Pythonコードを実行し、Nginxと話します。
Pythonコードには実際のFlask Webアプリケーションがあり、UWSGIによって実行されます。
画像Tiangolo/UWSGI-Nginxは、すでに既存のスリムで最適化されたDocker画像（Dockerが推奨するDebianに基づいて）を利用し、Dockerのベストプラクティスのいくつかを実装しています。
公式のPython Docker画像を使用し、UWSGIをインストールし、その上に（変更の最小量で）公式Nginx画像を追加します。
また、これらすべてのプロセスを監督者と一緒に制御します。
このレポで作成された画像（およびタグ）は、Tiangolo/UWSGI-Nginxの画像に基づいています。この画像は、フラスコとその上に賢明なデフォルトを追加します。
手順に従って、containerにルートディレクトリ/appコンテナ内に保持する場合、 main.pyという名前のファイルとその中にappという名前のフラスコオブジェクトが含まれている場合は、「単に動作する」必要があります。
/appディレクトリには、 uwsgi.iniファイルがUWSGI構成を備えた「Just Work」を備えています。そして、他のすべての必要なパラメーターは、画像内の別のuwsgi.iniファイル、内部/etc/uwsgi/にあります。
メインファイル名またはメインフラスコオブジェクトを変更する必要がある場合は、独自のuwsgi.iniファイルを提供する必要があります。このリポジトリの1つをテンプレートとして使用することができます（2つの対応する行を変更する必要があります）。
/app/staticディレクトリを持つことができ、それらのファイルはnginxが直接効率的に提供します（フラスココードやuwsgiを使用することなく）、すでに構成されています。ただし、環境変数を使用してさらに構成できます（上記を読む）。
Supervisordは、 /appファイル（ / /etc/uwsgi/uwsgi.iniのファイルも含む）および開始nginxを含むuwsgi.iniファイルを使用してuwsgiを実行します。
「コンテナごとに1つのプロセス」が必要な経験則があります。
これにより、たとえば、アプリとそのデータベースをさまざまなコンテナで分離するのに役立ちます。
ただし、「マイクロサービス」アプローチが必要な場合は、すべて同じ「サービス」に関連している場合は、1つのコンテナに複数のプロセスが必要になり、同じコンテナにフラスココード、UWSGI、およびNginxを含めてください（およびデータベースで別のコンテナを実行する可能性があります）。
それがこの画像で取られたアプローチです。
この画像（およびタグ）にはいくつかのデフォルトファイルがあるため、単独で実行すると（独自のプロジェクトのベースイメージとしてではなく）、デフォルトの「Hello World」Webアプリが表示されます。
COPY ./app /appでDockerfileを構築すると、それらのデフォルトファイルをアプリコードに置き換えます。
メインのデフォルトファイルは/app/main.pyにのみです。また、 -indexを使用したタグの場合、 /app/static/index.htmlもあります。
ただし、これらのファイルは、提供されたWebページに「（デフォルト）」テキストをレンダリングするため、デフォルトのコードが表示されているか、デフォルトをオーバーライドする独自のコードが表示されているかどうかを確認できます。
アプリコードはコンテナ/appディレクトリにある必要があり、 main.pyファイルがあり、 main.pyファイルにはFlaskオブジェクトappが必要です。
上記の手順に従って、またはダウンロード可能なサンプルテンプレートのいずれかを使用する場合は、大丈夫です。
また、UWSGIのデフォルトパラメーターを備えた画像内には/app/uwsgi.iniファイルもあります。
ダウンロード可能な例には、デバッグ目的で同じuwsgi.iniファイルのコピーが含まれます。詳細については、以下の「高度な開発指示」をお読みください。
開発中に、コードディレクトリをDockerコンテナのボリュームにすることをお勧めします。
それにより、コンテナを再度構築する必要なく、変更するたびに（一時的に）更新されるでしょう。
これを行うには、 docker run内のコマンドpwd （印刷作業ディレクトリ）を使用し、ボリュームにFlag -v使用できます。
そのため./app appディレクトリをコンテナ/appディレクトリにマッピングできます。
ただし、最初に、コンテナ内のディレクトリ/app （およびそのすべてのコンテンツ）を完全に交換するため、 ./appディレクトリにuwsgi.iniファイルを使用する必要があります。
[uwsgi]
module = main
callable = appそして、Dockerボリュームマッピングを行うことができます。
注： uwsgi.iniファイルは、ダウンロード可能な例に含まれています。
Dockerfileと./appディレクトリのあるディレクトリ）にアクセスしてください。./appディレクトリにuwsgi.iniファイルがあることを確認してくださいdocker build -t myimage ./appディレクトリにコードディレクトリ（ ./app ）をマッピングします。 docker run -d --name mycontainer -p 80:80 -v $( pwd ) /app:/app myimage Docker Container URLに移動すると、アプリが表示されるはずで、 ./app/static/ app/static/でファイルを変更し、リロードするだけでブラウザに反映されている変更を確認できるはずです。
...しかし、UWSGIがPython Flask Webアプリケーション全体を起動するとロードすると、Python Flaskコードを編集して反映される変更を確認することはできません。
（一時的に）Python Flaskコードをライブデバッグできるようにするには、デフォルトのコマンド（監督を起動する監督とnginxを起動します）をオーバーライドするコンテナを実行し、環境変数を持つflaskコマンドを使用してpythonでアプリケーションを直接実行できます。
したがって、上記のすべての変更とアプリをflaskで直接実行することで、最終的なDockerコマンドは次のとおりです。
docker run -d --name mycontainer -p 80:80 -v $( pwd ) /app:/app -e FLASK_APP=main.py -e FLASK_DEBUG=1 myimage flask run --host=0.0.0.0 --port=80または、パッケージプロジェクトの場合、 FLASK_APP=main/main.pyを設定します：
docker run -d --name mycontainer -p 80:80 -v $( pwd ) /app:/app -e FLASK_APP=main/main.py -e FLASK_DEBUG=1 myimage flask run --host=0.0.0.0 --port=80これで、ローカルマシンでフラスココードを編集でき、ブラウザを更新すると、変更がライブで表示されます。
これをデバッグと開発にのみ使用する必要があります。本番展開のためには、ボリュームをマウントする必要はなく、監督を開始してUWSGIとnginxを開始する必要があります（デフォルトで起こることです）。
パッケージを持っていないが、単一のファイル（モジュール）を備えたフラットな構造だけで、これらの最後の手順が機能するための代替手段であるPython Flaskコードは、次のセクションを持つことができます。
if __name__ == "__main__" :
# Only for debugging while developing
app . run ( host = '0.0.0.0' , debug = True , port = 80 ) ...そして、 python main.pyで実行できます。しかし、それはあなたがパッケージ構造を使用していない場合にのみ機能し、後でそれをするつもりはありません。その特定のケースでは、上記のコードブロックを追加しなかった場合、アプリはDebugモードではなく、別のポート（5000）でlocalhost （コンテナ内）のみを聞きます。
また、環境変数STATIC_INDEX=1 （ /app/static/index.htmlを要求されたときに直接/app/static/index.htmlを使用して/ nginxを使用して同じライブデバッグを実行したい場合は、実行しないため、直接サービスを提供しません（デバッグモードのPython Flaskアプリのみが実行されます）。
from flask import Flask , send_fileそして
@ app . route ( '/' )
def route_root ():
index_path = os . path . join ( app . static_folder , 'index.html' )
return send_file ( index_path ) ...それは、あなたのアプリが/app/static/index.htmlファイルを要求されたときにも提供することを確認します/または、パッケージ構造を使用している場合は、 /app/main/static/index.html main/static/index.htmlファイルを使用しています。
また、SPAフレームワークを使用している場合、ブラウザのURLを処理できるようにする場合、Python Flaskコードには次のセクションがあります。
# Everything not declared before (not a Flask route / API endpoint)...
@ app . route ( '/<path:path>' )
def route_frontend ( path ):
# ...could be a static file needed by the front end that
# doesn't use the `static` path (like in `<script src="bundle.js">`)
file_path = os . path . join ( app . static_folder , path )
if os . path . isfile ( file_path ):
return send_file ( file_path )
# ...or should be handled by the SPA's "router" in front end
else :
index_path = os . path . join ( app . static_folder , 'index.html' )
return send_file ( index_path ) ...これにより、Flaskはルート（ / ）URLで要求されたときにすべてのCSS、JavaScript、および画像ファイルを送信しますが、Flaskアプリで定義されていない他のすべてのURLをフロントエンドスパが処理することも確認します。
これが上記のチュートリアルで書かれており、ダウンロード可能な例に含まれています。
上記の指示に従うと、ある時点で、Flask Debugging Serverを壊してクラッシュするコードを作成する可能性があります。
また、実行中のプロセスはデバッグサーバーであるため、現在は停止しているため、コンテナが停止します。
その後、コードを修正した後、もう一度コンテナを起動する必要があります。サーバーがクラッシュしているエラーは何ですか。
したがって、開発中に、あなたは次のことをすることができます（それは私が通常することですが、私はDocker Composeでそれを行いますが、プロジェクトの例のようにそれをします）：
docker run -d --name mycontainer -p 80:80 -v $( pwd ) /app:/app -e FLASK_APP=main.py -e FLASK_DEBUG=1 myimage bash -c " while true ; do sleep 10 ; done "FLASK_APP=main/main.pyを設定します： docker run -d --name mycontainer -p 80:80 -v $( pwd ) /app:/app -e FLASK_APP=main/main.py -e FLASK_DEBUG=1 myimage bash -c " while true ; do sleep 10 ; done "docker exec -it mycontainer bashこれで、 /appディレクトリのコンテナ内になります。
flask run --host=0.0.0.0 --port=80Flask Debugging Serverの起動が表示され、すべてのリクエストへの応答がどのように送信されるかがわかります。コードを破るときにエラーがスローされ、サーバーを停止する方法が表示されます。
すべての画像タグ、構成、環境変数、アプリケーションオプションがテストされています。
issue-manager.ymlを更新します。 @tiangoloによるPR＃385。latest-changes GitHubアクションを更新します。 @tiangoloによるPR＃360。latest-changes.ymlを更新します。 PR＃348 by @alejsdev。README.mdのテストバッジを更新します。 PR＃346 by @alejsdev。 このリリースのハイライト：
python3.6-2022-11-25およびpython2.7-2022-11-25です。1.17.10 .3.11 .-index sufix tags.-index (use ENV STATIC_INDEX 1 instead).2020-05-04 .tiangolo/uwsgi-nginx-flask:python3.8-2019-10-14 . PR #154./start.sh and /app/prestart.sh functionality to parent image. PR #134.2019-02-02:
uwsgi-nginx and PR #121./app/nginx.conf file that overrides the generated one. PR #51 in the parent image uwsgi-nginx and PR #122.2019-01-01:
2018-12-29:
2018-11-23:
2018-09-22:
2018-06-22:
NGINX_WORKER_CONNECTIONS to set the maximum number of Nginx worker connections and NGINX_WORKER_OPEN_FILES to set the maximum number of open files. Thanks to ronlut in this PR.2018-06-22:
Improvements from parent image:
Make uWSGI require an app to run, instead of going in "full dynamic mode" while there was an error. Supervisord doesn't terminate itself but tries to restart uWSGI and shows the errors. Uses need-app as suggested by luckydonald in this comment.
Correctly handled graceful shutdown of uWSGI and Nginx. Thanks to desaintmartin in this PR.
2018-02-04:
It's now possible to set the number of Nginx worker processes with the environment variable NGINX_WORKER_PROCESSES . Thanks to naktinis in this PR.
2018-01-14:
python2.7-alpine3.7 and python3.6-alpine3.7 .2017-12-10:
/app/prestart.sh script to run arbitrary code before starting the app (for example, Alembic - SQLAlchemy migrations). The documentation for the /app/prestart.sh is in the main README./app is part of the PYTHONPATH environment variable. That allows global imports from several places, easier Alembic integration, etc. 2017-12-08: Now you can configure which port the container should listen on, using the environment variable LISTEN_PORT thanks to tmshn in this PR.
2017-09-10: Updated examples and sample project to work with SPAs even when structuring the app as a package (with subdirectories).
2017-09-02:
flask run commands, that allows running a package application while developing more easily.2017-08-10: Many changes:
python3.6 , python3.6-index , python.3.5 , python3.5-index , python2.7 and python2.7-index . All the other images are deprecated in favor is this ones.latest will point to Python 3.6 and the other tags will be removed.tiangolo/uwsgi-nginx that improved this image too.index.html directly: STATIC_INDEXNGINX_MAX_UPLOADuwsgi.ini file (that allows using a custom directory different than /app ): UWSGI_INI (using the ideas by @bercikr in #5 )../static/ path: STATIC_PATH/static/ URL: STATIC_URLDockerfile with: FROM tiangolo/uwsgi-nginx-flask:python3.6
COPY ./app /appand then customize with environment variables.
This project is licensed under the terms of the Apache license.
