コンテナ内のFastAPI - Docker¶

FastAPIアプリケーションをデプロイする際、一般的なアプローチはLinuxコンテナイメージを構築することです。これは通常、Dockerを使用して行われます。その後、そのコンテナイメージをいくつかの可能な方法でデプロイできます。

Linuxコンテナを使用することには、セキュリティ、再現性、シンプルさなど、いくつかの利点があります。

ヒント

急いでいて、すでにこれらを知っている方へ？以下のDockerfileにジャンプしてください👇。

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 ["fastapi", "run", "app/main.py", "--port", "80"]

# If running behind a proxy like Nginx or Traefik add --proxy-headers
# CMD ["fastapi", "run", "app/main.py", "--port", "80", "--proxy-headers"]

コンテナとは¶

コンテナ（主にLinuxコンテナ）は、アプリケーションとそのすべての依存関係と必要なファイルを、同じシステム内の他のコンテナ（他のアプリケーションやコンポーネント）から分離しつつ、非常に軽量にパッケージ化する方法です。

Linuxコンテナは、ホスト（マシン、仮想マシン、クラウドサーバーなど）の同じLinuxカーネルを使用して実行されます。これは、それらが非常に軽量であること（OS全体をエミュレートする完全な仮想マシンと比較して）を意味します。

この方法により、コンテナは少ないリソースしか消費せず、プロセスを直接実行するのと同程度の量です（仮想マシンははるかに多く消費します）。

コンテナはまた、独自の分離された実行中のプロセス（通常は1つのプロセス）、ファイルシステム、およびネットワークを持ち、デプロイ、セキュリティ、開発などを簡素化します。

コンテナイメージとは¶

コンテナはコンテナイメージから実行されます。

コンテナイメージは、コンテナ内に存在するすべてのファイル、環境変数、およびデフォルトのコマンド/プログラムの静的バージョンです。ここでの静的とは、コンテナイメージが実行されておらず、実行されていないことを意味します。それはパッケージ化されたファイルとメタデータにすぎません。

保存された静的コンテンツである「コンテナイメージ」とは対照的に、「コンテナ」は通常、実行中のインスタンス、つまり実行されているものを指します。

コンテナが起動して実行中（コンテナイメージから起動）の場合、ファイルや環境変数などを作成または変更できます。これらの変更はそのコンテナ内のみに存在しますが、基盤となるコンテナイメージには永続化されません（ディスクに保存されません）。

コンテナイメージは、プログラムファイルとコンテンツ、たとえばpythonとファイルmain.pyに例えることができます。

そして、コンテナ自体（コンテナイメージとは対照的に）は、イメージの実際の実行中のインスタンスであり、プロセスに例えることができます。実際、コンテナはプロセスが実行されている場合にのみ実行されます（通常は単一のプロセスのみ）。コンテナ内でプロセスが実行されていない場合、コンテナは停止します。

コンテナイメージ¶

Dockerは、コンテナイメージとコンテナを作成および管理するための主要なツールの1つです。

そして、多くのツール、環境、データベース、アプリケーション向けの事前に作成された公式コンテナイメージを備えた公開Docker Hubがあります。

たとえば、公式のPythonイメージがあります。

そして、データベースなど、さまざまなものに対応する他の多くのイメージがあります。たとえば、

事前に作成されたコンテナイメージを使用することで、さまざまなツールを組み合わせて使用することが非常に簡単になります。たとえば、新しいデータベースを試す場合などです。ほとんどの場合、公式イメージを使用し、環境変数で構成するだけで済みます。

そうすることで、多くの場合、コンテナとDockerについて学び、その知識をさまざまなツールやコンポーネントで再利用できます。

したがって、データベース、Pythonアプリケーション、Reactフロントエンドアプリケーションを備えたWebサーバーなど、さまざまなものを使用して複数のコンテナを実行し、それらを内部ネットワーク経由で接続することになります。

すべてのコンテナ管理システム（DockerやKubernetesなど）には、これらのネットワーク機能が統合されています。

コンテナとプロセス¶

コンテナイメージには通常、コンテナが起動されたときに実行されるべきデフォルトのプログラムまたはコマンドと、そのプログラムに渡されるパラメーターがメタデータに含まれています。これはコマンドラインの場合と非常に似ています。

