The English version of quarkus.io is the official project site. Translated sites are community supported on a best-effort basis.
Volver a las guias
Edit this Page

AWS Lambda

La extensión quarkus-amazon-lambda le permite utilizar Quarkus para construir sus AWS Lambdas. Sus lambdas pueden utilizar anotaciones de inyección de CDI o Spring y otras facilidades de Quarkus según las necesite.

Las lambdas de Quarkus pueden desplegarse utilizando el tiempo de ejecución de Amazon Java, o puede construir un ejecutable nativo y utilizar el tiempo de ejecución personalizado de Amazon si desea una huella de memoria menor y un tiempo de arranque en frío más rápido.

La integración de Quarkus con las lambdas también es compatible con el ciclo de desarrollo Live Coding de Quarkus. Usted puede traer su proyecto Quarkus lambda en el modo de desarrollo o de prueba y el código en su proyecto en vivo.

Requisitos previos

To complete this guide, you need:

Para proyectos Gradle por favor vea más abajo, o para mayor referencia consulte la guía en la página de configuración de Gradle .

Primeros pasos

Esta guía le mostrará cómo generar un proyecto Java de ejemplo mediante un arquetipo de maven e implementarlo en AWS.

Instalación de los bits de AWS

Instalar todos los bits de AWS es probablemente lo más difícil de esta guía. Asegúrate de seguir todos los pasos para instalar AWS CLI.

Creación del proyecto de Maven

Crea el proyecto Quarkus AWS Lambda maven usando nuestro Maven Archetype.

mvn archetype:generate \
       -DarchetypeGroupId=io.quarkus \
       -DarchetypeArtifactId=quarkus-amazon-lambda-archetype \
       -DarchetypeVersion=3.16.3

Si prefiere utilizar Gradle, puede generar rápida y fácilmente un proyecto Gradle a través de code.quarkus.io añadiendo la extensión quarkus-amazon-lambda como dependencia.

Copie el build.gradle, gradle.properties y settings.gradle en el proyecto arquetipo de Maven generado anteriormente, para seguir con esta guía.

Ejecuta: gradle wrapper para configurar el gradle wrapper (recomendado).

Para obtener todos los detalles de Gradle, consulte la sección de construcción de Gradle más abajo.

Elija su lambda

La extensión quarkus-amazon-lambda busca en tu proyecto una clase que implemente directamente la interfaz de Amazon RequestHandler<?, ?> o RequestStreamHandler. Debe encontrar una clase en tu proyecto que implemente esta interfaz o lanzará un fallo de compilación. Si encuentra más de una clase manejadora, también se lanzará una excepción de tiempo de compilación.

A veces, sin embargo, puede tener unas cuantas lambdas relacionadas que comparten código y crear varios módulos maven es una sobrecarga que no quiere hacer. La extensión quarkus-amazon-lambda le permite agrupar varias lambdas en un proyecto y utilizar la configuración o una variable de entorno para elegir el manejador que desea desplegar.

El proyecto generado tiene tres lambdas en su interior. Dos que implementan la interfaz RequestHandler<?, ?> y una que implementa la interfaz RequestStreamHandler. Una que se utiliza y dos que no se utilizan. Si abre src/main/resources/application.properties verá esto:

quarkus.lambda.handler=test

La propiedad quarkus.lambda.handler le dice a Quarkus qué manejador lambda desplegar. Esto también puede anularse con una variable de entorno.

Si observas las tres clases manejadoras generadas en el proyecto, verás que son @Named diferentes.

@Named("test")
public class TestLambda implements RequestHandler<InputObject, OutputObject> {
}

@Named("unused")
public class UnusedLambda implements RequestHandler<InputObject, OutputObject> {
}

@Named("stream")
public class StreamLambda implements RequestStreamHandler {
}

El nombre CDI de la clase manejadora debe coincidir con el valor especificado en la propiedad quarkus.lambda.handler.

Implementar en AWS Lambda Java Runtime

Hay unos cuantos pasos para conseguir que su lambda funcione en AWS. El proyecto maven generado contiene un script útil para crear, actualizar, eliminar e invocar sus lambdas para implementaciones Java puras y nativas.

