# 定義 API 路徑 @app.post("/items/") asyncdefcreate_item(item: Item): # 假設邏輯檢查 if item.price <= 0: return {"error": "Price must be greater than 0"} return {"message": "Item created successfully!", "item": item}
接下來,讓我試著用不正確的方式呼叫 API,並且得到一個 422 的錯誤
1 2 3 4
curl -X POST "http://127.0.0.1:8000/items/" -H "Content-Type: application/json" -d '{"item": "should be number", "price": 10.5}'
# 定義 API 路徑 @app.post("/items/") asyncdefcreate_item(item: Item): # 假設邏輯檢查 if item.price <= 0: return {"error": "Price must be greater than 0"} return {"message": "Item created successfully!", "item": item}
GCP 防火牆(Firewall)用來控制進出 Google Cloud 資源的網路流量,確保服務的安全性。 而 Health Check 則是用來監控後端服務的健康狀態,透過 GCP 負載平衡器(Load Balancer)進行流量分配。 我將介紹如何在 GCP 設定防火牆規則以支持 Health Check 的運作。
情境
instance 有一個 Allow Load Balancer Health checks 選項, 被勾起來後 Network tags 會加上lb-health-check 但是不知為什麼狀態仍然會顯示為 Off ?
所以我們必須多作一些步驟
我有許多服務都掛在負載平衡器之後,並且使用 Backend Service 來管理這些流量。 一個 LB 會有多個 Backend Service (本文先不涉及 Backend Bucket) 由於成本考量,為了提高資源利用率,一台機器可能會承載多個 Web 服務。 這樣做可以節省硬體和虛擬機的成本,但同時也需要確保每個 Web 服務能夠獨立且穩定地運行。
在這樣的架構中,LB 會依 Path Rules 將流量分配到多個實例組(Instance Group)中, 每個實例中可能運行著多個 Web 服務。 透過這些實例和 Backend Service 的組合,負載平衡器能夠有效地將流量分配到不同的服務上。 然而,為了確保服務的穩定性,我們必須配置健康檢查(Health Check)來監控每個 Web 服務的運行狀態。
在 GCP 中,當我們使用負載平衡器(Load Balancer)時,會涉及以下資源:
Backend Service:負責接收來自負載平衡器的流量,並將流量分發給後端的實例。
Health Check:用來檢查後端服務是否健康,負載平衡器會依據這些檢查結果決定是否將流量導向特定實例。
Instance Group:一組相同配置的虛擬機(VM),負責運行服務,並自動進行縮放。
Instance:每個實際的虛擬機,執行後端服務。
這些資源之間的關係是,Backend Service 根據 Health Check 監控的結果選擇健康的 Instance, 並將流量分發給 Instance Group 中的實例。 當負載平衡器根據路徑規則(LB Path Rule)將流量導向某個服務時,這些流量會被引導到 Instance 中運行的 Web 服務。
我們會在一台 Instance 上使用多個 web 服務,使用不同的 Port 來區分,範圍是 6000~6100。 而我們需要對這些所有的服務設定 Health Check
在打造安全的 VM 環境時,常常會遇到一個經典的矛盾點: 我們希望 VM 保持隱蔽,避免直接暴露於網際網路以減少安全風險,但同時又需要對外存取資源。 例如在開發或維運階段,像是執行 npm install、apt-get update,甚至提供給合作第三方的白名單 IP 等需求,往往都依賴外部下載與連線。
在 GCP 控制台中,前往 VPC 網路,選擇 建立 VPC 網路。 設定一個新的 VPC 網路,並確保 VM 的子網路設為 私有(Private)。這樣做可以保護 VM 不被直接暴露於公共網路。 實務上我選擇 default
步驟 2: 配置 Cloud NAT
前往 VPC 網路 > Cloud NAT,並選擇 建立 NAT 網關。 在設置過程中,選擇對應的子網路和路由(Route)設定。這樣可以確保 VM 在沒有 Public IP 的情況下仍能夠透過 NAT 網關訪問外部網路。 配置完成後,Cloud NAT 將會自動幫助 VM 處理對外的連線請求,而不需要直接公開 VM 的 IP。
步驟 3: 配置 Public IP(如果需要)
若要讓 VM 直接對外發送請求或開放服務,可以在創建 VM 時為其配置 Public IP。 在 Google Cloud Console 中創建虛擬機時,選擇 外部 IP 設為 靜態(static),這樣可以確保 Public IP 地址不會變動。 當 VM 配置了 Public IP,所有對外的請求將會直接通過這個 IP 進行。