Azure Functions with Quarkus REST, Undertow, or Reactive Routes

Para concluir este guia, você precisa:

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.

You can generate the example code from Quarkus’s online application generator at this link.

You can also generate this example with the Quarkus CLI:

Add the --gradle switch if you want to generate a gradle project.

If you don’t log in to Azure you won’t be able to deploy.

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.

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 now all within application.properties. The only required configuration switch is quarkus.azure-functions.app-name.

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.

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

If you don’t log in to Azure you won’t be able to deploy.

Quarkus dev mode does not work currently with Azure Functions.

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

or

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.

Note that you must have the Azure Functions Core Tools installed for this to work!

The URL to access the example would be:

http://localhost:8081/api/hello

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.

For maven:

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

For Gradle:

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.

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 our config properties here.

To run the deploy, after you build your project execute:

or

If deployment is a success, Quarkus will output the endpoint URL of the example function to the console For Gradle, you must use the --info switch to see this output!

i.e.

The URL to access the service would be something like

https://{appName}.azurewebsites.net/api/hello