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

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, sarà 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.
  • Accedi alle impostazioni dell'app del 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.
  • Azure Developer CLI installata. È possibile seguire la procedura con Azure Cloud Shell perché è già installata Azure Developer CLI.
  • 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.

Passare alla fine

È possibile distribuire rapidamente l'app di esempio in questa esercitazione e visualizzarla in esecuzione in Azure. 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 praticità, il repository di esempio include una configurazione del contenitore di sviluppo. 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 un codespace GitHub, il che significa che è possibile eseguire l'esempio in qualsiasi computer con un Web browser.

Passaggio 1: in una nuova finestra del browser:

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

Screenshot che mostra come creare un fork del repository GitHub di esempio.

Passaggio 2: Nel fork di GitHub:

  1. 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.
  2. Selezionare Codice>Creare codespace in starter-no-infra. La configurazione del codespace richiede alcuni minuti.

Screenshot che mostra come creare un codespace in GitHub.

Passaggio 3: Nel terminale codespace:

  1. Eseguire mvn jetty:run.
  2. 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.

Screenshot che mostra come eseguire l'applicazione di esempio all'interno del codespace GitHub.

Suggerimento

È possibile chiedere a GitHub Copilotinformazioni 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 per l'app sotto forma di https://<app-name>-<hash>.<region>.azurewebsites.net.
  • Area in cui eseguire l'app fisicamente nel mondo. Viene usato anche come parte del nome DNS per l'app.
  • 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.

Per creare risorse del Servizio app di Azure, accedere al portale di Azure e seguire questa procedura.

Passaggio 1: nel portale di Azure:

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

Screenshot che mostra come usare la casella di ricerca nella barra degli strumenti superiore per trovare la creazione guidata di App Web e database.

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

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

Screenshot che mostra come configurare una nuova app e un nuovo database nella procedura guidata App Web e database.

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.
  • Servizio app: rappresenta l'app ed è in esecuzione nel piano di servizio app.
  • Rete virtuale: integrata con l'app del servizio app e isola il traffico di rete back-end.
  • 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.

Screenshot che mostra il processo di distribuzione completato.

Problemi? Controllare la sezione Risoluzione dei problemi.

3. Proteggere i segreti di connessione

La creazione guidata ha generato la stringa di connettività già 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. Si sposteranno i segreti in un insieme di credenziali delle chiavi e si cambierà l'impostazione dell'app in un riferimento Key Vault con l'aiuto dei Connettori di servizi.

Passaggio 1: nella pagina Servizio app:

  1. Nel menu a sinistra selezionare Impostazioni > Variabili di ambiente.
  2. 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 la inserisce come origine dati JNDI (Java Naming and Directory Interface) nel file context.xml del server Tomcat.
  3. IN Aggiungi/Modifica impostazione applicazione, nel campo Valore, trovare la sezione password= alla fine della stringa.
  4. 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.

Screenshot che mostra come visualizzare il valore di un'impostazione dell'app.

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

  1. Nella barra di ricerca superiore digitare "insieme di credenziali delle chiavi", quindi selezionare Marketplace>Key Vault.
  2. In Gruppo di risorse, selezionare msdocs-tomcat-mysql-tutorial.
  3. In Nome insieme di credenziali delle chiavi digitare un nome costituito solo da lettere e numeri.
  4. In Area, impostarlo sul percorso di esempio come gruppo di risorse.

Screenshot che mostra come creare un insieme di credenziali delle chiavi.

Passaggio 3:

  1. Selezionare la scheda Rete.
  2. Deselezionare Abilita l'accesso pubblico.
  3. Selezionare Creare un endpoint privato.
  4. In Gruppo di risorse, selezionare msdocs-tomcat-mysql-tutorial.
  5. In Nome insieme di credenziali delle chiavi digitare un nome costituito solo da lettere e numeri.
  6. In Area, impostarlo sul percorso di esempio come gruppo di risorse.
  7. Nella finestra di dialogo, in Località, selezionare la stessa posizione dell'app del servizio app.
  8. In Gruppo di risorse, selezionare msdocs-tomcat-mysql-tutorial.
  9. In Nome, digitare msdocs-tomcat-mysql-XYZVaultEndpoint.
  10. In Rete virtuale, selezionare msdocs-tomcat-mysql-XYZVnet.
  11. In Subnet, msdocs-tomcat-mysql-XYZSubnet.
  12. Seleziona OK.
  13. 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".

Screenshot che mostra come proteggere un insieme di credenziali delle chiavi con un endpoint privato.

Passaggio 4:

  1. Nella barra di ricerca superiore, digitare msdocs-tomcat-mysql, quindi la risorsa del Servizio app denominata msdocs-tomcat-mysql-XYZ.
  2. Nel menu a sinistra della pagina Servizio app selezionare Impostazioni > Connettore di servizi. Esiste già un connettore, creato automaticamente dalla creazione guidata dell'app.
  3. Selezionare la casella di controllo accanto al connettore, quindi selezionare Modifica.
  4. Nella scheda Dati principali, impostare Tipo client su SpringBoot.
  5. Seleziona la scheda Autenticazione.
  6. In Password, incollare la password copiata in precedenza.
  7. Selezionare Archivia segreto in Key Vault.
  8. 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.

