部署

部署FastAPI應用程序相對容易。

• 部署是什么意思

部署應用程序意味著執行必要的步驟以使其可供用戶使用。

對于Web API來說，通常涉及將上傳到云服務器中，搭配一個性能和穩定性都不錯的服務器程序，以便你的用戶可以高效地訪問你的應用程序，而不會出現中斷或其他問題。

這與開發階段形成鮮明對比，在開發階段，你不斷更改代碼、破壞代碼、修復代碼，來回停止和重啟服務器等。

• 部署策略

根據你的使用場景和使用的工具，有多種方法可以實現此目的。

你可以使用一些工具自行部署服務器，你也可以使用能為你完成部分工作的云服務，或其他可能的選項。

關于FastAPI版本

FastAPI已在許多應用程序和系統的生產環境中使用。并且測試覆蓋率保持在100%。但其開發進度仍在快速推進。

經常添加新功能，定期修復錯誤，并且代碼仍在持續改進。

這就是為什么當前版本仍然是0.x.x，這反映出每個版本都可能有Breaking changes。這遵循語義版本控制的約定。

你現在就可以使用FastAPI創建生產環境應用程序，你只需確保使用的版本可以與其余代碼正確配合即可。

固定你的fastapi版本

你應該做的第一件事是將你正在使用的FastAPI版本”固定“到你知道適用于你的應用程序的特定最新版本。

例如，假設你在應用程序中使用版本0.45.0。

如果你使用requirements.txt文件，你可以使用以下命令指定版本：

fastapi==0.45.0

這意味著你將使用版本0.45.0。

或者你也可以將其固定為：

fastapi>=0.45.0,<0.46.0

這意味著你將使用0.45.0或更高版本，但低于0.46.0，例如，版本0.45.2仍會被接受。

關于HTTPS

人們很容易認為HTTPS僅僅是”啟用“或”未啟用“的東西。

但實際情況筆者復雜得多。

要從用戶的視角了解HTTPS的基礎知識，請查看https://howhttps.works/。

現在，從開發人員的視角，在了解HTTPS時需要記住以下幾點：

• 要使用HTTPS，服務器需要擁有由第三方生成的”證書（certificate）“。
• • 這些證書實際上是從第三方獲取的，而不是”生成“的。
• 證書有生命周期。
• • 它們會過期。
• • 然后它們需要更新，再次從第三方獲取。
• 連接的加密發生在TCP層。
• • 這是HTTP協議下面的一層。
• • 因此，證書和加密處理是在HTTP之前完成的。
• TCP不知道域名。僅僅知道IP地址。
• • 有關所請求的特定域名的信息位于HTTP數據中。
• HTTPS證書”證明“某個域名，但協議和加密發生在TCP層，在知道正在處理哪個域名之前。
• 默認情況下，這意味著你每個IP地址只能擁有一個HTTPS證書。
• • 無論你的服務器有多大，或者服務器上的每個應用程序有多小。
• • 不過，對此有一個解決方案。
• TLS協議（在HTTP之下的TCP層處理加密的協議）有一個擴展，稱為SNI。
• • SNI擴展允許一臺服務器（具有單個IP地址）擁有多個HTTPS證書并提供多個HTTPS域名/應用程序。
• 為此，服務器上會有單獨的一個組件（程序）偵聽公共IP地址，這個組件必須擁有服務器中的所有HTTPS證書。
• 獲得安全連接后，通信協議仍然是HTTP。
• • 內容時加密過的，即使它們是通過HTTP協議發送的。

通常的做法是在服務器上運行一個程序/HTTP服務器并管理所有HTTPS部分：接收加密的HTTPS請求，將解密的HTTP請求發送到在同一服務器中運行的實際HTTP應用程序（在本例中那個為FastAPI應用程序），從應用程序中獲取HTTP響應，使用適當的HTTPS證書對其進行加密并使用HTTPS將其發送回客戶端。此服務器通常被稱為TLS終止代理。

你可以用作TLS終止代理的一些選項包括：

• Traefik（也可以處理證書更新）
• Caddy（也可以處理證書更新）
• Nginx
• HAProxy

Let’s Encrypt

在Let’s Encrypt之前，這些HTTPS證書由受信任的第三方出售。

過去，獲得這些證書的過程非常繁瑣，需要大量的文書工作，而且證書非常昂貴。

但隨后Let‘s Encrypt創建了。

