Esercitazione: Creare un'app Web Tomcat con il Servizio app di Azure in Linux e MySQL

2025-04-30

Questa esercitazione illustra come compilare, configurare e distribuire un'applicazione Tomcat sicura nel servizio app di Azure che si connette a un database MySQL (usando Database di Azure per MySQL). Il servizio app di Azure è un servizio di hosting Web altamente scalabile e scalabile che può distribuire facilmente app in Windows o Linux. Al termine, è disponibile un'app Tomcat in esecuzione nel servizio app di Azure in Linux.

Screenshot dell'applicazione Tomcat che archivia i dati in MySQL.

In questa esercitazione apprenderai a:

Creare un'architettura sicura per impostazione predefinita per app Azure Servizio e Database di Azure per MySQL.
Proteggere i segreti di connessione usando un'identità gestita e riferimenti a Key Vault.
Implementare un'app di esempio Tomcat nel servizio app da un repository GitHub.
Accedere alle impostazioni dell'app servizio app nel codice dell'applicazione.
Apportare aggiornamenti e ridistribuire il codice dell'applicazione.
Eseguire lo streaming dei log di diagnostica dal servizio app.
Gestire l'app nel portale di Azure.
Effettuare il provisioning della stessa architettura ed effettuare l'implementazione usando Azure Developer CLI.
Ottimizzare il flusso di lavoro di sviluppo con GitHub Codespaces e GitHub Copilot.

Prerequisiti

Un account Azure con una sottoscrizione attiva. Se non si ha un account Azure, è possibile crearne uno gratuitamente.
Un account GitHub. è anche possibile ottenere uno gratuitamente.
Conoscenza di Java con lo sviluppo Tomcat.
(Facoltativo) Per provare GitHub Copilot, un account GitHub Copilot. È disponibile una versione di valutazione gratuita di 30 giorni.

Un account Azure con una sottoscrizione attiva. Se non si ha un account Azure, è possibile crearne uno gratuitamente.
CLI per sviluppatori Azure installata. È possibile seguire la procedura con Azure Cloud Shell perché è già installata l'interfaccia della riga di comando per sviluppatori di Azure.
Conoscenza di Java con lo sviluppo Tomcat.
(Facoltativo) Per provare GitHub Copilot, un account GitHub Copilot. È disponibile una versione di valutazione gratuita di 30 giorni.

È possibile distribuire rapidamente l'app di esempio in questa esercitazione e visualizzarla in esecuzione in Azure. È sufficiente eseguire i comandi seguenti in Azure Cloud Shell e seguire il prompt:

mkdir msdocs-tomcat-mysql-sample-app
cd msdocs-tomcat-mysql-sample-app
azd init --template msdocs-tomcat-mysql-sample-app
azd up

1. Eseguire l'esempio

Prima di tutto, configurare un'app guidata dai dati di esempio come punto di partenza. Per la tua comodità, il repository di esempio include una configurazione del dev container. Il contenitore di sviluppo include tutti gli elementi necessari per sviluppare un'applicazione, tra cui il database, la cache e tutte le variabili di ambiente necessarie per l'applicazione di esempio. Il contenitore di sviluppo può essere eseguito in uno spazio di codice GitHub, il che significa che è possibile eseguire l'esempio in qualsiasi computer con un Web browser.

Passaggio 1: In una nuova finestra del browser:

Accedi all'account GitHub.
Accedere a https://github.com/Azure-Samples/msdocs-tomcat-mysql-sample-app/fork.
Deselezionare Copia solo il ramo principale. Si desiderano tutti i rami.
Selezionare Crea fork.

Passaggio 2: Nel fork di GitHub:

Selezionare main>starter-no-infra per il ramo starter. Questo ramo contiene solo il progetto di esempio e nessun file o configurazione correlati ad Azure.
Selezionare Codice>Crea codespace in starter-no-infra. La configurazione del codespace richiede alcuni minuti.

Passaggio 3: Nel terminale codespace:

Eseguire mvn jetty:run.
Quando viene visualizzata la notifica Your application running on port 80 is available., selezionare Apri nel browser. L'applicazione di esempio dovrebbe essere visualizzata in una nuova scheda del browser. Per arrestare il server Jetty, digitare Ctrl+C.

Suggerimento

Puoi chiedere a GitHub Copilot informazioni su questo repository. Ad esempio:

@workspace Cosa fa questo progetto?
@workspace Cosa fa la cartella .devcontainer?

Problemi? Controllare la sezione Risoluzione dei problemi.

2. Creare il servizio app e MySQL

Creare prima di tutto le risorse di Azure. I passaggi usati in questa esercitazione creano un set di risorse sicure per impostazione predefinita che includono servizio app e Database di Azure per MySQL. Per il processo di creazione, si specifica:

