Tutorial: Deploy a Quarkus web app to Azure App Service and PostgreSQL

In this tutorial, you deploy a data-driven Quarkus web application to Azure App Service with the Azure Database for PostgreSQL relational database service. Azure App Service supports Java Standard Edition (Java SE) in a Windows or Linux server environment.

In this tutorial, you learn how to:

• Create a secure-by-default architecture for Azure App Service and Azure Database for PostgreSQL flexible server.
• Secure connection secrets using a managed identity and Key Vault reference.
• Deploy a sample Quarkus app to App Service from a GitHub repository.
• Access App Service app settings in the application code.
• Make updates and redeploy the application code.
• Generate database schema by running database migrations.
• Stream diagnostic logs from Azure.
• Manage the app in the Azure portal.
• Provision the same architecture and deploy by using Azure Developer CLI.
• Optimize your development workflow with GitHub Codespaces and GitHub Copilot.

Prerequisites

• An Azure account with an active subscription. If you don't have an Azure account, you can create one for free.
• A GitHub account. you can also get one for free.
• Knowledge of Java with Quarkus development.
• (Optional) To try GitHub Copilot, a GitHub Copilot account. A 30-day free trial is available.

• An Azure account with an active subscription. If you don't have an Azure account, you can create one for free.
• A GitHub account. you can also get 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 Quarkus development.
• (Optional) To try GitHub Copilot, a GitHub Copilot account. A 30-day free trial is available.

Skip to the end

If you just want to see the sample app in this tutorial running in Azure, just run the following commands in the Azure Cloud Shell, and follow the prompt:

mkdir msdocs-quarkus-postgresql-sample-app
cd msdocs-quarkus-postgresql-sample-app
azd init --template msdocs-quarkus-postgresql-sample-app
azd up

1. Run the sample

First, you set up a sample data-driven app as a starting point. For your convenience, the sample repository, Hibernate ORM with Panache and RESTEasy, includes a dev container configuration. The dev container has everything you need to develop an application, including the database, cache, and all environment variables needed by the sample application. The dev container can run in a GitHub codespace, which means you can run the sample on any computer with a web browser.

Step 1: In a new browser window:

1. Sign in to your GitHub account.
2. Navigate to https://github.com/Azure-Samples/msdocs-quarkus-postgresql-sample-app/fork.
3. Unselect Copy the main branch only. You want all the branches.
4. Select Create fork.

Step 2: In the GitHub fork:

1. Select main > starter-no-infra for the starter branch. This branch contains just the sample project and no Azure-related files or configuration.
2. Select Code > Create codespace on starter-no-infra. The codespace takes a few minutes to set up.

Step 3: In the codespace terminal:

1. Run mvn quarkus:dev.
2. Ignore the notification Your application running on port 5005 is available.
3. When you see the notification Your application running on port 8080 is available., select Open in Browser. You should see the sample application in a new browser tab. To stop the Quarkus development server, type Ctrl+C.

For more information on how the Quarkus sample application is created, see Quarkus documentation Simplified Hibernate ORM with Panache and Configure data sources in Quarkus.

Tip

You can ask GitHub Copilot about this repository. For example:

• @workspace What does this project do?
• @workspace What does the .devcontainer folder do?

Having issues? Check the Troubleshooting section.

2. Create App Service and PostgreSQL

In this step, 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 specify:

• The Name for the web app. It's used as part of the DNS name for your app in the form of https://<app-name>-<hash>.<region>.azurewebsites.net.
• The Region to run the app physically in the world. It's also used as part of the DNS name for your app.
• 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.

Step 1: In the Azure portal:

1. In the top search bar, type app service.
2. Select the item labeled App Service under the Services heading.
3. Select Create > Web App. You can also navigate to the creation wizard directly.

Step 2: Configure the new app Fill out the form as follows.

1. Name: msdocs-quarkus-postgres. A resource group named msdocs-quarkus-postgres_group is generated for you.
2. Runtime stack: Java 21.
3. Java web server stack: Java SE (Embedded Web Server).
4. Operating system: Linux.
5. Region: Any Azure region near you.
6. Linux Plan: Create new and use the name msdocs-quarkus-postgres.
7. Pricing plan: Basic B1. When you're ready, you can scale up to a different pricing tier.