コンテナが起動されると、そのコマンド/プログラムが実行されます（ただし、それをオーバーライドして別のコマンド/プログラムを実行させることもできます）。

コンテナは、メインプロセス（コマンドまたはプログラム）が実行されている限り実行されます。

コンテナは通常単一のプロセスを持ちますが、メインプロセスからサブプロセスを起動することも可能で、そのようにして同じコンテナ内に複数のプロセスを持つことができます。

しかし、少なくとも1つの実行中のプロセスなしで実行中のコンテナを持つことはできません。メインプロセスが停止すると、コンテナも停止します。

FastAPI用Dockerイメージの構築¶

さて、それでは何か構築しましょう！🚀

公式Pythonイメージに基づいて、FastAPI用のDockerイメージをゼロから構築する方法を紹介します。

これは、ほとんどの場合にやりたいことでしょう。たとえば、

Kubernetesまたは同様のツールを使用する場合
Raspberry Piで実行する場合
コンテナイメージを実行するクラウドサービスを使用する場合など

パッケージ要件¶

通常、アプリケーションのパッケージ要件はファイルに記載されています。

これは主に、それらの要件をインストールするために使用するツールによって異なります。

最も一般的な方法は、パッケージ名とそのバージョンを1行に1つずつ記載したrequirements.txtファイルを持つことです。

もちろん、バージョン範囲を設定するには、FastAPIのバージョンについてで読んだのと同じアイデアを使用します。

たとえば、requirements.txtは次のようになるでしょう。

fastapi[standard]>=0.113.0,<0.114.0
pydantic>=2.7.0,<3.0.0

そして、通常、これらのパッケージ依存関係はpipでインストールします。たとえば、

$ pip install -r requirements.txt
---> 100%
Successfully installed fastapi pydantic

情報

パッケージの依存関係を定義およびインストールするための他の形式やツールもあります。

FastAPI コードの作成¶

appディレクトリを作成し、そこに入ります。
空のファイル__init__.pyを作成します。
次の内容でmain.pyファイルを作成します。

from typing import Union

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: Union[str, None] = None):
    return {"item_id": item_id, "q": q}

Dockerfile¶

次に、同じプロジェクトディレクトリに、次の内容で`Dockerfile`を作成します。

# (1)!
FROM python:3.9

# (2)!
WORKDIR /code

# (3)!
COPY ./requirements.txt /code/requirements.txt

# (4)!
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt

# (5)!
COPY ./app /code/app

# (6)!
CMD ["fastapi", "run", "app/main.py", "--port", "80"]

公式のPythonベースイメージから開始します。
現在の作業ディレクトリを /code に設定します。

ここに requirements.txt ファイルと app ディレクトリを置きます。
要件ファイルを作成し、/code ディレクトリにコピーします。

他のコードではなく、まず要件ファイルのみをコピーします。

このファイルは頻繁に変更されないため、Dockerはそれを検出し、このステップにキャッシュを使用し、次のステップにもキャッシュを有効にします。
要件ファイル内のパッケージ依存関係をインストールします。

--no-cache-dirオプションは、ダウンロードしたパッケージをローカルに保存しないようにpipに指示します。これは、pipが同じパッケージを再度インストールするために実行される場合にのみ必要ですが、コンテナを使用する場合はそうではありません。

注記

--no-cache-dirはpipにのみ関連し、Dockerやコンテナとは関係ありません。

--upgradeオプションは、パッケージが既にインストールされている場合にアップグレードするようにpipに指示します。

前のステップでのファイルコピーがDockerキャッシュによって検出される可能性があるため、このステップも利用可能な場合はDockerキャッシュを使用します。

このステップでキャッシュを使用すると、開発中にイメージを何度も再構築する際に、依存関係を毎回ダウンロードしてインストールする代わりに、多くの時間を節約できます。
./app ディレクトリを /code ディレクトリ内にコピーします。

これは最も頻繁に変更されるすべてのコードを含むため、Dockerのキャッシュは、このステップや以降のステップには簡単に使用されません。

そのため、コンテナイメージのビルド時間を最適化するために、これをDockerfileの最後の方に配置することが重要です。
Uvicornを内部で使用する fastapi run を使用するようコマンドを設定します。

CMD は文字列のリストを受け取ります。これらの文字列のそれぞれは、コマンドラインでスペースで区切って入力するものです。

