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:
-
Roughly 15 minutes
-
An IDE
-
JDK 17+ installed with
JAVA_HOMEconfigured appropriately -
Apache Maven 3.9.11
-
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)
-
An Azure Account. Free accounts work.
-
Azure Functions Core Tools version 4.x
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:
For Windows users:
-
If using cmd, (don’t use backward slash
\and put everything on the same line) -
If using Powershell, wrap
-Dparameters 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.
quarkus dev
./mvnw quarkus:dev
./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:
quarkus run
./mvnw quarkus:run
./gradlew --console=plain --info --no-daemon quarkusRun
|
Gradle is a bit quirky with process management, so you need the |
|
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.
./mvnw verify
./gradlew --info quarkusIntTest
|
Make sure any integration tests you execute with Maven use the |
|
Make sure any integration tests you execute with Gradle are located within |
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:
./mvnw quarkus:deploy
./gradlew --info deploy
|
For Gradle, you must use the |
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: Show more |
string |
|
Azure Resource Group for your Azure Functions Environment variable: Show more |
string |
|
Specifies the region where your Azure Functions will be hosted; default value is westus. Valid values Environment variable: Show more |
string |
|
Specifies whether to disable application insights for your function app Environment variable: Show more |
boolean |
|
Specifies the instrumentation key of application insights which will bind to your function app Environment variable: Show more |
string |
|
Valid values are linux, windows, and docker Environment variable: Show more |
string |
|
Should be set to at least the minimum Quarkus compatible version Environment variable: Show more |
string |
|
URL of docker image if deploying via docker Environment variable: Show more |
string |
|
If using docker, url of registry Environment variable: Show more |
string |
|
Description of each type can be found here Valid values are
Defaults to "azure_cli" for authentication Environment variable: Show more |
string |
|
Filesystem path to properties file if using file type Environment variable: Show more |
string |
|
Client or App Id required if using managed_identity type Environment variable: Show more |
string |
|
Tenant ID required if using oauth2 or device_code type Environment variable: Show more |
string |
|
Specifies the name of the existing App Service Plan when you do not want to create a new one. Environment variable: Show more |
string |
|
The app service plan resource group. Environment variable: Show more |
string |
|
Azure subscription id. Required only if there are more than one subscription in your account Environment variable: Show more |
string |
|
The pricing tier. Environment variable: Show more |
string |
|
Port to run azure function in local runtime. Will default to quarkus.http.test-port or 8081 Environment variable: Show more |
int |
|
Config String for local debug Environment variable: Show more |
string |
|