The English version of quarkus.io is the official project site. Translated sites are community supported on a best-effort basis.
Voltar aos Guias

AWS Lambda

A extensão quarkus-amazon-lambda permite que você use o Quarkus para criar seus Lambdas da AWS. Seus lambdas podem usar anotações de injeção do CDI ou do Spring e outros recursos do Quarkus, conforme a necessidade.

Os lambdas do Quarkus podem ser implantados usando o runtime Java do AWS Lambda, ou você pode criar um executável nativo e usar o runtime personalizado da Amazon, se quiser um espaço de memória menor e um tempo de inicialização mais rápido no cold boot.

A integração do Quarkus com lambdas também suporta o ciclo de desenvolvimento Quarkus’s Live Coding. Você pode abrir seu projeto lambda do Quarkus no modo de desenvolvimento ou teste e codificar seu projeto ao vivo.

Pré-requisitos

Para concluir este guia, você precisa:

  • Mais ou menos 30 minutes

  • Um IDE

  • JDK 17+ installed with JAVA_HOME configured appropriately

  • Apache Maven 3.9.9

  • Opcionalmente, o Quarkus CLI se você quiser usá-lo

  • Opcionalmente, Mandrel ou GraalVM instalado e configurado apropriadamente se você quiser criar um executável nativo (ou Docker se você usar uma compilação de contêiner nativo)

  • Uma conta Amazon AWS

  • CLI da AWS

  • AWS SAM CLI, para testes locais

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

Como começar

Este guia orienta-o na geração de um projeto Java de exemplo através de um arquétipo maven e na sua implementação na AWS.

Instalação de bits da AWS

A instalação de todos os bits da AWS é provavelmente a parte mais difícil deste guia. Certifique-se de seguir todas as etapas para instalar a AWS CLI.

Criar o projeto de implementação Maven

Crie o projeto maven do Quarkus AWS Lambda utilizando o nosso Arquétipo Maven.

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

Se preferir usar o Gradle, você pode gerar um projeto Gradle de forma rápida e fácil em code.quarkus.io , adicionando a extensão quarkus-amazon-lambda como uma dependência.

Copie o build.gradle, gradle.properties e settings.gradle para o projeto de arquétipo Maven gerado acima, para seguir este guia.

Execute: gradle wrapper para configurar o gradle wrapper (recomendado).

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

Escolha o seu Lambda

A extensão quarkus-amazon-lambda verifica seu projeto em busca de uma classe que implemente diretamente a interface Amazon RequestHandler<?, ?> ou RequestStreamHandler. Ela deve encontrar uma classe em seu projeto que implemente essa interface, caso contrário, lançará uma falha no tempo de compilação. Se encontrar mais de uma classe de manipulador, uma exceção de tempo de compilação também será lançada.

Às vezes, porém, você pode ter alguns lambdas relacionados que compartilham código e a criação de vários módulos maven é apenas uma sobrecarga que não se deseja fazer. A extensão quarkus-amazon-lambda permite agrupar vários lambdas em um projeto e usar a configuração ou uma variável de ambiente para escolher o manipulador que deseja implantar.

O projeto gerado tem três lambdas dentro dele. Dois que implementam a interface RequestHandler<?, ?> e um que implementa a interface RequestStreamHandler. Um que é usado e dois que não são usados. Se você abrir o arquivo src/main/resources/application.properties , verá o seguinte:

quarkus.lambda.handler=test

A propriedade quarkus.lambda.handler informa ao Quarkus qual manipulador de lambda deve ser implantado. Isso também pode ser substituído por uma variável de ambiente.

Se olhar para as três classes de manipuladores geradas no projeto, verá que são @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 {
}

O nome CDI da classe do manipulador deve corresponder ao valor especificado na propriedade quarkus.lambda.handler.

Implantar no runtime Java da AWS Lambda

Há algumas etapas para que seu lambda seja executado na AWS. O projeto maven gerado contém um script útil para criar, atualizar, excluir e invocar seus lambdas para implantações puramente Java e nativas.

Construir e implementar

Construir o projeto:

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

Isto irá compilar e empacotar o seu código.

Criar uma função de execução

Consulte o Guia de Introdução para implantar um lambda com a AWS CLI. Especificamente, certifique-se de ter criado um Execution Role. Será necessário definir uma variável de ambiente LAMBDA_ROLE_ARN no seu perfil ou na janela do console. Como alternativa, você pode editar o script manage.sh gerado pela compilação e colocar o valor da função diretamente lá:

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