它是Linux基金會的一個項目。它以自動方式免費提供HTTPS證書。這些證書可以使用所有符合標準的安全加密，并且有效期很短（大約3個月），因此安全性實際上更好，因為它們的生命周期縮短了。

域可以被安全地驗證并自動生成證書。這還允許自動更新這些證書。

我們的想法是自動獲取和更新這些證書，以便你可以永遠免費擁有安全地HTTPS。

面向開發人員的HTTPS

這里有一個HTTPS API看起來是什么樣的示例，我們會分布說明，并且主要關注對開發人員重要的部分。

域名

第一步我們要先獲取一些域名（Domain Name）。然后可以在DNS服務器（可能是你的同一家云服務器提供的）中配置它。

你可能擁有一個云服務器（虛擬機）或類似的東西，并且它會有一個固定公共IP地址。

在DNS服務器中，你可以配置一條記錄（”A記錄“）以將你的域名指向你服務器的公共IP地址。

這個操作一般只需要在最開始執行一次。

DNS

現在讓我們關注真正的HTTPS部分。

首先，瀏覽器將通過DNS 服務器查詢域名的IP是什么，在本例中為someapp.example.com。

DNS服務器會告訴瀏覽器使用某個特定的IP地址。這將是你在DNS服務器中為你的服務器配置的公共IP地址。

TLS握手開始

然后，瀏覽器將在端口443（HTTPS端口）上與該IP地址進行通信。

通信的第一部分只是建立客戶端和服務器之間的連接并決定它們將使用的加密密鑰等。

客戶端和服務器之間建立TLS連接的過程稱為TLS握手。

帶有SNI擴展的TLS

服務器中只有一個進程可以偵聽特定IP地址的特定端口。可能有其他進程在同一IP地址的其他端口上偵聽，但每個IP地址和端口組合只有一個進程。

TLS（HTTPS）默認使用端口443。這就是我們需要的端口。

由于只有一個進程可以監聽此端口，因此監聽端口的進程將是TLS終止代理。

TLS終止代理可以訪問一個或多個TLS證書（HTTPS證書）。

使用上面討論的SNI擴展，TLS終止代理將檢查應該用于此連接的可用TLS（HTTPS）證書，并使用與客戶端期望的域名相匹配的證書，

在這種情況下，它將使用someapp.example.com的證書。

客戶端已經信任生成該 TLS 證書的實體（在本例中為 Let’s Encrypt，但我們稍后會看到），因此它可以驗證該證書是否有效。

然后，通過使用證書，客戶端和 TLS 終止代理 決定如何加密 TCP 通信 的其余部分。 這就完成了 TLS 握手 部分。

此后，客戶端和服務器就擁有了加密的 TCP 連接，這就是 TLS 提供的功能。 然后他們可以使用該連接來啟動實際的 HTTP 通信。

這就是 HTTPS，它只是 安全 TLS 連接 內的普通 HTTP，而不是純粹的（未加密的）TCP 連接。

HTTPS請求

現在客戶端和服務器（特別是瀏覽器和 TLS 終止代理）具有 加密的 TCP 連接，它們可以開始 HTTP 通信。

接下來，客戶端發送一個 HTTPS 請求。 這其實只是一個通過 TLS 加密連接的 HTTP 請求。

解密請求

TLS 終止代理將使用協商好的加密算法解密請求，并將（解密的）HTTP 請求傳輸到運行應用程序的進程（例如運行 FastAPI 應用的 Uvicorn 進程）。

HTTP響應

應用程序將處理請求并向 TLS 終止代理發送（未加密）HTTP 響應。

HTTPS響應

然后，TLS 終止代理將使用之前協商的加密算法（以someapp.example.com的證書開頭）對響應進行加密，并將其發送回瀏覽器。

接下來，瀏覽器將驗證響應是否有效和是否使用了正確的加密密鑰等。然后它會解密響應并處理它。

客戶端（瀏覽器）將知道響應來自正確的服務器，因為它使用了他們之前使用 HTTPS 證書 協商出的加密算法。

多個應用程序

在同一臺（或多臺）服務器中，可能存在多個應用程序，例如其他 API 程序或數據庫。

只有一個進程可以處理特定的 IP 和端口（在我們的示例中為 TLS 終止代理），但其他應用程序/進程也可以在服務器上運行，只要它們不嘗試使用相同的 公共 IP 和端口的組合。

這樣，TLS 終止代理就可以為多個應用程序處理多個域名的 HTTPS 和證書，然后在每種情況下將請求傳輸到正確的應用程序。

