本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
實作容器映像的 SnapStart 掛鉤
概觀
搭配容器映像函數使用 SnapStart 時,執行時間需要協調函數的生命週期,並在適當的生命週期階段調用快照前和還原後掛鉤。這些掛鉤可讓您在snapshot-and-restore生命週期的點執行自訂邏輯 (例如重新整理憑證或重新查看隨機數字產生器)。如果您使用支援 SnapStart 的受管執行期,或這些執行期的對應基礎映像 (Java 版本 11+、Python 版本 3.12+ 和 .NET 版本 8+),Lambda 會為您協調生命週期。透過中所述的 API 註冊掛鉤在 Lambda 函數快照之前或之後實作程式碼。
如果您針對 provided.al2023、Node.js 或 Ruby 使用自己的基礎容器映像、執行期介面用戶端 (RICs) 或 Lambda 的基礎映像,請依照此頁面上的步驟使用 SnapStart。
先決條件
當 Lambda 從快照還原函數時,初始化期間定義的任何狀態,例如亂數產生器、唯一 IDs 和快取的登入資料,都會在從該快照還原的所有執行環境中共用。將 SnapStart 與容器映像型 Lambda 函數搭配使用之前,請檢閱使用 Lambda SnapStart 處理唯一性並確保符合使用密碼編譯安全虛擬隨機數字產生器 (CSPRNGs) 中概述的要求。
驗證是否符合要求後,請選擇下列兩個選項之一:
-
選項 1:如果您需要快照前和還原後掛鉤,以便在函數快照恢復時執行自訂邏輯,請遵循 一節中的指示實作 SnapStart 生命週期掛鉤。
-
選項 2:如果您不需要這些掛鉤,請在 Dockerfile 中指定下列標籤,為此容器映像啟用 SnapStart:
LABEL com.amazonaws.lambda.feature.snapstart="Allow"
如果您的容器映像既未實作 /restore/next API,也未包含 標籤,則版本發佈將會失敗。
注意
如果您使用適用於 Java (11+ 版)、Python (3.12+ 版) 和 .NET (8+ 版) 的 Lambda 受管基礎映像,則不需要這些先決條件,因為它們已經協調 SnapStart 生命週期並提供唯一性要求。
生命週期概觀
下圖顯示 SnapStart 自訂執行期預期進行的執行期 API 呼叫順序。所有呼叫都是執行期 API 合約的一部分;而呼叫 #3、#4、#5 和 #6 則專屬於 SnapStart。
實作 SnapStart 生命週期掛鉤
若要搭配容器映像函數使用 SnapStart,請依照下列步驟進行:
-
執行快照前掛鉤並觸發快照程序:作為函數初始化程式碼的最後一個步驟,視需要執行快照前掛鉤並觸發快照程序。只有在啟用 SnapStart 時才執行這些步驟,方法是檢查
AWS_LAMBDA_INITIALIZATION_TYPE環境變數的值是否設定為snap-start。執行您已註冊的快照前掛鉤,然後呼叫GET /runtime/restore/next來觸發快照程序。如果擷取前勾點擲回或傳回錯誤,執行時間會將錯誤發佈到/runtime/init/error端點。請參閱以下虛擬程式碼範例:# After all initialization code has finished: READ initialization_type FROM environment variable "AWS_LAMBDA_INITIALIZATION_TYPE" IF initialization_type IS "snap-start" THEN TRY EXECUTE registered before-snapshot hooks ON ERROR POST error to /runtime/init/error SET header Lambda-Runtime-Function-Error-Type TO <Category>.<Reason> SET body TO { errorMessage, errorType, stackTrace } EXIT process with non-zero code # Signal readiness for snapshot SEND GET request to /runtime/restore/next # The request blocks until Lambda restores the execution environment from the snapshot, then returns HTTP 200. END IF注意
初始階段和快照前掛鉤共用 的合併逾時
max(function_timeout, 130 seconds)。如果超過此限制,Lambda 會失敗 PublishVersion 請求。此外,如同/runtime/invocation/next,/runtime/restore/next呼叫是封鎖呼叫。它封鎖,直到 Lambda 從快照還原執行環境。 -
執行還原後掛鉤,然後輸入叫用迴圈。當
GET /runtime/restore/next傳回 200 時,您的執行時間必須執行任何已註冊的還原後掛鉤,才能繼續叫用迴圈。如果還原後掛鉤失敗,請向 報告錯誤/runtime/restore/error。還原後掛鉤完成後,請呼叫 來輸入標準叫用迴圈GET /runtime/invocation/next。從此時開始,行為與不使用 SnapStart 的函數相同。請參閱以下虛擬程式碼範例:# After the snapshot has been restored # (i.e., GET /runtime/restore/next has returned HTTP 200): TRY EXECUTE registered after-restore hooks ON ERROR POST error to /runtime/restore/error SET header Lambda-Runtime-Function-Error-Type TO <Category>.<Reason> SET body TO { errorMessage, errorType, stackTrace } # Proceed to the invoke loop
錯誤處理
如果勾點失敗,執行時間必須向適當的 API 端點報告錯誤,並結束程序。下表摘要說明每個階段的行為:
| 階段 | 錯誤 API 端點 | 失敗時會發生什麼情況 |
|---|---|---|
| Init / 快照前 | POST /runtime/init/error |
Lambda 失敗 PublishVersion 請求。結束程序。 |
| 還原後 | POST /runtime/restore/error |
Lambda 使傳輸中的調用失敗,並破壞執行環境。結束程序。 |
對於這兩個 API 端點,將 Lambda-Runtime-Function-Error-Type 標頭設定為 格式的值 <Category.Reason>(例如, Runtime.BeforeSnapshotError或 Runtime.AfterRestoreError)。使用 errorMessage、 errorType和選用的 包含錯誤內文stackTrace。
如需完整的 API 端點規格和回應代碼,請參閱 Runtime API 參考還原錯誤 (僅適用於 SnapStart)中的 初始化錯誤和 。