Construir y desplegar

Construye el proyecto:

CLI
quarkus build
Maven
./mvnw install
Gradle
./gradlew build

Esto compilará y empaquetará su código.

Crear un rol de ejecución

Consulte la Guía de inicio para implementar un lambda con AWS CLI. Específicamente, asegúrese de haber creado un Execution Role. Tendrá que definir una variable de entorno LAMBDA_ROLE_ARN en su perfil o ventana de consola, Alternativamente, puede editar el script manage.sh que es generado por la compilación y poner el valor del rol directamente allí:

LAMBDA_ROLE_ARN="arn:aws:iam::1234567890:role/lambda-role"

Archivos extra generados por la compilación

Después de ejecutar la compilación, hay algunos archivos adicionales generados por la extensión quarkus-amazon-lambda. Estos archivos están en el directorio de construcción: target/ para maven, build/ para gradle.

  • function.zip - archivo de despliegue de lambda

  • manage.sh - envoltura alrededor de las llamadas aws lambda cli

  • bootstrap-example.sh - ejemplo de secuencia de comandos de arranque para las implantaciones nativas

  • sam.jvm.yaml - (opcional) para su uso con sam cli y pruebas locales

  • sam.native.yaml - (opcional) para su uso con sam cli y pruebas locales nativas

Crear la función

El script target/manage.sh sirve para administrar su lambda utilizando el tiempo de ejecución Java de AWS Lambda. Este script se proporciona únicamente para su comodidad. Examine la salida del script manage.sh si desea saber qué comandos aws se ejecutan para crear, eliminar y actualizar sus lambdas.

manage.sh admite cuatro operaciones: create, delete, update, y invoke.

Para verificar su configuración, que tiene la CLI de AWS instalada, ha ejecutado aws configure para las claves de acceso de AWS y ha configurado la variable de entorno LAMBDA_ROLE_ARN (como se ha descrito anteriormente), ejecute manage.sh sin ningún parámetro. Se imprimirá una declaración de uso para guiarte en consecuencia.
Si utiliza Gradle, la ruta a los binarios en manage.sh debe cambiarse de target a build

Para ver la declaración usage, y validar la configuración de AWS:

sh target/manage.sh

Puede crear su función utilizando el siguiente comando, create:

sh target/manage.sh create

o si no tiene LAMBDA_ROLE_ARN ya definido en este shell:

LAMBDA_ROLE_ARN="arn:aws:iam::1234567890:role/lambda-role" sh target/manage.sh create
No cambie el interruptor del manejador. Este debe estar codificado de manera fija como io.quarkus.amazon.lambda.runtime.QuarkusStreamHandler::handleRequest. Este controlador inicializa Quarkus y envuelve su controlador real para que la inyección se puede realizar.

Si hay algún problema en la creación de la función, debe borrarla con la función delete antes de volver a ejecutar el comando create.

sh target/manage.sh delete

Los comandos también pueden apilarse:

sh target/manage.sh delete create

Invocar la lambda

Utilice el comando invoke para invocar su función.

sh target/manage.sh invoke

La lambda de ejemplo toma la entrada pasada a través del modificador --payload que apunta a un archivo json en el directorio raíz del proyecto.

La lambda también se puede invocar localmente con la CLI de SAM de la siguiente manera:

sam local invoke --template target/sam.jvm.yaml --event payload.json

Si está trabajando con su construcción de imagen nativa, simplemente reemplace el nombre de la plantilla con la versión nativa:

sam local invoke --template target/sam.native.yaml --event payload.json

Actualizar la lambda

Puede actualizar el código Java como considere oportuno. Una vez que haya reconstruido, puede volver a desplegar su lambda ejecutando el comando update.

sh target/manage.sh update

Implementación en el tiempo de ejecución personalizado (nativo) de AWS Lambda

Si quieres una menor huella de memoria y tiempos de inicialización más rápidos para tu lambda, puedes compilar tu código Java a un ejecutable nativo. Sólo asegúrese de reconstruir su proyecto con el interruptor -Pnative.

Para hosts Linux, ejecute:

