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

Amazon Lambda

quarkus-amazon-lambda エクステンションを使うと、Quarkusを使ってAWS Lambda を構築することができます。Lambda では、CDIやSpringからのインジェクションアノテーションや、必要に応じてQuarkusの他の機能を使用することができます。

Quarkus の Lambda は、Amazon Java ランタイムを使用してデプロイすることもできますが、より小さなメモリーフットプリントとより高速なコールドブート起動時間が必要な場合は、ネイティブ実行可能ファイルをビルドして Amazon のカスタムランタイムを使用することもできます。

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.

前提条件

このガイドを完成させるには、以下が必要です:

  • ざっと 30 minutes

  • IDE

  • JDK 11+ がインストールされ、 JAVA_HOME が適切に設定されていること

  • Apache Maven 3.8.1+

  • 使用したい場合、 Quarkus CLI

  • ネイティブ実行可能ファイルをビルドしたい場合、MandrelまたはGraalVM(あるいはネイティブなコンテナビルドを使用する場合はDocker)をインストールし、 適切に設定していること

  • An Amazon AWS account

  • AWS CLI

  • AWS SAM CLI 、ローカルテスト用

Gradle プロジェクトの場合は 下記を参照 してください。詳細については、Gradle setup page セットアップページのガイドを参照してください。

はじめに

このガイドでは、maven の Archetype を使用して Java プロジェクトのサンプルを生成し、AWS にデプロイする方法を説明します。

AWS ビットのインストール

AWSのすべてのツールをインストールすることは、おそらくこのガイドでは最も難しいことです。AWS CLIをインストールするためのすべての手順に従っていることを確認してください。

デプロイ用のMavenプロジェクトを作成する

Maven Archetypeを使用してQuarkus AWS Lambda mavenプロジェクトを作成します。

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

Gradleを使いたい場合は、 code.quarkus.io を使って、 quarkus-amazon-lambda エクステンションを依存関係として追加することで、素早く簡単にGradleプロジェクトを生成することができます。

build.gradle、gradle.properties、settings.gradleを上記の生成されたMavenのアーキタイププロジェクトにコピーして、このガイドに従ってください。

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

Gradle の詳細については、以下を参照 してください。

使用する Lambda の選択

quarkus-amazon-lambda エクステンションは、Amazon RequestHandler<?, ?> または RequestStreamHandler インターフェイスを直接実装しているクラスをプロジェクト内でスキャンします。このインターフェイスを実装しているクラスがプロジェクト内で見つかるようにしなければならず、そうでない場合にはビルド時に例外がスローされます。複数のハンドラークラスを見つけた場合にも、ビルド時の例外がスローされます。

しかし、時にはコードを共有するいくつかの関連する Lambda があって、複数の maven モジュールを作成することは、やりたくないオーバーヘッドに過ぎないことがあるかもしれません。 quarkus-amazon-lambda エクステンションを使用すると、1 つのプロジェクトに複数のラムダをバンドルし、設定または環境変数を使用してデプロイしたいハンドラーを選択することができます。

生成されたプロジェクトは、その中に3つの Lambda を持っています。 RequestHandler<?, ?> インターフェイスを実装したものが 2 つ、 RequestStreamHandler インターフェイスを実装したものが 1 つ。1つは使用され、2つは未使用です。 src/main/resources/application.properties を開くと、このようになります。

quarkus.lambda.handler=test

quarkus.lambda.handler プロパティーは、デプロイする Lambda ハンドラーをQuarkusに伝えます。これは環境変数でオーバーライドすることもできます。

プロジェクト内で生成された3つのハンドラークラスを見てみると、異なる @Named が指定されていることがわかります。

@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 {
}

ハンドラークラスのCDI名は、 quarkus.lambda.handler プロパティー内で指定された値と一致しなければなりません。

AWS Lambda Java Runtime ランタイムへのデプロイ

Lambda をAWS上で動作させるには、いくつかのステップがあります。生成されたmavenプロジェクトには、pure Java とネイティブデプロイメント用の Lambda を作成、更新、削除、呼び出しするための便利なスクリプトが含まれています。

ビルドとデプロイ

プロジェクトをビルドします。

CLI
quarkus build
Maven
./mvnw clean package
Gradle
./gradlew build

これでコードがコンパイルされ、パッケージ化されます。

実行ロールの作成

AWS CLIを使った Lambda のデプロイ方法については、 Getting Started Guide を参照してください。具体的には、 Execution Role を作成していることを確認してください。プロファイルやコンソールウィンドウで LAMBDA_ROLE_ARN 環境変数を定義する必要があります。また、ビルドで生成される manage.sh スクリプトを編集して、そこに直接ロール値を置くこともできます。

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