このコマンドは、上記の WORKDIR /code で設定したのと同じ 現在の作業ディレクトリ、つまり /code ディレクトリから実行されます。

ヒント

コードの各番号バブルをクリックして、各行が何をするかを確認してください。👆

警告

以下で説明するように、CMD命令のexec形式を常に使用するようにしてください。

`CMD` の使用 - Exec 形式¶

CMD Docker命令は2つの形式で記述できます。

✅ Exec 形式

# ✅ Do this
CMD ["fastapi", "run", "app/main.py", "--port", "80"]

⛔️ シェル形式

# ⛔️ Don't do this
CMD fastapi run app/main.py --port 80

FastAPIが正常にシャットダウンし、ライフサイクルイベントがトリガーされるように、常にexec形式を使用してください。

詳細については、シェルとexec形式に関するDockerドキュメントをご覧ください。

これはdocker composeを使用する場合にかなり顕著になることがあります。詳細な技術情報については、このDocker Compose FAQセクションをご覧ください: なぜ私のサービスは再作成または停止に10秒かかるのですか？。

ディレクトリ構造¶

現在、次のようなディレクトリ構造になっているはずです。

.
├── app
│   ├── __init__.py
│   └── main.py
├── Dockerfile
└── requirements.txt

TLS終端プロキシの背後¶

Nginx や Traefik のような TLS 終端プロキシ (ロードバランサー) の背後でコンテナを実行している場合、--proxy-headers オプションを追加してください。これにより、Uvicorn (FastAPI CLI 経由で) は、アプリケーションが HTTPS の背後で実行されていることなどを伝えるプロキシによって送信されたヘッダーを信頼するようになります。

CMD ["fastapi", "run", "app/main.py", "--proxy-headers", "--port", "80"]

Dockerキャッシュ¶

このDockerfileには重要なトリックがあります。まず、残りのコードではなく、依存関係を含むファイルだけをコピーします。その理由を説明します。

COPY ./requirements.txt /code/requirements.txt

Dockerやその他のツールは、Dockerfileの先頭から開始し、Dockerfileの各命令によって作成されたファイルを追加して、これらのコンテナイメージを段階的に構築し、互いの上に1つのレイヤーを追加します。

Dockerや同様のツールは、イメージの構築時に内部キャッシュも使用します。コンテナイメージの最後の構築以来ファイルが変更されていない場合、ファイルを再度コピーして新しいレイヤーをゼロから作成する代わりに、前回作成された同じレイヤーを再利用します。

ファイルをコピーするのを避けるだけでは、あまり改善されませんが、そのステップでキャッシュを使用したため、次のステップでもキャッシュを使用できます。たとえば、次の方法で依存関係をインストールする命令にキャッシュを使用できます。

RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt

パッケージ要件ファイルは頻繁に変更されません。そのため、そのファイルだけをコピーすることで、Dockerはそのステップにキャッシュを使用できるようになります。

そして、Dockerは次のステップ（これらの依存関係をダウンロードしてインストールするステップ）にキャッシュを使用できるようになります。ここで、私たちは多くの時間を節約します。✨ ...そして退屈な待ち時間を避けます。😪😆

パッケージの依存関係をダウンロードしてインストールするには数分かかることがありますが、キャッシュを使用すればせいぜい数秒で済みます。

開発中にコードの変更が機能していることを確認するためにコンテナイメージを何度も構築するでしょうから、これによりかなりの累積時間が節約されます。

次に、Dockerfileの終わり近くで、すべてのコードをコピーします。これが最も頻繁に変更されるものであるため、このステップ以降のものはほとんど常にキャッシュを使用できないため、最後に配置します。

COPY ./app /code/app

Dockerイメージの構築¶

これで全てのファイルが揃ったので、コンテナイメージを構築しましょう。

プロジェクトディレクトリ（Dockerfileがあり、appディレクトリを含む場所）に移動します。
FastAPIイメージをビルドします

$ docker build -t myimage .

---> 100%

ヒント

末尾の.に注意してください。これは./と同じで、コンテナイメージを構築するために使用するディレクトリをDockerに伝えます。

この場合、それは現在のディレクトリ (.) です。

Dockerコンテナの起動¶

イメージに基づいてコンテナを実行

