Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Dans ce tutoriel, vous déployez une application web basée sur les données Quarkus sur Azure App Service avec le service de base de données relationnelles Azure Database pour PostgreSQL. Azure App Service prend en charge Java Standard Edition (Java SE) dans un environnement de serveur Windows ou Linux.
Dans ce tutoriel, vous allez apprendre à :
- Créez une architecture sécurisée par défaut pour azure App Service et un serveur flexible Azure Database pour PostgreSQL.
- Sécuriser les secrets de connexion à l’aide d’une identité managée et d’une référence Key Vault.
- Déployez un exemple d’application Quarkus sur Azure App Service à partir d’un dépôt GitHub.
- Accéder aux paramètres d’application App Service dans le code de l’application.
- Effectuer des mises à jour, et redéployer le code de l’application.
- Générer des schémas de base de données en exécutant des migrations de base de données.
- Diffuser des journaux de diagnostic à partir d’Azure.
- Gérer l’application dans le portail Azure.
- Approvisionner la même architecture et la déployer à l’aide d’Azure Developer CLI.
- Optimiser votre workflow de développement avec GitHub Codespaces et GitHub Copilot.
Conditions préalables
- Compte Azure avec un abonnement actif. Si vous ne possédez pas de compte Azure, vous pouvez créer un compte gratuit.
- Un compte GitHub. Vous pouvez aussi en obtenir un gratuitement.
- Connaissance de Java avec le développement Quarkus.
- (Facultatif) Pour essayer GitHub Copilot, un compte GitHub Copilot. Un essai gratuit de 30 jours est disponible.
- Compte Azure avec un abonnement actif. Si vous ne possédez pas de compte Azure, vous pouvez créer un compte gratuit.
- Un compte GitHub. Vous pouvez aussi en obtenir un gratuitement.
- Azure Developer CLI installé. Vous pouvez suivre les étapes avec Azure Cloud Shell, car Azure Developer CLI est déjà installé.
- Connaissance de Java avec le développement Quarkus.
- (Facultatif) Pour essayer GitHub Copilot, un compte GitHub Copilot. Un essai gratuit de 30 jours est disponible.
Passer à la fin
Si vous souhaitez simplement voir l’exemple d’application dans ce tutoriel s’exécutant dans Azure, exécutez simplement les commandes suivantes dans Azure Cloud Shell, puis suivez l’invite :
mkdir msdocs-quarkus-postgresql-sample-app
cd msdocs-quarkus-postgresql-sample-app
azd init --template msdocs-quarkus-postgresql-sample-app
azd up
1. Exécution de l'exemple
Tout d’abord, vous configurez un exemple d’application pilotée par les données comme point de départ. Pour votre commodité, l’exemple de référentiel, Mettre en veille prolongée ORM avec Panache et RESTEasy, contient une configuration du conteneur de développement. Le conteneur de développement dispose de tout ce dont vous avez besoin pour développer une application, notamment la base de données, le cache et toutes les variables d’environnement nécessaires par l’exemple d’application. Le conteneur de développement peut s’exécuter dans un codespace GitHub, ce qui signifie que vous pouvez exécuter l’exemple sur n’importe quel ordinateur avec un navigateur web.
Étape 1 : Dans une nouvelle fenêtre du navigateur :
- Connectez-vous à votre compte GitHub.
- Accédez à https://github.com/Azure-Samples/msdocs-quarkus-postgresql-sample-app/fork.
- Désélectionnez Copier la branche principale uniquement. Vous voulez toutes les branches.
- Sélectionnez Créer la fourche.
Étape 2 : dans la fourche GitHub :
- Sélectionnez main>starter-no-infra pour la branche de démarrage. Cette branche contient uniquement l’exemple de projet et aucun fichier ou configuration lié à Azure.
- Sélectionnez Code>Créer un codespace sur starter-no-infra. Il faut quelques minutes pour configurer le codespace.
Étape 3 : Dans le terminal codespace :
- Exécutez
mvn quarkus:dev. - Ignorer la notification
Your application running on port 5005 is available. - Lorsque la notification
Your application running on port 8080 is available.s’affiche, sélectionnez Ouvrir dans le navigateur. Vous devez voir l’exemple d’application dans un nouvel onglet de navigateur. Pour arrêter le serveur de développement Quarkus, tapezCtrl+C.
Pour plus d’informations sur la création de l’exemple d’application Quarkus, consultez la documentation Quarkus sur la Mise en veille prolongée ORM simplifiée avec Panache et Configurer des sources de données dans Quarkus.
Conseil
Vous pouvez interroger GitHub Copilot à propos de ce référentiel. Exemple :
- @workspace Que fait ce projet ?
- @workspace Que fait le dossier .devcontainer ?
Vous rencontrez des problèmes ? Examinez la section Résolution des problèmes.
2. Créer les instances App Service et PostgreSQL
Dans cette étape, vous créez les ressources Azure. La procédure indiquée dans ce tutoriel permet de créer un ensemble de ressources sécurisées par défaut qui incluent App Service et Azure DB pour PostgreSQL. Pour le processus de création, vous devez spécifier :
- Le nom de l’application web. Il est utilisé dans le cadre du nom DNS de votre application sous la forme
https://<app-name>-<hash>.<region>.azurewebsites.net. - La Région du monde où l’application sera physiquement exécutée. Il est également utilisé dans le cadre du nom DNS de votre application.
- La Pile du runtime de l’application. C’est là que vous sélectionnez la version de Java à utiliser pour votre application.
- Le Plan d’hébergement de l’application. Il s’agit du niveau tarifaire qui inclut l’ensemble des fonctionnalités et la scalabilité de l’application.
- Le groupe de ressources pour l’application. Un groupe de ressources vous permet de regrouper (dans un conteneur logique) toutes les ressources Azure nécessaires à l’application.
Connectez-vous au portail Azure et procédez comme suit pour créer vos ressources Azure App Service.
Étape 1 : Dans le Portail Azure :
- Dans la barre de recherche, tapez app service.
- Sélectionnez l’élément intitulé App Service sous l’en-tête Services .
- Sélectionnez Créer>Application web. Vous pouvez également accéder directement à l’Assistant de création.
Étape 2 : Configurer la nouvelle application Remplissez le formulaire comme suit.
- Nom : msdocs-quarkus-postgres. Un groupe de ressources nommé msdocs-quarkus-postgres_group est généré pour vous.
- Pile d’exécution : Java 21.
- Pile de serveurs web Java : Java SE (serveur web incorporé).
- Système d’exploitation : Linux.
- Région : toute région Azure près de chez vous.
- Plan Linux: Créer nouveau et utiliser le nom msdocs-postgres-postgres.
- Plan tarifaire : B1 de base. Une fois que vous êtes prêt, vous pouvez effectuer un scale-up vers un niveau tarifaire différent.
Étape 3 : Ajouter une base de données
- Sélectionnez l’onglet Base de données .
- Sélectionnez Créer une base de données.
- Dans le moteur, sélectionnez PostgreSQL - Serveur flexible. Les noms du serveur et de la base de données sont définis par défaut sur des valeurs appropriées.
Étape 4 : Configurer le déploiement GitHub
- Sélectionnez l’onglet Déploiement .
- Sélectionnez Déploiement continu.
- Si c’est la première fois que vous configurez le déploiement GitHub dans App Service, sélectionnez Autoriser et s’authentifier auprès de votre compte GitHub.
- Dans l’organisation, sélectionnez votre alias GitHub.
- Dans Référentiel, sélectionnez msdocs-quarkus-postgresql-sample-app.
- Dans Branche, sélectionnez starter-no-infra.
- Sélectionnez Revoir + créer.
- Une fois la validation terminée, sélectionnez Créer. Par défaut, l'Assistant Création crée une identité assignée par l'utilisateur afin que le flux de travail puisse s'authentifier à l'aide de Microsoft Entra (authentification OIDC). Pour des options d’authentification alternatives, consultez Déployer sur App Service à l’aide de GitHub Actions.
Étape 3 : le déploiement prend quelques minutes. Une fois le déploiement terminé, sélectionnez le bouton Accéder à la ressource. L’application App Service s’ouvre automatiquement, mais les ressources suivantes sont créées :
- Groupe de ressources : conteneur pour toutes les ressources créées.
- Plan App Service : définit les ressources de calcul pour App Service. Un plan Linux est créé sur le niveau De base.
- App Service : représente votre application et s’exécute dans le plan App Service.
- Réseau virtuel : intégré à l’application App Service, isole le trafic réseau principal.
- Azure Database pour PostgreSQL – Serveur flexible : accessible uniquement à partir du réseau virtuel. Une base de données et un utilisateur sont créés pour vous sur le serveur.
- Zones DNS privées : active la résolution DNS du coffre de clés et du serveur de base de données dans le réseau virtuel.
3. Secrets de la connexion sécurisée
L’assistant de création a généré les variables de connectivité pour vous déjà en tant que paramètres d’application. Toutefois, la meilleure pratique de sécurité consiste à éliminer complètement les secrets d’App Service. Vous allez déplacer vos secrets vers un coffre de clés et modifier votre paramètre d’application sur Références Key Vault à l’aide des connecteurs de services.
Étape 1 : Récupérer la chaîne de connexion existante
- Dans le menu de gauche de la page App Service, sélectionnez Paramètres > Variables d’environnement.
- Sélectionnez Chaînes de connexion.
- Sélectionnez AZURE_POSTGRESQL_CONNECTIONSTRING.
- Dans le paramètre Ajouter/Modifier l’application, dans le champ Valeur , recherchez les parties ID d’utilisateur= et Password= à la fin de la chaîne.
- Copiez les chaînes de nom d’utilisateur et de mot de passe après l’ID d’utilisateur etle mot de passe= pour une utilisation ultérieure. Ce paramètre d’application vous permet de vous connecter à une base de données Postgres sécurisée derrière un point de terminaison privé. Toutefois, le secret est enregistré directement dans l’application App Service, ce qui n’est pas le meilleur. Vous allez changer ça.
Étape 2 : Créer un sous-réseau pour sécuriser Key Vault Le réseau virtuel a déjà deux sous-réseaux existants, mais l’un est déjà délégué à App Service et l’autre est déjà délégué à Azure Database pour PostgreSQL. Vous en créez un autre pour un accès sécurisé à Key Vault avec un point de terminaison privé (pour plus d’informations, consultez Sécurité réseau pour Azure Key Vault).
- Dans le menu de gauche de la page App Service, sélectionnez l’onglet Vue d’ensemble .
- Sélectionnez le groupe de ressources de l’application.
- Sélectionnez le réseau virtuel dans le groupe de ressources.
- Dans le menu de gauche du réseau virtuel, sélectionnez Paramètres > Sous-réseaux.
- Sélectionnez + un sous-réseau.
- Dans Name, tapez subnet-keyvault. Acceptez les valeurs par défaut.
- Sélectionnez Ajouter.
Étape 3 : Créer un coffre de clés pour la gestion sécurisée des secrets
- Dans la barre de recherche supérieure, tapez « coffre de clés », puis sélectionnez Place de marché>Coffre de clés.
- Dans groupe de ressources, sélectionnez msdocs-quarkus-postgres_group.
- Dans nom du coffre de clés, tapez un nom composé uniquement de lettres et de chiffres.
- Dans Région, définissez-la sur le même emplacement en tant que groupe de ressources.
Étape 4 : Sécuriser le coffre-fort de clés avec un point de terminaison privé
- Sélectionnez l’onglet Réseau.
- Désélectionnez Activer l’accès public.
- Séllectionnez Créer un point de terminaison privé.
- Dans groupe de ressources, sélectionnez msdocs-quarkus-postgres_group.
- Dans la boîte de dialogue, dans Emplacement,sélectionnez le même emplacement que votre application App Service.
- Dans Name, tapez msdocs-quarkus-postgresVaultEndpoint.
- Dans le réseau virtuel, sélectionnez vnet-xxxxxxx.
- Dans Sous-réseau, sous-réseau-coffre de clés.
- Cliquez sur OK.
- Sélectionnez Vérifier + créer, puis sélectionnez Créer. Attendez que le déploiement du coffre de clés se termine. Vous devez voir « Votre déploiement est terminé ».
Étape 5 : Créer un connecteur PostgreSQL
- Dans la barre de recherche supérieure, tapez msdocs-quarkus-postgres, puis sélectionnez la ressource App Service appelée msdocs-quarkus-postgres.
- Dans la page App Service, dans le menu de gauche, sélectionnez Paramètres > Service Connector > Create.
- Dans le type de service, sélectionnez DB pour le serveur flexible PostgreSQL.
- Dans le serveur flexible PostgreSQL, msdocs-quarkus-postgres-server devrait déjà être sélectionné.
- Dans la base de données PostgreSQL, sélectionnez msdocs-quarkus-postgres-database.
- Dans le type de client, sélectionnez Java.
Étape 6 : Enregistrer les secrets dans le coffre de clés
- Sélectionnez l’onglet Authentification.
- Sélectionnez Chaîne de connexion.
- Dans Nom d’utilisateur et mot de passe, collez le mot de passe que vous avez copié précédemment.
- Sélectionnez Stocker le secret dans Key Vault.
- Sous Connexion à Key Vault, sélectionnez Créer nouveau. Une boîte de dialogue Créer une connexion est ouverte en haut de la boîte de dialogue d’édition.
Étape 7 : Établir la connexion Key Vault
- Dans la boîte de dialogue Créer une connexion pour la connexion Key Vault, dans Key Vault, sélectionnez le coffre de clés que vous avez créé précédemment.
- Dans le type de client, sélectionnez Java pour la cohérence. Votre code d’application n’utilise pas directement le coffre de clés.
- Sélectionnez Vérifier + créer.
- Lorsque la validation terminée, sélectionnez Créer.
Étape 8 : Finaliser les paramètres du connecteur PostgreSQL
- Vous revenez dans la boîte de dialogue d’édition du connecteur PostgreSQL. Sous l’onglet Authentification, attendez que le connecteur Key Vault soit créé. Une fois l’opération terminée, la liste déroulante Key Vault Connection la sélectionne automatiquement.
- Sélectionnez Vérifier + créer.
- Lorsque la validation terminée, sélectionnez Créer. Attendez que la notification de création réussisse s’affiche.
Étape 9 : Vérifier l’intégration de Key Vault
- Dans le menu de gauche, sélectionnez à nouveau Paramètres > Variables d’environnement.
- À côté d’AZURE_POSTGRESQL_CONNECTIONSTRING, sélectionnez Afficher la valeur. La valeur doit être
@Microsoft.KeyVault(...), ce qui signifie qu’il s’agit d’une référence coffre de clés, car le secret est maintenant managé dans le coffre de clés.
Étape 10 : Supprimer les informations d’identification de base de données d’App Service
- Sélectionnez l’onglet Chaînes de connexion .
- À droite de AZURE_POSTGRESQL_CONNECTIONSTRING, sélectionnez Supprimer. N’oubliez pas que l'assistant de création a créé cette chaîne de connexion pour vous au début.
En résumé, le processus de sécurisation de vos secrets de connexion est complexe :
- Récupération des secrets de connexion depuis les variables d'environnement de l'application App Service.
- Création d’un coffre de clés avec un point de terminaison privé.
- Création d'une connexion Key Vault avec l'identité gérée attribuée par le système.
- Créez un connecteur de service pour stocker les secrets de connexion dans le coffre de clés.
- Supprimez les anciens secrets de connexion de l’application App Service.
Vous rencontrez des problèmes ? Examinez la section Résolution des problèmes.
4. Déployer l’exemple de code
Dans l’Assistant Création, vous avez déjà configuré le déploiement continu à partir de votre exemple de référentiel GitHub à l’aide de GitHub Actions. Cette méthode fait partie des nombreuses façons de déployer sur App Service, mais elle permet également de bénéficier d’une intégration continue dans votre processus de déploiement. Par défaut, chaque git push vers votre référentiel GitHub lance l’action de build et de déploiement.
Notez les points suivants :
- Quarkus écoute le port 8080 par défaut. En production, il doit être configuré pour écouter le port spécifié par la
PORTvariable d’environnement dans App Service. - Votre package Java déployé doit être de type Uber-Jar.
- Par souci de simplicité du didacticiel, vous allez désactiver les tests pendant le processus de déploiement. Les exécuteurs GitHub Actions n’ont pas accès à la base de données PostgreSQL dans Azure. Par conséquent, tous les tests d’intégration nécessitant l’accès à une base de données échouent, comme c’est le cas avec l’exemple d’application Quarkus.
Étape 1 : De retour dans l’espace de code GitHub de votre exemple de duplication, exécutez git pull origin starter-no-infra.
Cela extrait le fichier de flux de travail GitHub nouvellement validé dans votre espace de code.
Étape 2 (Option 1 : avec GitHub Copilot) :
- Démarrez une nouvelle session de conversation en sélectionnant la vue Conversation, puis en sélectionnant +.
- Demandez à « @workspace Comment l’application se connecte-t-elle à la base de données ? » Copilot pourra vous fournir des explications sur la façon dont les paramètres de la source de données Quarkus sont configurés dans src/main/resources/application.properties.
- Supposons que « @workspace j’ai créé un connecteur de service PostgreSQL dans Azure App Service à l’aide du type de client Java et que le nom du paramètre d’application est AZURE_POSTGRESQL_CONNECTIONSTRING. Je souhaite utiliser cette chaîne de connexion lorsque l’application est en cours d’exécution en production. » Copilot peut vous donner une suggestion de code similaire à celle de l’option 2 : sans étapes gitHub Copilot ci-dessous et même vous indiquer d’apporter la modification dans le fichier src/main/resources/application.properties .
- Ouvrez src/main/resources/application.properties dans l’Explorateur et ajoutez la suggestion de code.
- Dites : « @workspace Comment configurer ce projet pour créer un Uber Jar ? » Copilot peut vous donner une suggestion de code similaire à celle de l’option 2 : sans étapes gitHub Copilot ci-dessous et même vous indiquer d’apporter la modification dans le fichier src/main/resources/application.properties .
- Ouvrez src/main/resources/application.properties dans l’Explorateur et ajoutez la suggestion de code.
- Dites « @workspace Comment utiliser le port App Service ? » Copilot peut vous donner une suggestion de code similaire à celle de l’option 2 : sans GitHub Copilot ci-dessous et même vous dire de faire la modification dans le fichier src/main/resources/application.properties.
- Ouvrez src/main/resources/application.properties dans l’Explorateur et ajoutez la suggestion de code. GitHub Copilot ne vous donne pas la même réponse à chaque fois, et elle n’est pas toujours correcte. Vous devrez peut-être poser plus de questions pour affiner sa réponse. Pour obtenir des conseils, consultez Que puis-je faire avec GitHub Copilot dans mon codespace ?
Étape 2 (Option 2 : sans GitHub Copilot) :
- Ouvrezsrc/main/resources/application.properties dans l’explorateur. Quarkus utilise ce fichier pour charger des propriétés Java.
- Décommentez les lignes 10-12. Ces paramètres utilisent le paramètre d’application que vous avez créé avec le connecteur PostgreSQL, crée un Jar Uber et définit le port sur celui utilisé par App Service.
Étape 3 (Option 1 : avec GitHub Copilot) :
- Demandez à « @workspace pour le déploiement gitHub Actions, je souhaite ignorer les tests pour éviter les erreurs liées à la base de données. » Copilot peut vous donner une suggestion de code similaire à celle de l’option 2 : sans étapes gitHub Copilot ci-dessous et même vous indiquer d’apporter la modification dans le fichier .github/workflows/starter-no-infra_msdocs-quarkus-postgres.yml .
- Ouvrez .github/workflows/starter-no-infra_msdocs-quarkus-postgres.yml dans l’Explorateur et ajoutez la suggestion de code. Pour obtenir des conseils, consultez Que puis-je faire avec GitHub Copilot dans mon codespace ?
Étape 3 (Option 2 : sans GitHub Copilot) :
- Ouvrez .github/workflows/starter-no-infra_msdocs-quarkus-postgres.yml dans l’Explorateur. Il s’agit du flux de travail GitHub Actions que l’assistant de création a créé pour vous.
- Recherchez l’étape
Build with Mavenet modifiez laruncommande surmvn clean install -DskipTests.-DskipTestsindique à Maven d’ignorer les tests afin que le déploiement ne échoue pas sur les erreurs de base de données. Le conteneur GitHub Actions ne peut pas se connecter à un serveur PostgreSQL.
Étape 4 :
- Sélectionnez l’extension Contrôle de code source.
- Dans la zone de texte, tapez un message de commit comme
Configure DB and deployment. Vous pouvez également sélectionner
, puis laisser GitHub Copilot générer un message de commit à votre place. - Sélectionnez Valider, puis confirmez en choisissant Oui.
- Sélectionnez Synchroniser les modifications 1, puis confirmez en choisissant OK.
Étape 5 :
- Dans le menu de gauche, sélectionnez Déploiement, >, Journaux.
- Dans l’élément de journal de l’exécution du déploiement, sélectionnez l’entrée Générer/déployer des journaux avec le timestamp le plus récent.
Étape 6 : Vous accédez à votre dépôt GitHub et voyez que l’action GitHub est en cours d’exécution. Le fichier de workflow définit deux étapes distinctes : la build et le déploiement. Attendez que l’exécution de GitHub affiche l’état Opération réussie. Cela prend environ 5 minutes.
Vous rencontrez des problèmes ? Examinez la section Résolution des problèmes.
5. Accéder à l’application
Étape 1 : Dans la page App Service,
- Dans le menu de gauche, sélectionnez Vue d’ensemble.
- Sélectionnez l’URL de votre application.
Étape 2 : Ajoutez quelques fruits à la liste. Félicitations, vous exécutez une application web Flask dans Azure App Service, avec une connectivité sécurisée vers Azure Database pour PostgreSQL.
6. Diffuser les journaux de diagnostic
Azure App Service capture tous les messages qui s’affichent sur la console pour vous aider à diagnostiquer les problèmes liés à votre application. L’exemple d’application contient des instructions de journalisation JBoss standard pour montrer cette fonctionnalité, comme ci-dessous.
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"));
}
Étape 1 : Dans la page App Service,
- Dans le menu de gauche, sélectionnez Monitoring>Journaux App Service.
- Sous Application Logging, sélectionnez Système de fichiers.
- Dans le menu principal, sélectionnez Enregistrer.
Étape 2 : Dans le menu de gauche, sélectionnez Flux de journal. Les journaux de votre application, notamment les journaux de plateforme et ceux issus de l’intérieur du conteneur, apparaissent.
En savoir plus sur la journalisation dans des applications Java dans des séries sur Activer Azure Monitor OpenTelemetry pour les applications .NET, Node.js, Java et Python.
7. Nettoyer les ressources
Lorsque vous avez terminé, vous pouvez supprimer toutes les ressources de votre abonnement Azure en supprimant le groupe de ressources.
Étape 1 : Dans la barre de recherche située en haut du portail Azure :
- Entrez le nom du groupe de ressources.
- Sélectionnez le groupe de ressources.
Étape 2 : Sur la page Groupe de ressources, sélectionnez Supprimer un groupe de ressources.
Étape 3 :
- Entrer le nom du groupe de ressources pour confirmer la suppression.
- Sélectionnez Supprimer.
- Confirmez à nouveau en choisissant Supprimer.
2. Créer des ressources Azure et déployer un exemple d’application
Dans cette étape, vous allez créer les ressources Azure et déployer un exemple d’application dans App Service sur Linux. La procédure indiquée dans ce tutoriel permet de créer un ensemble de ressources sécurisées par défaut qui incluent App Service et Azure DB pour PostgreSQL.
Le conteneur de développement dispose déjà d’Azure Developer CLI (AZD).
À partir de la racine du référentiel de l’espace de code GitHub, exécutez
azd init.azd init --template javase-app-service-postgresql-infraLorsque vous y êtes invité, fournissez les réponses suivantes :
Question Réponse Le répertoire actuel n’est pas vide. Voulez-vous initialiser un projet ici dans «<votre-répertoire>» ? O Que souhaitez-vous faire de ces fichiers ? Conserver mes fichiers existants inchangés Entrer un nom pour le nouvel environnement Tapez un nom unique. Le modèle AZD utilise ce nom dans le cadre du nom DNS de votre application web dans Azure ( <app-name>-<hash>.azurewebsites.net). Les caractères alphanumériques et les traits d’union sont autorisés.Connectez-vous à Azure en exécutant la commande
azd auth loginet en suivant l’invite :azd auth loginCréez les ressources Azure nécessaires avec la commande
azd provision. Suivez l’invite pour sélectionner l’abonnement et l’emplacement souhaités pour les ressources Azure.azd provisionLa commande
azd provisionprend environ 15 minutes (le cache Redis prend le plus de temps). Plus tard, vous modifierez votre code pour qu'il fonctionne avec App Service et déploierez les changements avecazd deploy. Pendant son exécution, la commande fournit des messages sur le processus d’approvisionnement et de déploiement, y compris un lien vers le déploiement dans Azure.Ce modèle AZD contient des fichiers (azure.yaml et le répertoire infra) qui génèrent une architecture sécurisée par défaut avec les ressources Azure suivantes :
- Groupe de ressources : conteneur pour toutes les ressources créées.
- Plan App Service : définit les ressources de calcul pour App Service. Un plan Linux est créé sur le niveau De base.
- App Service : représente votre application et s’exécute dans le plan App Service.
- Réseau virtuel : intégré à l’application App Service, isole le trafic réseau principal.
- Points de terminaison privés : Points de terminaison d’accès pour le coffre de clés et le cache Redis dans le réseau virtuel.
- Interfaces réseau : représente les adresses IP privées, une pour chacun des points de terminaison privés.
- Azure Database pour PostgreSQL – Serveur flexible : accessible uniquement à partir du réseau virtuel. Une base de données et un utilisateur sont créés pour vous sur le serveur.
- Zone DNS privée : active la résolution DNS du serveur PostgreSQL dans le réseau virtuel.
- L’espace de travail Log Analytics : agit comme le conteneur cible de votre application pour expédier ses journaux d’activité, dans lequel vous pouvez également interroger les journaux.
- Azure Managed Redes : accessible uniquement depuis l’arrière de son point de terminaison privé.
- Coffre de clés : accessible uniquement depuis l’arrière de son point de terminaison privé. Permet de gérer les secrets de l’application App Service.
Une fois l’approvisionnement terminé, recherchez le paramètre
AZURE_POSTGRESQL_CONNECTIONSTRINGdans la sortie AZD. Pour préserver la sécurité des secrets, seuls les noms des paramètres sont affichés. Ils ressemblent à ceci dans la sortie AZD :App Service app has the following connection settings: - AZURE_POSTGRESQL_CONNECTIONSTRING - AZURE_REDIS_CONNECTIONSTRING - AZURE_KEYVAULT_RESOURCEENDPOINT - AZURE_KEYVAULT_SCOPELe modèle AZD utilisé a généré les variables de connectivité pour vous en tant que paramètres d’application et les restitue sur le terminal pour plus de facilité. Les paramètres d’application sont un moyen de préserver les secrets de connexion hors de votre référentiel de code. Vous trouverez également le lien direct vers la page des paramètres de l’application pour l’application App Service créée.
Vous rencontrez des problèmes ? Examinez la section Résolution des problèmes.
3. Modifier l’exemple de code et redéployer
Vous devez apporter des modifications dans votre code d’application pour qu’elle fonctionne avec App Service :
- Quarkus écoute le port 8080 par défaut. En production, il doit être configuré pour écouter le port spécifié par la
PORTvariable d’environnement dans App Service. - Votre package Java déployé doit être de type Uber-Jar.
- Par souci de simplicité du didacticiel, vous allez désactiver les tests pendant le processus de déploiement. Les exécuteurs GitHub Actions n’ont pas accès à la base de données PostgreSQL dans Azure. Par conséquent, tous les tests d’intégration nécessitant l’accès à une base de données échouent, comme c’est le cas avec l’exemple d’application Quarkus.
Dans le codespace GitHub, démarrez une nouvelle session de conversation en sélectionnant la vue Conversation, puis en sélectionnant +.
Demandez « @workspace Comment l’application se connecte-t-elle à la base de données ? » Copilot peut vous donner des explications sur la façon dont les paramètres de source de données quarkus sont configurés dans src/main/resources/application.properties.
Supposons que « @workspace j’ai créé un connecteur de service PostgreSQL dans Azure App Service à l’aide du type de client Java et le nom du paramètre d’application est AZURE_POSTGRESQL_CONNECTIONSTRING. Je souhaite utiliser cette chaîne de connexion lorsque l’application est en cours d’exécution en production. » Copilot peut vous donner une suggestion de code similaire à celle de l’option 2 : sans étapes gitHub Copilot ci-dessous et même vous indiquer d’apporter la modification dans le fichier src/main/resources/application.properties .
Ajoutez la suggestion de code dans src/main/resources/application.properties.
Dites : « @workspace Comment configurer ce projet pour créer un Uber Jar ? » Copilot peut vous donner une suggestion de code similaire à celle de l’option 2 : sans étapes gitHub Copilot ci-dessous et même vous indiquer d’apporter la modification dans le fichier src/main/resources/application.properties .
Ajoutez la suggestion de code dans src/main/resources/application.properties.
Dites « @workspace Comment utiliser le port App Service ? » Copilot peut vous donner une suggestion de code similaire à celle de l’option 2 : sans GitHub Copilot ci-dessous et même vous dire de faire la modification dans le fichier src/main/resources/application.properties.
Ajoutez la suggestion de code dans src/main/resources/application.properties.
GitHub Copilot ne vous donne pas la même réponse à chaque fois, et elle n’est pas toujours correcte. Vous devrez peut-être poser plus de questions pour affiner sa réponse. Pour obtenir des conseils, consultez Que puis-je faire avec GitHub Copilot dans mon codespace ?
Dans le terminal, exécutez
azd deploy.azd deploy
Vous rencontrez des problèmes ? Examinez la section Résolution des problèmes.
5. Accéder à l’application
Dans la sortie AZD, retrouvez l’URL de votre application et accédez-y dans le navigateur. L’URL ressemble à ceci dans la sortie AZD :
Deploying services (azd deploy) (✓) Done: Deploying service web - Endpoint: https://<app-name>.azurewebsites.net/
Ajoutez quelques fruits à la liste.
Félicitations, vous exécutez une application web Flask dans Azure App Service, avec une connectivité sécurisée vers Azure Database pour PostgreSQL.
Vous rencontrez des problèmes ? Examinez la section Résolution des problèmes.
6. Diffuser les journaux de diagnostic
Azure App Service peut capturer les journaux de la console pour vous aider à diagnostiquer les problèmes liés à votre application. Pour plus de facilité, le modèle AZD active déjà la journalisation sur le système de fichiers local et expédie les journaux vers un espace de travail Log Analytics.
L’exemple d’application contient des instructions de journalisation JBoss standard pour montrer cette fonctionnalité, comme ci-dessous.
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"));
}
Dans la sortie AZD, retrouvez le lien pour diffuser en continu les journaux App Service et accédez-y dans le navigateur. Le lien ressemble à ceci dans la sortie AZD :
Stream App Service logs at: https://portal.azure.com/#@/resource/subscriptions/<subscription-guid>/resourceGroups/<group-name>/providers/Microsoft.Web/sites/<app-name>/logStream
En savoir plus sur la journalisation dans des applications Java dans des séries sur Activer Azure Monitor OpenTelemetry pour les applications .NET, Node.js, Java et Python.
Vous rencontrez des problèmes ? Examinez la section Résolution des problèmes.
7. Nettoyer les ressources
Pour supprimer toutes les ressources Azure dans le présent environnement de déploiement, exécutez azd down et suivez les invites.
azd down
Dépannage
L’exécution gitHub Actions a échoué à l’étape de génération
Sélectionnez l’étape de génération ayant échoué pour voir quelle étape a échoué. S’il s’agit de la phase build avec Maven, déroulez l’étape pour vérifier que l’option -DskipTests est utilisée. Si ce n’est pas le cas, revenez à 4. Déployez un exemple de code et modifiez le fichier de flux de travail GitHub en fonction des instructions.
L’application n’a pas pu démarrer et affiche l’erreur suivante dans le flux de journal : « Les classes de modèle sont définies pour la valeur par défaut de l’unité <de persistance par défaut, mais la source >de données configurée par défaut< est introuvable : l’EntityManagerFactory par défaut> ne sera pas créée. »
Cette erreur Quarkus est probablement due à une absence de connexion de l’application à la base de données Azure. Assurez-vous que le paramètre AZURE_POSTGRESQL_CONNECTIONSTRING de l’application n’a pas été modifié et que application.properties utilise correctement le paramètre d’application.
L’application n’a pas pu démarrer et le flux de journal affiche « Attente de la réponse à la demande de préchauffement du conteneur »
Votre application n’est probablement pas configurée pour écouter le port spécifié par la variable d’environnement App Service PORT , de sorte qu’elle ne peut pas répondre aux demandes. Si App Service n’obtient pas de réponse de votre application, il part du principe que l’application n’a pas pu démarrer. Revenez à 4. Déployez un exemple de code et vérifiez que application.properties est configuré correctement.
L’application fonctionne, mais je vois le journal des erreurs « 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 ».
Il s’agit d’une erreur Vert.x (voir l’architecture réactive Quarkus) indiquant que le client a demandé un chemin inconnu. Cela peut se produire la première fois que l’application démarre, lorsque le client demande l’API REST avant la migration de la base de données en veille prolongée.
Dans App Service, cette erreur se produit également sur chaque démarrage de l’application, car App Service vérifie que l’application commence par envoyer une GET demande à /robots933456.txt.
Forum aux questions
- Quel est le coût de cette configuration ?
- Comment se connecter au serveur PostgreSQL sécurisé derrière le réseau virtuel avec d’autres outils ?
- Comment le développement d’applications locales fonctionne-t-il avec GitHub Actions ?
- Que se passe-t-il si je souhaite exécuter des tests avec PostgreSQL pendant le workflow GitHub ?
- Je n’ai pas les autorisations pour créer une identité utilisateur assignée
- Que puis-je faire avec GitHub Copilot dans mon codespace ?
Quel est le coût de cette configuration ?
Le prix des ressources créées est calculé comme suit :
- Le plan App Service est créé au niveau Essentiel. Il peut faire l’objet d’un scale-up ou d’un scale-down. Consultez la tarification App Service.
- Le serveur flexible PostgreSQL est créé dans le plus bas niveau burstable Standard_B1ms, avec la taille minimale de stockage qui peut être augmentée ou diminuée. Consultez Tarifs d’Azure Database pour PostgreSQL.
- Le réseau virtuel n’entraîne pas de frais, sauf si vous configurez des fonctionnalités supplémentaires, telles que le peering. Consultez Tarification du réseau virtuel Azure.
- La zone DNS privée entraîne des frais minimes. Consultez la tarification d’Azure DNS.
Comment se connecter au serveur PostgreSQL sécurisé derrière le réseau virtuel avec d’autres outils ?
- Pour un accès de base à partir d’un outil en ligne de commande, vous pouvez exécuter
psqlà partir du terminal SSH de l’application. - Pour vous connecter à partir d’un outil de bureau, votre ordinateur doit se trouver dans le réseau virtuel. Par exemple, il peut s’agir d’une machine virtuelle Azure connectée à l’un des sous-réseaux ou d’une machine dans un réseau local disposant d’une connexion VPN de site à site avec le réseau virtuel Azure.
- Vous pouvez également intégrer Azure Cloud Shell au réseau virtuel.
Comment le développement d’applications locales fonctionne-t-il avec GitHub Actions ?
Grâce au fichier de flux de travail généré automatiquement à partir d’App Service comme exemple, chaque git push démarre une nouvelle exécution de build et de déploiement. À partir d’un clone local du référentiel GitHub, vous effectuez les mises à jour souhaitées et poussez vers GitHub. Exemple :
git add .
git commit -m "<some-message>"
git push origin main
Que se passe-t-il si je souhaite exécuter des tests avec PostgreSQL pendant le workflow GitHub ?
L’exemple d’application par défaut Quarkus comprend des tests avec une connectivité à la base de données. Pour éviter des erreurs de connexion, vous avez ajouté la propriété -skipTests. Au besoin, vous pouvez exécuter les tests sur un conteneur de service PostgreSQL. Par exemple, dans le fichier du workflow généré automatiquement dans votre duplication (fork) GitHub (.github/workflows/main_cephalin-quarkus.yml), apportez les modifications suivantes :
Ajoutez du code YAML pour le conteneur PostgreSQL au travail
build, comme illustré dans l’extrait de code suivant.... 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: ubuntuindique à GitHub d’exécuter le travailbuilddans un conteneur. De cette façon, la chaîne de connexion dans votre environnement de développementjdbc:postgresql://postgresdb:5432/postgrespeut fonctionner en l’état lorsque le workflow s’exécute. Pour plus d’informations sur la connectivité PostgreSQL dans GitHub Actions, consultez Création de conteneurs de service PostgreSQL.À l’étape
Build with Maven, supprimez-DskipTests. Exemple :- name: Build with Maven run: mvn clean install -Dquarkus.package.type=uber-jar
Je n’ai pas les autorisations pour créer une identité assignée par l’utilisateur.
Consultez Configurer le déploiement de GitHub Actions à partir du Centre de déploiement.
Que puis-je faire avec GitHub Copilot dans mon codespace ?
Vous avez peut-être remarqué que la vue de conversation GitHub Copilot était déjà là pour vous quand vous avez créé le codespace. Cependant, vous avez besoin d’un compte GitHub Copilot (essai gratuit de 30 jours disponible).
Quelques conseils à appliquer quand vous parlez à GitHub Copilot :
- Dans une session de conversation unique, les questions et réponses s’appuient les unes sur les autres et vous pouvez ajuster vos questions pour affiner la réponse que vous obtenez.
- Par défaut, GitHub Copilot n’a accès à aucun fichier de votre référentiel. Pour poser des questions sur un fichier, vous devez d’abord l’ouvrir dans l’éditeur.
- Pour permettre à GitHub Copilot d’accéder à tous les fichiers du référentiel lors de la préparation de ses réponses, commencez votre question par
@workspace. Pour plus d’informations, consultez Use the @workspace agent. - Dans la session de conversation, GitHub Copilot peut suggérer des modifications et même (avec
@workspace) où apporter les modifications, mais il n’est pas autorisé à apporter les modifications pour vous. C’est à vous d’ajouter les changements suggérés et de les tester.
Étapes suivantes
En savoir plus sur l’exécution des applications Java sur App Service dans le guide du développeur.
Découvrez comment sécuriser votre application avec un domaine personnalisé et un certificat.