證書更新

在未來的某個時候，每個證書都會過期（大約在獲得證書后 3 個月）。

然后，會有另一個程序（在某些情況下是另一個程序，在某些情況下可能是同一個 TLS 終止代理）與 Let’s Encrypt 通信并更新證書。

TLS 證書 與域名相關聯，而不是與 IP 地址相關聯。

因此，要更新證書，更新程序需要向權威機構（Let’s Encrypt）證明它確實“擁有”并控制該域名。

有多種方法可以做到這一點。 一些流行的方式是：

• 修改一些DNS記錄。
• • 為此，續訂程序需要支持 DNS 提供商的 API，因此，要看你使用的 DNS 提供商是否提供這一功能。
• 在與域名關聯的公共 IP 地址上作為服務器運行（至少在證書獲取過程中）。
• • 正如我們上面所說，只有一個進程可以監聽特定的 IP 和端口。
• • 這就是當同一個 TLS 終止代理還負責證書續訂過程時它非常有用的原因之一。
• • 否則，你可能需要暫時停止 TLS 終止代理，啟動續訂程序以獲取證書，然后使用 TLS 終止代理配置它們，然后重新啟動 TLS 終止代理。 這并不理想，因為你的應用程序在 TLS 終止代理關閉期間將不可用。

通過擁有一個單獨的系統來使用 TLS 終止代理來處理 HTTPS, 而不是直接將 TLS 證書與應用程序服務器一起使用 （例如 Uvicorn）,你可以在 更新證書的過程中同時保持提供服務。

手動運行服務器-Uvicorn

在遠程服務器計算機上運行FastAPI應用程序所需的主要東西是ASGI服務器程序，例如Uvicorn。

有3個主要可選方案：

• Uvicorn：高性能ASGI服務器。
• Hypercorn：與HTTP/2和Trio等兼容的ASGI服務器。
• Daphne：為Django Channels構建的ASGI服務器。

服務器主機和服務器程序

關于名稱，有一個小細節需要記住。

”服務器“一詞通常用于指遠程/云計算機（物理機或虛擬機）以及在該計算機上運行的程序（例如Uvicorn）。

請記住，當您一般讀到”服務器“這個名詞時，它可能指的是這兩者之一。

當提到遠程主機時，通常將其稱為服務器，但也稱為機器（machine）、VM（虛擬機）、節點。這些都是指某種類型的遠程計算機，通常運行Linux，您可以在其中運行程序。

安裝服務器程序

您可以使用以下命令安裝ASGI兼容服務器：

• Uvicorn，一個快如閃電ASGI服務器，基于uvloop和httptools構建。

$ pip install "uvicorn[standard]"

運行服務器程序

您可以按照之前教程中的相同方式運行應用程序，但不使用reload選項，例如：

$ uvicorn main:app --host 0.0.0.0 --port 80

部署概念

這些示例運行服務器程序（例如Uvicorn），啟動單個進程，在所有IP（0.0.0.0）上監聽預定義端口（例如80）。

這是基本思路。但您可能需要處理一些其他事情，例如：

• 安全性-HTTPS
• 啟動時運行
• 重新啟動
• Replication（運行的進程數）
• 內存
• 開始前的步驟

在部署FastAPI應用程序或任何類型的Web API時，有幾個概念值得了解，通過掌握這些概念您可以找到最合適的方法來部署您的應用程序。

安全性-HTTPS

見原文https://fastapi.tiangolo.com/zh/deployment/concepts/

程序和進程

什么是程序

程序這個詞通常用來描述很多東西：

• 您編寫的代碼、Python文件。
• 操作系統可以執行的文件，例如：python、python.exe或uvicorn。
• 在操作系統上運行、使用CPU并將內容存儲在內存上的特定程序。這也被稱為進程。

什么是進程

進程 這個詞通常以更具體的方式使用，僅指在操作系統中運行的東西（如上面的最后一點）：

• 在操作系統上運行的特定程序。
• • 這不是指文件，也不是指代碼，它具體指的是操作系統正在執行和管理的東西。
• 任何程序，任何代碼，只有在執行時才能做事。 因此，是當有進程正在運行時。
• 該進程可以由您或操作系統終止（或“殺死”）。 那時，它停止運行/被執行，并且它可以不再做事情。
• 您計算機上運行的每個應用程序背后都有一些進程，每個正在運行的程序，每個窗口等。并且通常在計算機打開時同時運行許多進程。
• 同一程序可以有多個進程同時運行。