ビルド時に追加生成されるファイル

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 - Lambda デプロイファイル

  • manage.sh - aws Lambda CLI の呼び出しのラッパー

  • bootstrap-example.sh - ネイティブデプロイ用のブートストラップスクリプトの例

  • sam.jvm.yaml - (オプション) SAM CLI やローカル・テスト用

  • sam.native.yaml - (オプション) SAM CLI やネイティブ・ローカル・テスト用(オプション)

関数を作成する

target/manage.sh スクリプトは、AWS Lambda Java ランタイムを使用して Lambda を管理するためのものです。このスクリプトは利便性のためだけに提供されています。Lambda の作成、削除、更新のためにどのようなawsコマンドが実行されるかを知りたい場合は、 manage.sh スクリプトの出力を確認してください。

manage.sh は、 create , delete , update , invoke の 4 つの操作をサポートしています。

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.
Gradleを使用している場合、 manage.sh のバイナリーへのパスを target から build に変更しなければなりません。

usage を参照したり、AWS の設定を検証するためには次のようにします。

sh target/manage.sh

次のコマンドを使って、 Function を create します。

sh target/manage.sh create

または、このシェルで既に LAMBDA_ROLE_ARN が定義されていない場合にはこうです。

LAMBDA_ROLE_ARN="arn:aws:iam::1234567890:role/lambda-role" sh target/manage.sh create
ハンドラースイッチを変更しないでください。これは、 io.quarkus.amazon.lambda.runtime.QuarkusStreamHandler::handleRequest にハードコードする必要があります。このハンドラは、Quarkusをブートストラップし、インジェクションを実行できるように実際のハンドラをラップします。

Function の作成に問題がある場合は、 delete で Function を削除してから create コマンドを再実行する必要があります。

sh target/manage.sh delete

コマンドはスタックすることもできます。

sh target/manage.sh delete create

Lambda の呼び出し

Function を呼び出すには invoke コマンドを使用します。

sh target/manage.sh invoke

サンプルの Lambda は、プロジェクトのルートディレクトリーにある json ファイルを指す --payload スイッチを介して渡された入力を受け取ります。

Lambda は、以下のようにSAM CLI によってローカルで呼び出すこともできます。

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

ネイティブイメージのビルドで作業している場合は、テンプレート名をネイティブバージョンに置き換えてください。

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

Lambda の更新

お好きなように Java コードを更新することができます。リビルドしたら、 update コマンドを実行することで、Lambda を再配備できます。

sh target/manage.sh update

AWS Lambda カスタム (ネイティブ) ランタイムにデプロイ

Lambda のメモリーフットプリントを減らし、初期化時間を短縮したい場合は、Javaコードをネイティブ実行可能ファイルにコンパイルすることができます。 -Pnative スイッチでプロジェクトをリビルドすることを確認してください。

Linux ホストの場合は以下を実行します。

CLI
quarkus build --native
Maven
./mvnw package -Dnative
Gradle
./gradlew build -Dquarkus.package.type=native
Linux 以外のシステムでビルドしている場合は、Amazon Lambda が Linux バイナリーを必要とするため、Docker ビルドを使用するように Quarkus に指示するプロパティーも渡す必要があります。これを行うには、-Dquarkus.native.container-build=true プロパティーをビルドに渡します。ただし、これには Docker をローカルにインストールする必要があります。
CLI
quarkus build --native --no-tests -Dquarkus.native.container-build=true
# The --no-tests flag is required only on Windows and macOS.
Maven
./mvnw package -Dnative -Dquarkus.native.container-build=true
Gradle
./gradlew build -Dquarkus.package.type=native -Dquarkus.native.container-build=true

これらのコマンドのいずれかがコンパイルされ、ネイティブの実行イメージが作成されます。また、zip ファイル target/function.zip も生成されます。このzipファイルには、 bootstrap にリネームされたネイティブ実行イメージが含まれています。これはAWS Lambda Custom (Provided) Runtimeの要件です。

ここでの説明は上記と全く同じですが、1つ変更点があります: manage.sh スクリプトの最初のパラメーターとして native を追加する必要があります。

sh target/manage.sh native create

上記のように、コマンドはスタックすることができます。唯一の要件は、ネイティブイメージビルドで作業したい場合、最初のパラメーターとして native を指定することです。このスクリプトは、ネイティブイメージ Function のデプロイメントを管理するために必要な残りの詳細を処理します。

Lambda を作成、削除、更新するためにどのようなawsコマンドが実行されるかを知りたい場合は、 manage.sh スクリプトの出力を調べてください。