Screenshot che mostra come modificare un connettore di servizi con una connessione dell'insieme di credenziali delle chiavi.

Passaggio 5: Nella finestra di dialogo Crea connessione per la connessione a Key Vault:

  1. In Key Vault, selezionare l'insieme di credenziali delle chiavi creato in precedenza.
  2. Selezionare Rivedi e crea. Si noterà che l'identità gestita assegnata dal sistema è impostata su Selezionata.
  3. Al termine della convalida selezionare Crea.

Screenshot che mostra come configurare un connettore di servizi dell'insieme di credenziali delle chiavi.

Passaggio 6: Si torna alla finestra di dialogo di modifica per defaultConnector.

  1. 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.
  2. Selezionare Avanti: Rete.
  3. Seleziona Salva. Attendere che venga visualizzata la notifica Aggiornamento completato.

Screenshot che mostra la connessione dell'insieme di credenziali delle chiavi selezionata in defaultConnector.

Passaggio 7: per verificare le modifiche:

  1. Nel menu a sinistra selezionare di nuovo Variabili di ambiente > Stringhe di connessione.
  2. Accanto a AZURE_MYSQL_CONNECTIONSTRING, selezionare Mostra valore. Il valore deve essere @Microsoft.KeyVault(...), il che significa che si tratta di un riferimento all'insieme di credenziali delle chiavi perché il segreto è ora gestito nell'insieme di credenziali delle chiavi.

Screenshot che mostra come visualizzare il valore della variabile di ambiente MYSQL in Azure.

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:

  1. Nel menu a sinistra selezionare SSH.
  2. Selezionare Vai.

Screenshot che mostra come aprire la shell SSH per l'app dal portale di Azure.

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.

Screenshot che mostra i comandi da eseguire nella shell SSH e il relativo output.

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 compilato ROOT.war.

Passaggio 1: Di nuovo nella pagina Servizio app, nel menu a sinistra selezionare Centro distribuzione.

Screenshot che mostra come aprire il Centro distribuzione nel servizio app.

Passaggio 2: nella pagina Centro distribuzione:

  1. In Origine, selezionare GitHub. Per impostazione predefinita, GitHub Actions è selezionato come provider di compilazione.
  2. Accedere all'account GitHub e seguire la richiesta di autorizzare Azure.
  3. In Organizzazione selezionare l'account.
  4. In Repository selezionare msdocs-tomcat-mysql-sample-app.
  5. In Ramo, selezionare starter-no-infra. Si tratta dello stesso ramo usato con l'app di esempio, senza file o configurazione correlati ad Azure.
  6. Per Tipo di autenticazione, selezionare Identità assegnata dall'utente.
  7. 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 nel servizio app usando GitHub Actions.

Screenshot che mostra come configurare CI/CD con GitHub Actions.

Passaggio 3: tornare nel codespace 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.

Screenshot che mostra il pull git all'interno di un codespace GitHub.

Passaggio 4 (opzione 1: con GitHub Copilot):

  1. Avviare una nuova sessione di chat facendo clic sulla visualizzazione Chat e quindi su +.
  2. Chiedere "@workspace Come si connette l'app al database e alla cache?" Copilot potrebbe fornire una spiegazione sull'origine dati jdbc/MYSQLDS e su come è configurata.
  3. Chiedere "@workspace Voglio sostituire l'origine dati definita in persistence.xml con un'origine dati JNDI esistente in Tomcat, ma voglio farlo 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.
  4. Aprire src/main/java/com/microsoft/azure/appservice/examples/tomcatmysql/ContextListener.java in Explorer e aggiungere il suggerimento del codice nel metodo contextInitialized. GitHub Copilot non offre la stessa risposta ogni volta, potrebbe essere necessario porre altre domande per ottimizzarla. Per suggerimenti, vedere Cosa è possibile fare con GitHub Copilot nel codespace?.

Screenshot che mostra come porre una domanda in una nuova sessione di chat di GitHub Copilot.

Passaggio 4 (opzione 2: senza GitHub Copilot):

  1. 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.
  2. 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.

Screenshot che mostra un codespace GitHub e il file ContextListener.java aperto.

Passaggio 5:

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

Screenshot che mostra le modifiche di cui è stato eseguito il commit e il push in GitHub.

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

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

Screenshot che mostra come aprire i log di distribuzione nel Centro distribuzione.

Passaggio 7: Si viene portati 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 visualizzi lo stato Operazione completata. Ci vogliono circa 5 minuti.

Screenshot che mostra un'esecuzione di GitHub in corso.

Problemi? Controllare la sezione Risoluzione dei problemi.

6. Passare all'app

Passaggio 1: Nella pagina Servizio app:

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