$ docker run -d --name mycontainer -p 80:80 myimage

確認¶

DockerコンテナのURL、たとえばhttp://192.168.99.100/items/5?q=somequeryまたはhttp://127.0.0.1/items/5?q=somequery（またはDockerホストを使用する同等のもの）で確認できるはずです。

次のような表示になります。

{"item_id": 5, "q": "somequery"}

インタラクティブ API ドキュメント¶

次に、http://192.168.99.100/docsまたはhttp://127.0.0.1/docs（または同等のDockerホストを使用）にアクセスできます。

自動インタラクティブ API ドキュメント (Swagger UI が提供) が表示されます。

Swagger UI

代替 API ドキュメント¶

そして、http://192.168.99.100/redoc または http://127.0.0.1/redoc (または、Docker ホストを使用する同等のもの) にもアクセスできます。

代替の自動ドキュメント (ReDoc が提供) が表示されます。

ReDoc

単一ファイルFastAPIでDockerイメージを構築¶

FastAPIが単一ファイル、たとえば./appディレクトリのないmain.pyである場合、ファイル構造は次のようになります。

.
├── Dockerfile
├── main.py
└── requirements.txt

次に、Dockerfile内でファイルをコピーするための対応するパスを変更するだけです。

FROM python:3.9

WORKDIR /code

COPY ./requirements.txt /code/requirements.txt

RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt

# (1)!
COPY ./main.py /code/

# (2)!
CMD ["fastapi", "run", "main.py", "--port", "80"]

main.pyファイルを/codeディレクトリに直接コピーします（./appディレクトリなし）。
fastapi run を使用して、単一ファイル main.py でアプリケーションを提供します。

fastapi run にファイルを渡すと、それが単一ファイルでありパッケージの一部ではないことを自動的に検出し、FastAPIアプリをインポートして提供する方法を認識します。😎

デプロイのコンセプト¶

コンテナの観点から、同じデプロイメントの概念について再度説明しましょう。

コンテナは主に、アプリケーションの構築とデプロイのプロセスを簡素化するためのツールですが、これらのデプロイメントの概念を扱う特定のアプローチを強制するものではなく、いくつかの可能な戦略があります。

良いニュースは、異なる戦略ごとに、すべてのデプロイメントの概念をカバーする方法があることです。🎉

これらのデプロイメントの概念をコンテナの観点から確認しましょう。

HTTPS
起動時の実行
再起動
レプリケーション（実行中のプロセス数）
メモリ
起動前の事前準備

HTTPS¶

FastAPIアプリケーションのコンテナイメージ（および後で実行されるコンテナ）だけに焦点を当てると、HTTPSは通常、別のツールによって外部で処理されます。

それは、たとえばTraefikのような別のコンテナで、HTTPSと証明書の自動取得を処理する可能性があります。

ヒント

TraefikはDocker、Kubernetesなどと統合されているため、コンテナのHTTPSを非常に簡単にセットアップおよび設定できます。

または、HTTPSはクラウドプロバイダーがサービスとして処理することもできます（アプリケーションはコンテナ内で実行され続けます）。

起動時と再起動時の実行¶

通常、コンテナの起動と実行を担当する別のツールがあります。

それは、Docker、Docker Compose、Kubernetes、クラウドサービスなどです。

ほとんど（またはすべて）の場合、起動時にコンテナを実行し、障害時に再起動を有効にするためのシンプルなオプションがあります。たとえば、Dockerではコマンドラインオプション--restartです。

コンテナを使用しない場合、アプリケーションを起動時に実行し、再起動を伴うようにするのは面倒で難しい場合があります。しかし、コンテナを使用する場合、ほとんどの場合、その機能はデフォルトで含まれています。✨

レプリケーション - プロセスの数¶

Kubernetes、Docker Swarm Mode、Nomad、または複数のマシンに分散コンテナを管理する他の同様の複雑なシステムを備えたクラスターがある場合、各コンテナでプロセスマネージャー（ワーカー付きのUvicornなど）を使用するのではなく、クラスターレベルでレプリケーションを処理したいと思うでしょう。

Kubernetesのような分散コンテナ管理システムの1つは、通常、着信リクエストに対するロードバランシングをサポートしながら、コンテナのレプリケーションを処理する統合された方法を持っています。すべてクラスターレベルで行われます。