如果您檢查操作系統中的“任務管理器”或“系統監視器”（或類似工具），您將能夠看到許多正在運行的進程。

例如，您可能會看到有多個進程運行同一個瀏覽器程序（Firefox、Chrome、Edge 等）。 他們通常每個tab運行一個進程，再加上一些其他額外的進程。

啟動時運行

在大多數情況下，當您創建Web API時，您希望它始終運行、不間斷，以便您的客戶端始終可以訪問它。 這是當然的，除非您有特定原因希望它僅在某些情況下運行，但大多數時候您希望它不斷運行并且可用。

在遠程服務器中

當您設置遠程服務器（云服務器、虛擬機等）時，您可以做的最簡單的事情就是手動運行 Uvicorn（或類似的），就像本地開發時一樣。

它將會在開發過程中發揮作用并發揮作用。

但是，如果您與服務器的連接丟失，正在運行的進程可能會終止。

如果服務器重新啟動（例如更新后或從云提供商遷移后），您可能不會注意到它。 因此，您甚至不知道必須手動重新啟動該進程。 所以，你的 API 將一直處于掛掉的狀態。

啟動時自動運行

一般來說，您可能希望服務器程序（例如 Uvicorn）在服務器啟動時自動啟動，并且不需要任何人為干預，讓進程始終與您的 API 一起運行（例如 Uvicorn 運行您的 FastAPI 應用程序）。

單獨的程序

為了實現這一點，您通常會有一個單獨的程序來確保您的應用程序在啟動時運行。 在許多情況下，它還可以確保其他組件或應用程序也運行，例如數據庫。

啟動時運行的示例工具

可以完成這項工作的工具的一些示例是：

• Docker
• Kubernetes
• Docker Compose
• Docker in Swarm Mode
• Systemd
• Supervisor
• 作為其服務的一部分由云提供商內部處理
• 其他的…

重新啟動

與確保應用程序在啟動時運行類似，您可能還想確保它在掛掉后重新啟動。

自動處理小錯誤

使用 FastAPI 構建 Web API 時，如果我們的代碼中存在錯誤，FastAPI 通常會將其包含到觸發錯誤的單個請求中。

對于該請求，客戶端將收到 500 內部服務器錯誤，但應用程序將繼續處理下一個請求，而不是完全崩潰。

更大的錯誤-崩潰

盡管如此，在某些情況下，我們編寫的一些代碼可能會導致整個應用程序崩潰，從而導致 Uvicorn 和 Python 崩潰。

盡管如此，您可能不希望應用程序因為某個地方出現錯誤而保持死機狀態，您可能希望它繼續運行，至少對于未破壞的路徑操作。

崩潰后重新啟動

但在那些嚴重錯誤導致正在運行的進程崩潰的情況下，您需要一個外部組件來負責重新啟動進程，至少嘗試幾次…

在大多數情況下，用于啟動時運行程序的同一工具也用于處理自動重新啟動。

復制 - 進程和內存

對于 FastAPI 應用程序，使用像 Uvicorn 這樣的服務器程序，在一個進程中運行一次就可以同時為多個客戶端提供服務。

但在許多情況下，您會希望同時運行多個工作進程。

多進程 - Workers

如果您的客戶端數量多于單個進程可以處理的數量（例如，如果虛擬機不是太大），并且服務器的 CPU 中有 多個核心，那么您可以讓 多個進程 運行 同時處理同一個應用程序，并在它們之間分發所有請求。

當您運行同一 API 程序的多個進程時，它們通常稱為 workers。

每個進程的內存

現在，當程序將內容加載到內存中時，例如，將機器學習模型加載到變量中，或者將大文件的內容加載到變量中，所有這些都會消耗服務器的一點內存 (RAM) 。

多個進程通常不共享任何內存。 這意味著每個正在運行的進程都有自己的東西、變量和內存。 如果您的代碼消耗了大量內存，每個進程將消耗等量的內存。

服務器內存

例如，如果您的代碼加載 1 GB 大小的機器學習模型，則當您使用 API 運行一個進程時，它將至少消耗 1 GB RAM。 如果您啟動 4 個進程（4 個工作進程），每個進程將消耗 1 GB RAM。 因此，您的 API 總共將消耗 4 GB RAM。

如果您的遠程服務器或虛擬機只有 3 GB RAM，嘗試加載超過 4 GB RAM 將導致問題。

