The English version of quarkus.io is the official project site. Translated sites are community supported on a best-effort basis.
Back to Guides

Amazon Lambda

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

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

Quarkus’s integration with lambdas also supports Quarkus’s Live Coding development cycle. You can bring up your Quarkus lambda project in dev or test mode and code on your project live.

Requisitos previos

To complete this guide, you need:

  • Roughly 30 minutes

  • An IDE

  • JDK 11+ installed with JAVA_HOME configured appropriately

  • Apache Maven 3.8.8

  • Optionally the Quarkus CLI if you want to use it

  • Optionally Mandrel or GraalVM installed and configured appropriately if you want to build a native executable (or Docker if you use a native container build)

  • A Amazon AWS account

  • AWS CLI

  • AWS SAM CLI, para pruebas locales

For Gradle projects please see below, or for further reference consult the guide in the Gradle setup page.

Cómo empezar

Esta guía le guía a través de la generación de un proyecto Java de ejemplo a través de un arquetipo de maven y su implementación 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 implementación de Maven

Crea el proyecto maven de Quarkus AWS Lambda utilizando nuestro arquetipo Maven.

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

Si prefieres usar Gradle, puedes 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.

Copy the build.gradle, gradle.properties and settings.gradle into the above-generated Maven archetype project, to follow along with this guide.

Execute: gradle wrapper to set up the gradle wrapper (recommended).

For full Gradle details, see the Gradle build section below.

Elija su lambda

The quarkus-amazon-lambda extension scans your project for a class that directly implements the Amazon RequestHandler<?, ?> or RequestStreamHandler interface. It must find a class in your project that implements this interface, or it will throw a build time failure. If it finds more than one handler class, a build time exception will also be thrown.

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

El proyecto generado tiene tres lambdas dentro de él. Dos que implementan la interfaz RequestHandler<?, ?>, y una que implementa la interfaz RequestStreamHandler. Una que se usa y dos que no se usan. Si abres src/main/resources/application.properties verás esto:

quarkus.lambda.handler=test

La propiedad quarkus.lambda.handler indica a Quarkus qué manejador lambda debe desplegar. Esto puede ser anulado con una variable de entorno también.

Si miras las tres clases de manejadores 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 algunos pasos para conseguir que su lambda se ejecute en AWS. El proyecto maven generado contiene un script útil para crear, actualizar, eliminar e invocar sus lambdas para implementaciones puramente Java 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 una función 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 construcció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

After you run the build, there are a few extra files generated by the quarkus-amazon-lambda extension. These files are in the build directory: target/ for maven, build/ for 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 es para administrar su lambda utilizando el tiempo de ejecución de AWS Lambda Java. Este script se proporciona sólo para su comodidad. Examine la salida del script manage.sh si desea saber qué comandos de aws se ejecutan para crear, eliminar y actualizar sus lambdas.

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

To verify your setup, that you have the AWS CLI installed, executed aws configure for the AWS access keys, and set up the LAMBDA_ROLE_ARN environment variable (as described above), please execute manage.sh without any parameters. A usage statement will be printed to guide you accordingly.
Si se utiliza Gradle, la ruta de acceso 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 switch del manejador. Esto debe ser codificado en io.quarkus.amazon.lambda.runtime.QuarkusStreamHandler::handleRequest. Este manejador arranca Quarkus y envuelve su manejador real para que la inyección pueda ser realizada.

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 switch --payload que apunta a un archivo json en el directorio raíz del proyecto.

La lambda también puede ser invocada 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

Puedes actualizar el código Java como creas conveniente. Una vez que hayas reconstruido, puedes volver a desplegar tu 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 los hosts de Linux, ejecute:

CLI
quarkus build --native
Maven
./mvnw install -Dnative
Gradle
./gradlew build -Dquarkus.package.type=native
Si estás construyendo en un sistema que no es Linux, tendrás que pasar también una propiedad que indique a Quarkus que utilice una construcción docker, ya que Amazon Lambda requiere binarios linux. Puedes hacerlo pasando esta propiedad a tu construcción: -Dquarkus.native.container-build=true. Sin embargo, esto requiere que tengas 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.package.type=native -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.

Examina la salida del script manage.sh si quieres saber qué comandos aws se ejecutan para crear, borrar y actualizar tus 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 construcción de 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 puedas necesitar para tu despliegue de lambda.

In previous versions of this extension, you had to set up your pom or gradle to zip up your executable for native deployments, but this is not the case anymore.

Construcción de Gradle

Similarly, for Gradle projects, you also just have to add the quarkus-amazon-lambda dependency. The extension automatically generates everything you might need for your lambda deployment.

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 de unidad/integración

Para reflejar el entorno de AWS Lambda con la mayor exactitud posible en un entorno de desarrollo, la extensión de Quarkus Amazon Lambda inicia un servidor de eventos de AWS Lambda falso en el modo de desarrollo y prueba de Quarkus. Este servidor de eventos falso simula un verdadero entorno de AWS Lambda.

Mientras se ejecuta en el modo de desarrollo de Quarkus, puede alimentar los eventos haciendo un POST HTTP a http://localhost:8080. El servidor de eventos falso recibirá los eventos y su lambda será invocado. Puedes realizar codificación en vivo en tu lambda y los cambios se recompilarán automáticamente y estarán disponibles en la siguiente invocación que hagas. Aquí tienes un ejemplo:

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