Step 3: Add database

1. Select the Database tab.
2. Select Create a Database.
3. In Engine, select PostgreSQL - Flexible Server. The server name and database name are set by default to appropriate values.

Step 4: Configure GitHub deployment

1. Select the Deployment tab.
2. Select Continuous deployment.
3. If this is your first time configuring GitHub deployment in App Service, select Authorize and authenticate with your GitHub account.
4. In Organization, select your GitHub alias.
5. In Repository, select msdocs-quarkus-postgresql-sample-app.
6. In Branch, select starter-no-infra.
7. Select Review + create.
8. After validation completes, select Create. By default, the create wizard creates a user-assigned identity for the workflow to authenticate using Microsoft Entra (OIDC authentication). For alternative authentication options, see Deploy to App Service using GitHub Actions.

Step 3: The deployment takes a few minutes to complete. Once deployment completes, select the Go to resource button. You're taken directly to the App Service app, but the following resources are created:

• Resource group: The container for all the created resources.
• App Service plan: Defines the compute resources for App Service. A Linux plan in the Basic 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 within the virtual network. A database and a user are created for you on the server.
• Private DNS zones: Enables DNS resolution of the key vault and the database server in the virtual network.

3. Secure connection secrets

The creation wizard generated the connectivity variables for you already as app settings. However, the security best practice is to keep secrets out of App Service completely. You'll move your secrets to a key vault and change your app setting to Key Vault references with the help of Service Connectors.

Step 1: Retrieve the existing connection string

1. In the left menu of the App Service page, select Settings > Environment variables.
2. Select Connection strings.
3. Select AZURE_POSTGRESQL_CONNECTIONSTRING.
4. In Add/Edit application setting, in the Value field, find the User Id= and Password= parts at the end of the string.
5. Copy the username and password strings after User Id= and Password= for use later. This app setting lets you connect to the Postgres database secured behind a private endpoint. However, the secret is saved directly in the App Service app, which isn't the best. You'll change this.

Step 2: Create a subnet for securing Key Vault The virtual network already has two existing subnets, but one is already delegated to App Service and the other is already delegated to Azure Database for PostgreSQL. You create another one for secure access to Key Vault with a private endpoint (for more information, see Network security for Azure Key Vault).

1. In the left menu of the App Service page, select the Overview tab.
2. Select the resource group of the app.
3. Select the virtual network in the resource group.
4. In the left menu of the virtual network, select Settings > Subnets.
5. Select + Subnet.
6. In Name, type subnet-keyvault. Accept the defaults.
7. Select Add.

Step 3: Create a key vault for secure management of secrets

1. In the top search bar, type "key vault", then select Marketplace > Key Vault.
2. In Resource Group, select msdocs-quarkus-postgres_group.
3. In Key vault name, type a name that consists of only letters and numbers.
4. In Region, set it to the same location as the resource group.

Step 4: Secure the key vault with a Private Endpoint

1. Select the Networking tab.
2. Unselect Enable public access.
3. Select Create a private endpoint.
4. In Resource Group, select msdocs-quarkus-postgres_group.
5. In the dialog, in Location, select the same location as your App Service app.
6. In Name, type msdocs-quarkus-postgresVaultEndpoint.
7. In Virtual network, select vnet-xxxxxxx.
8. In Subnet, subnet-keyvault.
9. Select OK.
10. Select Review + create, then select Create. Wait for the key vault deployment to finish. You should see "Your deployment is complete."

Step 5: Create a PostgreSQL connector

1. In the top search bar, type msdocs-quarkus-postgres, then select the App Service resource called msdocs-quarkus-postgres.
2. In the App Service page, in the left menu, select Settings > Service Connector > Create.
3. In Service type, select DB for PostgreSQL flexible server.
4. In PostgreSQL flexible server, msdocs-quarkus-postgres-server should be selected already.
5. In PostgreSQL database, select msdocs-quarkus-postgres-database.
6. In Client type, select Java.

Step 6: Save secrets in key vault

