

# Cuándo utilizar los tiempos de ejecución exclusivos del sistema operativo de Lambda
<a name="runtimes-provided"></a>

Lambda proporciona [tiempos de ejecución gestionados](lambda-runtimes.md) para Java, Python, Node.js, .NET y Ruby. Para crear funciones de Lambda en un lenguaje de programación que no esté disponible como tiempo de ejecución gestionado, utilice un tiempo de ejecución exclusivo del sistema operativo (la familia de tiempos de ejecución `provided`). Existen tres casos de uso principales para los tiempos de ejecución exclusivos del sistema operativo:
+ **Compilación nativa anticipada (AOT):** lenguajes como Go, Rust, Swift y C\$1\$1 se compilan de forma nativa en un binario ejecutable, que no requiere un tiempo de ejecución de lenguaje específico. Estos lenguajes solo necesitan un entorno de sistema operativo en el que se pueda ejecutar el binario compilado. También puede usar tiempos de ejecución exclusivos del sistema operativo de Lambda para implementar binarios compilados con .NET Native AOT y Java GraalVM Native Image.

  Debe incluir un cliente de interfaz de tiempo de ejecución en el binario. El cliente de la interfaz del tiempo de ejecución llama a [Uso de la API de tiempo de ejecución de Lambda para tiempos de ejecución personalizados](runtimes-api.md) para recuperar las invocaciones de funciones y, a continuación, llama al controlador de funciones. Lambda proporciona clientes de interfaz de tiempo de ejecución para [Rust](lambda-rust.md), [Go](golang-package.md#golang-package-mac-linux), [.NET Native AOT](dotnet-native-aot.md), [Swift](https://github.com/awslabs/swift-aws-lambda-runtime) y [C\$1\$1](https://github.com/awslabs/aws-lambda-cpp) (experimental).

  Debe compilar el binario para un entorno Linux y para la misma arquitectura de conjunto de instrucciones que planea usar para la función (x86\$164 o arm64).
+ **Tiempos de ejecución de terceros**: puede ejecutar funciones de Lambda con tiempos de ejecución listos para usar, como [Bref](https://bref.sh/docs/news/01-bref-1.0.html#amazon-linux-2) para PHP.
+ **Tiempos de ejecución personalizados**: puede crear su propio tiempo de ejecución para un lenguaje (o una versión de un lenguaje) para el que Lambda no proporcione un tiempo de ejecución gestionado, como Node.js 19. Para obtener más información, consulte [Creación de un tiempo de ejecución personalizado para AWS Lambda](runtimes-custom.md). Este es el caso de uso menos común para los tiempos de ejecución exclusivos del sistema operativo.

Lambda admite los siguientes tiempos de ejecución exclusivos del sistema operativo de Ruby.


| Nombre | Identificador | Sistema operativo | Fecha de baja | Bloqueo de la función Crear | Bloqueo de la función Actualizar | 
| --- | --- | --- | --- | --- | --- | 
|  Tiempo de ejecución exclusivo del sistema operativo  |  `provided.al2023`  |  Amazon Linux 2023  |   30 de junio de 2029   |   31 de julio de 2029   |   31 de agosto de 2029   | 
|  Tiempo de ejecución exclusivo del sistema operativo  |  `provided.al2`  |  Amazon Linux 2  |   31 de julio de 2026   |   31 de agosto de 2026   |   30 de septiembre de 2026   | 

El tiempo de ejecución de Amazon Linux 2023 (`provided.al2023`) ofrece varias ventajas con respecto a Amazon Linux 2, incluida una huella de implementación más reducida y versiones actualizadas de bibliotecas como `glibc`.

El tiempo de ejecución `provided.al2023` utiliza `dnf` como administrador de paquetes en lugar de `yum`, que es el administrador de paquetes predeterminado en Amazon Linux 2. Para obtener más información sobre las diferencias entre `provided.al2023` y `provided.al2`, consulte [Presentación del tiempo de ejecución de Amazon Linux 2023 AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/) en el Blog de informática de AWS.

# Creación de un tiempo de ejecución personalizado para AWS Lambda
<a name="runtimes-custom"></a>

Puede implementar tiempos de ejecución de AWS Lambda con cualquier lenguaje de programación. El tiempo de ejecución es un programa que ejecuta un método de controlador de función de Lambda cuando se invoca la función. El tiempo de ejecución se puede incluir en el paquete de implementación de la función o se puede distribuir en una [capa](chapter-layers.md). Cuando cree la función de Lambda, elija un [tiempo de ejecución exclusivo del sistema operativo](runtimes-provided.md) (la familia de tiempos de ejecución `provided`).

**nota**  
La creación de un tiempo de ejecución personalizado es un caso de uso avanzado. Si busca información sobre la compilación en un binario nativo o el uso de un tiempo de ejecución estándar de terceros, consulte [Cuándo utilizar los tiempos de ejecución exclusivos del sistema operativo de Lambda](runtimes-provided.md).

Para ver un recorrido por el proceso de implementación de un tiempo de ejecución personalizado, consulte [Tutorial: cómo crear un tiempo de ejecución personalizado](runtimes-walkthrough.md).

**Topics**
+ [Requisitos](#runtimes-custom-build)
+ [Implementación de la transmisión de respuestas en un entorno de ejecución personalizado](#runtimes-custom-response-streaming)
+ [Creación de tiempos de ejecución personalizados para instancias administradas de Lambda](#runtimes-custom-managed-instances)

## Requisitos
<a name="runtimes-custom-build"></a>

Los tiempos de ejecución personalizados deben completar determinadas tareas de inicialización y procesamiento. El tiempo de ejecución ejecuta el código de configuración de la función, lee el nombre del controlador a partir de una variable de entorno y lee los eventos de invocación desde la API de tiempo de ejecución de Lambda. El tiempo de ejecución transfiere los datos de los eventos al controlador de la función y publica la respuesta desde el controlador de vuelta a Lambda.

### Tareas de inicialización
<a name="runtimes-custom-initialization"></a>

Las tareas de inicialización se ejecutan una vez [por instancia de la función](lambda-runtime-environment.md) para preparar el entorno para gestionar invocaciones.
+ **Retrieve settings (Recuperar opciones de configuración)**: leer variables de entorno para obtener detalles acerca de la función y el entorno.
  + `_HANDLER`: la ubicación del controlador, a partir de la configuración de la función. El formato estándar es `file.method`, donde `file` es el nombre del archivo sin extensión, y `method` es el nombre de un método o una función que se define en el archivo.
  + `LAMBDA_TASK_ROOT`: el directorio que contiene el código de la función.
  + `AWS_LAMBDA_RUNTIME_API`: el host y el puerto de la API de tiempo de ejecución.

  Para obtener una lista completa de variables disponibles, consulte [Variables definidas de entorno de tiempo de ejecución](configuration-envvars.md#configuration-envvars-runtime).
+ **Inicializar la función**: cargar el archivo de controlador y ejecutar cualquier código global o estático en él. Las funciones deben crear los recursos estáticos, como clientes SDK y conexiones de bases de datos, una vez, y después volver a utilizarlos para varias invocaciones.
+ **Administración de errores**: si se produce un error, llamar a la API de [error de inicialización](runtimes-api.md#runtimes-api-initerror) y salir de forma inmediata.

La inicialización se tiene en cuenta al calcular el tiempo de ejecución y el tiempo de espera que se factura. Cuando una ejecución activa la inicialización de una nueva instancia de la función, puede ver el tiempo de inicialización en los registros y el [rastreo de AWS X-Ray](services-xray.md).

**Example registro**  

```
REPORT RequestId: f8ac1208... Init Duration: 48.26 ms   Duration: 237.17 ms   Billed Duration: 300 ms   Memory Size: 128 MB   Max Memory Used: 26 MB
```

### Procesamiento de tareas
<a name="runtimes-custom-processing"></a>

Mientras se ejecuta, el tiempo de ejecución utiliza la [interfaz de tiempo de ejecución de Lambda](runtimes-api.md) para administrar eventos entrantes e informar sobre errores. Después de completar las tareas de inicialización, el tiempo de ejecución procesa los eventos entrantes en bucle. En el código de tiempo de ejecución, realice los siguientes pasos en orden.
+ **Get an event (Obtener un evento)**: llamar a la API de la [siguiente invocación](runtimes-api.md#runtimes-api-next) para obtener el siguiente evento. El cuerpo de la respuesta contiene los datos del evento. Los encabezados de respuesta contienen el ID de la solicitud y otra información.
+ **Propagate the tracing header (Propagar el encabezado de rastreo)**: obtenga el encabezado de rastreo de X-Ray desde el encabezado `Lambda-Runtime-Trace-Id` en la respuesta de la API. Establezca localmente la variable de entorno `_X_AMZN_TRACE_ID` con el mismo valor. El SDK de X-Ray utiliza este valor para conectar datos de rastreo entre servicios.
+ **Create a context object (Crear un objeto context)**: cree un objeto con información de contexto a partir de las variables de entorno y los encabezados en la respuesta de la API.
+ **Invoke the function handler (Invocar el controlador de la función)**: transfiera el evento y el objeto context al controlador.
+ **Handle the response (Administrar la respuesta)**: llame a la API de [respuesta de invocación](runtimes-api.md#runtimes-api-response) para publicar la respuesta desde el controlador.
+ **Handle errors (Administrar errores)**: si se produce un error, llamar a la API de [error de invocación](runtimes-api.md#runtimes-api-invokeerror).
+ **Cleanup (Limpiar)**: libere recursos no utilizados, envíe datos a otros servicios o realice tareas adicionales antes de obtener el siguiente evento.

### Punto de entrada
<a name="runtimes-custom-bootstrap"></a>

El punto de entrada de un tiempo de ejecución personalizado es un archivo ejecutable llamado `bootstrap`. El archivo de arranque puede ser el tiempo de ejecución o puede invocar otro archivo que cree el tiempo de ejecución. Si la raíz del paquete de implementación no contiene un archivo con el nombre `bootstrap`, Lambda busca el archivo en las capas de la función. Si el archivo `bootstrap` no existe o no es ejecutable, la función devuelve el error `Runtime.InvalidEntrypoint` tras la invocación.

Este es un ejemplo de un archivo `bootstrap` que utiliza una versión empaquetada de Node.js para ejecutar un tiempo de ejecución de JavaScript en un archivo aparte llamado `runtime.js`.

**Example arranque**  

```
#!/bin/sh
    cd $LAMBDA_TASK_ROOT
    ./node-v11.1.0-linux-x64/bin/node runtime.js
```

## Implementación de la transmisión de respuestas en un entorno de ejecución personalizado
<a name="runtimes-custom-response-streaming"></a>

Para las [funciones de transmisión de respuestas](configuration-response-streaming.md), los puntos de conexión de `response` y `error` han modificado ligeramente su comportamiento, lo que permite que el tiempo de ejecución transmita respuestas parciales al cliente y devuelva las cargas en fragmentos. Para obtener más información sobre el comportamiento específico, consulte lo siguiente:
+ `/runtime/invocation/AwsRequestId/response`: propaga el encabezado `Content-Type` desde el tiempo de ejecución para enviarlo al cliente. Lambda devuelve la carga de respuesta en fragmentos mediante la codificación de transferencia fragmentada de HTTP/1.1. Para transmitir la respuesta a Lambda, el tiempo de ejecución debe realizar lo siguiente:
  + Establecer el encabezado HTTP `Lambda-Runtime-Function-Response-Mode` en `streaming`.
  + Establezca el encabezado `Transfer-Encoding` en `chunked`.
  + Escribir la respuesta de acuerdo con la especificación de codificación de transferencia fragmentada de HTTP/1.1.
  + Cerrar la conexión subyacente después de que la respuesta se haya escrito correctamente.
+ `/runtime/invocation/AwsRequestId/error`: el tiempo de ejecución puede utilizar este punto de conexión para informar sobre errores de función o tiempo de ejecución a Lambda, que también acepta el encabezado `Transfer-Encoding`. Solo se puede llamar a este punto de conexión antes de que el tiempo de ejecución comience a enviar una respuesta de invocación.
+ Informe los errores intermedios mediante los tráileres de errores en `/runtime/invocation/AwsRequestId/response`: el tiempo de ejecución puede adjuntar opcionalmente los encabezados finales de HTTP con los nombres `Lambda-Runtime-Function-Error-Type` y`Lambda-Runtime-Function-Error-Body` para informar sobre los errores que se producen después de haber empezado a escribir la respuesta de invocación. Lambda trata esto como una respuesta correcta y reenvía los metadatos de error proporcionados por el tiempo de ejecución al cliente. 
**nota**  
Para adjuntar encabezados finales, el tiempo de ejecución debe establecer el valor del encabezado `Trailer` al principio de la solicitud HTTP. Este es un requisito de la especificación de codificación de transferencia fragmentada de HTTP/1.1.
  + `Lambda-Runtime-Function-Error-Type`: el tipo de error que encontró el tiempo de ejecución. Este encabezado consta de un valor de cadena. Lambda acepta cualquier cadena, pero recomendamos un formato de *<category.reason>*. Por ejemplo, `Runtime.APIKeyNotFound`.
  + `Lambda-Runtime-Function-Error-Body`: información sobre el error codificada en Base64.

## Creación de tiempos de ejecución personalizados para instancias administradas de Lambda
<a name="runtimes-custom-managed-instances"></a>

Las instancias administradas de Lambda utilizan la misma API de tiempo de ejecución que las funciones de Lambda (predeterminadas). Sin embargo, existen diferencias clave en la forma en que se deben implementar los tiempos de ejecución personalizados para admitir el modelo de ejecución simultánea de las instancias administradas.

### Gestión de solicitudes simultáneas
<a name="runtimes-custom-managed-instances-concurrency"></a>

La principal diferencia a la hora de crear tiempos de ejecución personalizados para las instancias administradas es la compatibilidad con las invocaciones simultáneas. A diferencia de las funciones de Lambda (predeterminadas), en las que el tiempo de ejecución procesa una invocación a la vez, las instancias administradas pueden procesar varias invocaciones simultáneamente en un único entorno de ejecución.

Su tiempo de ejecución personalizado debe cumplir con lo siguiente:
+ **Admitir solicitudes simultáneas de `/next`:** el tiempo de ejecución puede realizar varias llamadas simultáneas a la [siguiente API de invocación](runtimes-api.md#runtimes-api-next), hasta el límite especificado por la variable de entorno de `AWS_LAMBDA_MAX_CONCURRENCY`.
+ **Gestionar solicitudes simultáneas de `/response`**: varias invocaciones pueden llamar a la [API de respuesta a la invocación](runtimes-api.md#runtimes-api-response) simultáneamente.
+ **Implementar una gestión de solicitudes segura para subprocesos**: asegúrese de que las invocaciones simultáneas no interfieran entre sí mediante la administración adecuada de los recursos y el estado compartidos.
+ **Usar identificadores de solicitud únicos**: realice un seguimiento de cada invocación por separado mediante el encabezado `Lambda-Runtime-Aws-Request-Id` para hacer coincidir las respuestas con las solicitudes correspondientes.

### Patrón de implementación
<a name="runtimes-custom-managed-instances-implementation"></a>

Un patrón de implementación típico para los tiempos de ejecución de las instancias administradas implica la creación de subprocesos o procesos de trabajo para gestionar las invocaciones simultáneas:

1. **Lectura del límite de concurrencia**: en la inicialización, lea la variable de entorno de `AWS_LAMBDA_MAX_CONCURRENCY` para determinar el número de invocaciones simultáneas que se admitirán.

1. **Creación de un grupo de trabajo**: inicialice un grupo de trabajo (subprocesos, procesos o tareas asíncronas) igual al límite de concurrencia.

1. **Bucle de procesamiento de trabajo**: cada trabajo realiza lo siguiente de forma independiente:
   + Llama a `/runtime/invocation/next` para obtener un evento de invocación.
   + Invoca al controlador de funciones con los datos del evento.
   + Publica la respuesta en `/runtime/invocation/AwsRequestId/response`.
   + Repite el bucle.

### Consideraciones adicionales
<a name="runtimes-custom-managed-instances-considerations"></a>
+ **Formato de registro**: las instancias administradas solo admiten el formato de registro JSON. Asegúrese de que el tiempo de ejecución respete la variable de entorno de `AWS_LAMBDA_LOG_FORMAT` y solo utilice el formato JSON. Para obtener más información, consulte [Configuración de los formatos de registro JSON y de texto sin formato](monitoring-cloudwatchlogs-logformat.md).
+ **Recursos compartidos**: use con precaución los recursos compartidos, como el directorio de `/tmp`, con invocaciones simultáneas. Implemente los mecanismos de bloqueo adecuados para evitar condiciones de carrera.

Para obtener más información acerca de los entorno de ejecución de instancias administradas de Lambda, consulte [Descripción del entorno de ejecución de instancias administradas de Lambda](lambda-managed-instances-execution-environment.md).

# Tutorial: cómo crear un tiempo de ejecución personalizado
<a name="runtimes-walkthrough"></a>

En este tutorial creará una función de Lambda con un tiempo de ejecución personalizado. Para empezar incluirá el tiempo de ejecución en el paquete de implementación de la función. A continuación, lo migrará a una capa que gestiona independientemente de la función. Por último, compartirá la capa de tiempo de ejecución globalmente actualizando su política de permisos basados en recursos.

## Requisitos previos
<a name="runtimes-walkthrough-prereqs"></a>

En este tutorial, se presupone que tiene algunos conocimientos sobre las operaciones básicas de Lambda y la consola de Lambda. Si aún no lo ha hecho, siga las instrucciones de [Cree una función de Lambda con la consola.](getting-started.md#getting-started-create-function) para crear su primera función de Lambda.

Para completar los siguientes pasos, necesita la [versión 2 de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). Los comandos y la salida esperada se enumeran en bloques separados:

```
aws --version
```

Debería ver los siguientes datos de salida:

```
aws-cli/2.13.27 Python/3.11.6 Linux/4.14.328-248.540.amzn2.x86_64 exe/x86_64.amzn.2
```

Para comandos largos, se utiliza un carácter de escape (`\`) para dividir un comando en varias líneas.

En Linux y macOS, use su administrador de intérprete de comandos y paquetes preferido.

**nota**  
En Windows, algunos comandos de la CLI de Bash que se utilizan habitualmente con Lambda (por ejemplo, `zip`) no son compatibles con los terminales integrados del sistema operativo. Para obtener una versión de Ubuntu y Bash integrada con Windows, [instale el subsistema de Windows para Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10). Los comandos de la CLI de ejemplo de esta guía utilizan el formato Linux. Los comandos que incluyen documentos JSON en línea deben reformatearse si utiliza la CLI de Windows. 

Necesita un rol de IAM para crear una función de Lambda. El rol necesita permiso para enviar registros a los Registros de CloudWatch y acceder a los Servicios de AWS que utiliza su función. Si no tiene un rol de para el desarrollo de funciones, cree uno.

**Para crear un rol de ejecución**

1. Abra la [página Roles](https://console.aws.amazon.com/iam/home#/roles) en la consola de IAM.

1. Elija **Creación de rol**.

1. Cree un rol con las propiedades siguientes.
   + **Trusted entity (Entidad de confianza).**–**Lambda:**.
   + **Permisos**: **AWSLambdaBasicExecutionRole**.
   + **Nombre de rol**: **lambda-role**.

   La política **AWSLambdaBasicExecutionRole** tiene permisos que la función necesita para escribir registros a Registros de CloudWatch.

## Crear una función
<a name="runtimes-walkthrough-function"></a>

Cree una función de Lambda con un tiempo de ejecución personalizado. En este ejemplo se incluyen dos archivos: un archivo `bootstrap` de tiempo de ejecución y un controlador de la función. Ambos se implementan en Bash.

1. Cree un directorio para el proyecto y, a continuación, cambie a ese directorio.

   ```
   mkdir runtime-tutorial
   cd runtime-tutorial
   ```

1. Cree un nuevo archivo denominado `bootstrap`. Este es el tiempo de ejecución personalizado.  
**Example bootstrap**  

   ```
   #!/bin/sh
   
   set -euo pipefail
   
   # Initialization - load function handler
   source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
   
   # Processing
   while true
   do
     HEADERS="$(mktemp)"
     # Get an event. The HTTP request will block until one is received
     EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
   
     # Extract request ID by scraping response headers received above
     REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
   
     # Run the handler function from the script
     RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
   
     # Send the response
     curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response"  -d "$RESPONSE"
   done
   ```

   El tiempo de ejecución carga un script de función desde el paquete de implementación. Utiliza dos variables para localizar el script. `LAMBDA_TASK_ROOT` le indica dónde se extrajo el paquete y `_HANDLER` incluye el nombre del script.

   Luego de que el tiempo de ejecución carga el script de la función, utiliza la API de tiempo de ejecución para recuperar un evento de invocación de Lambda, pasa el evento al controlador y publica la respuesta de vuelta en Lambda. Para obtener el ID de la solicitud, el tiempo de ejecución guarda los encabezados de la respuesta de la API en un archivo temporal y lee el encabezado `Lambda-Runtime-Aws-Request-Id` del archivo.
**nota**  
Los tiempos de ejecución se encargan de algunas cosas más, como gestionar errores y proporcionar información de contexto al controlador. Para obtener más información, consulte [Requisitos](runtimes-custom.md#runtimes-custom-build).

1. Cree un script para la función. El script del ejemplo a continuación, define una función de controlador que toma datos de eventos, los registra en `stderr` y los devuelve.  
**Example function.sh**  

   ```
   function handler () {
     EVENT_DATA=$1
     echo "$EVENT_DATA" 1>&2;
     RESPONSE="Echoing request: '$EVENT_DATA'"
   
     echo $RESPONSE
   }
   ```

   El directorio `runtime-tutorial` debe tener ahora el siguiente aspecto:

   ```
   runtime-tutorial
   ├ bootstrap
   └ function.sh
   ```

1. Haga los archivos ejecutables y añádalos a un archivo .zip. Este es el paquete de implementación.

   ```
   chmod 755 function.sh bootstrap
   zip function.zip function.sh bootstrap
   ```

1. Cree una función llamada `bash-runtime`. Para `--role`, introduzca el ARN de su [rol de ejecución](lambda-intro-execution-role.md) de Lambda.

   ```
   aws lambda create-function --function-name bash-runtime \
   --zip-file fileb://function.zip --handler function.handler --runtime provided.al2023 \
   --role arn:aws:iam::123456789012:role/lambda-role
   ```

1. Invoque la función.

   ```
   aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
   ```

   La opción **cli-binary-format** es obligatoria si va a utilizar la versión 2 de la AWS CLI. Para que esta sea la configuración predeterminada, ejecute `aws configure set cli-binary-format raw-in-base64-out`. Para obtener más información, consulte [Opciones de la línea de comandos globales compatibles con AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) en la *Guía del usuario de la AWS Command Line Interface versión 2*.

   Debería ver una respuesta como la siguiente:

   ```
   {
       "StatusCode": 200,
       "ExecutedVersion": "$LATEST"
   }
   ```

1. Verifique la respuesta.

   ```
   cat response.txt
   ```

   Debería ver una respuesta como la siguiente:

   ```
   Echoing request: '{"text":"Hello"}'
   ```

## Crear una capa
<a name="runtimes-walkthrough-layer"></a>

Para separar el código de tiempo de ejecución del código de la función, cree una capa que solo contenga el tiempo de ejecución. Las capas le permiten desarrollar las dependencias de la función de forma independiente y, si utiliza la misma capa con varias funciones, podrá hacer un menor uso del almacenamiento. Para obtener más información, consulte [Administración de las dependencias de Lambda con capas](chapter-layers.md).

1. Cree un archivo .zip que contenga el archivo `bootstrap`.

   ```
   zip runtime.zip bootstrap
   ```

1. Cree una capa con el comando [publish-layer-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-layer-version.html?highlight=nodejs16%20x).

   ```
   aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
   ```

   Esto crea la primera versión de la capa.

## Actualización de la función
<a name="runtimes-walkthrough-update"></a>

Para utilizar la capa de tiempo de ejecución con la función, configure la función para que use la capa, y elimine de ella el código de tiempo de ejecución.

1. Actualice la configuración de la función para incluir la capa.

   ```
   aws lambda update-function-configuration --function-name bash-runtime \
   --layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:1
   ```

   Esto agrega el tiempo de ejecución a la función en el directorio `/opt`. Para garantizar que Lambda utilice el tiempo de ejecución de la capa, debe eliminar el `boostrap` del paquete de implementación de la función, como se muestra en los dos pasos a continuación.

1. Cree un archivo .zip que contenga el código de la función.

   ```
   zip function-only.zip function.sh
   ```

1. Actualice el código de la función para que incluya solo el script del controlador.

   ```
   aws lambda update-function-code --function-name bash-runtime --zip-file fileb://function-only.zip
   ```

1. Invoque la función para confirmar que funciona con la capa de tiempo de ejecución.

   ```
   aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
   ```

   La opción **cli-binary-format** es obligatoria si va a utilizar la versión 2 de la AWS CLI. Para que esta sea la configuración predeterminada, ejecute `aws configure set cli-binary-format raw-in-base64-out`. Para obtener más información, consulte [Opciones de la línea de comandos globales compatibles con AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) en la *Guía del usuario de la AWS Command Line Interface versión 2*.

   Debería ver una respuesta como la siguiente:

   ```
   {
       "StatusCode": 200,
       "ExecutedVersion": "$LATEST"
   }
   ```

1. Verifique la respuesta.

   ```
   cat response.txt
   ```

   Debería ver una respuesta como la siguiente:

   ```
   Echoing request: '{"text":"Hello"}'
   ```

## Actualización del tiempo de ejecución
<a name="runtimes-walkthrough-runtime"></a>

1. Para registrar información sobre el entorno de ejecución, actualice el script de tiempo de ejecución para emitir variables de entorno.  
**Example bootstrap**  

   ```
   #!/bin/sh
   
   set -euo pipefail
   
   # Configure runtime to output environment variables
   echo "##  Environment variables:"
   env
   
   # Load function handler
   source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
   
   # Processing
   while true
   do
     HEADERS="$(mktemp)"
     # Get an event. The HTTP request will block until one is received
     EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
   
     # Extract request ID by scraping response headers received above
     REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
   
     # Run the handler function from the script
     RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
   
     # Send the response
     curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response"  -d "$RESPONSE"
   done
   ```

1. Cree un archivo .zip que contenga la nueva versión del archivo `bootstrap`.

   ```
   zip runtime.zip bootstrap
   ```

1. Cree una nueva versión de la capa `bash-runtime`.

   ```
   aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
   ```

1. Configure la función para utilizar la nueva versión de la capa.

   ```
   aws lambda update-function-configuration --function-name bash-runtime \
   --layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2
   ```

## Uso compartido de la capa
<a name="runtimes-walkthrough-share"></a>

Para compartir una función con otra Cuenta de AWS, agregue una declaración de permisos entre cuentas a la [política basada en los recursos](access-control-resource-based.md) de la capa. Ejecute el comando [add-layer-version-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-layer-version-permission.html) y especifique el ID de la cuenta como `principal`. En cada instrucción, puede conceder permiso a una única cuenta, a todas las cuentas o a una organización en [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html).

El siguiente ejemplo concede a la cuenta 111122223333 acceso a la versión 2 de la capa `bash-runtime`.

```
aws lambda add-layer-version-permission \
  --layer-name bash-runtime \
  --version-number 2 \  
  --statement-id xaccount \
  --action lambda:GetLayerVersion \
  --principal 111122223333 \
  --output text
```

Debería ver una salida similar a esta:

```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2"}
```

Los permisos solo se aplican a una única versión de una capa. Repita el proceso cada vez que cree una nueva versión de la capa.

## Limpieza
<a name="runtimes-walkthrough-cleanup"></a>

Elimine cada versión de la capa.

```
aws lambda delete-layer-version --layer-name bash-runtime --version-number 1
aws lambda delete-layer-version --layer-name bash-runtime --version-number 2
```

Puesto que la función contiene una referencia a la versión 2 de la capa, esta sigue existiendo en Lambda. Si bien la función sigue funcionando, ya no se pueden configurar funciones para que utilicen la versión eliminada. Si modifica la lista de capas de la función, deberá especificar una nueva versión u omitir la capa eliminada.

Elimine la función con el comando [delete-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-function.html).

```
aws lambda delete-function --function-name bash-runtime
```