Arquivos extras gerados pela compilação

Depois você executa a compilação, há alguns arquivos extras gerados pela extensão quarkus-amazon-lambda. Esses arquivos estão no diretório de compilação: target/ para maven, build/ para gradle.

  • function.zip - arquivo de implementação do lambda

  • manage.sh - script para chamadas do lambda através da AWS CLI

  • bootstrap-example.sh - exemplo de script de inicialização para implementações nativas

  • sam.jvm.yaml - (opcional) para utilização com SAM CLI e testes locais

  • sam.native.yaml - (opcional) para utilização com SAM CLI e testes locais nativos

Criar a função

O script target/manage.sh serve para gerenciar seu lambda usando o tempo de execução Java do AWS Lambda. Esse script é fornecido apenas para sua conveniência. Examine a saída do script manage.sh se quiser saber quais comandos do AWS são executados para criar, excluir e atualizar seus lambdas.

manage.sh suporta quatro operações: create , delete , update , e invoke.

Para verificar a configuração, se você tem a AWS CLI instalada, se executou o aws configure para as chaves de acesso da AWS, e configurou a variável de ambiente LAMBDA_ROLE_ARN (conforme descrito acima), execute manage.sh sem nenhum parâmetro. Uma declaração de uso será impressa para orientá-lo adequadamente.
Se estiver utilizando o Gradle, o caminho para os binários em manage.sh deve ser alterado de target para build

Para ver a declaração usage e validar a configuração da AWS:

sh target/manage.sh

Pode create a sua função utilizando o seguinte comando:

sh target/manage.sh create

ou se não tiver LAMBDA_ROLE_ARN já definido neste shell:

LAMBDA_ROLE_ARN="arn:aws:iam::1234567890:role/lambda-role" sh target/manage.sh create
Não altere a chave do manipulador. Isso deve ser codificado para io.quarkus.amazon.lambda.runtime.QuarkusStreamHandler::handleRequest. Esse manipulador inicializa o Quarkus e envolve o seu manipulador real para que a injeção possa ser executada.

Se houver algum problema na criação da função, você deverá excluí-la com a função delete antes de executar novamente o comando create.

sh target/manage.sh delete

Os comandos também podem ser empilhados:

sh target/manage.sh delete create

Invocar o Lambda

Utilize o comando invoke para invocar a sua função.

sh target/manage.sh invoke

O exemplo de lambda recebe a entrada passada por meio da opção --payload que aponta para um arquivo json no diretório raiz do projeto.

O lambda também pode ser invocado localmente com o SAM CLI da seguinte forma:

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

Se estiver a trabalhar com a sua compilação de imagem nativa, basta substituir o nome do modelo pela versão nativa:

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

Atualizar o Lambda

Você pode atualizar o código Java conforme achar necessário. Após a reconstrução, você pode reimplantar o lambda executando o comando update.

sh target/manage.sh update

Implantar no runtime personalizado (nativo) do AWS Lambda

Se quiser um espaço de memória menor e tempos de inicialização mais rápidos para seu lambda, você compilar o código Java em um executável nativo. Apenas certifique-se de reconstruir seu projeto com a opção -Dnative.

Para sistemas Linux, execute:

CLI
quarkus build --native
Maven
./mvnw install -Dnative
Gradle
./gradlew build -Dquarkus.native.enabled=true
Se estiver construindo em um sistema que não seja Linux, também precisará passar uma propriedade instruindo o Quarkus a usar uma construção do docker, pois o Amazon Lambda exige binários Linux. Você pode fazer isso passando esta propriedade para sua compilação: -Dquarkus.native.container-build=true. No entanto, isso exige que o Docker esteja 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

Qualquer um desses comandos compilará e criará uma imagem executável nativa. Ele também gera um arquivo zip target/function.zip. Esse arquivo zip contém sua imagem executável nativa renomeada para bootstrap. Esse é um requisito do runtime personalizado (fornecido) do AWS Lambda.

As instruções aqui são exatamente como acima, com uma alteração: você precisará adicionar native como o primeiro parâmetro do script manage.sh:

sh target/manage.sh native create