1. Select the Authentication tab.
2. Select Connection string.
3. In Username and Password, paste the password you copied earlier.
4. Select Store Secret in Key Vault.
5. Under Key Vault Connection, select Create new. A Create connection dialog is opened on top of the edit dialog.

Step 7: Establish the Key Vault connection

1. In the Create connection dialog for the Key Vault connection, in Key Vault, select the key vault you created earlier.
2. In Client type, select Java for consistency. Your application code doesn't actually use the key vault directly.
3. Select Review + Create.
4. When validation completes, select Create.

Step 8: Finalize the PostgreSQL connector settings

1. You're back in the edit dialog for the PostgreSQL connector. In the Authentication tab, wait for the key vault connector to be created. When it's finished, the Key Vault Connection dropdown automatically selects it.
2. Select Review + Create.
3. When validation completes, select Create. Wait until the Creation succeeded notification appears.

Step 9: Verify the Key Vault integration

1. From the left menu, select Settings > Environment variables again.
2. Next to AZURE_POSTGRESQL_CONNECTIONSTRING, select Show value. The value should be @Microsoft.KeyVault(...), which means that it's a key vault reference because the secret is now managed in the key vault.

Step 10: Delete database credentials from App Service

1. Select the Connection strings tab.
2. To the right of AZURE_POSTGRESQL_CONNECTIONSTRING, select Delete. Remember that the create wizard created this connection string for you at the beginning.

To summarize, the process for securing your connection secrets involved:

• Retrieving the connection secrets from the App Service app's environment variables.
• Creating a key vault with a private endpoint.
• Creating a Key Vault connection with the system-assigned managed identity.
• Create a service connector to store the connection secrets in the key vault.
• Delete the old connection secrets from the App Service app.

Having issues? Check the Troubleshooting section.

4. Deploy sample code

In the create wizard, you already configured continuous deployment from your sample GitHub repository 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 kicks off the build and deploy action.

Note the following:

• Quarkus listens to port 8080 by default. In production, it needs to be configured to listen to the port specified by the PORT environment variable in App Service.
• 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.

Step 1: Back in the GitHub codespace of your sample fork, run git pull origin starter-no-infra. This pulls the newly committed GitHub workflow file into your codespace.

Step 2 (Option 1: with GitHub Copilot):

1. Start a new chat session by selecting the Chat view, then selecting +.
2. Ask, "@workspace How does the app connect to the database?" Copilot might give you some explanation about how the Quarkus data source settings are configured in src/main/resources/application.properties.
3. Say, "@workspace I created a PostgreSQL service connector in Azure App Service using the Java client type and the app setting name is AZURE_POSTGRESQL_CONNECTIONSTRING. I want to use this connection string when the app is running in production." Copilot might give you a code suggestion similar to the one in the Option 2: without GitHub Copilot steps below and even tell you to make the change in the src/main/resources/application.properties file.
4. Open src/main/resources/application.properties in the explorer and add the code suggestion.
5. Say, "@workspace How do i configure this project to create an Uber Jar?" Copilot might give you a code suggestion similar to the one in the Option 2: without GitHub Copilot steps below and even tell you to make the change in the src/main/resources/application.properties file.
6. Open src/main/resources/application.properties in the explorer and add the code suggestion.
7. Say, "@workspace How do I use the App Service port?" Copilot might give you a code suggestion similar to the one in the Option 2: without GitHub Copilot steps below and even tell you to make the change in the src/main/resources/application.properties file.
8. Open src/main/resources/application.properties in the explorer and add the code suggestion. GitHub Copilot doesn't give you the same response every time, and it's not always correct. You might need to ask more questions to fine-tune its response. For tips, see What can I do with GitHub Copilot in my codespace?.

Step 2 (Option 2: without GitHub Copilot):

1. Open src/main/resources/application.properties in the explorer. Quarkus uses this file to load Java properties.
2. Uncomment lines 10-12. These settings use the app setting you created with the PostgreSQL connector, creates an Uber Jar, and sets the port to the one used by App Service.

Step 3 (Option 1: with GitHub Copilot):

