Edit this Page

Azure Functions with Quarkus REST, Undertow, or Reactive Routes

The quarkus-azure-functions-http extension allows you to write microservices with Quarkus REST (our Jakarta REST implementation), Undertow (servlet), Reactive Routes, or Funqy HTTP and make these microservices deployable to the Azure Functions runtime. In other words, this extension is a bridge from the Azure Functions HttpTrigger and the Quarkus family of HTTP APIs. One azure function deployment can represent any number of Jakarta REST, servlet, Reactive Routes, or Funqy HTTP endpoints.

This technology is considered preview.

In preview, backward compatibility and presence in the ecosystem is not guaranteed. Specific improvements might require changing configuration or APIs, and plans to become stable are under way. Feedback is welcome on our mailing list or as issues in our GitHub issue tracker.

For a full list of possible statuses, check our FAQ entry.

Only text based media types are supported at the moment as Azure Functions HTTP Trigger for Java does not support a binary format

Prerequisites

To complete this guide, you need:

Solution

This guide walks you through running a maven project that can deploy a Quarkus REST endpoint to Azure Functions. While only Jakarta REST is provided as an example, you can easily replace it with the HTTP framework of your choice.

Creating the Maven/Gradle Project

First, we need a new project. Create a new project with the following command:

CLI
quarkus create app org.acme:azure-functions-http-quickstart \
    --extension='quarkus-azure-functions-http'
cd azure-functions-http-quickstart

To create a Gradle project, add the --gradle or --gradle-kotlin-dsl option.

For more information about how to install and use the Quarkus CLI, see the Quarkus CLI guide.

Maven
mvn io.quarkus.platform:quarkus-maven-plugin:3.29.1:create \
    -DprojectGroupId=org.acme \
    -DprojectArtifactId=azure-functions-http-quickstart \
    -Dextensions='quarkus-azure-functions-http'
cd azure-functions-http-quickstart

To create a Gradle project, add the -DbuildTool=gradle or -DbuildTool=gradle-kotlin-dsl option.

For Windows users:

  • If using cmd, (don’t use backward slash \ and put everything on the same line)

  • If using Powershell, wrap -D parameters in double quotes e.g. "-DprojectArtifactId=azure-functions-http-quickstart"

This command generates a project structure importing the Quarkus Azure Functions HTTP extension. It includes an example.

Examining the project

If you open the pom.xml or build.gradle build file of the generated project you’ll see that the project is similar to any other Quarkus project. The quarkus-azure-functions-http extension is the integration point between Quarkus and Azure Functions.

The current implementation of the quarkus-azure-functions-http extension no longer requires the azure-functions-maven-plugin or Gradle equivalent. Local development and Azure Functions packaging and deployment is now all done by Quarkus.

Build configuration is all within application.properties. The only required configuration switch is quarkus.azure-functions.app-name.

Azure Deployment Descriptors

The Azure Functions host.json deployment descriptor is automatically generated, but if you need to override it, declare it in the root directory of the project and rerun the build when you are ready.

Configuring Root Paths

The default route prefix for an Azure Function is /api. All of your Jakarta REST, Servlet, Reactive Routes, and Funqy HTTP endpoints must explicitly take this into account. In the generated project this is handled by the quarkus.http.root-path switch in application.properties

Quarkus dev mode

Quarkus dev mode works by just running your application as a HTTP endpoint. In dev mode, there is no special interaction with the Azure Functions local runtime.

CLI
quarkus dev
Maven
./mvnw quarkus:dev
Gradle
./gradlew --console=plain quarkusDev

Run locally in Azure Functions local environment

If you want to try this example within the local Azure Functions environment, you can use this command:

CLI
quarkus run
Maven
./mvnw quarkus:run
Gradle
./gradlew --console=plain --info --no-daemon quarkusRun

Gradle is a bit quirky with process management, so you need the --no-daemon switch or control-c will not destroy the process cleanly and you’ll have open ports.

You must have the Azure Functions Core Tools installed for this to work.

The URL to access the example would be:

Quarkus Integration Testing

You can implement integration tests using @QuarkusIntegrationTest functionality. When these integration tests run, the local Azure Functions environment will be spun up for the duration of integration testing.

Maven
./mvnw verify
Gradle
./gradlew --info quarkusIntTest

Make sure any integration tests you execute with Maven use the *IT.java file pattern so that regular builds do not execute the test.

Make sure any integration tests you execute with Gradle are located within src/integrationTest/java. Integration tests that exist in src/test will run with normal build and fail.

Login to Azure

To be able to deploy your application to Azure, log in to Azure:

az login

Deploy to Azure