CLI
quarkus build --native
Maven
./mvnw install -Dnative
Gradle
./gradlew build -Dquarkus.native.enabled=true
Si está construyendo en un sistema que no sea Linux, tendrá que pasar también una propiedad indicando a Quarkus que utilice una construcción docker, ya que Amazon Lambda requiere binarios linux. Puede hacerlo pasando esta propiedad a su build: -Dquarkus.native.container-build=true. Sin embargo, esto requiere que tenga Docker instalado localmente.
CLI
quarkus build --native --no-tests -Dquarkus.native.container-build=true
# The --no-tests flag is required only on Windows and macOS.
Maven
./mvnw install -Dnative -DskipTests -Dquarkus.native.container-build=true
Gradle
./gradlew build -Dquarkus.native.enabled=true -Dquarkus.native.container-build=true

Cualquiera de estos comandos compilará y creará una imagen ejecutable nativa. También genera un archivo zip target/function.zip. Este archivo zip contiene su imagen ejecutable nativa renombrada a bootstrap. Este es un requisito del tiempo de ejecución personalizado (proporcionado) de AWS Lambda.

Las instrucciones son exactamente las mismas que las anteriores con un cambio: tendrá que añadir native como primer parámetro del script manage.sh:

sh target/manage.sh native create

Como en el caso anterior, los comandos se pueden apilar. El único requisito es que native sea el primer parámetro si desea trabajar con construcciones de imágenes nativas. El script se encargará del resto de los detalles necesarios para gestionar sus despliegues de funciones de imagen nativa.

Examine la salida del script manage.sh si desea saber qué comandos aws se ejecutan para crear, eliminar y actualizar sus lambdas.

Una cosa a tener en cuenta sobre el comando de creación para nativos es que la llamada a aws lambda create-function debe establecer una variable de entorno específica:

--environment 'Variables={DISABLE_SIGNAL_HANDLERS=true}'

Examinar el POM y la compilación Gradle

No hay nada especial en el POM aparte de la inclusión de la extensión quarkus-amazon-lambda como dependencia. La extensión genera automáticamente todo lo que pueda necesitar para el despliegue de su lambda.

En versiones anteriores de esta extensión había que configurar el pom o gradle para comprimir el ejecutable para despliegues nativos, pero esto ya no es así.

Construcción de Gradle

Del mismo modo, para los proyectos de Gradle, también sólo tienes que añadir la dependencia de quarkus-amazon-lambda. La extensión genera automáticamente todo lo que puedas necesitar para el despliegue de tu lambda.

Ejemplo de dependencias de Gradle:

dependencies {
    implementation enforcedPlatform("${quarkusPlatformGroupId}:${quarkusPlatformArtifactId}:${quarkusPlatformVersion}")
    implementation 'io.quarkus:quarkus-resteasy'
    implementation 'io.quarkus:quarkus-amazon-lambda'

    testImplementation 'io.quarkus:quarkus-junit5'
    testImplementation 'io.rest-assured:rest-assured'
}

Codificación en vivo y pruebas unitarias y de integración

Para reflejar el entorno de AWS Lambda lo más fielmente posible en un entorno de desarrollo, la extensión AWS Lambda de Quarkus inicia un servidor de eventos AWS Lambda simulado en el modo de desarrollo y prueba de Quarkus. Este servidor de eventos simulado simula un verdadero entorno de AWS Lambda.

Mientras se ejecuta en Quarkus Dev Mode, puede alimentarlo con eventos haciendo un POST HTTP a http://localhost:8080. El servidor de eventos simulado recibirá los eventos y su lambda será invocada. Puede realizar codificación en vivo en su lambda y los cambios se recompilarán automáticamente y estarán disponibles en la siguiente invocación que realice. He aquí un ejemplo:

CLI
quarkus dev
Maven
./mvnw quarkus:dev
Gradle
./gradlew --console=plain quarkusDev
$ curl -d "{\"name\":\"John\"}" -X POST http://localhost:8080

Para tus pruebas unitarias, también puedes invocar en el servidor de eventos falso usando cualquier cliente HTTP que quieras. Aquí hay un ejemplo usando rest-assured. Quarkus inicia un servidor de eventos simulados separado bajo el puerto 8081. El puerto por defecto para Rest Assured se establece automáticamente a 8081 por Quarkus para que pueda invocar en este punto final.

