meinheld gunicorn flask docker
0.5.0
Dockerfileリンクpython3.9 、 latest （dockerfile） これらのタグはサポートまたは維持されなくなり、GitHubリポジトリから削除されますが、誰かがそれらを引っ張っている場合は、Docker Hubでプッシュされた最後のバージョンはまだ利用できる可能性があります。
python3.9-alpine3.13python3.8python3.8-alpine3.11python3.7python3.7-alpine3.8python3.6python3.6-alpine3.8python2.7これらのバージョンの最後の日付タグは次のとおりです。
python3.9-alpine3.13-2024-03-11python3.8-2024-10-28python3.8-alpine3.11-2024-03-11python3.7-2024-10-28python3.7-alpine3.8-2024-03-11python3.6-2022-11-25python3.6-alpine3.8-2022-11-25python2.7-2022-11-25注：ビルド日ごとにタグがあります。使用するDocker画像バージョンを「ピン留め」する必要がある場合は、それらのタグのいずれかを選択できます。例： tiangolo/meinheld-gunicorn-flask:python3.9-2024-11-02 。
Meinheldを使用したDockerイメージは、パフォーマンスオートチューニングを備えたPythonを使用して、 Flaskの高性能WebアプリケーションのためにGunicornが管理しています。
Github Repo ：https：//github.com/tiangolo/meinheld-gunicorn-flask-docker
Docker Hub画像：https：//hub.docker.com/r/tiangolo/meinheld-gunicorn-flask/
Gunicornで制御されたMeinheldで実行されているPython Flask Webアプリケーションには、Flask（*）が達成できる最高のパフォーマンスがいくつかあります。
Flaskにすでに既存のアプリケーションがある場合、または新しいアプリケーションを構築している場合、この画像は可能な限り最高のパフォーマンスを提供します（またはそれに近い）。
この画像には「自動調整」メカニズムが含まれているため、コードを追加して自動的に優れたパフォーマンスを取得できます。犠牲を払わずに（ロギングなど）。
現在の最新バージョンのMeinheldリリースは、2020年5月17日から1.0.2です。このバージョンのMeinheldには、Python 3.10および3.11と互換性がないGreenlet（ >=0.4.5,<0.5 ）の古いバージョンが必要です。そのため、この画像でサポートされているPythonの最新バージョンはPython 3.9です。
新しいプロジェクトを開始している場合は、 Fastapi （FlaskやDjangoのようなWSGIの代わりにASGIに基づいている）のような新しくて高速なフレームワークと、 Tiangolo/Uvicorn-Gunicorn-FastapiのようなDocker画像の恩恵を受けることができます。
この画像を使用している場合でも、フラスコで達成可能なパフォーマンスの約200％が得られます。
また、WebSocketのような新しいテクノロジーを使用したい場合は、 FastapiなどのASGIに基づく新しいフレームワークを使用すると簡単になります。標準的なASGIは、WebSocketに必要なような非同期コードを処理できるように設計されていました。
Meinheldは、高性能のWSGI準拠のWebサーバーです。
Gunicornを使用してMeinheldを管理し、複数のプロセスを実行できます。
Flaskは、Werkzeug、Jinja 2、およびGoodintionsに基づいたPythonのマイクロフレームワークです。
この画像は、Tiangolo/UWSGI-Nginx-Flaskの代替品として作成され、その画像のパフォーマンスを約400％提供しました。
これは、より一般的な画像Tiangolo/Meinheld-Gunicornに基づいています。それは、Djangoのような他のWSGIフレームワークに使用するものです。
おそらく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.9
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/meinheld-gunicorn-flask:python3.9
COPY ./requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt
COPY ./app /appファイルが/app/app/main.pyに期待されます。
または、 /app/main.pyのファイル。
また、「WSGI」アプリケーションを備えた可変appが含まれることを期待します。
次に、 Dockerfileを持つディレクトリから画像を作成できます。
docker build -t myimage ./これらは、コンテナに設定して設定してデフォルト値を構成できる環境変数です。
MODULE_NAMEPython "Module"（file）は、Gunicornによってインポートされるため、このモジュールには変数に実際のFlaskアプリケーションが含まれます。
デフォルト：
app.main file /app/app/main.pyがある場合/app/main.pyがある場合mainたとえば、メインファイルが/app/custom_app/custom_main.pyである場合、次のように設定できます。
docker run -d -p 80:80 -e MODULE_NAME= " custom_app.custom_main " myimageVARIABLE_NAMEFlaskアプリケーションを含むPythonモジュール内の変数。
デフォルト：
appたとえば、メインのPythonファイルに次のようなものがある場合：
from flask import Flask
api = Flask ( __name__ )
@ api . route ( "/" )
def hello ():
return "Hello World from Flask"この場合、 api 「Flaskアプリケーション」の変数になります。あなたはそれを次のように設定することができます：
docker run -d -p 80:80 -e VARIABLE_NAME= " api " myimageAPP_MODULEPythonモジュールと変数名が付いた文字列はGunicornに渡されました。
デフォルトでは、変数MODULE_NAMEとVARIABLE_NAMEに基づいて設定されています。
app.main:appまたはmain:appあなたはそれを次のように設定することができます：
docker run -d -p 80:80 -e APP_MODULE= " custom_app.custom_main:api " myimageGUNICORN_CONFGunicorn Python構成ファイルへのパス。
デフォルト：
/app/gunicorn_conf.pyそれが存在する場合/app/app/gunicorn_conf.pyそれが存在する場合/gunicorn_conf.py （含まれるデフォルト）あなたはそれを次のように設定することができます：
docker run -d -p 80:80 -e GUNICORN_CONF= " /app/custom_gunicorn_conf.py " myimageWORKERS_PER_COREこの画像では、コンテナを実行している現在のサーバーで使用可能なCPUコアの数を確認します。
労働者の数は、この値を掛けたCPUコアの数に設定します。
デフォルト：
2あなたはそれを次のように設定することができます：
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 3 " myimage 2つのCPUコアを持つサーバーで値3使用すると、6つのワーカープロセスを実行します。
フローティングポイント値も使用できます。
したがって、たとえば、いくつかのアプリケーションを実行している大きなサーバー（たとえば、8つのCPUコアを使用して）がある場合、高性能は必要ないASGIアプリケーションがあります。そして、あなたはサーバーのリソースを無駄にしたくありません。 CPUコアごとに0.5ワーカーを使用させることができます。例えば：
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 0.5 " myimage8つのCPUコアを備えたサーバーでは、4つのワーカープロセスのみを開始できます。
WEB_CONCURRENCY労働者数の自動定義をオーバーライドします。
デフォルト：
WORKERS_PER_COREによって乗算されます。したがって、2つのコアを持つサーバーでは、デフォルトでは4に設定されます。あなたはそれを次のように設定することができます：
docker run -d -p 80:80 -e WEB_CONCURRENCY= " 2 " myimageこれにより、サーバーで利用可能なCPUコアの数とは無関係に、画像が2ワーカープロセスを開始します。
HOSTGunicornが使用する「ホスト」は、Gunicornがリクエストを聞くIPです。
コンテナ内のホストです。
したがって、たとえば、この変数を127.0.0.1に設定すると、コンテナ内でのみ使用でき、ホストを実行していません。
完全性のために提供されていますが、おそらく変更してはいけません。
デフォルト：
0.0.0.0PORTコンテナが聴く必要があるポート。
特定のポート（ 8080など）の使用を強制する制限環境でコンテナを実行している場合は、この変数で設定できます。
デフォルト：
80あなたはそれを次のように設定することができます：
docker run -d -p 80:8080 -e PORT= " 8080 " myimageBIND実際のホストとポートはグニコーンに渡されました。
デフォルトでは、変数HOSTとPORTに基づいて設定されています。
したがって、何も変更しなかった場合、デフォルトで次のように設定されます。
0.0.0.0:80あなたはそれを次のように設定することができます：
docker run -d -p 80:8080 -e BIND= " 0.0.0.0:8080 " myimageLOG_LEVELGunicornのログレベル。
1つ：
debuginfowarningerrorcriticalデフォルトでは、 infoに設定します。
より多くのパフォーマンスを犠牲にしてロギングを絞る必要がある場合は、それをwarningに設定します。たとえば
あなたはそれを次のように設定することができます：
docker run -d -p 80:8080 -e LOG_LEVEL= " warning " myimageログはコンテナのstderrとstdoutに送信されます。つまり、 docker logs -f your_container_name_hereコマンドでログを表示できます。
画像には、 /gunicorn_conf.pyのデフォルトのGunicorn Python構成ファイルが含まれています。
上記で宣言された環境変数を使用して、すべての構成を設定します。
次のファイルを含めることでそれをオーバーライドできます。
/app/gunicorn_conf.py/app/app/gunicorn_conf.py/gunicorn_conf.py/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要するに、おそらくPythonプロジェクトにAlpineを使用してはいけません。代わりに、 slim Dockerイメージバージョンを使用してください。
詳細が必要ですか？読み続けますか？
Alpineは、1つのDocker画像段階（マルチステージDockerビルディングを使用）で静的バイナリを構築し、単純なAlpineイメージにコピーして、そのバイナリを実行する他の言語により便利です。たとえば、goを使用します。
しかし、Pythonの場合、AlpineはPython拡張機能の構築に使用される標準ツーリングを使用していないため、パッケージをインストールするときにPython（ pip ）が多くの場合、Alpine用の事前コンパイルされたインストール可能なパッケージ（「ホイール」）が見つかりません。そして、多くの奇妙なエラーをデバッグした後、これらの一般的なPythonパッケージの一部を使用するためだけに、多くの追加のツールをインストールし、多くの依存関係を構築する必要があることに気付くでしょう。 ？
つまり、元の高山画像は小さいかもしれませんが、標準のPython画像（Debianに基づいて）を使用した場合、または場合によってはさらに大きい場合に、サイズに匹敵するサイズのサイズの画像になります。 ？
そして、これらのすべての場合、ビルドにはるかに時間がかかり、より多くのリソースを消費し、依存関係をより長く構築し、各ビルドにCPU時間とエネルギーを使用しているため、二酸化炭素排出量を増やします。 ？
Slim Python画像が必要な場合は、代わりにDebianに基づいているがslimバージョンを試してみてください。 ？
すべての画像タグ、構成、環境変数、アプリケーションオプションがテストされています。
issue-manager.ymlを更新します。 @tiangoloによるPR＃154。latest-changes GitHubアクションを更新します。 @tiangoloによるPR＃153。latest-changes.ymlを更新します。 PR＃141 by @alejsdev。README.mdのテストバッジを更新します。 PR＃137 by @alejsdev。 このリリースのハイライト：
Python 3.9および3.8のサポート。
Python 3.6および2.7の非難。
python3.6-2022-11-25およびpython2.7-2022-11-25です。すべての依存関係のアップグレードされたバージョン。
小さな改善と修正。
Python 3.9とPython 3.9 Alpineのサポートを追加します。 @tiangoloによるPR＃50。
Alpine 3.11にPython 3.8を追加します。 PR＃28。
Python 3.8のサポートを追加します。 PR＃27。
tiangolo/meinheld-gunicorn-flask:python3.7-2019-10-15など、各ビルド日にEnv varsを使用し、各ビルド日に画像タグを追加します。 PR＃17。Python 2.7のサポートを追加します（Python 3.7またはPython 3.6を使用する必要があります）。 PR＃11。
Travis CI構成を更新します。 @cclaussによるPR＃10。
/app/prestart.shのサポートを追加します。 このプロジェクトは、MITライセンスの条件に基づいてライセンスされています。
