uvicorn gunicorn fastapi docker
0.8.0
このDocker画像は現在廃止されました。それを使用する必要はありません。Uvicornを使用するだけで--workersを使用できます。
詳細については、以下をご覧ください。
Dockerfileリンクpython3.11 、 latest （dockerfile）python3.10 、 （dockerfile）python3.9 、 （dockerfile）python3.11-slim （dockerfile）python3.10-slim （dockerfile）python3.9-slim （dockerfile） これらのタグはサポートまたは維持されなくなり、GitHubリポジトリから削除されますが、誰かがそれらを引っ張っている場合は、Docker Hubでプッシュされた最後のバージョンはまだ利用できる可能性があります。
python3.8python3.8-slimpython3.7python3.9-alpine3.14python3.8-alpine3.10python3.7-alpine3.8python3.6python3.6-alpine3.8これらのバージョンの最後の日付タグは次のとおりです。
python3.8-2024-11-02python3.8-slim-2024-11-02python3.7-2024-11-02python3.9-alpine3.14-2024-03-11python3.8-alpine3.10-2024-01-29python3.7-alpine3.8-2024-03-11python3.6-2022-11-25python3.6-alpine3.8-2022-11-25注：ビルド日ごとにタグがあります。使用するDocker画像バージョンを「ピン留め」する必要がある場合は、それらのタグのいずれかを選択できます。例： tiangolo/uvicorn-gunicorn-fastapi:python3.11-2024-11-02 。
Gunicornが管理するUvicornを使用したDockerイメージは、 Pythonの高性能Fastapi Webアプリケーションをパフォーマンスオートチューニングで管理しています。
Github Repo ：https：//github.com/tiangolo/uvicorn-gunicorn-fastapi-docker
Docker Hub画像：https：//hub.docker.com/r/tiangolo/uvicorn-gunicorn-fastapi/
Fastapiは、 Starletteに基づいて搭載されているおかげで、サードパーティのベンチマークで測定されるように、最高のパフォーマンスの1つを備えたPython Webフレームワークであることが示されています。
達成可能なパフォーマンスは、 GOおよびnode.jsフレームワークと同等です（および多くの場合より優れています）。
この画像には、利用可能なCPUコアに基づいて多くのワーカープロセスを開始するための自動調整メカニズムが含まれています。そうすれば、コードを追加して自動的に高性能を取得できます。これは、単純な展開に役立ちます。
おそらくKubernetesまたは同様のツールを使用しています。その場合、おそらくこの画像（または他の同様のベース画像）は必要ありません。コンテナのFastapiのドキュメントで説明されているように、 Docker画像をゼロから作成する方が良いでしょう - Docker：FastapiのDocker画像を構築します。
Kubernetes 、Docker Swarm Mode、Nomad、または複数のマシン上の分散コンテナを管理するための他の同様の複雑なシステムを備えたマシンのクラスターがある場合は、おそらく各コンテナでプロセスマネージャー（UVicorn Workersを持つGunicornなど）を使用する代わりに、クラスターレベルで複製を処理することをお勧めします。
そのような場合（たとえば、Kubernetesの使用） 、Docker画像をゼロから作成し、依存関係をインストールし、この画像の代わりに1つのUvicornプロセスを実行することをお勧めします。
たとえば、 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 [ "uvicorn" , "app.main:app" , "--host" , "0.0.0.0" , "--port" , "80" ]これについては、Fastapiのドキュメントで詳細を読むことができます。
1つの容器に複数の労働者がいることが絶対に必要な場合は、Uvicornが死んだものの再起動を含むサブプロセスの取り扱いをサポートするようになりました。したがって、グニコーンが単一の容器で複数の労働者を管理する必要はありません。
上記のDockerfile例を変更して、Uvicornに--workersオプションを追加できます。
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 [ "uvicorn" , "app.main:app" , "--host" , "0.0.0.0" , "--port" , "80" , "--workers" , "4" ]必要なのはそれだけです。このDocker画像はまったく必要ありません。 ？
詳細については、Dockerでの展開に関するFastapi Docsで詳細をご覧ください。
Uvicornは、死んだ労働者の再起動など、労働者の処理を管理するためのサポートがありませんでした。しかし、今はそうです。
それ以前は、Gunicornをプロセスマネージャーとして使用して、Uvicornの労働者を走らせることができました。これはもはや必要ではない複雑さを追加しました。
このドキュメントの残りは歴史的な理由で保持されていますが、おそらくあなたはそれを必要としないでしょう。 ？
tiangolo/uvicorn-gunicorn-fastapiこの画像は、犠牲を払わずに実行されているサーバー（利用可能なCPUコアの量）に基づいて賢明な構成を設定します。
賢明なデフォルトがありますが、環境変数で構成したり、構成ファイルをオーバーライドしたりできます。
スリムバージョンもあります。それらのいずれかが必要な場合は、上のタグの1つを使用してください。
tiangolo/uvicorn-gunicornこの画像（ tiangolo/uvicorn-gunicorn-fastapi ）は、Tiangolo/uvicorn-gunicornに基づいています。
そのイメージは、実際にすべての仕事をしていることです。
この画像はFastapiをインストールするだけで、Fastapiをターゲットにしたドキュメントがあります。
Uvicorn、Gunicorn、Asgiの知識に自信がある場合は、その画像を直接使用できます。
tiangolo/uvicorn-gunicorn-starlette兄弟のドッカーの画像があります： Tiangolo/uvicorn-gunicorn-starlette
新しいStarlette Webアプリケーションを作成し、Fastapiのすべての追加機能を破棄したい場合は、代わりにTiangolo/Uvicorn-Gunicorn-Starletteを使用する必要があります。
注：FastapiはStarletteに基づいており、その上にいくつかの機能を追加します。 APIおよびその他のケースに役立つ：データの検証、データ変換、OpenAPIによるドキュメント、依存関係インジェクション、セキュリティ/認証など。
GitHubリポジトリをクローンする必要はありません。
この画像を他の画像のベース画像として使用できます。
ファイルrequirements.txtがあると仮定すると、txtは次のようなDockerfileを持つことができます。
FROM tiangolo/uvicorn-gunicorn-fastapi:python3.11
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のファイル。
また、FastAPIアプリケーションを備えた可変appが含まれることを期待します。
次に、 Dockerfileを持つディレクトリから画像を作成できます。
docker build -t myimage ./Dockerfileを作成します： FROM tiangolo/uvicorn-gunicorn-fastapi:python3.11
COPY ./requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt
COPY ./app /appappディレクトリを作成し、入力します。main.pyファイルを作成します。 from fastapi import FastAPI
app = FastAPI ()
@ app . get ( "/" )
def read_root ():
return { "Hello" : "World" }
@ app . get ( "/items/{item_id}" )
def read_item ( item_id : int , q : str = None ):
return { "item_id" : item_id , "q" : q } .
├── app
│ └── main.py
└── Dockerfile
Dockerfileがある場所に、 appディレクトリが含まれています）。docker build -t myimage .docker run -d --name mycontainer -p 80:80 myimageこれで、Dockerコンテナに最適化されたFastAPIサーバーができました。現在のサーバー（およびCPUコアの数）用に自動調整されています。
たとえば、http：//192.168.99.100/items/5？q = somequeryまたはhttp://127.0.0.0.1/items/5?q = somequery（または同等のドッカーホストを使用する）。
あなたは次のようなものを見るでしょう：
{ "item_id" : 5 , "q" : " somequery " }これで、http：///192.168.99.100/docsまたはhttp://127.0.0.1/docs（または同等のドッカーホストを使用）にアクセスできます。
自動インタラクティブAPIドキュメント（Swagger UIが提供）が表示されます。
また、http：///192.168.99.100/Redocまたはhttp://127.0.0.1/Redoc(OR同等のDockerホストを使用することもできます。
代替自動ドキュメント（Redocが提供）が表示されます。
また、おそらくアプリの依存関係を追加し、おそらくUvicorn、Gunicorn、Fastapiを含む特定のバージョンに固定することもできます。
これにより、アプリが常に期待どおりに機能することを確認できます。
Dockerfileにpipコマンドを含むパッケージ、 requirements.txtを使用して、または詩を使用することもできます。
そして、それらの依存関係を制御された方法でアップグレードし、テストを実行し、すべてが機能することを確認することができますが、新しいバージョンが互換性がない場合は生産アプリケーションを壊すことはできません。
パッケージごとにピン留めバージョンがあることを確認できるように、依存関係をインストールできる方法の1つの小さな例を示します。
詩で管理されたプロジェクトがあるとしましょう。そのため、ファイルpyproject.tomlにパッケージの依存関係があります。そして、おそらくファイルpoetry.lock 。
次に、Docker Multi Stage Buildingを使用してDockerfile使用できます。
FROM python:3.9 as requirements-stage
WORKDIR /tmp
RUN pip install poetry
COPY ./pyproject.toml ./poetry.lock* /tmp/
RUN poetry export -f requirements.txt --output requirements.txt --without-hashes
FROM tiangolo/uvicorn-gunicorn-fastapi:python3.11
COPY --from=requirements-stage /tmp/requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt
COPY ./app /appそれは：
./poetry.lock* （ *で終わる）を使用するため、そのファイルがまだ使用できない場合、クラッシュしません。依存関係をインストールした後にアプリコードをコピーすることが重要です。そのため、Dockerのキャッシュを活用できます。そうすれば、アプリケーションファイルを更新するたびにすべてをゼロからインストールする必要はありません。新しい依存関係を追加した場合にのみ。
これは、依存関係をインストールするために使用する他の方法にも適用されます。 requirements.txtを使用している場合は、単独でコピーして、すべての依存関係をDockerfileの上部にインストールし、その後アプリコードを追加します。
これらは、コンテナに設定して設定してデフォルト値を構成できる環境変数です。
MODULE_NAMEPython "Module"（file）は、Gunicornによってインポートされるため、このモジュールには変数に実際のアプリケーションが含まれます。
デフォルト：
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_NAMEFastAPIアプリケーションを含むPythonモジュール内の変数。
デフォルト：
appたとえば、メインのPythonファイルに次のようなものがある場合：
from fastapi import FastAPI
api = FastAPI ()
@ api . get ( "/" )
def read_root ():
return { "Hello" : "World" }この場合、 api FASTAPIアプリケーションの変数になります。あなたはそれを次のように設定することができます：
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 " myimageベース画像の構成ファイルを、あなたの出発点として使用できます。
WORKERS_PER_COREこの画像では、コンテナを実行している現在のサーバーで使用可能なCPUコアの数を確認します。
労働者の数は、この値を掛けたCPUコアの数に設定します。
デフォルト：
1あなたはそれを次のように設定することができます：
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 3 " myimage 2つのCPUコアを持つサーバーで値3使用すると、6つのワーカープロセスを実行します。
フローティングポイント値も使用できます。
したがって、たとえば、いくつかのアプリケーションを実行している大きなサーバー（たとえば、8つのCPUコアを使用して）があり、高性能が必要ないことがわかっているFASTAPIアプリケーションがある場合。そして、あなたはサーバーのリソースを無駄にしたくありません。 CPUコアごとに0.5ワーカーを使用させることができます。例えば：
docker run -d -p 80:80 -e WORKERS_PER_CORE= " 0.5 " myimage8つのCPUコアを備えたサーバーでは、4つのワーカープロセスのみを開始できます。
注：デフォルトでは、 WORKERS_PER_COREが1であり、サーバーに1人のシングルワーカーを起動する代わりに1 CPUコアしかない場合、2回開始します。これは、パフォーマンスが低いことを回避し、小型マシン（サーバーマシン/クラウド/など）でアプリケーション（サーバーアプリケーション）をブロックすることです。これは、 WEB_CONCURRENCYを使用してオーバーライドできます。
MAX_WORKERS使用する労働者の最大数を設定します。
それを使用して、イメージの数を自動的に計算することができますが、最大に制限されていることを確認できます。
これは、たとえば、各ワーカーがデータベース接続を使用し、データベースにオープン接続の最大制限がある場合に役立ちます。
デフォルトでは設定されていません。つまり、無制限であることを意味します。
あなたはそれを次のように設定することができます：
docker run -d -p 80:80 -e MAX_WORKERS= " 24 " myimageこれにより、サーバーで利用可能なCPUコアの数とは無関係に、画像が最大24人のワーカーで開始されます。
WEB_CONCURRENCY労働者数の自動定義をオーバーライドします。
デフォルト：
WORKERS_PER_COREによって乗算されます。したがって、2つのコアを持つサーバーでは、デフォルトでは2に設定されます。あなたはそれを次のように設定することができます：
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 " myimageWORKER_CLASSGunicornが労働者のために使用するクラス。
デフォルトでは、 uvicorn.workers.UvicornWorkerに設定します。
Uvicornを使用するという事実は、FastapiのようなASGIフレームワークを使用することを可能にするものであり、それが最大のパフォーマンスを提供するものでもあります。
おそらく変更すべきではありません。
ただし、何らかの理由で、代替のuvicornワーカー： uvicorn.workers.UvicornH11Workerを使用する必要がある場合は、この環境変数で設定できます。
あなたはそれを次のように設定することができます：
docker run -d -p 80:8080 -e WORKER_CLASS= " uvicorn.workers.UvicornH11Worker " myimageTIMEOUT労働者は、この数秒以上にわたって沈黙して殺され、再開されます。
Gunicorn Docs：Timeoutで詳細をご覧ください。
デフォルトでは、 120に設定します。
FastapiのようなUvicornおよびASGIフレームワークは同期ではなく非同期であることに注意してください。したがって、同期ワーカーよりも高いタイムアウトを持つことはおそらく安全です。
あなたはそれを次のように設定することができます：
docker run -d -p 80:8080 -e TIMEOUT= " 20 " myimageKEEP_ALIVEキープアライブ接続のリクエストを待つ秒数。
Gunicorn Docs：KeepAliveで詳細をご覧ください。
デフォルトでは、 2に設定します。
あなたはそれを次のように設定することができます：
docker run -d -p 80:8080 -e KEEP_ALIVE= " 20 " myimageGRACEFUL_TIMEOUT優雅な労働者のタイムアウトは再起動します。
Gunicorn Docs：Gracefultimeoutで詳細をご覧ください。
デフォルトでは、 120に設定します。
あなたはそれを次のように設定することができます：
docker run -d -p 80:8080 -e GRACEFUL_TIMEOUT= " 20 " myimageACCESS_LOG書き込みするアクセスログファイル。
デフォルトでは、 "-" 、つまりstdout（dockerログに印刷）を意味します。
ACCESS_LOG無効にする場合は、空の値に設定します。
たとえば、以下で無効にすることができます。
docker run -d -p 80:8080 -e ACCESS_LOG= myimageERROR_LOG書き込むエラーログファイル。
デフォルトでは、 "-" 、つまりstderr（dockerログに印刷）を意味します。
ERROR_LOG無効にする場合は、空の値に設定します。
たとえば、以下で無効にすることができます。
docker run -d -p 80:8080 -e ERROR_LOG= myimageGUNICORN_CMD_ARGS GUNICORN_CMD_ARGS環境変数で、Gunicornの追加のコマンドライン設定を渡すことができます。
Gunicorn Docs：settingsで詳細をご覧ください。
これらの設定は、他の環境変数とGunicorn構成ファイルよりも優先されます。
たとえば、使用するカスタムTLS/SSL証明書がある場合は、それらをDocker画像にコピーするか、コンテナにマウントして、 --keyfileと--certfileをファイルの場所に設定できます。たとえば
docker run -d -p 80:8080 -e GUNICORN_CMD_ARGS= " --keyfile=/secrets/key.pem --certfile=/secrets/cert.pem " -e PORT=443 myimage注：TLS/SSLを自分で処理してコンテナで構成する代わりに、Traefikのような「TLS終端プロキシ」を使用することをお勧めします。詳細については、HTTPSに関するFastapiドキュメントをご覧ください。
PRE_START_PATHスタート前スクリプトを見つける場所。
デフォルトでは、 /app/prestart.shに設定します。
あなたはそれを次のように設定することができます：
docker run -d -p 80:8080 -e PRE_START_PATH= " /custom/script.sh " myimage画像には、 /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上記の環境変数PRE_START_PATHを使用して、prestartスクリプトの場所をカスタマイズできます。
実行されるデフォルトプログラムは/start.shです。上記のすべてを行います。
また、Live Auto-Reloadを使用した開発用バージョンもあります。
/start-reload.sh開発のために、アプリケーションコードのコンテンツをコンテナ内にドッカーの「ホストボリューム」として取り付け、コードを変更してライブでテストできるようにすることができます。
その場合、ライブAuto-Reloadでサーバーを実行すると、すべてのコード変更で自動的に再起動することも役立ちます。
追加のScript /start-reload.shは、Uvicornを単独で（Gunicornなし）、単一のプロセスで実行します。
開発に最適です。
たとえば、実行する代わりに：
docker run -d -p 80:80 myimage実行できます：
docker run -d -p 80:80 -v $( pwd ) :/app myimage /start-reload.sh-v $(pwd):/app ：ディレクトリ$(pwd)は/appのコンテナ内のボリュームとしてマウントする必要があることを意味します。$(pwd) ： pwd （ "Print Working Directory"）を実行し、文字列の一部として配置します。/start-reload.sh ：コマンドの最後に何か（ /start-reload.shなど）を追加すると、デフォルトの「コマンド」をこれに置き換えます。この場合、デフォルト（ /start.sh ）を開発の代替/start-reload.shに置き換えます。 /start-reload.shがgunicornで実行されないため、 gunicorn_conf.pyファイルに入れた構成は適用されません。
しかし、これらの環境変数は上記と同じように機能します。
MODULE_NAMEVARIABLE_NAMEAPP_MODULEHOSTPORTLOG_LEVEL要するに、おそらくPythonプロジェクトにAlpineを使用してはいけません。代わりに、 slim Dockerイメージバージョンを使用してください。
詳細が必要ですか？読み続けますか？
Alpineは、1つのDocker画像段階（マルチステージDockerビルディングを使用）で静的バイナリを構築し、単純なAlpineイメージにコピーして、そのバイナリを実行する他の言語により便利です。たとえば、goを使用します。
しかし、Pythonの場合、AlpineはPython拡張機能の構築に使用される標準ツーリングを使用していないため、パッケージをインストールするときにPython（ pip ）が多くの場合、Alpine用の事前コンパイルされたインストール可能なパッケージ（「ホイール」）が見つかりません。そして、多くの奇妙なエラーをデバッグした後、これらの一般的なPythonパッケージの一部を使用するためだけに、多くの追加のツールをインストールし、多くの依存関係を構築する必要があることに気付くでしょう。 ？
つまり、元の高山画像は小さいかもしれませんが、標準のPython画像（Debianに基づいて）を使用した場合、または場合によってはさらに大きい場合に、サイズに匹敵するサイズのサイズの画像になります。 ？
そして、これらのすべての場合、ビルドにはるかに時間がかかり、より多くのリソースを消費し、依存関係をより長く構築し、各ビルドにCPU時間とエネルギーを使用しているため、二酸化炭素排出量を増やします。 ？
Slim Python画像が必要な場合は、代わりにDebianに基づいているがslimバージョンを試してみてください。 ？
すべての画像タグ、構成、環境変数、アプリケーションオプションがテストされています。
--workersを使用します。 @tiangoloによるPR＃303。issue-manager.ymlを更新します。 @tiangoloによるPR＃343。latest-changes GitHubアクションを更新します。 @tiangoloによるPR＃340。latest-changes.ymlを更新します。 @alejsdevによるPR＃276。README.mdのテストバッジを更新します。 @alejsdevによるPR＃275。README.mdのテストバッジを更新します。 PR＃274 by @alejsdev。 このリリースのハイライト：
python3.6-2022-11-25です。slimバージョンを追加します。 PR＃40。WORKER_CLASSTIMEOUTKEEP_ALIVEGRACEFUL_TIMEOUTACCESS_LOGERROR_LOGGUNICORN_CMD_ARGSMAX_WORKERSPRE_START_PATH env varのドキュメントを追加します。 PR＃33。tiangolo/uvicorn-gunicorn-fastapi:python3.7-2019-10-15など、env varsを使用してビルド日ごとに画像タグを追加するリファクタントテスト。 PR＃17。/start-reload.shを使用して、ライブオートレロードのサポートを追加し、更新されたドキュメントを確認してください。親画像のPR＃6。WORKERS_PER_COREで1に設定します。WEB_CONCURRENCYが設定されていない場合、最低2人の労働者にデフォルトのWeb並行性を作成します。これは、小さなマシン（サーバーマシン/クラウド/など）でのパフォーマンスの低下とブロックアプリケーション（サーバーアプリケーション）を避けるためです。これは、 WEB_CONCURRENCYを使用してオーバーライドできます。これは、 WORKERS_PER_COREが1 （デフォルト）に設定され、サーバーには1つのCPUコアしか設定されていない場合に適用されます。親画像のPR＃6とPR＃5。/start.shを独立して実行し、使用したデフォルトの環境変数を読み取り、生成します。 /entrypoint.shを削除すると、システム内の何も変更せず、環境変数のみを読み取ります。親画像のPR＃4。/app/prestart.shのサポートを追加します。 このプロジェクトは、MITライセンスの条件に基づいてライセンスされています。