import org.junit.jupiter.api.Test;

import io.quarkus.test.junit.QuarkusTest;

import static io.restassured.RestAssured.given;
import static org.hamcrest.CoreMatchers.containsString;

@QuarkusTest
public class LambdaHandlerTest {

    @Test
    public void testSimpleLambdaSuccess() throws Exception {
        Person in = new Person();
        in.setName("Stu");
        given()
                .contentType("application/json")
                .accept("application/json")
                .body(in)
                .when()
                .post()
                .then()
                .statusCode(200)
                .body(containsString("Hello Stu"));
    }
}

El servidor de eventos simulados también se inicia para las pruebas de @NativeImageTest y @QuarkusIntegrationTest, por lo que también funcionará con binarios nativos. Todo esto proporciona una funcionalidad similar a las pruebas locales de SAM CLI, sin la sobrecarga de Docker.

Por último, si el puerto 8080 o el puerto 8081 no están disponibles en su ordenador, puede modificar los puertos de los modos dev y test con application.properties

quarkus.lambda.mock-event-server.dev-port=8082
quarkus.lambda.mock-event-server.test-port=8083

Un valor de puerto de cero resultará en un puerto asignado aleatoriamente.

Para desactivar el servidor de eventos simulado:

quarkus.lambda.mock-event-server.enabled=false

Pruebas con la CLI de SAM

Si no desea utilizar el servidor de eventos simulado, puede probar sus lambdas con SAM CLI.

La CLI SAM de AWS le permite ejecutar sus lambdas localmente en su portátil en un entorno Lambda simulado. Esto requiere que Docker esté instalado. Se trata de un enfoque opcional en caso de que decida aprovecharlo. De lo contrario, la integración JUnit de Quarkus debería ser suficiente para la mayoría de sus necesidades.

Se ha generado una plantilla de inicio para los modos de ejecución JVM y nativo.

Ejecute el siguiente comando CLI de SAM para probar localmente su función lambda, pasándole el parámetro apropiado de SAM template . El parámetro event toma cualquier archivo JSON, en este caso la muestra payload.json.

Si se utiliza Gradle, la ruta a los binarios en las plantillas YAML debe cambiarse de target a build 
sam local invoke --template target/sam.jvm.yaml --event payload.json

La imagen nativa también puede probarse localmente utilizando la plantilla sam.native.yaml:

sam local invoke --template target/sam.native.yaml --event payload.json

Modificación de function.zip

Hay veces en las que puedes tener que añadir algunas adiciones al despliegue de lambda function.zip que es generado por la construcción. Para ello crea un directorio zip.jvm o zip.native dentro de src/main. Crea zip.jvm/ si estás haciendo una lambda puramente Java. zip.native/ si estás haciendo un despliegue nativo.

Todos los archivos y directorios que crees bajo tu directorio zip se incluirán dentro de function.zip

Guión personalizado de bootstrap

Hay ocasiones en las que puede querer establecer unas propiedades específicas del sistema u otros argumentos cuando lambda invoque su despliegue lambda nativo de quarkus. Si incluye un archivo de script bootstrap dentro de zip.native , la extensión quarkus renombrará automáticamente el ejecutable a runner dentro de function.zip y establecerá el modo unix del script bootstrap a ejecutable.

El ejecutable nativo debe ser referenciado como runner si incluye un script personalizado de bootstrap.

La extensión genera un script de ejemplo dentro de target/bootstrap-example.sh.

Rastreo con AWS XRay y GraalVM

Si estás construyendo imágenes nativas, y quieres usar AWS X-Ray Tracing con tu lambda necesitarás incluir quarkus-amazon-lambda-xray como una dependencia en tu pom. La biblioteca de AWS X-Ray no es totalmente compatible con GraalVM, por lo que hemos tenido que hacer un trabajo de integración para que funcione.

Además, recuerde habilitar el parámetro de rastreo de AWS X-Ray en manage.sh, en la función cmd_create(). Esto también se puede configurar en la consola de administración de AWS.

    --tracing-config Mode=Active