Server Workers-Gunicorn with Uvicorn

到目前為止，通過文檔中的所有教程，您可能已經在單個進程上運行了像Uvicorn這樣的服務器程序。

部署應用程序時，您可能希望進行一些進程復制，以利用多核并能夠處理更多請求。

在這里時將Gunicorn與Uvicorn worker進程一起使用。

Gunicorn with Uvicorn Workers

Gunicorn主要是一個使用WSGI標準的應用服務器。這意味著Gunicorn可以為Flask和Django等應用程序提供服務。Gunicorn本身與FastAPI不兼容，因為FastAPI使用最新的ASGI標準。

但Gunicorn支持充當進程管理器并允許用戶告訴它要使用哪個特定的worker類。然后Gunicorn將使用該類啟動一個或多個worker進程。

Uvicorn有一個Gunicorn兼容的worker類。

使用這種組合，Gunicorn將充當進程管理器，監聽端口和IP。它會將通信傳輸到運行Uvicorn類的worker進程。

然后與Gunicorn兼容的Uvicorn worker類將負責將Gunicorn發送的數據轉換為ASGI標準以供FastAPI使用。

安裝Gunicorn和Uvicorn

$ pip install "uvicorn[standard]" gunicorn

這將安裝帶有standard擴展包（以獲得高性能）的Uvicorn和Gunicorn。

Run Gunicorn with Uvicorn Workers

接下來你可以通過以下命令運行Gunicorn：

$ gunicorn main:app --workers 4 --worker-class 
uvicorn.workers.UvicornWorker --bind 0.0.0.0:80[19499] [INFO] Starting gunicorn 20.1.0
[19499] [INFO] Listening at: http://0.0.0.0:80 (19499)
[19499] [INFO] Using worker: uvicorn.workers.UvicornWorker
[19511] [INFO] Booting worker with pid: 19511
[19513] [INFO] Booting worker with pid: 19513
[19514] [INFO] Booting worker with pid: 19514
[19515] [INFO] Booting worker with pid: 19515
[19511] [INFO] Started server process [19511]
[19511] [INFO] Waiting for application startup.
[19511] [INFO] Application startup complete.
[19513] [INFO] Started server process [19513]
[19513] [INFO] Waiting for application startup.
[19513] [INFO] Application startup complete.
[19514] [INFO] Started server process [19514]
[19514] [INFO] Waiting for application startup.
[19514] [INFO] Application startup complete.
[19515] [INFO] Started server process [19515]
[19515] [INFO] Waiting for application startup.
[19515] [INFO] Application startup complete.

• main:app：這與Uvicorn使用的語法相同，main表示名為"main"的Python模塊，因此是文件main.py。app是FastAPI應用程序的變量名稱。

你可以想象main:app相當于一個Pythonimport語句，例如：

from main import app

因此，main:app中的冒號相當于from main import app中的Python import部分。

• --workers：要使用的worker進程數量，每個進程將運行一個Uvicorn worker進程，在本例中為4個worker進程。
• --worker-class：在worker進程中使用的與Gunicorn兼容的工作類。

這里我們傳遞了Gunicorn可以導入和使用的類：

import uvicorn.workers.UvicornWorker

• --bind：這告訴Gunicorn要監聽的IP和端口，使用冒號（:）分隔IP和端口。

如果您直接運行Uvicorn，則可以使用--host 0.0.0.0和--port 80，而不是--bind 0.0.0.0:80（Gunicorn選項）。

在輸出中，您可以看到它顯示了每個進程的PID（進程ID）。

你可以看到：

• Gunicorn進程管理器以PID 19499開頭（在您的情況下，它將是一個不同的數字）。
• 然后它開始Listening at: http://0.0.0.0:80。
• 然后它檢測到它必須使用uvicorn.workers.UvicornWorder處的worker類。
• 然后它啟動4個worker，每個都有自己的PID：19511、19513、19514和19515。

Gunicorn還將負責管理死進程和重新啟動新進程。因此，這在一定程度上有助于上面列表中重啟的概念。

Uvicorn with Workers

Uvicorn也有一個選項可以啟動和運行多個worker進程。

然而，到目前為止，Uvicorn處理worker進程的能力比Gunicorn更有限。因此，如果您想擁有這個級別（Python級別）的進程管理器，那么最好嘗試使用Gunicorn作為進程管理器。

$ uvicorn main:app --host 0.0.0.0 --port 8080 --workers 4