そのような場合、上記で説明したように、依存関係をインストールし、複数のUvicornワーカーを使用する代わりに単一のUvicornプロセスを実行して、Dockerイメージをゼロから構築したいと思うでしょう。

ロードバランサー¶

コンテナを使用する場合、通常、主要なポートでリッスンしているコンポーネントがあります。これは、HTTPSや同様のツールを処理するTLS終端プロキシでもある別のコンテナである可能性があります。

このコンポーネントはリクエストの負荷を受け取り、（できれば）バランスの取れた方法でワーカー間で分散するため、一般的にロードバランサーとも呼ばれます。

ヒント

HTTPSに使用されるのと同じTLS終端プロキシコンポーネントは、おそらくロードバランサーでもあります。

コンテナを操作する場合、それらを起動および管理するために使用するのと同じシステムに、そのロードバランサー（TLS終端プロキシでもある可能性がある）からアプリを含むコンテナへのネットワーク通信（HTTPリクエストなど）を送信するための内部ツールがすでに組み込まれています。

1つのロードバランサー - 複数のワーカーコンテナ¶

Kubernetes または同様の分散コンテナ管理システムを使用する場合、その内部ネットワークメカニズムにより、メインのポートでリッスンしている単一のロードバランサーが、アプリを実行している複数のコンテナに通信（リクエスト）を送信できるようになります。

これらのアプリを実行している各コンテナは、通常、1つのプロセスのみ（例：FastAPIアプリケーションを実行しているUvicornプロセス）を持ちます。これらはすべて同一のコンテナであり、同じものを実行しますが、それぞれ独自のプロセス、メモリなどを持っています。これにより、CPUの異なるコアや、異なるマシンでさえ並列化の利点を活用できます。

そして、ロードバランサーを備えた分散コンテナシステムは、アプリを実行している各コンテナに順番にリクエストを分散します。したがって、各リクエストは、アプリを実行している複数のレプリケートされたコンテナの1つによって処理される可能性があります。

そして通常、このロードバランサーは、クラスター内の他のアプリ（例：異なるドメイン、または異なるURLパスプレフィックスの下）にアクセスするリクエストを処理し、その通信をクラスターで実行されているその他のアプリケーションの正しいコンテナに送信できます。

コンテナあたり1プロセス¶

このようなシナリオでは、クラスターレベルですでにレプリケーションを処理しているため、コンテナごとに単一の（Uvicorn）プロセスを持つことをお勧めします。

したがって、この場合、コンテナ内に複数のワーカーを持つこと（たとえば、--workersコマンドラインオプションを使用すること）は望ましくありません。コンテナごとに単一のUvicornプロセスを持つことだけを望むでしょう（ただし、おそらく複数のコンテナ）。

コンテナ内に別のプロセスマネージャーを持つこと（複数のワーカーの場合のように）は、クラスターシステムで既に対応している可能性が最も高い不必要な複雑さを追加するだけです。

複数プロセスを持つコンテナと特殊なケース¶

もちろん、内部に複数の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

# (1)!
CMD ["fastapi", "run", "app/main.py", "--port", "80", "--workers", "4"]

ここでは、--workersコマンドラインオプションを使用して、ワーカー数を4に設定しています。

それが理にかなっているいくつかの例を挙げます。

シンプルなアプリ¶

アプリケーションが十分シンプルで、クラスターではなく単一のサーバーで実行できる場合、コンテナ内にプロセスマネージャーが必要になることがあります。

Docker Compose¶

Docker Composeを使用して単一サーバー（クラスターではない）にデプロイしている場合、共有ネットワークとロードバランシングを維持しながら、コンテナのレプリケーションを（Docker Composeで）簡単に管理する方法がない可能性があります。

その場合、内部でいくつかのワーカープロセスを開始するプロセスマネージャーを持つ単一のコンテナが必要になることがあります。

重要なのは、これらのどれも絶対的なルールではないということです。これらのアイデアを使用して、自身のユースケースを評価し、システムの最適なアプローチを決定し、次の概念を管理する方法を確認できます。

セキュリティ - HTTPS
起動時の実行
再起動
レプリケーション（実行中のプロセス数）
メモリ
起動前の事前準備

メモリ¶