1. Ask, "@workspace For the GitHub Actions deployment, I want to skip tests to avoid database related errors." Copilot might give you a code suggestion similar to the one in the Option 2: without GitHub Copilot steps below and even tell you to make the change in the .github/workflows/starter-no-infra_msdocs-quarkus-postgres.yml file.
2. Open .github/workflows/starter-no-infra_msdocs-quarkus-postgres.yml in the explorer and add the code suggestion. For tips, see What can I do with GitHub Copilot in my codespace?.

Step 3 (Option 2: without GitHub Copilot):

1. Open .github/workflows/starter-no-infra_msdocs-quarkus-postgres.yml in the explorer. This is the GitHub Actions workflow that the create wizard created for you.
2. Find the Build with Maven step, and modify the run command to mvn clean install -DskipTests. -DskipTests tells Maven to skip tests so that the deployment doesn't fail on database errors. The GitHub Actions container can't connect to a PostgreSQL server.

Step 4:

1. Select the Source Control extension.
2. In the textbox, type a commit message like Configure DB and deployment. Or, select and let GitHub Copilot generate a commit message for you.
3. Select Commit, then confirm with Yes.
4. Select Sync changes 1, then confirm with OK.

Step 5:

1. From the left menu, select Deployment > Deployment Center > Logs.
2. In the log item for the deployment run, select the Build/Deploy Logs entry with the latest timestamp.

Step 6: You're taken to your GitHub repository and see that the GitHub action is running. The workflow file defines two separate stages, build and deploy. Wait for the GitHub run to show a status of Success. It takes about 5 minutes.

Having issues? Check the Troubleshooting section.

5. Browse to the app

Step 1: In the App Service page:

1. From the left menu, select Overview.
2. Select the URL of your app.

Step 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.

6. Stream diagnostic logs

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

Step 1: In the App Service page:

1. From the left menu, select Monitoring > App Service logs.
2. Under Application logging, select File System.
3. In the top menu, select Save.

Step 2: From the left menu, select Log stream. You see the logs for your app, including platform logs and logs from inside the container.

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

7. Clean up resources

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

Step 1: In the search bar at the top of the Azure portal:

1. Enter the resource group name.
2. Select the resource group.

Step 2: In the resource group page, select Delete resource group.

Step 3:

1. Enter the resource group name to confirm your deletion.
2. Select Delete.
3. Confirm with Delete again.

:

2. Create Azure resources and deploy a sample app

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 of the GitHub codespace, run azd init.

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

2. When prompted, give the following answers:

   Question	Answer
   The current directory is not empty. Would you like to initialize a project here 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>-<hash>.azurewebsites.net). 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 with the azd provision command. Follow the prompt to select the desired subscription and location for the Azure resources.

   azd provision
   

   The azd provision command takes about 15 minutes to complete (the Redis cache takes the most time). Later, you'll modify your code to work with App Service and deploy the changes with azd deploy. While it's running, the command provides messages about the provisioning and deployment process, including a link to the deployment in Azure.

   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 Basic 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.
   • Private endpoints: Access endpoints for the key vault and the Redis cache in the virtual network.
   • Network interfaces: Represents private IP addresses, one for each of the private endpoints.
   • Azure Database for PostgreSQL flexible server: Accessible only from within the virtual network. A database and a user are created for you on the server.
   • Private DNS zone: Enables DNS resolution of the PostgreSQL server 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.
   • Azure Cache for Redis: Accessible only from behind its private endpoint.
   • Key vault: Accessible only from behind its private endpoint. Used to manage secrets for the App Service app.

5. Once provisioning finishes, find the setting AZURE_POSTGRESQL_CONNECTIONSTRING in the AZD output. 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 settings:
            - AZURE_POSTGRESQL_CONNECTIONSTRING
            - AZURE_REDIS_CONNECTIONSTRING
            - AZURE_KEYVAULT_RESOURCEENDPOINT
            - AZURE_KEYVAULT_SCOPE
    

   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. You can also find the direct link to the app settings page for the created App Service app.

Having issues? Check the Troubleshooting section.

3. Modify sample code and redeploy

You must make some changes in your application code to make it work with App Service:

• Quarkus listens to port 8080 by default. In production, it needs to be configured to listen to the port specified by the PORT environment variable in App Service.
• 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.

With GitHub Copilot

1. In the GitHub codespace, start a new chat session by selecting the Chat view, then selecting +.

2. Ask, "@workspace How does the app connect to the database?" Copilot might give you some explanation about how the quarkus data source settings are configured in src/main/resources/application.properties.

3. Say, "@workspace I have created a PostgreSQL service connector in Azure App Service using the Java client type and the app setting name is AZURE_POSTGRESQL_CONNECTIONSTRING. I want to use this connection string when the app is running in production." Copilot might give you a code suggestion similar to the one in the Option 2: without GitHub Copilot steps below and even tell you to make the change in the src/main/resources/application.properties file.

4. Add the code suggestion in src/main/resources/application.properties.

5. Say, "@workspace How do i configure this project to create an Uber Jar?" Copilot might give you a code suggestion similar to the one in the Option 2: without GitHub Copilot steps below and even tell you to make the change in the src/main/resources/application.properties file.

6. Add the code suggestion in src/main/resources/application.properties.

7. Say, "@workspace How do I use the App Service port?" Copilot might give you a code suggestion similar to the one in the Option 2: without GitHub Copilot steps below and even tell you to make the change in the src/main/resources/application.properties file.

8. Add the code suggestion in src/main/resources/application.properties.

   GitHub Copilot doesn't give you the same response every time, and it's not always correct. You might need to ask more questions to fine-tune its response. For tips, see What can I do with GitHub Copilot in my codespace?.

9. In the terminal, run azd deploy.

   azd deploy
   

Without GitHub Copilot

1. Open src/main/resources/application.properties in the explorer. Quarkus uses this file to load Java properties.

2. Uncomment lines 10-12. These settings use the app setting you created with the PostgreSQL connector, creates an Uber Jar, and sets the port to the one used by App Service.

3. In the terminal, run azd deploy.

   azd deploy
   

Note

If you run azd up, it combines azd package, azd provision, and azd deploy. The reason you didn't do it at the beginning was because you didn't have the PostgreSQL connection settings to modify your code with yet. If you ran azd up then, the deploy stage would stall because the Quarkus app wouldn't be able to start without the changes you made here.

Having issues? Check the Troubleshooting section.

5. Browse to the app

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>.azurewebsites.net/
    

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.

6. Stream diagnostic logs

Azure App Service can capture console logs to help you diagnose issues with your application. For convenience, the AZD template already enables 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.com/#@/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.

7. Clean up resources

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

azd down

Troubleshooting

The GitHub Actions run failed at the build stage

Select the failed build stage to see which step failed. If it's the Build with Maven stage, expand the step to verify that the -DskipTests option is used. If not, go back to 4. Deploy sample code and modify the GitHub workflow file according to the instructions.

The app failed to start and shows the following error in the log stream: "Model classes are defined for the default persistence unit <default> but configured datasource <default> not found: the default EntityManagerFactory will not be created."

This Quarkus error is most likely because the app can't connect to the Azure database. Make sure that the app setting AZURE_POSTGRESQL_CONNECTIONSTRING hasn't been changed, and that application.properties is using the app setting properly.

The app failed to start and the log stream shows "Waiting for response to warmup request for container"

Your application is probably not configured to listen to the port specified by the App Service PORT environment variable, so it can't respond to any requests. If App Service doesn't get a response from your application, it assumes that the application failed to start. Go back to 4. Deploy sample code and verify that application.properties is configured properly.

The app works, but I see the error log "ERROR [org.acm.hib.orm.pan.ent.FruitEntityResource] (vert.x-eventloop-thread-0) Failed to handle request: jakarta.ws.rs.NotFoundException: HTTP 404 Not Found".

This is a Vert.x error (see Quarkus Reactive Architecture), indicating that the client requested an unknown path. It can happen the first time the app starts, when the client requests the REST API before the Hibernate database migration happens.

In App Service, this error also happens on every app startup because App Service verifies that the app starts by sending a GET request to /robots933456.txt.

Frequently asked questions