The quarkus-azure-functions-http extension handles all the work to deploy to Azure. By default, Quarkus will use the Azure CLI in the background to authenticate and deploy to Azure. If you have multiple subscriptions associated with your account, you must set the quarkus.azure-functions.subscription-id property in your application.properties file to the subscription you want to use. For other authentication mechanisms and deployment options see Azure Functions Configuration Reference.

To deploy your application, after you built your project, execute:

Maven
./mvnw quarkus:deploy
Gradle
./gradlew --info deploy

For Gradle, you must use the --info switch to see this output.

If deployment is a success, Quarkus will output the endpoint URL of the example function to the console:

[INFO] HTTP Trigger Urls:
[INFO] 	 HttpExample : https://{appName}.azurewebsites.net/api/{*path}

The URL to access the service would be something like: https://{appName}.azurewebsites.net/api/hello.

Azure Functions Configuration Reference

Configuration property fixed at build time - All other configuration properties are overridable at runtime

Configuration property

Type

Default

App name for azure function project. This is required setting. Defaults to the base artifact name

Environment variable: QUARKUS_AZURE_FUNCTIONS_APP_NAME

Show more

string

Azure Resource Group for your Azure Functions

Environment variable: QUARKUS_AZURE_FUNCTIONS_RESOURCE_GROUP

Show more

string

quarkus

Specifies the region where your Azure Functions will be hosted; default value is westus. Valid values

Environment variable: QUARKUS_AZURE_FUNCTIONS_REGION

Show more

string

westus

Specifies whether to disable application insights for your function app

Environment variable: QUARKUS_AZURE_FUNCTIONS_DISABLE_APP_INSIGHTS

Show more

boolean

false

Specifies the instrumentation key of application insights which will bind to your function app

Environment variable: QUARKUS_AZURE_FUNCTIONS_APP_INSIGHTS_KEY

Show more

string

Valid values are linux, windows, and docker

Environment variable: QUARKUS_AZURE_FUNCTIONS_RUNTIME_OS

Show more

string

linux

Should be set to at least the minimum Quarkus compatible version

Environment variable: QUARKUS_AZURE_FUNCTIONS_RUNTIME_JAVA_VERSION

Show more

string

17

URL of docker image if deploying via docker

Environment variable: QUARKUS_AZURE_FUNCTIONS_RUNTIME_IMAGE

Show more

string

If using docker, url of registry

Environment variable: QUARKUS_AZURE_FUNCTIONS_RUNTIME_REGISTRY_URL

Show more

string

Description of each type can be found here Valid values are

  • azure_cli Delegates to Azure CLI for login

  • managed_identity Requires client to be set

  • oauth2 Requires tenant to be set

  • device_code Requires tenant to be set

  • file Filesystem path to a property file that defines authentication. Properties supported are

  • type Supports same type values as well as service_principal

  • client

  • tenant

  • key Password for service_principal if using password authentication

  • certificate Path to PEM file if using service_principal

  • certificate-password Password for PEM file if it is password protected and if using service_principal

  • environment if using service_principal

Defaults to "azure_cli" for authentication

Environment variable: QUARKUS_AZURE_FUNCTIONS_AUTH_TYPE

Show more

string

azure_cli

Filesystem path to properties file if using file type

Environment variable: QUARKUS_AZURE_FUNCTIONS_AUTH_PATH

Show more

string

Client or App Id required if using managed_identity type

Environment variable: QUARKUS_AZURE_FUNCTIONS_AUTH_CLIENT

Show more

string

Tenant ID required if using oauth2 or device_code type

Environment variable: QUARKUS_AZURE_FUNCTIONS_AUTH_TENANT

Show more

string

Specifies the name of the existing App Service Plan when you do not want to create a new one.

Environment variable: QUARKUS_AZURE_FUNCTIONS_APP_SERVICE_PLAN_NAME

Show more

string

java-functions-app-service-plan

The app service plan resource group.

Environment variable: QUARKUS_AZURE_FUNCTIONS_APP_SERVICE_PLAN_RESOURCE_GROUP

Show more

string

Azure subscription id. Required only if there are more than one subscription in your account

Environment variable: QUARKUS_AZURE_FUNCTIONS_SUBSCRIPTION_ID

Show more

string

The pricing tier.

Environment variable: QUARKUS_AZURE_FUNCTIONS_PRICING_TIER

Show more

string

Port to run azure function in local runtime. Will default to quarkus.http.test-port or 8081

Environment variable: QUARKUS_AZURE_FUNCTIONS_FUNC_PORT

Show more

int

Config String for local debug

Environment variable: QUARKUS_AZURE_FUNCTIONS_LOCAL_DEBUG_CONFIG

Show more

string

transport=dt_socket,server=y,suspend=n,address=5005

Related content