Tutorial: Build a Quarkus web app with Azure App Service on Linux and PostgreSQL

• An Azure account with an active subscription. If you don't have an Azure account, you can create a trial account.
• Knowledge of Java with Quarkus development.

• An Azure account with an active subscription. If you don't have an Azure account, you can create one for free.
• Azure Developer CLI installed. You can follow the steps with the Azure Cloud Shell because it already has Azure Developer CLI installed.
• Knowledge of Java with Tomcat development.

First, you create the Azure resources. The steps used in this tutorial create a set of secure-by-default resources that include App Service and Azure Database for PostgreSQL. For the creation process, you'll specify:

• The Name for the web app. It's the name used as part of the DNS name for your webapp in the form of https://<app-name>.chinacloudsites.cn.
• The Region to run the app physically in the world.
• The Runtime stack for the app. It's where you select the version of Java to use for your app.
• The Hosting plan for the app. It's the pricing tier that includes the set of features and scaling capacity for your app.
• The Resource Group for the app. A resource group lets you group (in a logical container) all the Azure resources needed for the application.

Sign in to the Azure portal and follow these steps to create your Azure App Service resources.

Having issues? Check the Troubleshooting section.

The creation wizard generated the connectivity variables for you already as app settings. In this step, you learn where to find the app settings, and how you can create your own.

App settings are one way to keep connection secrets out of your code repository. When you're ready to move your secrets to a more secure location, you can use Key Vault references instead.

Having issues? Check the Troubleshooting section.

In this step, you'll configure GitHub deployment using GitHub Actions. It's just one of many ways to deploy to App Service, but also a great way to have continuous integration in your deployment process. By default, every git push to your GitHub repository will kick off the build and deploy action.

Note the following:

• Your deployed Java package must be an Uber-Jar.
• For simplicity of the tutorial, you'll disable tests during the deployment process. The GitHub Actions runners don't have access to the PostgreSQL database in Azure, so any integration tests that require database access will fail, such as is the case with the Quarkus sample application.

Having issues? Check the Troubleshooting section.

Azure App Service captures all messages output to the console to help you diagnose issues with your application. The sample application includes standard JBoss logging statements to demonstrate this capability as shown below.

    private static final Logger LOGGER = Logger.getLogger(FruitEntityResource.class.getName());

    @GET
    public List<FruitEntity> get() {
        LOGGER.info("In FruitEntityResource.get()");
        return FruitEntity.listAll(Sort.by("name"));
    }

Learn more about logging in Java apps in the series on Enable Azure Monitor OpenTelemetry for .NET, Node.js, Python and Java applications.

When you're finished, you can delete all of the resources from your Azure subscription by deleting the resource group.

In this step, you create the Azure resources and deploy a sample app to App Service on Linux. The steps used in this tutorial create a set of secure-by-default resources that include App Service and Azure Database for PostgreSQL.

The dev container already has the Azure Developer CLI (AZD).

1. From the repository root, run azd init.

   azd init --template javase-app-service-postgresql-infra
   

2. When prompted, give the following answers:

   Expand table

   Question	Answer
   Continue initializing an app in '<your-directory>'?	Y
   What would you like to do with these files?	Keep my existing files unchanged
   Enter a new environment name	Type a unique name. The AZD template uses this name as part of the DNS name of your web app in Azure (<app-name>.chinacloudsites.cn). Alphanumeric characters and hyphens are allowed.

3. Sign into Azure by running the azd auth login command and following the prompt:

   azd auth login
   

4. Create the necessary Azure resources and deploy the app code with the azd up command. Follow the prompt to select the desired subscription and location for the Azure resources.

   azd up
   

   The azd up command takes about 15 minutes to complete (the Redis cache take the most time). It also compiles and deploys your application code, but you'll modify your code later to work with App Service. While it's running, the command provides messages about the provisioning and deployment process, including a link to the deployment in Azure. When it finishes, the command also displays a link to the deploy application.

   This AZD template contains files (azure.yaml and the infra directory) that generate a secure-by-default architecture with the following Azure resources:

   • Resource group: The container for all the created resources.
   • App Service plan: Defines the compute resources for App Service. A Linux plan in the B1 tier is created.
   • App Service: Represents your app and runs in the App Service plan.
   • Virtual network: Integrated with the App Service app and isolates back-end network traffic.
   • Azure Database for PostgreSQL flexible server: Accessible only from behind its private endpoint. A database is created for you on the server.
   • Azure Cache for Redis: Accessible only from within the virtual network.
   • Private DNS zones: Enable DNS resolution of the database server and the Redis cache in the virtual network.
   • Log Analytics workspace: Acts as the target container for your app to ship its logs, where you can also query the logs.
   • Key vault: Used to keep your database password the same when you redeploy with AZD.