Nome dell'app Web. Viene usato come parte del nome DNS.
L'area in cui eseguire l'app fisicamente nel mondo. Viene usato anche come parte del nome DNS per l'app.
Lo stack di runtime per l'app. È qui che si seleziona la versione Java da usare per l'app.
Piano di hosting per l'app. Si tratta del piano tariffario che include il set di funzionalità e la capacità di ridimensionamento per l'app.
Gruppo di risorse per l'app. Un gruppo di risorse consente di raggruppare (in un contenitore logico) tutte le risorse di Azure necessarie per l'applicazione.

Accedere al portale di Azure e seguire questa procedura per creare le risorse del servizio app di Azure.

Passaggio 1: Nel portale di Azure:

Immettere "database dell'app Web" nella barra di ricerca nella parte superiore del portale di Azure.
Selezionare l'elemento con etichetta App Web e database sotto l'intestazione Marketplace . È anche possibile accedere direttamente al wizard di creazione.

Passaggio 2: Nella pagina Crea app Web e database compilare il modulo come indicato di seguito.

Gruppo di risorse: selezionare Crea nuovo e usare un nome msdocs-tomcat-mysql-tutorial.
Area: qualsiasi area di Azure nelle vicinanze.
Nome: msdocs-tomcat-mysql-XYZ, dove XYZ è costituito da tre caratteri casuali.
Stack di esecuzione: Java 17.
Stack di server Web Java: Apache Tomcat 10.1.
Motore: MySQL - Server flessibile è selezionato per impostazione predefinita come motore di database. In caso contrario, selezionarlo. Database di Azure per MySQL: il server flessibile è un database MySQL come servizio completamente gestito in Azure, compatibile con le edizioni community più recenti.
Piano di hosting: Basic. Quando si è pronti, è possibile aumentare a un piano tariffario di produzione.
Selezionare Rivedi e crea.
Al termine della convalida, selezionare Crea.

Passaggio 3: Il completamento della distribuzione richiede alcuni minuti. Al termine della distribuzione, selezionare il pulsante Vai alla risorsa . Si accede direttamente all'app del servizio app, ma vengono create le risorse seguenti:

Gruppo di risorse: contenitore per tutte le risorse create.
Piano di servizio app: definisce le risorse di calcolo per il servizio app. Viene creato un piano Linux nel livello Basic .
App Service: rappresenta la tua app ed è in esecuzione nel piano di Servizio App.
Rete virtuale: integrata con l'App Service e isola il traffico di rete interno.
Server flessibile di Database di Azure per MySQL: accessibile solo dalla rete virtuale. Vengono automaticamente creati un database e un utente nel server.
Zone DNS private: abilitare la risoluzione DNS del server di database nella rete virtuale.

Problemi? Controllare la sezione Risoluzione dei problemi.

3. Proteggere i segreti di connessione

La creazione guidata ha già generato la stringa di connettività come un'impostazione dell'app. Tuttavia, le procedure consigliate in materia di sicurezza prevedono di tenere i segreti completamente al di fuori del Servizio app. Sposti i tuoi segreti in un "Key Vault" e modifichi la tua impostazione dell'app in un riferimento a Key Vault con l'aiuto dei connettori di servizio.

Passaggio 1: Recuperare la stringa di connessione esistente

Nel menu a sinistra della pagina Servizio app selezionare Impostazioni Variabili > di ambiente.
Selezionare AZURE_MYSQL_CONNECTIONSTRING. Contiene una stringa di connessione JDBC. Se si aggiunge un'impostazione dell'app contenente una stringa di connessione Oracle, SQL Server, PostgreSQL o MySQL valida, il servizio app lo inserisce come origine dati JNDI (Java Naming and Directory Interface) nel file context.xml del server Tomcat.
Nel campo Aggiungi/Modifica impostazione dell'applicazione, nel Valore, trovare la parte password= alla fine della stringa.
Copiare la stringa della password dopo Password= per usarla in un secondo momento. Questa impostazione dell'app consente di connettersi al database MySQL protetto dietro un endpoint privato. Tuttavia, il segreto viene salvato direttamente nell'app del servizio app, che non è il migliore. Questa operazione verrà modificata.

Passaggio 2: Creare un insieme di credenziali delle chiavi per la gestione sicura dei segreti

Nella barra di ricerca superiore digitare "Key Vault", quindi selezionare Marketplace>Key Vault.
In Gruppo di risorse selezionare msdocs-tomcat-mysql-tutorial.
In Nome dell'insieme di credenziali, digitare un nome che sia costituito solo da lettere e numeri.
In Area impostarlo sulla stessa posizione del gruppo di risorse.

Passaggio 3: Proteggere il Key Vault con un endpoint privato

Selezionare la scheda Rete .
Deselezionare Abilita l'accesso pubblico.
Selezionare Crea un endpoint privato.
In Gruppo di risorse selezionare msdocs-tomcat-mysql-tutorial.
In Nome digitare un nome per l'endpoint privato costituito solo da lettere e numeri.
In Area impostarlo sulla stessa posizione del gruppo di risorse.
Nella finestra di dialogo, in Località, selezionare la stessa posizione dell'app del servizio App Service.
In Gruppo di risorse selezionare msdocs-tomcat-mysql-tutorial.
In Nome, digitare msdocs-tomcat-mysql-XYZVaultEndpoint.
In Rete virtuale selezionare msdocs-tomcat-mysql-XYZVnet.
Nella Subnet, msdocs-tomcat-mysql-XYZSubnet.
Selezionare OK.
Selezionare Rivedi e crea e quindi crea. Attendere il completamento della distribuzione dell'insieme di credenziali delle chiavi. Verrà visualizzato il messaggio "La distribuzione è stata completata".