Screenshot che mostra come avviare un servizio app dal portale di Azure.

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.

Screenshot dell'app Web Tomcat con MySQL in esecuzione in Azure.

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:

  1. Nel menu a sinistra selezionare Log di servizio app.
  2. In Application Logging, selezionare File System.
  3. Nel menu in alto, selezionare Salva.

Screenshot che mostra come abilitare i log nativi nel servizio app nel portale di Azure.

Passaggio 2: dal 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.

Screenshot che mostra come visualizzare il flusso di log nel portale di Azure.

Altre informazioni sulla registrazione nelle app Java nella serie abilitare OpenTelemetry di Monitoraggio di Azure per .NET, Node.js, Python e Applicazioni 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:

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

Screenshot che illustra come cercare e passare a un gruppo di risorse nel portale di Azure.

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

Screenshot che mostra la posizione del pulsante

Passaggio 3:

  1. Confermare l'eliminazione digitando il nome del gruppo di risorse.
  2. Selezionare Elimina.
  3. Confermare nuovamente con Elimina.

Screenshot della finestra di dialogo di conferma per l’eliminazione di un gruppo di risorse nel portale di Azure.

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à l'interfaccia della Azure Developer CLI (AZD).

  1. Dalla radice del repository eseguire azd init.

    azd init --template tomcat-app-service-mysql-infra
    
  2. 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.
  3. Accedere ad Azure eseguendo il comando azd auth login e seguendo il prompt:

    azd auth login
    
  4. 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 il codice verrà modificato in un secondo momento per funzionare con il 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.
    • Servizio app: rappresenta l'app ed è in esecuzione nel piano di servizio app.
    • Rete virtuale: integrata con l'app del servizio app e isola il traffico di rete back-end.
    • 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 di Azure per Redis: 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 che spedisce i log e permette anche di eseguire query sui log.
    • Insieme di credenziali delle chiavi: usato per mantenere uguale la password del database quando si ridistribuisce 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 usato ha generato le variabili di connettività già come impostazioni dell'app e li restituisce al terminale per praticità. Le impostazioni dell'app sono un modo per mantenere i segreti di connessione all'esterno del repository di codice.

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

  2. 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 la aggiunge come origine dati JNDI (Java Naming and Directory Interface) nel file context.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.

  1. 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: https://<app-name>-<hash>.scm.azurewebsites.net/webssh/host
     
  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.

    Screenshot che mostra i comandi da eseguire nella shell SSH e il relativo output.

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. Modificare il codice di esempio e ridistribuire

  1. Nel codespace GitHub avviare una nuova sessione di chat facendo clic sulla visualizzazione Chat e quindi facendo clic su +.

  2. Chiedere "@workspace Come si connette l'app al database e alla cache?" Copilot potrebbe fornire una spiegazione sull'origine dati jdbc/MYSQLDS e su come è configurata.

  3. Chiedere "@workspace Voglio sostituire l'origine dati definita in persistence.xml con un'origine dati JNDI esistente in Tomcat, ma voglio farlo in modo dinamico." Copilot potrebbe fornire un suggerimento di codice simile a quello nei passaggi dell'Opzione 2: senza GitHub Copilot descritti di seguito e anche indicare di apportare la modifica nella classe ContextListener.

  4. Aprire src/main/java/com/microsoft/azure/appservice/examples/tomcatmysql/ContextListener.java in Explorer e aggiungere il suggerimento del codice nel metodo contextInitialized.

    GitHub Copilot non offre la stessa risposta ogni volta, potrebbe essere necessario porre altre domande per ottimizzarla. Per suggerimenti, vedere Cosa è possibile fare con GitHub Copilot nel codespace?.

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

  1. 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: https://<app-name>-<hash>.azurewebsites.net/
     
  2. Aggiungere alcune attività all'elenco.

    Screenshot dell'app Web Tomcat con MySQL in esecuzione in Azure che mostra attività.

    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: https://portal.azure.com/#@/resource/subscriptions/<subscription-guid>/resourceGroups/<group-name>/providers/Microsoft.Web/sites/<app-name>/logStream

Altre informazioni sulla registrazione nelle app Java nella serie abilitare OpenTelemetry di Monitoraggio di Azure per .NET, Node.js, Python e Applicazioni 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ù posizioni con mvn jetty:run

È possibile ignorare gli avvisi. Il plug-in Maven Jetty mostra gli avvisi perché il file pom.xml dell'app contiene la dipendenza per jakarta.servlet.jsp.jstl, che Jetty fornisce già in modo predefinito. 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 occured 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?

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 ed è possibile aumentarne o ridurne le prestazioni. Con un account gratuito di Azure, il livello B1ms è gratuito per 12 mesi, fino ai limiti mensili. Vedere Prezzi di Database di Azure per MySQL.
  • Cache Redis di Azure viene creata nel livello Basic con le dimensioni minime 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. Vedere Prezzi di cache di Azure 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

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

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

 Proteggere con dominio personalizzato e certificato di protezione