• How much does this setup cost?
• How do I connect to the PostgreSQL server that's secured behind the virtual network with other tools?
• How does local app development work with GitHub Actions?
• What if I want to run tests with PostgreSQL during the GitHub workflow?
• I don't have permissions to create a user-assigned identity
• What can I do with GitHub Copilot in my codespace?

How much does this setup cost?

Pricing for the created resources is as follows:

• The App Service plan is created in Basic tier and can be scaled up or down. See App Service pricing.
• The PostgreSQL flexible server is created in the lowest burstable tier Standard_B1ms, with the minimum storage size, which can be scaled up or down. See Azure Database for PostgreSQL pricing.
• The virtual network doesn't incur a charge unless you configure extra functionality, such as peering. See Azure Virtual Network pricing.
• The private DNS zone incurs a small charge. See Azure DNS pricing.

How do I connect to the PostgreSQL server that's secured behind the virtual network with other tools?

• For basic access from a command-line tool, you can run psql from the app's SSH terminal.
• To connect from a desktop tool, your machine must be within the virtual network. For example, it could be an Azure VM that's connected to one of the subnets, or a machine in an on-premises network that has a site-to-site VPN connection with the Azure virtual network.
• You can also integrate Azure Cloud Shell with the virtual network.

How does local app development work with GitHub Actions?

Using the autogenerated workflow file from App Service as an example, each git push kicks off a new build and deployment run. From a local clone of the GitHub repository, you make the desired updates and push to GitHub. For example:

git add .
git commit -m "<some-message>"
git push origin main

What if I want to run tests with PostgreSQL during the GitHub workflow?

The default Quarkus sample application includes tests with database connectivity. To avoid connection errors, you added the -skipTests property. If you want, you can run the tests against a PostgreSQL service container. For example, in the automatically generated workflow file in your GitHub fork (.github/workflows/main_cephalin-quarkus.yml), make the following changes:

1. Add YAML code for the PostgreSQL container to the build job, as shown in the following snippet.

   ...
   jobs:
     build:
       runs-on: ubuntu-latest
   
       # BEGIN CODE ADDITION
       container: ubuntu
       services:
         # Hostname for the PostgreSQL container
         postgresdb:
           image: postgres
           env:
             POSTGRES_PASSWORD: postgres
             POSTGRES_USER: postgres
             POSTGRES_DB: postgres
           # Set health checks to wait until postgres has started
           options: >-
             --health-cmd pg_isready
             --health-interval 10s
             --health-timeout 5s
             --health-retries 5
   
       # END CODE ADDITION
   
       steps:
         - uses: actions/checkout@v4
         ...
   

   container: ubuntu tells GitHub to run the build job in a container. This way, the connection string in your dev environment jdbc:postgresql://postgresdb:5432/postgres can work as-is in when the workflow runs. For more information about PostgreSQL connectivity in GitHub Actions, see Creating PostgreSQL service containers.

2. In the Build with Maven step, remove -DskipTests. For example:

         - name: Build with Maven
           run: mvn clean install -Dquarkus.package.type=uber-jar
   

I don't have permissions to create a user-assigned identity

See Set up GitHub Actions deployment from the Deployment Center.

What can I do with GitHub Copilot in my codespace?

You might have noticed that the GitHub Copilot chat view was already there for you when you created the codespace. However, you need a GitHub Copilot account (30-day free trial available).

A few tips for you when you talk to GitHub Copilot:

• In a single chat session, the questions and answers build on each other and you can adjust your questions to fine-tune the answer you get.
• By default, GitHub Copilot doesn't have access to any file in your repository. To ask questions about a file, open the file in the editor first.
• To let GitHub Copilot have access to all of the files in the repository when preparing its answers, begin your question with @workspace. For more information, see Use the @workspace agent.
• In the chat session, GitHub Copilot can suggest changes and (with @workspace) even where to make the changes, but it's not allowed to make the changes for you. It's up to you to add the suggested changes and test it.

Next steps

• Azure for Java Developers
• Quarkus,
• Getting Started with Quarkus

Learn more about running Java apps on App Service in the developer guide.

Configure a Java app in Azure App Service

Learn how to secure your app with a custom domain and certificate.

 Secure with custom domain and certificate