Para los archivos de plantilla sam, añada lo siguiente a las Propiedades de la función YAML.

    Tracing: Active

AWS X-Ray añade muchas clases a su distribución, asegúrese de que está utilizando al menos el tamaño de memoria de 256 MB de AWS Lambda. Esto se establece explícitamente en manage.sh cmd_create(). Mientras que la imagen nativa potencialmente siempre puede utilizar una configuración de memoria inferior, sería recomendable mantener la misma configuración, especialmente para ayudar a comparar el rendimiento.

Uso de HTTPS o SSL/TLS

Si tu código hace llamadas HTTPS, como por ejemplo a un microservicio (o servicio AWS), tendrás que añadir la configuración a la imagen nativa, ya que GraalVM sólo incluirá las dependencias cuando se declaren explícitamente. Quarkus, por defecto habilita esta funcionalidad en las extensiones que implícitamente lo requieren. Para más información, consulta la Guía de Quarkus SSL

Abra src/main/resources/application.properties y añada la siguiente línea para habilitar SSL en su imagen nativa.

quarkus.ssl.native=true

Uso del AWS Java SDK v2

Quarkus tiene ahora extensiones para DynamoDB, S3, SNS y SQS (más en camino). Por favor, consulte esas guías sobre cómo utilizar los diversos servicios de AWS con Quarkus, en lugar de cablear manualmente como a continuación.

Con una integración mínima, es posible aprovechar el AWS Java SDK v2, que puede utilizarse para invocar servicios como SQS, SNS, S3 y DynamoDB.

Para la imagen nativa, sin embargo, se debe preferir el cliente de Conexión URL sobre el Cliente HTTP de Apache cuando se utiliza el modo síncrono, debido a problemas en la compilación de GraalVM (en la actualidad).

Añade quarkus-jaxb como dependencia en tu archivo Maven pom.xml, o Gradle build.gradle.

También debe forzar a su cliente de servicios de AWS para SQS, SNS, S3, entre otros, a utilizar el cliente de Conexión URL, que se conecta a los servicios de AWS a través de HTTPS, de ahí la inclusión de la propiedad SSL enabled, tal y como se describe en la sección Uso de HTTPS o SSL/TLS anterior.

// select the appropriate client, in this case SQS, and
// insert your region, instead of XXXX, which also improves startup time over the default client
  client = SqsClient.builder().region(Region.XXXX).httpClient(software.amazon.awssdk.http.urlconnection.UrlConnectionHttpClient.builder().build()).build();

