# Implementación de enlaces de SnapStart para imágenes de contenedores ## Descripción general Cuando se utiliza SnapStart con una función de [imagen de contenedor](images-create.md), el tiempo de ejecución debe coordinar el ciclo de vida de la función e invocar los enlaces anteriores a la instantánea y posteriores a la restauración durante las fases correspondientes del ciclo de vida. Estos enlaces permiten ejecutar una lógica personalizada (por ejemplo, actualizar las credenciales o reinicializar generadores de números asignados al azar) en determinados momentos del ciclo de vida de la captura y la restauración. Si utiliza un tiempo de ejecución administrado compatible con SnapStart o las imágenes base correspondientes para esos tiempos de ejecución (Java versión 11\+, Python versión 3.12\+ y .NET versión 8\+), Lambda coordina el ciclo de vida automáticamente. Registre sus enlaces a través de la API que se describe en [Implemente el código antes o después de las instantáneas de la función de Lambda](snapstart-runtime-hooks.md). Si utiliza sus propias imágenes de contenedor base, clientes de interfaz de tiempo de ejecución (RIC) o imágenes base de Lambda para provided.al2023, Node.js o Ruby, siga los pasos de esta página para usar SnapStart. ## Requisitos previos Cuando Lambda restaura una función a partir de una instantánea, cualquier estado definido durante la inicialización, como los generadores de números asignados al azar, los ID únicos y las credenciales en caché, se comparte en todos los entornos de ejecución restaurados a partir de esa instantánea. Antes de usar SnapStart con su función de Lambda basada en imágenes de contenedores, revise [Control de la exclusividad con Lambda SnapStart](snapstart-uniqueness.md) y asegúrese de que se cumplen los requisitos descritos en [Uso de generadores de números pseudoaleatorios criptográficamente seguros (CSPRNG)](https://docs.aws.amazon.com/lambda/latest/dg/snapstart-uniqueness.html#snapstart-csprng). Después de validar que se cumplen los requisitos, seleccione una de las dos opciones siguientes: 1. **Opción 1:** si necesita enlaces anteriores a la instantánea y posteriores a la restauración para ejecutar una lógica personalizada cuando se reanude la instantánea de la función, siga las instrucciones de la sección [Implementación de enlaces de ciclo de vida de SnapStart](#snapstart-custom-implement). 1. **Opción 2:** si no necesita estos enlaces, habilite SnapStart para esta imagen de contenedor especificando la siguiente etiqueta en su Dockerfile: ``` LABEL com.amazonaws.lambda.feature.snapstart="Allow" ``` Si la imagen del contenedor no implementa la API `/restore/next` ni incluye la etiqueta, no se podrá publicar la versión. **nota** Estos requisitos previos no son necesarios si utiliza imágenes base administradas por Lambda para Java (versión 11\+), Python (versión 3.12\+) y .NET (versión 8\+), ya que ya coordinan el ciclo de vida de SnapStart y proporcionan los requisitos de exclusividad. ## Descripción del ciclo de vida El siguiente diagrama muestra el orden de las llamadas a la API de tiempo de ejecución que se espera que realice un tiempo de ejecución personalizado de SnapStart. Todas las llamadas forman parte del contrato de la API de tiempo de ejecución, mientras que las llamadas \#3, \#4, \#5 y \#6 son específicas de SnapStart. ![Diagrama de secuencia que muestra el orden de las solicitudes de la API de tiempo de ejecución para un tiempo de ejecución personalizado de SnapStart: init, enlaces anteriores a la instantánea, GET /runtime/restore/next, enlaces posteriores a la instantánea y el bucle de invocación estándar.](https://docs.aws.amazon.com/es_es/lambda/latest/dg/images/snapstart-custom-runtime-lifecycle.png) ## Implementación de enlaces de ciclo de vida de SnapStart Para usar SnapStart con las funciones de imagen de contenedor, siga los pasos que se indican a continuación: 1. **Ejecute los enlaces anteriores a la instantánea y active el proceso de creación de instantáneas:** como último paso del código de inicialización de la función, ejecute los enlaces anteriores a la instantánea, si es necesario, y active el proceso de creación de instantáneas. Realice estos pasos solo si SnapStart está habilitado, comprobando que el valor de la variable de entorno `AWS_LAMBDA_INITIALIZATION_TYPE` esté establecido en `snap-start`. Ejecute los enlaces registrados antes de la instantánea y, a continuación, llame a `GET /runtime/restore/next` para desencadenar el proceso de creación de instantáneas. Si un enlace anterior a la instantánea arroja o devuelve un error, el tiempo de ejecución publica el error en el punto de conexión `/runtime/init/error`. Consulte los ejemplos de pseudocódigo que aparecen a continuación: ``` # 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 . 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 ``` **nota** Los enlaces de la fase de inicio y anteriores a la instantánea comparten un tiempo de espera combinado de `max(function_timeout, 130 seconds)`. Si se supera este límite, Lambda no aceptará la solicitud PublishVersion. Además, al igual que `/runtime/invocation/next`, la llamada `/runtime/restore/next` es una llamada de bloqueo. Se bloquea hasta que Lambda restaure el entorno de ejecución a partir de la instantánea. 1. **Ejecute los enlaces posteriores a la restauración y, a continuación, entre en el bucle de invocación.** Cuando `GET /runtime/restore/next` devuelve 200, el tiempo de ejecución debe ejecutar todos los enlaces registrados tras la restauración antes de pasar al bucle de invocación. Si se produce un error en un enlace posterior a la restauración, notifique el error a `/runtime/restore/error`. Una vez completados los enlaces posteriores a la restauración, introduzca el bucle de invocación estándar mediante una llamada a `GET /runtime/invocation/next`. A partir de este momento, el comportamiento es idéntico al de una función que no usa SnapStart. Consulte los ejemplos de pseudocódigo que aparecen a continuación: ``` # 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 . SET body TO { errorMessage, errorType, stackTrace } # Proceed to the invoke loop ``` ## Gestión de errores Si se produce un error en un enlace, el tiempo de ejecución debe informar del error al punto de conexión de la API correspondiente y cerrar el proceso. La siguiente tabla resume el comportamiento de cada fase: | Phase (Fase) | Punto de conexión de la API de error | Qué sucede en caso de fallo | | --- | --- | --- | | Inicio/antes de la instantánea | POST /runtime/init/error | Lambda no supera la solicitud PublishVersion. Salga del proceso. | | Después de la restauración | POST /runtime/restore/error | Lambda produce un error en la invocación en curso y destruye el entorno de ejecución. Salga del proceso. | Para ambos puntos de conexión de la API, defina el encabezado `Lambda-Runtime-Function-Error-Type` con un valor en el formato `` (por ejemplo, `Runtime.BeforeSnapshotError` o `Runtime.AfterRestoreError`). Incluye un cuerpo de error con `errorMessage`, `errorType` y un elemento opcional `stackTrace`. Para ver la especificación completa del punto de conexión de la API y los códigos de respuesta, consulte [Error de inicialización](runtimes-api.md#runtimes-api-initerror) y [Restauración del error (solo aplicable a SnapStart)](runtimes-api.md#runtimes-api-restore-error) en la referencia de la API de tiempo de ejecución.