ネイティブ用のcreateコマンドについて注意すべき点は、 aws lambda create-function 呼び出しで特定の環境変数を設定しなければならないということです。

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

POM および Gradle ビルドを調べる

POM には quarkus-amazon-lambda-http エクステンションが依存関係として含まれている以外に特別なことは何もありません。このエクステンションは Lambda のデプロイに必要なものをすべて自動的に生成します。

このエクステンションの以前のバージョンでは、ネイティブデプロイメントのために実行ファイルを zip 化するように pom や gradle を設定しなければなりませんでしたが、今はそうではありません。

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.

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'
}

ライブコーディングおよび単体/統合テスト

開発環境で AWS Lambda 環境を可能な限りミラーリングするために、Quarkus Amazon Lambda エクステンションは、Quarkus 開発およびテストモードで模擬 AWS Lambda イベントサーバーを起動します。この模擬イベントサーバーは、真の AWS Lambda 環境をシミュレートしています。

Quarkus Dev モードで実行しているときに、http://localhost:8080 に HTTP POST を実行することで、イベントをフィードできます。模擬イベントサーバーがイベントを受信し、ラムダが呼び出されます。Lambda でライブコーディングを実行すると、変更が自動的に再コンパイルされ、次に行う呼び出しで利用できるようになります。次に例を示します。

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

模擬イベントサーバーは、@NativeImageTest および @QuarkusIntegrationTest テストでも起動されるため、ネイティブバイナリーでも機能します。これはすべて、Docker のオーバーヘッドなしで、SAM CLI ローカルテストと同様の機能を提供します。

最後に、ポート 8080 またはポート 8081 がコンピューターで使用できない場合は、application.properties を使用して開発モードとテストモードのポートを変更できます。

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

ポート値がゼロの場合、ポートはランダムに割り当てられます。

SAM CLI を使用したテスト

模擬イベントサーバーを使用しない場合は、SAM CLI を使用して Lambda をテストできます。

AWS SAM CLI を利用すると、Lambda をシミュレートした環境でラップトップ上のローカルで Lambda を実行することができます。これには docker のインストールが必要です。これは、利用することを選択した場合のオプションのアプローチです。それ以外の場合は、Quarkus JUnitの統合でほとんどのニーズを満たすことができるはずです。

JVMとネイティブ実行モードの両方に対応したスターターテンプレートが生成されています。

以下の SAM CLI コマンドを実行して、適切な SAM template を渡して Lambda Function をローカルでテストします。 event パラメーターには任意の JSON ファイルを指定します。この場合はサンプル payload.json を指定しています。

Gradle を使用している場合、YAML テンプレートのバイナリーへのパスを target から build に変更しなければなりません。
sam local invoke --template target/sam.jvm.yaml --event payload.json

ネイティブイメージは、 sam.native.yaml テンプレートを使ってローカルでテストすることもできます。

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

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.

zipディレクトリーの下に作成したファイルやディレクトリーは、すべて function.zip に含まれます。

カスタム bootstrap スクリプト

ラムダがネイティブの quarkus ラムダデプロイメントを起動する際に、特定のシステムプロパティーやその他の引数を設定したい場合があるかもしれません。 zip.native 内に bootstrap スクリプトファイルを含めると、Quarkus エクステンションは自動的に実行ファイルの名前を function.zip 内の runner に変更し、 bootstrap スクリプトの unix モードを実行ファイルに設定します。

カスタム bootstrap スクリプトを含む場合は、ネイティブ実行可能ファイルを runner として参照する必要があります。

このエクステンションは、サンプルのスクリプト target/bootstrap-example.sh を生成します。

AWS XRay と 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.

さらに、 manage.shcmd_create() 関数で AWS X-Ray tracing パラメーターを有効にすることを忘れないでください。これはAWSマネジメントコンソールでも設定できます。

    --tracing-config Mode=Active

SAM テンプレートファイルの場合は、YAML の Function Properties に以下を追加します。

    Tracing: Active

AWS X-Ray はディストリビューションに多くのクラスを追加しますが、最低でも256MBのAWS Lambdaメモリーサイズを使用していることを確認してください。これは manage.sh cmd_create() で明示的に設定されています。ネイティブイメージは常により低いメモリー設定を使用できる可能性がありますが、特にパフォーマンスを比較するためには同じ設定にしておくことをお勧めします。

HTTPS または 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

src/main/resources/application.properties を開き、以下の行を追加してネイティブイメージでSSLを有効にします。

quarkus.ssl.native=true

AWS Java SDKv2 の使用