Como acima, os comandos podem ser empilhados. A única exigência é que native seja o primeiro parâmetro, caso deseje trabalhar com compilações de imagens nativas. O script cuidará dos detalhes necessários para gerenciar suas implementações de funções de imagem nativa.

Examine a saída do script manage.sh se quiser saber quais comandos da aws são executados para criar, excluir e atualizar seus lambdas.

Um aspecto a ser observado sobre o comando create para nativo é que a chamada aws lambda create-function deve definir uma variável de ambiente específica:

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

Examinar o POM e a compilação do Gradle

Não há nada de especial no POM além da inclusão da extensão quarkus-amazon-lambda como uma dependência. A extensão gera automaticamente tudo o que pode precisar para a implantação do lambda.

Nas versões anteriores dessa extensão, era necessário configurar o pom ou gradle para compactar o executável para implantações nativas, mas esse não é mais o caso.

Construção Gradle

Da mesma forma, para projetos Gradle, você também só precisa adicionar a dependência quarkus-amazon-lambda. A extensão gera automaticamente tudo o que pode precisar para a implantação do lambda.

Exemplo de dependências do 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'
}

Live Coding e testes unitários/integração

Para espelhar o ambiente do AWS Lambda o mais próximo possível em um ambiente de desenvolvimento, a extensão do Quarkus AWS Lambda inicializa um servidor de eventos simulado do AWS Lambda no modo de desenvolvimento e teste do Quarkus. Esse servidor de eventos simulado simula um verdadeiro ambiente do AWS Lambda.

Durante a execução no modo de desenvolvimento do Quarkus, voê pode alimentar eventos para ele fazendo um HTTP POST para http://localhost:8080. O servidor de eventos simulado receberá os eventos e seu lambda será chamado. Você pode executar a codificação ao vivo no seu lambda e as alterações serão automaticamente recompiladas e estarão disponíveis na próxima invocação que fizer. Veja um exemplo:

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

Para seus testes de unidade, você também pode invocar o servidor de eventos simulado usando qualquer cliente HTTP que desejar. Aqui está um exemplo usando o rest-assured. O Quarkus inicia um servidor de evento simulado separado na porta 8081. A porta padrão do Rest Assured é automaticamente definida como 8081 pelo Quarkus, portanto, pode invocar esse 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"));
    }
}

O servidor de eventos simulado também é iniciado para os testes do @QuarkusIntegrationTest , portanto, também funcionará com binários nativos. Tudo isso oferece funcionalidade semelhante ao teste local da SAM CLI, sem a sobrecarga do Docker.

Por fim, se a porta 8080 ou a porta 8081 não estiver disponível em seu computador, você poderá modificar as portas dos modos dev e test com application.properties

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

Um valor de porta igual a zero resultará numa porta atribuída aleatoriamente.

Para desativar o servidor de eventos simulado:

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

Testes com a SAM CLI

Se não pretende utilizar o servidor de eventos simulado, pode testar os seus lambdas com o SAM CLI.

O AWS SAM CLI permite que execute seus lambdas localmente no seu laptop em um ambiente Lambda simulado. Isso requer a instalação do docker . Essa é uma abordagem opcional, caso opte por aproveitá-la. Caso contrário, a integração do Quarkus JUnit deve ser suficiente para a maioria das suas necessidades.

Foi gerado um modelo inicial para os modos de execução JVM e nativo.

Execute o seguinte comando SAM CLI para testar localmente sua função lambda, passando o template SAM apropriado. O parâmetro event usa qualquer arquivo JSON, neste caso o exemplo payload.json.

Se estiver a utilizar o Gradle, o caminho para os binários nos modelos YAML deve ser alterado de target para build 
sam local invoke --template target/sam.jvm.yaml --event payload.json

A imagem nativa também pode ser testada localmente utilizando o modelo sam.native.yaml:

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

Modificar function.zip

Há ocasiões em que você pode ter de adicionar alguns acréscimos à implementação do lambda function.zip gerada pela compilação. Para fazer isso, crie um diretório zip.jvm ou zip.native dentro de src/main. Crie zip.jvm/ se estiver fazendo um lambda Java puro. zip.native/ se estiver fazendo uma implementação nativa.

Todos os ficheiros e diretórios que criar no seu diretório zip serão incluídos no function.zip

Script personalizado bootstrap