For your unit tests, you can also invoke on the mock event server using any HTTP client you want. Here’s an example using rest-assured. Quarkus starts up a separate Mock Event server under port 8081. The default port for Rest Assured is automatically set to 8081 by Quarkus, so you can invoke on this endpoint.

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"));
    }
}

The mock event server is also started for @QuarkusIntegrationTest tests so will work with native binaries too. All this provides similar functionality to the SAM CLI local testing, without the overhead of Docker.

Por último, si el puerto 8080 o el puerto 8081 no están disponibles en su ordenador, puede modificar los puertos en modo 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.

Pruebas con la CLI de SAM

Si no quieres utilizar el servidor de eventos simulado, puedes probar tus lambdas con SAM CLI.

La AWS SAM CLI le permite ejecutar sus lambdas localmente en su portátil en un entorno de Lambda simulado. Esto requiere la instalación de docker. Este es un enfoque opcional en caso de que decidas aprovecharlo. De lo contrario, la integración de Quarkus JUnit 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, pasando el parámetro apropiado de SAM template. El parámetro event toma cualquier archivo JSON, en este caso el ejemplo 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

There are times when you may have to add some additions to the function.zip lambda deployment that is generated by the build. To do this, create a zip.jvm or zip.native directory within src/main. Create zip.jvm/ if you are doing a pure Java lambda. zip.native/ if you are doing a native deployment.

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

Script personalizado de bootstrap

Hay veces que puedes querer establecer unas propiedades específicas del sistema u otros argumentos cuando lambda invoca tu despliegue lambda nativo de quarkus. Si incluyes 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

If you are building native images, and want to use AWS X-Ray Tracing with your lambda you will need to include quarkus-amazon-lambda-xray as a dependency in your pom. The AWS X-Ray library is not fully compatible with GraalVM, so we had to do some integration work to make this work.

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 la función YAML Propiedades.

    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() . Aunque la imagen nativa siempre puede utilizar una configuración de memoria más baja, se recomienda mantener la misma configuración, especialmente para ayudar a comparar el rendimiento.

Uso de HTTPS o SSL/TLS

If your code makes HTTPS calls (e.g. to a microservice, to an AWS service), you will need to add configuration to the native image, as GraalVM will only include the dependencies when explicitly declared. Quarkus, by default enables this functionality on extensions that implicitly require it. For further information, please consult the Quarkus SSL guide

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 SDK de Java de AWS v2

Quarkus ahora tiene extensiones para DynamoDB, S3, SNS y SQS (más en camino). Por favor, consulte estas guías sobre cómo utilizar los diversos servicios de AWS con Quarkus, en lugar de cablear manualmente como se indica 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.

For native image, however, the URL Connection client must be preferred over the Apache HTTP Client when using synchronous mode, due to issues in the GraalVM compilation (at present).

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

You must also force your AWS service client for SQS, SNS, S3 et al., to use the URL Connection client, which connects to AWS services over HTTPS, hence the inclusion of the SSL enabled property, as described in the Using HTTPS or SSL/TLS section above.

// 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 ves 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 agrupar el function.zip, como se indica a continuación. Para más información, por favor vea la Guía de SSL nativa de Quarkus.

Requisitos adicionales para el SSL del cliente

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

  1. Un script personalizado de bootstrap

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

  3. cacerts debe añadirse a function.zip

To do this, first create a directory src/main/zip.native/ with your build. Next create a shell script file called bootstrap within src/main/zip.native/, like below. An example is created automatically in your build folder (target or build), called 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 debes copiar algunos archivos de tu distribución de GraalVM en src/main/zip.native/.

GraalVM versions can have different paths for these files whether you are using the Java 8 or 11 version. Adjust accordingly. 
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 construir, entonces 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, observando la salida del id del contenedor.

docker run -it -d --entrypoint bash quay.io/quarkus/ubi-quarkus-graalvmce-builder-image:22.3-java17

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

First, libsunec.so, the C library used for the SSL implementation:

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

Second, cacerts, the certificate store. You may need to periodically obtain an updated copy, also.

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

Su 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 supports creating your lambdas by referencing container images rather than uploading ZIP files. This can have some benefits such as bypassing the size limit of the uploaded ZIP files. You can define lambda functions for both native builds and regular JVM builds.

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 ejecutable nativa del contenedor

To create a lambda container image that uses the native executable we’ll need to do things a little differently. In this case, we won’t need to use the java:11 base image from AWS, but instead we’ll use a special image that assumes that the runtime environment for the lambda is provided. The example below creates such a container. It assumes that a Maven build has been executed (such as mvn package -Dnative=true) and has generated the native binary into the target/ directory. The binary needs to be named bootstrap and be placed in /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

Etiquetar la imagen con 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 empuje la imagen Docker a él

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 usar 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 el 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 de Alexa, como es normal, usando una sub-clase abstracta de com.amazon.ask.SkillStreamHandler, y añade la implementación de tu manejador de peticiones.

Eso es todo!

SnapStart

To optimize your application for Lambda SnapStart, check the SnapStart Configuration Documentation.

Quarkus es libre. Todas las dependencias de este proyecto están disponible bajo la Licencia Apache Software 2.0 o una licencia compatible.

Este sitio web fue construido con Jekyll, está alojado en GitHub Pages y es completamente de código abierto. Si quieres mejorarlo, crea un fork de la página web y muéstranos lo que tienes.

Navigation
Síguenos
Obtener ayuda
Languages
Quarkus está hecho a base de proyectos comunitarios
CC by 3.0 | Privacy Policy Sponsored by