QuarkusにはDynamoDB、S3、SNS、SQS (他にも追加中) のエクステンションが追加されました。以下のように手動でワイヤリングするのではなく、Quarkusを使って様々なAWSサービスを利用する方法については、 {amazon-services-guide}[それらのガイド] を確認してください。

最小限のインテグレーションで、AWSのJava SDK v2を活用し、SQS、SNS、S3、DynamoDBなどのサービスを呼び出すことが可能です。

しかしながら、ネイティブイメージに対しては、同期モードを使用する場合は、GraalVMのコンパイルの問題のため、Apache HTTPクライアントよりもURL接続クライアントを優先する必要があります(現在のところ)。

quarkus-jaxb を依存関係として Maven pom.xml または 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 HTTPS または 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();

Mavenの場合は、 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>
もし、 java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty 、または同様のSSLエラーが表示された場合、GraalVMの現状のため、 function.zip 、以下のようにバンドルするための追加作業があります。詳しくは、Quarkus Native SSL ガイド をご覧ください。

クライアントSSLの追加要件

ネイティブ実行可能ファイルは、S3 や他の aws ライブラリーが必要とするクライアント SSL を有効にするために、いくつかの追加の手順が必要です。

  1. カスタム bootstrap スクリプト

  2. function.ziplibsunec.so を追加する必要があります。

  3. function.zipcacerts を追加する必要があります。

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

cacerts ファイルがパスワードで保護されている場合は、追加で -Djavax.net.ssl.trustStorePassword=changeit を設定してください。

次に、GraalVM ディストリビューションから 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/

ネイティブビルドを実行すると、これらのファイルはすべて function.zip に含まれます。

Dockerイメージを使ってビルドする場合は、このイメージからこれらのファイルを抽出する必要があります。

必要な SSL を抽出するには、バックグラウンドでDockerコンテナーを起動し、そのコンテナーにアタッチしてアーティファクトをコピーする必要があります。

まず、GraalVMコンテナーを起動して、コンテナーIDの出力に注目してみましょう。

docker run -it -d --entrypoint bash quay.io/quarkus/ubi-quarkus-native-image:22.1-java11

# 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/

最終的なアーカイブは以下のようになります。

jar tvf target/function.zip

    bootstrap
    runner
    cacerts
    libsunec.so

コンテナイメージを使用して AWS Lambda にデプロイする

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.

JVM コンテナーイメージ

通常の JVM ディストリビューションの場合は、公式の AWS Java ベースイメージに基づいてイメージを作成する必要があります。以下は、Quarkus Lambda プロジェクトからコンテナーイメージを作成する Dockerfile の例です。mvn package が実行され、バイナリーが 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"]

ネイティブ実行可能コンテナーイメージ

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"]

コンテナーイメージ Lambda のデプロイ

以下に、docker および aws コマンドラインツールを使用して、上記で作成したコンテナーイメージをビルドして AWS にデプロイする方法を示します。これらの手順は、ネイティブコンテナーイメージと jvm コンテナーイメージの両方で機能し、aws コマンドラインツールがログインしていることを前提としています。

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

ユーザーの AWS アカウントに ECR リポジトリーを作成する

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

ECR レジストリー情報を使用してイメージにタグを付ける

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

Docker を ECR レジストリーにログインし、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

AWS CLI ツールを使用して AWS Lambda 関数を作成します

アップロードしておいたイメージを参照していることを確認してください (Lambda の実行に使用できるロールが存在することを前提としています)。JVM Lambda 関数の場合、デフォルトのメモリー制限である 128Mb が関数を実行するのに十分である可能性が高いことに注意してください。その場合は、aws lambda create-function コマンドに --memory-size 256 パラメーターを指定することで、関数を作成するときにメモリー制限を増やすことができます。関数を作成した後、AWS コンソールで関数を調整することもできます。

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]

これで、AWS コンソールを使用して、新しいラムダ関数を表示およびテストできます。

Amazon Alexa 統合

Quarkus ネイティブで Alexa を使用するには、 Quarkiverse Hub でホストされている Quarkus Amazon Alexa エクステンション を使用する必要があります。

<dependency>
    <groupId>io.quarkiverse.alexa</groupId>
    <artifactId>quarkus-amazon-alexa</artifactId>
    <version>${quarkus-amazon-alexa.version}</version> (1)
</dependency>
1 POM ファイルでエクステンションの最新バージョンを定義します。

通常通り、抽象クラス com.amazon.ask.SkillStreamHandler をサブクラス化して Alexa ハンドラーを作成し、リクエストハンドラーの実装を追加します。

これで、必要な作業は終了です。