Having issues? Check the Troubleshooting section.

The AZD template you use generated the connectivity variables for you already as app settings and outputs the them to the terminal for your convenience. App settings are one way to keep connection secrets out of your code repository.

1. In the AZD output, find the app setting AZURE_POSTGRESQL_CONNECTIONSTRING. To keep secrets safe, only the setting names are displayed. They look like this in the AZD output:

    App Service app has the following connection strings:
   
            - AZURE_POSTGRESQL_CONNECTIONSTRING
            - AZURE_REDIS_CONNECTIONSTRING
    

   AZURE_POSTGRESQL_CONNECTIONSTRING contains the connection string to the PostgreSQL database in Azure. You need to use it in your code later.

2. For your convenience, the AZD template shows you the direct link to the app's app settings page. Find the link and open it in a new browser tab. Later, you will add an app setting using AZD instead of in the portal.

Having issues? Check the Troubleshooting section.

1. Back in the GitHub codespace of your sample fork, open infra/resources.bicep.

2. Find the appSettings resource and comment the property PORT: '8080'. When you're done, your appSettings resource should look like the following code:

   resource appSettings 'config' = {
     name: 'appsettings'
     properties: {
       PORT: '8080'
     }
   }
   

3. From the explorer, open src/main/resources/application.properties.

4. Find the commented code (lines 10-11) and uncomment it.

   %prod.quarkus.datasource.jdbc.url=${AZURE_POSTGRESQL_CONNECTIONSTRING}
   quarkus.package.type=uber-jar
   

   This code sets the production variable %prod.quarkus.datasource.jdbc.url to the app setting that the creation wizard for you. The quarkus.package.type is set to build an Uber-Jar, which you need to run in App Service.

5. Back in the codespace terminal, run azd up.

   azd up
   

   Tip

   azd up actually does azd package, azd provision, and azd deploy. azd provision lets you update the Azure changes you made in infra/resources.bicep. azd deploy uploads the built Jar file.

   To find out how the Jar file is packaged, you can run azd package --debug by itself.

Having issues? Check the Troubleshooting section.

1. In the AZD output, find the URL of your app and navigate to it in the browser. The URL looks like this in the AZD output:

    Deploying services (azd deploy)
   
      (✓) Done: Deploying service web
      - Endpoint: https://<app-name>.chinacloudsites.cn/
    

2. Add a few fruits to the list.

   

   Congratulations, you're running a web app in Azure App Service, with secure connectivity to Azure Database for PostgreSQL.

Having issues? Check the Troubleshooting section.

Azure App Service can capture console logs to help you diagnose issues with your application. For convenience, the AZD template already enabled logging to the local file system and is shipping the logs to a Log Analytics workspace.

The sample application includes standard JBoss logging statements to demonstrate this capability as shown below.

    private static final Logger LOGGER = Logger.getLogger(FruitEntityResource.class.getName());

    @GET
    public List<FruitEntity> get() {
        LOGGER.info("In FruitEntityResource.get()");
        return FruitEntity.listAll(Sort.by("name"));
    }

In the AZD output, find the link to stream App Service logs and navigate to it in the browser. The link looks like this in the AZD output:

Stream App Service logs at: https://portal.azure.cn/#@/resource/subscriptions/<subscription-guid>/resourceGroups/<group-name>/providers/Microsoft.Web/sites/<app-name>/logStream

Learn more about logging in Java apps in the series on Enable Azure Monitor OpenTelemetry for .NET, Node.js, Python and Java applications.

Having issues? Check the Troubleshooting section.

To delete all Azure resources in the current deployment environment, run azd down and follow the prompts.

azd down