Às vezes, você pode querer definir propriedades específicas do sistema ou outros argumentos quando o lambda invoca a implantação nativa do lambda do quarkus. Se incluir um arquivo de script bootstrap em zip.native, a extensão quarkus renomeará automaticamente o executável para runner em function.zip e definirá o modo unix do script bootstrap como executável.

O executável nativo tem de ser referenciado como runner se incluir um script bootstrap personalizado.

A extensão gera um script de exemplo em target/bootstrap-example.sh.

Rastreabilidade com AWS X-Ray e GraalVM

Se estiver criando imagens nativas e quiser usar o AWS X-Ray Tracing com seu lambda, será necessário incluir quarkus-amazon-lambda-xray como uma dependência no seu pom. A biblioteca do AWS X-Ray não é totalmente compatível com o GraalVM, portanto, tivemos que fazer algum trabalho de integração para que isso funcionasse.

Além disso, lembre-se de ativar o parâmetro de rastreamento do AWS X-Ray em manage.sh, na função cmd_create(). Isso também pode ser definido no Console de gerenciamento da AWS.

    --tracing-config Mode=Active

Para os arquivos de modelo SAM, adicione o seguinte às propriedades da função YAML.

    Tracing: Active

O AWS X-Ray adiciona muitas classes à sua distribuição, portanto, certifique-se de que esteja usando pelo menos o tamanho de memória do AWS Lambda de 256 MB. Isso é definido explicitamente em manage.sh cmd_create(). Embora a imagem nativa sempre possa usar uma configuração de memória menor, seria recomendável manter a mesma configuração, especialmente para ajudar a comparar o desempenho.

Utilizar HTTPS ou SSL/TLS

Se o seu código fizer chamadas HTTPS (por exemplo, para um microsserviço, para um serviço AWS), precisará adicionar a configuração à imagem nativa, pois o GraalVM só incluirá as dependências quando declaradas explicitamente. O Quarkus, por padrão, habilita essa funcionalidade em extensões que implicitamente a exigem. Para obter mais informações, consulte o guia SSL do Quarkus

Abra src/main/resources/application.properties e adicione a seguinte linha para ativar o SSL na sua imagem nativa.

quarkus.ssl.native=true

Utilizar o AWS Java SDK v2

O Quarkus agora tem extensões para DynamoDB, S3, SNS e SQS (mais em breve). Consulte esses guias sobre como usar os vários serviços da AWS com o Quarkus, em vez de fazer a conexão manualmente, como abaixo.

Com uma integração mínima, é possível aproveitar o AWS Java SDK v2, que pode ser usado para invocar serviços como SQS, SNS, S3 e DynamoDB.

Para a imagem nativa, no entanto, o cliente de conexão de URL deve ser preferido ao cliente HTTP Apache ao usar o modo síncrono, devido a problemas na compilação do GraalVM (no momento).

Adicione quarkus-jaxb como uma dependência no seu arquivo Maven pom.xml, ou 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 Utilizar HTTPS ou 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 o Maven, adicione o seguinte ao seu 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>
Se você vir java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty ou erro SSL semelhante, devido ao status atual do GraalVM, há algum trabalho adicional para agrupar o function.zip , conforme abaixo. Para obter mais informações, consulte o Guia do Quarkus Native SSL.

Requisitos adicionais para o cliente SSL

O executável nativo requer algumas etapas adicionais para habilitar o SSL do cliente que o S3 e outras bibliotecas da AWS precisam.

  1. Um script bootstrap personalizado

  2. libsunec.so deve ser adicionado a function.zip

  3. cacerts deve ser adicionado a function.zip

Para fazer isso, primeiro crie um diretório src/main/zip.native/ com sua compilação. Em seguida, crie um arquivo de script de shell chamado bootstrap dentro de src/main/zip.native/, como abaixo. Um exemplo é criado automaticamente em sua pasta de compilação (target ou build), chamado bootstrap-example.sh

#!/usr/bin/env bash

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

Conjunto adicional -Djavax.net.ssl.trustStorePassword=changeit se o arquivo cacerts estiver protegido por senha.

Em seguida, deve copiar alguns arquivos da sua distribuição GraalVM para src/main/zip.native/.

As versões do GraalVM podem ter caminhos diferentes para estes arquivos, quer esteja a utilizar a versão Java 8 ou 11. Ajuste em conformidade. 
cp $GRAALVM_HOME/lib/libsunec.so $PROJECT_DIR/src/main/zip.native/
cp $GRAALVM_HOME/lib/security/cacerts $PROJECT_DIR/src/main/zip.native/