Passaggio 4: Configurare Service Connector

Nella barra di ricerca superiore digitare msdocs-tomcat-mysql, quindi la risorsa del servizio app denominata msdocs-tomcat-mysql-XYZ.
Nel menu a sinistra della pagina Servizio app selezionare Impostazioni > Service Connector. Esiste già un connettore, creato automaticamente dalla creazione guidata dell'app.
Selezionare la casella di controllo accanto al connettore, quindi selezionare Modifica.
Nella scheda Informazioni di base impostare Tipo client su Java.
Selezionare la scheda Autenticazione .
In Password incollare la password copiata in precedenza.
Selezionare Memorizza segreto in Key Vault.
In Connessione a Key Vault selezionare Crea nuovo. Viene aperta una finestra di dialogo Crea connessione nella parte superiore della finestra di dialogo di modifica.

Passaggio 5: Stabilire la connessione a Key Vault

Nella finestra di dialogo Crea connessione per la connessione a Key Vault, in Key Vault, selezionare il Key Vault creato in precedenza.
Seleziona Rivedi e Crea. Si noterà che l'identità gestita assegnata dal sistema è impostata su Selezionato.
Al termine della convalida, selezionare Crea.

Passaggio 6: Finalizzare la configurazione di Service Connector

Si torna alla finestra di dialogo di modifica per defaultConnector. Nella scheda Autenticazione attendere la creazione del connettore dell'insieme di credenziali delle chiavi. Al termine, l'elenco a discesa Connessione a Key Vault lo seleziona automaticamente.
Selezionare Avanti: Rete.
Selezionare Salva. Attendere che venga visualizzata la notifica Aggiornamento completato.

Passaggio 7: Verificare l'integrazione di Key Vault

Nel menu a sinistra selezionare di nuovo Impostazioni Variabili > di ambiente .
Accanto a AZURE_MYSQL_CONNECTIONSTRING selezionare Mostra valore. Il valore deve essere @Microsoft.KeyVault(...), il che significa che si tratta di un riferimento al key vault perché il segreto è ora gestito nel key vault.

Per riepilogare, il processo implica il recupero del stringa di connessione MySQL dalle variabili di ambiente del servizio app, la creazione di un insieme di credenziali delle chiavi di Azure per la gestione sicura dei segreti con accesso privato e l'aggiornamento del connettore di servizi per archiviare la password nell'insieme di credenziali delle chiavi. È stata stabilita una connessione sicura tra l'app servizio app e l'insieme di credenziali delle chiavi usando un'identità gestita assegnata dal sistema e la configurazione è stata verificata confermando che il stringa di connessione usa un riferimento a Key Vault.

Problemi? Controllare la sezione Risoluzione dei problemi.

4. Confermare l'origine dati JNDI

Se si aggiunge un'impostazione dell'app contenente una stringa di connessione JDBC valida per Oracle, SQL Server, PostgreSQL o MySQL, il servizio app aggiunge un'origine dati JNDI (Java Naming and Directory Interface) nel file context.xml del server Tomcat. In questo passaggio, si userà la connessione SSH al contenitore dell'app per verificare l'origine dati JNDI. Nel processo si apprenderà come accedere alla shell SSH per il contenitore Tomcat.

Passaggio 1: Tornare alla pagina Servizio app:

Nel menu a sinistra selezionare SSH.
Selezionare Vai.

Passaggio 2: Nel terminale SSH eseguire cat /usr/local/tomcat/conf/context.xml. Si noterà che è stata aggiunta una risorsa JNDI denominata jdbc/AZURE_MYSQL_CONNECTIONSTRING_DS. Questa origine dati verrà usata in un secondo momento.

Nota

Solo le modifiche apportate ai file in /home possono essere mantenute oltre i riavvii dell'app. Ad esempio, se si modifica /usr/local/tomcat/conf/server.xml, le modifiche non verranno mantenute se si riavvia l'app.

Problemi? Controllare la sezione Risoluzione dei problemi.

5. Distribuire il codice di esempio

In questo passaggio viene configurata la distribuzione di GitHub usando GitHub Actions. È solo uno dei molti modi per eseguire la distribuzione nel servizio app, ma anche un ottimo modo per avere l'integrazione continua nel processo di distribuzione. Per impostazione predefinita, ogni git push nel repository GitHub avvia l'azione di compilazione e distribuzione.

Analogamente alla convenzione Tomcat, se si vuole eseguire la distribuzione nel contesto radice di Tomcat, assegnare un nome all'artefatto predefinito ROOT.war.

Passaggio 1: Tornare alla pagina Servizio app, nel menu a sinistra, selezionare Centro distribuzione.