Para Maven, añada lo siguiente a su pom.xml.

    <properties>
        <aws.sdk2.version>2.10.69</aws.sdk2.version>
    </properties>

    <dependencyManagement>
        <dependencies>

            <dependency>
                <groupId>software.amazon.awssdk</groupId>
                <artifactId>bom</artifactId>
                <version>${aws.sdk2.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>

        </dependencies>
    </dependencyManagement>
    <dependencies>

        <dependency>
            <groupId>software.amazon.awssdk</groupId>
            <artifactId>url-connection-client</artifactId>
        </dependency>

        <dependency>
            <groupId>software.amazon.awssdk</groupId>
            <artifactId>apache-client</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>commons-logging</groupId>
                    <artifactId>commons-logging</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

        <dependency>
            <groupId>software.amazon.awssdk</groupId>
            <!-- sqs/sns/s3 etc -->
            <artifactId>sqs</artifactId>
            <exclusions>
                <!-- exclude the apache-client and netty client -->
                <exclusion>
                    <groupId>software.amazon.awssdk</groupId>
                    <artifactId>apache-client</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>software.amazon.awssdk</groupId>
                    <artifactId>netty-nio-client</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>commons-logging</groupId>
                    <artifactId>commons-logging</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

        <dependency>
            <groupId>org.jboss.logging</groupId>
            <artifactId>commons-logging-jboss-logging</artifactId>
        </dependency>
    </dependencies>
Si ve java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty o un error SSL similar, debido al estado actual de GraalVM, hay algo de trabajo adicional para empaquetar el function.zip, como se indica a continuación. Para obtener más información, consulte la Guía de SSL nativa de Quarkus.

Requisitos adicionales para SSL cliente

El ejecutable nativo requiere algunos pasos adicionales para habilitar SSL de cliente que S3 y otras bibliotecas de AWS necesitan.

  1. Un script personalizado de bootstrap

  2. libsunec.so debe añadirse a function.zip

  3. cacerts debe añadirse a function.zip

Para ello, primero cree un directorio src/main/zip.native/ con su construcción. A continuación, cree un archivo de secuencia de comandos llamado bootstrap dentro de src/main/zip.native/, como se indica a continuación. Un ejemplo es crear automáticamente en su carpeta de construcción (target o build), llamado bootstrap-example.sh

#!/usr/bin/env bash

./runner -Djava.library.path=./ -Djavax.net.ssl.trustStore=./cacerts

Conjunto adicional -Djavax.net.ssl.trustStorePassword=changeit si su archivo cacerts está protegido por contraseña.

A continuación, debe copiar algunos archivos de su distribución GraalVM en src/main/zip.native/.

Las versiones de GraalVM pueden tener diferentes rutas para estos archivos, y si se utiliza la versión de Java 8 o 11. Ajústalo en consecuencia. 
cp $GRAALVM_HOME/lib/libsunec.so $PROJECT_DIR/src/main/zip.native/
cp $GRAALVM_HOME/lib/security/cacerts $PROJECT_DIR/src/main/zip.native/

Ahora, cuando ejecute la compilación nativa, todos estos archivos se incluirán en function.zip

Si está utilizando una imagen Docker para compilar, debe extraer estos archivos de esta imagen.

Para extraer el ssl necesario, debe iniciar un contenedor Docker en segundo plano, y adjuntar a ese contenedor para copiar los artefactos.

En primer lugar, vamos a iniciar el contenedor GraalVM, tomando nota de la salida de id de contenedor.

docker run -it -d --entrypoint bash quay.io/quarkus/ubi-quarkus-mandrel-builder-image:jdk-21

# This will output a container id, like 6304eea6179522aff69acb38eca90bedfd4b970a5475aa37ccda3585bc2abdde
# Note this value as we will need it for the commands below

En primer lugar, libsunec.so, la biblioteca C utilizada para la implementación de SSL:

docker cp {container-id-from-above}:/opt/graalvm/lib/libsunec.so src/main/zip.native/

En segundo lugar, cacerts, el almacén de certificados. Es posible que tenga que obtener periódicamente una copia actualizada, también.

docker cp {container-id-from-above}:/opt/graalvm/lib/security/cacerts src/main/zip.native/

Tu archivo final tendrá este aspecto:

jar tvf target/function.zip

    bootstrap
    runner
    cacerts
    libsunec.so

Implementación en AWS Lambda mediante una imagen de contenedor

AWS Lambda admite la creación de sus lambdas haciendo referencia a imágenes de contenedores en lugar de cargar archivos ZIP. Esto puede tener algunas ventajas, como evitar el límite de tamaño de los archivos ZIP cargados. Puede definir funciones lambda tanto para compilaciones nativas como para compilaciones JVM normales.

Imagen del contenedor JVM

Para una distribución regular de JVM necesitas basar tu imagen en las imágenes base oficiales de AWS Java. A continuación se muestra un ejemplo de un archivo Docker que crearía una imagen de contenedor de su proyecto Quarkus Lambda. Asume que mvn package ha sido ejecutado y los binarios están disponibles en el directorio target/:

FROM  public.ecr.aws/lambda/java:11

ADD target/my-service-0.0.1-SNAPSHOT-runner.jar /var/task/lib/my-service.jar
ADD target/lib/  /var/task/lib/

CMD ["io.quarkus.amazon.lambda.runtime.QuarkusStreamHandler::handleRequest"]

Imagen contenedor ejecutable nativa

Para crear una imagen de contenedor lambda que utilice el ejecutable nativo tendremos que hacer las cosas de forma un poco diferente. En este caso, no necesitaremos utilizar la imagen base de java:11 de AWS, sino que utilizaremos una imagen especial que asume que se proporciona el entorno de ejecución para lambda. El siguiente ejemplo crea un contenedor de este tipo. Asume que se ha ejecutado una construcción de Maven (como mvn package -Dnative=true) y ha generado el binario nativo en el directorio target/. El binario necesita ser llamado bootstrap y ser colocado en /var/runtime/:

FROM  public.ecr.aws/lambda/provided

ADD target/my-service-0.0.1-SNAPSHOT-runner /var/runtime/bootstrap
RUN chmod ugo+x /var/runtime/bootstrap

CMD ["io.quarkus.amazon.lambda.runtime.QuarkusStreamHandler::handleRequest"]

Despliegue de una imagen de contenedor lambda

A continuación, puede ver cómo las imágenes de contenedor creadas anteriormente pueden construirse e implementarse en AWS utilizando las herramientas de línea de comandos docker y aws. Estas instrucciones funcionan tanto para imágenes de contenedor nativas como jvm y asumen que la herramienta de línea de comandos aws ha sido iniciada.

Construir la imagen Docker

# Assuming we are located in the root directory of the project and created a Dockerfile there
docker build .
   [output omitted]
    => exporting to image                    0.0s
    => => exporting layers                   0.0s
    => => writing image sha256:[SOME SHA]    0.0s

Crear un repositorio ECR en la cuenta AWS del usuario

aws ecr create-repository --repository-name my/test/quarkus-lambda

Etiquete la imagen utilizando la información de su registro ECR

docker tag [SOME SHA] [YOUR AWS ACCOUNT ID].dkr.ecr.[YOUR AWS ACCOUNT REGION].amazonaws.com/my/test/quarkus-lambda:v1

Registre Docker en su registro ECR y envíele la imagen Docker

aws ecr get-login-password --region region | docker login --username AWS --password-stdin [YOUR AWS ACCOUNT ID].dkr.ecr.[YOUR AWS ACCOUNT REGION].amazonaws.com
docker push [YOUR AWS ACCOUNT ID].dkr.ecr.[YOUR AWS ACCOUNT REGION].amazonaws.com/my/test/quarkus-lambda:v1

Crear la función AWS lambda con la herramienta AWS CLI

Asegúrate de que haces referencia a la imagen que has subido previamente (se supone que existe un rol que puede ser utilizado para ejecutar la lambda). Ten en cuenta que no es improbable que para la función lambda de JVM, el límite de memoria por defecto de 128Mb no sea suficiente para ejecutar la función. En ese caso, puede aumentar el límite de memoria al crear la función proporcionando el parámetro --memory-size 256 a su comando aws lambda create-function. También puede ajustar la función en la consola de AWS después de haberla creado.

aws lambda create-function --function-name my-test-quarkus-lambda-function --package-type Image --code ImageUri=[YOUR AWS ACCOUNT ID].dkr.ecr.[YOUR AWS ACCOUNT REGION].amazonaws.com/my/test/quarkus-lambda:v1 --role arn:aws:iam::[YOUR AWS ACCOUNT ID]:role/[SOME ROLE]

Ahora puedes utilizar la consola de AWS para ver y probar tu nueva función lambda.

Integración de Amazon Alexa

Para utilizar Alexa con Quarkus nativo, es necesario utilizar la extensión Quarkus Amazon Alexa alojada en Quarkiverse Hub.

<dependency>
    <groupId>io.quarkiverse.alexa</groupId>
    <artifactId>quarkus-amazon-alexa</artifactId>
    <version>${quarkus-amazon-alexa.version}</version> (1)
</dependency>
1 Defina la última versión de la extensión en su archivo POM.

Crea tu manejador Alexa, como es normal, subclasificando el abstracto com.amazon.ask.SkillStreamHandler, y añade la implementación de tu manejador de peticiones.

¡Eso es todo!

SnapStart

Para optimizar su aplicación para Lambda SnapStart, consulte la documentación de configuración de SnapStart.

Related content

On the same extensions

On the same topics

Quarkus is open. All dependencies of this project are available under the Apache Software License 2.0 or compatible license.

This website was built with Jekyll, is hosted on GitHub Pages and is completely open source. If you want to make it better, fork the website and show us what you’ve got.

Navigation
Follow Us
Get Help
Languages
Quarkus is made of community projects
CC by 3.0 | Privacy Policy Sponsored by