Agora, quando executar a compilação nativa, todos estes ficheiros serão incluídos no function.zip

Se estiver a utilizar uma imagem Docker para construir, então deve extrair estes arquivos desta imagem.

Para extrair o ssl necessário, você deve iniciar um contêiner Docker em segundo plano e anexar a esse contêiner para copiar os artefatos.

Primeiro, vamos iniciar o contêiner GraalVM, observando a saída do id do contêiner.

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

Em primeiro lugar, libsunec.so, a biblioteca C utilizada para a implementação do SSL:

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

Em segundo lugar, cacerts, o repositório de certificados. Poderá também ser necessário obter periodicamente uma cópia atualizada.

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

O seu arquivo final terá o seguinte formato:

jar tvf target/function.zip

    bootstrap
    runner
    cacerts
    libsunec.so

Implantar no AWS Lambda usando uma imagem de contêiner

O AWS Lambda suporta a criação dos seus lambdas referenciando imagens de contêineres em vez de carregar arquivos ZIP. Isso pode ter alguns benefícios, como contornar o limite de tamanho dos arquivos ZIP carregados. É possível definir funções lambda tanto para compilações nativas quanto para compilações regulares da JVM.

Imagem do contêiner JVM

Para uma distribuição regular da JVM, é necessário basear sua imagem nas imagens base oficiais do AWS Java. Abaixo está um exemplo de um Dockerfile que criaria uma imagem de contêiner a partir do seu projeto Quarkus Lambda. Ele assume que mvn package foi executado e que os binários estão disponíveis no diretório 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"]

Imagem de contêiner com executável nativo

Para criar uma imagem de contêiner lambda que use o executável nativo, precisaremos fazer as coisas de forma um pouco diferente. Nesse caso, não precisaremos usar a imagem base java:11 da AWS, mas, em vez disso, usaremos uma imagem especial que assume que o ambiente runtime para o lambda é fornecido. O exemplo abaixo cria esse contêiner. Ele assume que uma compilação Maven foi executada (como mvn package -Dnative=true) e gerou o binário nativo no diretório target/. O binário precisa ser nomeado bootstrap e ser colocado em /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"]

Implementar uma imagem de contêiner lambda

Abaixo, você pode ver como as imagens de contêiner criadas acima podem ser criadas e implantadas na AWS usando as ferramentas de linha de comando docker e aws. Essas instruções funcionam para imagens de contêineres nativas e jvm e pressupõem que a ferramenta de linha de comando aws tenha sido conectada.

Criar a imagem do 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

Criar um repositório ECR na conta AWS do usuário

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

Marque a imagem utilizando as suas informações de registro ECR

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

Registar o Docker no seu registo ECR e enviar a imagem Docker para o mesmo

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

Criar a função lambda da AWS com a ferramenta CLI do AWS

Certifique-se de que faz referência à imagem que carregou anteriormente (pressupõe que existe uma função que pode ser utilizada para executar o lambda). Observe que não é improvável que, para a função lambda da JVM, o limite de memória padrão de 128Mb não seja suficiente para executar a mesma. Nesse caso, pode aumentar o limite de memória ao criar a função, fornecendo o parâmetro --memory-size 256 ao seu comando aws lambda create-function. Também pode ajustar a função no console AWS depois de a ter criado.

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]

Agora pode utilizar o console AWS para ver e testar a sua nova função lambda.

Integração com o Amazon Alexa

Para utilizar a Alexa com o Quarkus nativo, é necessário utilizar a extensão Quarkus Amazon Alexa do Quarkiverse Hub.

<dependency>
    <groupId>io.quarkiverse.alexa</groupId>
    <artifactId>quarkus-amazon-alexa</artifactId>
    <version>${quarkus-amazon-alexa.version}</version> (1)
</dependency>
1 Defina a versão mais recente da extensão no seu arquivo POM.

Crie o seu manipulador Alexa, como habitualmente, sub-classificando o abstrato com.amazon.ask.SkillStreamHandler, e adicione a implementação do seu manipulador de pedidos.

É tudo o que há para fazer!

SnapStart

Para otimizar a sua aplicação para o Lambda SnapStart, consulte a documentação de configuração do SnapStart.

Conteúdo Relacionado

Nas mesmas extensões

Nos mesmos tópicos

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