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

• Un account Azure con una sottoscrizione attiva. Se non si ha un account Azure, è possibile crearne uno gratuitamente.
• Un account GitHub. è anche possibile ottenerne 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.
• 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.

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.

Problemi? Controllare la sezione Risoluzione dei problemi.

3. Proteggere i segreti di connessione

La creazione guidata ha generato la stringa di connettività del database già come impostazione dell'app. Tuttavia, le procedure consigliate in materia di sicurezza prevedono di tenere i segreti completamente al di fuori del Servizio app. È possibile spostare i segreti in un insieme di credenziali delle chiavi e modificare l'impostazione dell'app in un riferimento a Key Vault con l'aiuto di Service Connectors.

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.

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.

Problemi? Controllare la sezione Risoluzione dei problemi.

6. Passare all'app

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

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.

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 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.
   • 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.
   • Database di Azure per MySQL server flessibile: 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.

   

Problemi? Controllare la sezione Risoluzione dei problemi.

5. Modificare il codice di esempio e ridistribuire

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.

   

   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