コンテナごとに単一のプロセスを実行する場合、各コンテナによって消費されるメモリ量は、多かれ少なかれ明確に定義され、安定し、制限された量になります（レプリケートされている場合は複数）。

そして、これらの同じメモリ制限と要件をコンテナ管理システムの構成（たとえばKubernetesなど）に設定できます。そうすることで、それらが必要とするメモリ量と、クラスター内のマシンで利用可能なメモリ量を考慮して、利用可能なマシンにコンテナを複製できるようになります。

アプリケーションがシンプルな場合、これはおそらく問題になりませんし、厳密なメモリ制限を指定する必要もないかもしれません。しかし、多くのメモリを使用している場合（たとえば機械学習モデルを使用している場合）、消費しているメモリ量を確認し、各マシンで実行されるコンテナの数を調整する必要があります（そして、クラスターにマシンを追加することもできます）。

コンテナごとに複数のプロセスを実行する場合、開始されたプロセスの数が利用可能なメモリよりも多くならないようにする必要があります。

起動前とコンテナ前の手順¶

コンテナ (例: Docker、Kubernetes) を使用している場合、主に2つのアプローチがあります。

複数のコンテナ¶

複数のコンテナがあり、それぞれが単一のプロセスを実行している場合（たとえばKubernetesクラスターで）、おそらく、レプリケートされたワーカーコンテナを実行する前に、単一のコンテナで以前のステップの作業を行う別のコンテナが必要になるでしょう。

情報

Kubernetesを使用している場合、これはおそらくInit Containerになるでしょう。

ユースケースでそれらの前のステップを複数回並行して実行しても問題ない場合（たとえば、データベースの移行を実行しているのではなく、データベースの準備ができているかどうかを確認しているだけの場合）、それらをメインプロセスを開始する直前に各コンテナに配置することもできます。

単一コンテナ¶

複数のワーカープロセス（または単一のプロセス）を起動する単一のコンテナというシンプルな設定の場合、アプリのプロセスを開始する直前に、同じコンテナ内で以前のステップを実行できます。

ベースDockerイメージ¶

以前は公式のFastAPI Dockerイメージがありました。tiangolo/uvicorn-gunicorn-fastapi。しかし、現在は非推奨です。⛔️

このベースDockerイメージ（またはその他の類似のもの）は使用しないことをお勧めします。

Kubernetes (またはその他) を使用しており、クラスターレベルで既にレプリケーションを複数のコンテナで設定している場合。これらのケースでは、FastAPI用Dockerイメージの構築で説明したように、イメージをゼロから構築する方が良いでしょう。

複数のワーカーが必要な場合は、--workersコマンドラインオプションを使用するだけで済みます。

技術的な詳細

このDockerイメージは、Uvicornがデッドワーカーの管理と再起動をサポートしていなかった頃に作成されたもので、Uvicornワーカープロセスを管理・再起動するためにGunicornとUvicornを組み合わせる必要があり、かなりの複雑さを加えていました。

しかし、現在ではUvicorn（およびfastapiコマンド）が--workersの使用をサポートしているため、ベースDockerイメージを使用する代わりに独自のイメージを構築する理由はありません（ほとんど同じ量のコードです😅）。

コンテナイメージのデプロイ¶

コンテナ（Docker）イメージを作成した後、デプロイするにはいくつかの方法があります。

例えば

単一サーバーでのDocker Compose
Kubernetesクラスター
Docker Swarm Modeクラスター
Nomadなどの別のツールを使用
コンテナイメージを受け取ってデプロイするクラウドサービスを使用

`uv` を使用したDockerイメージ¶

uv を使用してプロジェクトをインストールおよび管理している場合は、彼らのuv Dockerガイドに従うことができます。

まとめ¶

コンテナシステム（DockerとKubernetesなど）を使用すると、すべてのデプロイメントの概念を扱うのが非常に簡単になります。

HTTPS
起動時の実行
再起動
レプリケーション（実行中のプロセス数）
メモリ
起動前の事前準備

ほとんどの場合、ベースイメージは使用せず、代わりに公式のPython Dockerイメージに基づいてゼロからコンテナイメージを構築することをお勧めします。

Dockerfile内の命令の順序とDockerキャッシュに注意を払うことで、ビルド時間を最小限に抑え、生産性を最大化し（そして退屈を避けます）。😎