Passaggio 2: Nella pagina Centro distribuzione:

In Origine selezionare GitHub. Per impostazione predefinita, GitHub Actions è selezionato come provider di compilazione.
Accedere all'account GitHub e seguire la richiesta di autorizzare Azure.
In Organizzazione selezionare l'account.
In Repository selezionare msdocs-tomcat-mysql-sample-app.
In Ramo, selezionare starter-no-infra. Si tratta dello stesso ramo usato con l'app di esempio, senza file o configurazione correlati ad Azure.
Per Tipo di autenticazione selezionare Identità assegnata dall'utente.
Nel menu in alto selezionare Salva. Il servizio app esegue il commit di un file del flusso di lavoro nel repository GitHub scelto, nella directory .github/workflows. Per impostazione predefinita, il centro distribuzione crea un'identità assegnata dall'utente per l'autenticazione tramite Microsoft Entra (autenticazione OIDC). Per le opzioni di autenticazione alternative, vedere Distribuire su App Service usando GitHub Actions.

Passaggio 3: Tornare allo spazio di codice GitHub del fork di esempio, eseguire git pull origin starter-no-infra. In questo modo viene eseguito il pull del file del flusso di lavoro appena eseguito nel codespace.

Passaggio 4 (opzione 1: con GitHub Copilot):

Avviare una nuova sessione di chat facendo clic sulla visualizzazione Chat e quindi su +.
Chiedi, "@workspace Come si connette l'app al database?" Copilot potrebbe fornire qualche spiegazione sull'origine jdbc/MYSQLDS dei dati e su come è configurata.
Chiedere: "@workspace si vuole sostituire l'origine dati definita in persistence.xml con un'origine dati JNDI esistente in Tomcat, ma si vuole eseguire questa operazione in modo dinamico". Copilot potrebbe fornire un suggerimento di codice simile a quello dell'opzione 2: senza i passaggi di GitHub Copilot riportati di seguito e anche indicare di apportare la modifica nella classe ContextListener .
Aprire src/main/java/com/microsoft/azure/appservice/examples/tomcatmysql/ContextListener.java in Explorer e aggiungere il suggerimento del contextInitialized codice nel metodo . GitHub Copilot non offre la stessa risposta ogni volta, potrebbe essere necessario porre altre domande per ottimizzarla. Per ulteriori suggerimenti, vedere Cosa posso fare con GitHub Copilot nel mio spazio di codice?.

Passaggio 4 (opzione 2: senza GitHub Copilot):

Aprire src/main/java/com/microsoft/azure/appservice/examples/tomcatmysql/ContextListener.java in Explorer. All'avvio dell'applicazione, questa classe carica le impostazioni del database in src/main/resources/META-INF/persistence.xml.
Nel metodo contextIntialized(), trovare il codice commentato (righe 29-33) e rimuovere il commento. Questo codice verifica se l'impostazione dell'app AZURE_MYSQL_CONNECTIONSTRING esiste e modifica l'origine dati in java:comp/env/jdbc/AZURE_MYSQL_CONNECTIONSTRING_DS, ovvero l'origine dati trovata in precedenza in context.xml nella shell SSH.

Passaggio 5:

Selezionare l'estensione Controllo del codice sorgente .
Nella casella di testo digitare un messaggio di commit come Configure Azure data source.
Selezionare Commit e quindi confermare con Sì.
Selezionare Sincronizza modifiche 1, quindi confermare con OK.

Passaggio 6: Tornare alla pagina Centro distribuzione nel portale di Azure:

Selezionare Log. Una nuova esecuzione della distribuzione è già stata avviata dalle modifiche di cui è stato eseguito il commit.
Nell'elemento di log per l'esecuzione della distribuzione selezionare la voce Build/Deploy Logs con il timestamp più recente.

Passaggio 7: Si viene visualizzati nel repository GitHub e si noterà che l'azione GitHub è in esecuzione. Il file del flusso di lavoro definisce due fasi separate, compilare e distribuire. Attendere che l'esecuzione di GitHub mostri lo stato Completato. Ci vogliono circa 5 minuti.

Problemi? Controllare la sezione Risoluzione dei problemi.

6. Passare all'app

Passaggio 1: Nella pagina Servizio app:

Nel menu a sinistra selezionare Panoramica.
Selezionare l'URL dell'app.

Passaggio 2: Aggiungere alcune attività all'elenco. Si esegue un'app Web nel servizio app di Azure, con connettività sicura al Database di Azure per MySQL.

Problemi? Controllare la sezione Risoluzione dei problemi.

7. Eseguire lo streaming dei log di diagnostica

Il Servizio app di Azure acquisisce tutto l’output dei messaggi nella console per facilitare la diagnosi dei problemi con l'applicazione. L'applicazione di esempio include istruzioni di registrazione Log4j standard per illustrare questa funzionalità, come illustrato nel frammento di codice seguente:

@WebServlet(urlPatterns = "/")
public class ViewServlet extends HttpServlet {
    private static Logger logger = LogManager.getLogger(ViewServlet.class.getName());
    
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {

        logger.info("GET /");

        EntityManagerFactory emf = (EntityManagerFactory) req.getServletContext().getAttribute("EMFactory");

Passaggio 1: Nella pagina Servizio app:

Nel menu a sinistra, selezionare Log di Servizio app.
In Registrazione applicazioni selezionare File System.
Nel menu in alto selezionare Salva.

Passaggio 2: Nel menu a sinistra selezionare Flusso di log. Vengono visualizzati i log per l'app, inclusi i log e i log della piattaforma dall'interno del contenitore.

Per altre informazioni sulla registrazione nelle app Java, vedere la serie Abilitare OpenTelemetry di Monitoraggio di Azure per applicazioni .NET, Node.js, Python e Java.

Problemi? Controllare la sezione Risoluzione dei problemi.

8. Pulire le risorse

Al termine, è possibile eliminare tutte le risorse dalla sottoscrizione di Azure eliminando il gruppo di risorse.

Passaggio 1: Nella barra di ricerca nella parte superiore del portale di Azure:

Immettere il nome del gruppo di risorse.
Selezionare il gruppo di risorse.

Passaggio 2: Nella pagina del gruppo di risorse selezionare Elimina gruppo di risorse.

Passaggio 3:

Confermare l'eliminazione digitando il nome del gruppo di risorse.
Selezionare Elimina.
Confermare con Elimina di nuovo.

2. Creare risorse di Azure e distribuire un'app di esempio

In questo passaggio si creano le risorse di Azure e si distribuisce un'app di esempio nel servizio app in Linux. I passaggi usati in questa esercitazione creano un set di risorse sicure per impostazione predefinita che includono servizio app e Database di Azure per MySQL.

Il contenitore di sviluppo ha già la CLI degli sviluppatori di Azure (AZD).

Dalla radice del repository eseguire azd init.

azd init --template tomcat-app-service-mysql-infra

Quando richiesto, fornire le risposte seguenti:

Domanda	Risposta
La directory corrente non è vuota. Inizializzare un progetto qui in "<your-directory>"?	Y
Cosa vuoi fare con questi file?	Mantenere invariati i file esistenti
Immettere un nuovo nome di ambiente	Digitare un nome univoco. Il modello AZD usa questo nome come parte del nome DNS dell'app Web in Azure (`<app-name>-<hash>.azurewebsites.net`). Sono consentiti caratteri alfanumerici e trattini.

Accedere ad Azure eseguendo il comando azd auth login e seguendo il prompt:
```
azd auth login
```
Creare le risorse di Azure necessarie e distribuire il codice dell'app con il comando azd up. Seguire la richiesta di selezionare la sottoscrizione e il percorso desiderati per le risorse di Azure.
```
azd up
```
Il completamento del comando azd up richiede circa 15 minuti (la cache Redis richiede il tempo maggiore). Compila e distribuisce anche il codice dell'applicazione, ma si modifica il codice in un secondo momento per usarlo con servizio app. Durante l'esecuzione, il comando fornisce messaggi sul processo di provisioning e distribuzione, incluso un collegamento alla distribuzione in Azure. Al termine, il comando visualizza anche un collegamento all'applicazione di distribuzione.

Questo modello AZD contiene file (azure.yaml e la directory infra ) che generano un'architettura sicura per impostazione predefinita con le risorse di Azure seguenti:
- Gruppo di risorse: contenitore per tutte le risorse create.
- Piano di servizio app: definisce le risorse di calcolo per il servizio app. Viene creato un piano Linux nel livello B1 .
- App Service: rappresenta la tua app ed è in esecuzione nel piano di Servizio App.
- Rete virtuale: integrata con l'App Service e isola il traffico di rete interno.
- Server flessibile di Database di Azure per MySQL: accessibile solo dalla rete virtuale tramite l'integrazione della zona DNS. Nel server viene creato un database.
- Cache Redis di Azure: accessibile solo dall'interno della rete virtuale.
- Endpoint privati: accedere agli endpoint per l’insieme di credenziali delle chiavi e la cache Redis nella rete virtuale.
- Zone DNS privato: abilitare la risoluzione DNS dell'insieme di credenziali delle chiavi, del server di database e la cache Redis nella rete virtuale.
- Area di lavoro Log Analytics: funge da contenitore di destinazione per l'app per la spedizione dei log, in cui è anche possibile eseguire query sui log.
- Vault delle chiavi: Usato per mantenere invariata la password del database quando ridistribuisci con AZD.
Una volta che il comando ha terminato di creare le risorse e di distribuire il codice dell'applicazione per la prima volta, l'app di esempio distribuita non funziona ancora perché è necessario apportare alcune piccole modifiche per effettuare la connessione al database in Azure.

Problemi? Controllare la sezione Risoluzione dei problemi.

3. Verificare le stringhe di connessione

Il modello AZD che usi ha già generato le variabili di connettività come impostazioni dell'app e le stampa nel terminale per praticità. Le impostazioni dell'app sono un modo per mantenere i segreti di connessione all'esterno del repository di codice.

Nell'output AZD trovare l'impostazione dell'app AZURE_MYSQL_CONNECTIONSTRING. Vengono visualizzati solo i nomi delle impostazioni. L'output AZD è simile al seguente:
```
 App Service app has the following connection strings:
         - AZURE_MYSQL_CONNECTIONSTRING
         - AZURE_REDIS_CONNECTIONSTRING
         - AZURE_KEYVAULT_RESOURCEENDPOINT
         - AZURE_KEYVAULT_SCOPE
 
```
AZURE_MYSQL_CONNECTIONSTRING contiene la stringa di connessione al database MySQL in Azure. È necessario usarla nel codice in un secondo momento.
Per praticità, il modello AZD mostra il collegamento diretto alla pagina delle impostazioni dell'app. Trovare il collegamento e aprirlo in una nuova scheda del browser.

Se si aggiunge un'impostazione dell'app contenente una stringa di connessione Oracle, SQL Server, PostgreSQL o MySQL valida, il servizio app lo aggiunge come origine dati JNDI (Java Naming and Directory Interface) nel file dicontext.xml del server Tomcat.

Problemi? Controllare la sezione Risoluzione dei problemi.

4. Confermare l'origine dati JNDI

In questo passaggio si usa la connessione SSH al contenitore dell'app per verificare l'origine dati JNDI nel server Tomcat. Nel processo si apprenderà come accedere alla shell SSH per il contenitore Tomcat.

Nell'output AZD trovare l'URL per la sessione SSH e passarvi nel browser. L'output è simile al seguente:
```
 Open SSH session to App Service container at: <URL>
 
```
Nel terminale SSH eseguire cat /usr/local/tomcat/conf/context.xml. Si noterà che è stata aggiunta una risorsa JNDI denominata jdbc/AZURE_MYSQL_CONNECTIONSTRING_DS. Questa origine dati verrà usata in un secondo momento.

Nota

Problemi? Controllare la sezione Risoluzione dei problemi.

5. Modificare il codice di esempio e ridistribuire

Con GitHub Copilot
Senza GitHub Copilot

Nello spazio di codice GitHub avviare una nuova sessione di chat facendo clic sulla visualizzazione Chat e quindi facendo clic su +.
Chiedi, "@workspace Come si connette l'app al database?" Copilot potrebbe fornire qualche spiegazione sull'origine jdbc/MYSQLDS dei dati e su come è configurata.
Chiedere: "@workspace si vuole sostituire l'origine dati definita in persistence.xml con un'origine dati JNDI esistente in Tomcat, ma si vuole eseguire questa operazione in modo dinamico". Copilot potrebbe fornire un suggerimento di codice simile a quello dell'opzione 2: senza i passaggi di GitHub Copilot riportati di seguito e anche indicare di apportare la modifica nella classe ContextListener .
Aprire src/main/java/com/microsoft/azure/appservice/examples/tomcatmysql/ContextListener.java in Explorer e aggiungere il suggerimento del contextInitialized codice nel metodo .

GitHub Copilot non offre la stessa risposta ogni volta, potrebbe essere necessario porre altre domande per ottimizzarla. Per ulteriori suggerimenti, vedere Cosa posso fare con GitHub Copilot nel mio spazio di codice?.
Nel terminale codespace eseguire azd deploy.
```
azd deploy
```

Da Explorer aprire src/main/java/com/microsoft/azure/appservice/examples/tomcatmysql/ContextListener.java. All'avvio dell'applicazione, questa classe carica le impostazioni del database in src/main/resources/META-INF/persistence.xml.
Nel metodo contextIntialized(), trovare il codice commentato (righe 29-33) e rimuovere il commento.
```
String azureDbUrl= System.getenv("AZURE_MYSQL_CONNECTIONSTRING");
if (azureDbUrl!=null) {
    logger.info("Detected Azure MySQL connection string. Adding Tomcat data source...");
    props.put("jakarta.persistence.nonJtaDataSource", "java:comp/env/jdbc/AZURE_MYSQL_CONNECTIONSTRING_DS");
}
```
Questo codice verifica se l'impostazione dell'app AZURE_MYSQL_CONNECTIONSTRING esiste e modifica l'origine dati in java:comp/env/jdbc/AZURE_MYSQL_CONNECTIONSTRING_DS, ovvero l'origine dati trovata in precedenza in context.xml nella shell SSH.
Di nuovo nel terminale codespace eseguire azd deploy.
```
azd deploy
```

Suggerimento

È anche possibile usare sempre e solo azd up, che esegue tutte le operazioni di azd package, azd provision e azd deploy.

Per scoprire come viene creato il pacchetto del file War, è possibile eseguire azd package --debug da sé.

Problemi? Controllare la sezione Risoluzione dei problemi.

6. Passare all'app

Nell'output AZD trovare l'URL dell'app e passarvi nel browser. L'URL è simile al seguente nell'output AZD:
```
 Deploying services (azd deploy)

   (✓) Done: Deploying service web
   - Endpoint: <URL>
 
```
Aggiungere alcune attività all'elenco.

Si esegue un'app Web nel servizio app di Azure, con connettività sicura al Database di Azure per MySQL.

Problemi? Controllare la sezione Risoluzione dei problemi.

7. Eseguire lo streaming dei log di diagnostica

Il servizio app di Azure può acquisire i log della console per diagnosticare i problemi relativi all'applicazione. Per praticità, il modello AZD ha già abilitato la registrazione nel file system locale e i log vengono distribuiti a un'area di lavoro Log Analytics.

L'applicazione di esempio include istruzioni di registrazione Log4j standard per illustrare questa funzionalità, come illustrato nel frammento di codice seguente:

@WebServlet(urlPatterns = "/")
public class ViewServlet extends HttpServlet {
    private static Logger logger = LogManager.getLogger(ViewServlet.class.getName());
    
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {

        logger.info("GET /");

        EntityManagerFactory emf = (EntityManagerFactory) req.getServletContext().getAttribute("EMFactory");

Nell'output AZD trovare il collegamento per trasmettere i log del servizio app e passarvi nel browser. Il collegamento è simile al seguente nell'output AZD:

Stream App Service logs at: <URL>

Per altre informazioni sulla registrazione nelle app Java, vedere la serie Abilitare OpenTelemetry di Monitoraggio di Azure per applicazioni .NET, Node.js, Python e Java.

Problemi? Controllare la sezione Risoluzione dei problemi.

8. Pulire le risorse

Per eliminare tutte le risorse di Azure nell'ambiente di distribuzione corrente, eseguire azd down e seguire le istruzioni.

azd down

Risoluzione dei problemi

Si vedono molte <Classi> analizzate da più avvertenze di posizioni con mvn jetty:run
La visualizzazione della distribuzione del portale per il server flessibile di Database di Azure per MySQL mostra uno stato di conflitto
L'app di esempio distribuita non mostra l'app elenco attività
Viene visualizzato un errore di pagina 404 non trovato nell'app di esempio distribuita

Si vedono molte <Classi> analizzate da più posizioni con mvn jetty:run

È possibile ignorare gli avvisi. Il plug-in Maven Jetty mostra gli avvisi perché pom.xml dell'app contiene la dipendenza per jakarta.servlet.jsp.jstl, che Jetty fornisce già di default. La dipendenza è necessaria per Tomcat.

La visualizzazione distribuzione del portale per il server flessibile di Database di Azure per MySQL mostra uno stato di conflitto

A seconda della sottoscrizione e dell'area selezionata, è possibile che lo stato della distribuzione per il server flessibile di Database di Azure per MySQL sia Conflict, con il messaggio seguente in Dettagli operazione:

InternalServerError: An unexpected error occurred while processing the request.

Questo errore è probabilmente causato da un limite per la sottoscrizione per l'area selezionata. Provare a scegliere un'area diversa per la distribuzione.

L'app di esempio distribuita non mostra l'elenco di attività

Se viene visualizzata una pagina Hey, Java developers! anziché l'app elenco attività, probabilmente il servizio app sta ancora caricando il contenitore aggiornato dalla distribuzione del codice più recente. Attendere alcuni minuti e aggiornare la pagina.

Viene visualizzato un errore 404 Pagina non trovata nell'app di esempio distribuita

Assicurarsi di aver apportato le modifiche al codice per usare l'origine dati java:comp/env/jdbc/AZURE_MYSQL_CONNECTIONSTRING_DS. Se sono state apportate modifiche ed è stato ridistribuito il codice, il servizio app probabilmente sta ancora caricando il contenitore aggiornato. Attendere alcuni minuti e aggiornare la pagina.

Domande frequenti

Quanto costa questa configurazione?
Come ci si connette al server MySQL dietro la rete virtuale con altri strumenti?
Come funziona lo sviluppo di app locali con GitHub Actions?
Non si dispone delle autorizzazioni per creare un'identità assegnata dall'utente
Cosa è possibile fare con GitHub Copilot nello spazio di codice?

Quanto costa questa configurazione?

I prezzi per le risorse create sono i seguenti:

Il piano di servizio app viene creato nel livello Basic e può essere ridimensionato verso l'alto o verso il basso. Vedere Prezzi del servizio app.
Il server flessibile MySQL viene creato nel livello B1ms e può essere ridimensionato verso l'alto o verso il basso. Con un account gratuito di Azure, il livello B1ms è gratuito per 12 mesi, fino ai limiti mensili. Consulta i prezzi di Azure Database per MySQL.
La Cache Redis di Azure è creata nel livello Basic con la dimensione minima della cache. È previsto un costo ridotto associato a questo livello. È possibile aumentare le prestazioni fino a livelli di prestazioni superiori per disponibilità, clustering e altre funzionalità più elevate. Vedi i prezzi di Azure Cache per Redis.
La rete virtuale non comporta alcun addebito a meno che non si configurino funzionalità aggiuntive, ad esempio il peering. Vedere Prezzi della rete virtuale di Azure.
La zona DNS privata comporta un piccolo addebito. Vedere Prezzi di DNS di Azure.

Come connettersi al server MySQL dietro la rete virtuale con altri strumenti?

Anche il contenitore Tomcat non dispone attualmente del terminale mysql-client. Se lo si desidera, è necessario installarlo manualmente. Tenere presente che tutto ciò che si installa non persiste tra i riavvii dell'app.
Per connettersi da uno strumento desktop come MySQL Workbench, il computer deve trovarsi all'interno della rete virtuale. Ad esempio, potrebbe trattarsi di una macchina virtuale di Azure in una delle subnet o di un computer in una rete locale con una connessione VPN da sito a sito con la rete virtuale di Azure.
È anche possibile integrare Azure Cloud Shell con la rete virtuale.

Come funziona lo sviluppo di app locali con GitHub Actions?

Quando si usa il file del flusso di lavoro generato automaticamente dal Servizio app come esempio, ogni git push avvia una nuova esecuzione della compilazione e della distribuzione. Da un clone locale del repository GitHub si effettua il push degli aggiornamenti desiderati in GitHub. Ad esempio:

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

Non si dispone delle autorizzazioni per creare un'identità assegnata dall'utente

Vedere Configurare la distribuzione di GitHub Actions dal Centro distribuzione.

Cosa è possibile fare con GitHub Copilot nel codespace?

Si potrebbe aver notato che la visualizzazione chat di GitHub Copilot era già presente quando è stato creato il codespace. Per praticità, includiamo l'estensione di chat di GitHub Copilot nella definizione del contenitore (vedere .devcontainer/devcontainer.json). Tuttavia, è necessario un account GitHub Copilot (disponibile una versione di valutazione gratuita di 30 giorni).

Alcuni suggerimenti per l'utente quando si parla con GitHub Copilot:

In una singola sessione di chat, le domande e le risposte si basano l'una sull'altra e puoi regolare le tue domande per ottimizzare la risposta che ottieni.
Per impostazione predefinita, GitHub Copilot non ha accesso ad alcun file nel repository. Per porre domande su un file, aprire prima il file nell'editor.
Per consentire a GitHub Copilot di accedere a tutti i file nel repository quando si preparano le risposte, iniziare la domanda con @workspace. Per ulteriori informazioni, vedere Use the @workspace agent.
Nella sessione di chat, GitHub Copilot può suggerire modifiche e (con @workspace) anche dove apportare le modifiche, ma non è consentito apportare le modifiche. È necessario aggiungere le modifiche suggerite e testarle.

Ecco alcune altre cose che puoi dire per ottimizzare la risposta che ottieni:

Cambiare questo codice per usare l'origine dati jdbc/AZURE_MYSQL_CONNECTIONSTRING_DS.
Alcune importazioni nel codice usano javax, ma si dispone di un'app Jakarta.
Si vuole che questo codice venga eseguito solo se è impostata la variabile di ambiente AZURE_MYSQL_CONNECTIONSTRING.
Si vuole che questo codice venga eseguito solo nel servizio app di Azure e non in locale.

Passaggi successivi

Azure per sviluppatori Java

Altre informazioni sull'esecuzione di app Java nel Servizio app sono disponibili nella Guida per gli sviluppatori.

Configurare un'app Java nel servizio app di Azure

Informazioni su come proteggere l'app con un dominio e un certificato personalizzati.

Proteggere con dominio e certificato personalizzati

Condividi tramite

Esercitazione: Creare un'app Web Tomcat con il Servizio app di Azure in Linux e MySQL

Prerequisiti

Passare alla fine

1. Eseguire l'esempio

2. Creare il servizio app e MySQL

3. Proteggere i segreti di connessione

4. Confermare l'origine dati JNDI

5. Distribuire il codice di esempio

6. Passare all'app

7. Eseguire lo streaming dei log di diagnostica

8. Pulire le risorse

2. Creare risorse di Azure e distribuire un'app di esempio

3. Verificare le stringhe di connessione

4. Confermare l'origine dati JNDI

5. Modificare il codice di esempio e ridistribuire

6. Passare all'app

7. Eseguire lo streaming dei log di diagnostica

8. Pulire le risorse

Risoluzione dei problemi

Si vedono molte <Classi> analizzate da più posizioni con mvn jetty:run

La visualizzazione distribuzione del portale per il server flessibile di Database di Azure per MySQL mostra uno stato di conflitto

L'app di esempio distribuita non mostra l'elenco di attività

Viene visualizzato un errore 404 Pagina non trovata nell'app di esempio distribuita

Domande frequenti

Quanto costa questa configurazione?

Come connettersi al server MySQL dietro la rete virtuale con altri strumenti?

Come funziona lo sviluppo di app locali con GitHub Actions?

Non si dispone delle autorizzazioni per creare un'identità assegnata dall'utente

Cosa è possibile fare con GitHub Copilot nel codespace?

Passaggi successivi

Commenti e suggerimenti

Risorse aggiuntive