Condividi tramite

Esercitazione: distribuire un'app ASP.NET Core con database SQL di Azure nel servizio app di Azure

  • Articolo

Questa esercitazione illustra come distribuire un'app basata sui dati ASP.NET Core nel servizio app di Azure e connettersi a un database SQL di Azure. Si distribuirà anche una Cache Redis di Azure per abilitare il codice di memorizzazione nella cache nell'applicazione. Il servizio app di Azure è un servizio di hosting Web altamente scalabile e scalabile che può distribuire facilmente app in Windows o Linux. Anche se questa esercitazione usa un'app ASP.NET Core 8.0, il processo è lo stesso per altre versioni di ASP.NET Core.

In questa esercitazione apprenderai a:

  • Creare un'architettura di cache redis, database SQL e servizio app sicura per impostazione predefinita.
  • Proteggere i segreti di connessione usando un'identità gestita e riferimenti a Key Vault.
  • Distribuire un'app di esempio ASP.NET Core nel servizio app da un repository GitHub.
  • Accedi alle stringhe di connessione del servizio app nel codice dell'applicazione.
  • Apportare aggiornamenti e ridistribuire il codice dell'applicazione.
  • Generare lo schema del database caricando un pacchetto delle migrazioni.
  • Eseguire lo streaming dei log di diagnostica in Azure.
  • 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 dello sviluppo di ASP.NET Core.
  • (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:

dotnet tool install --global dotnet-ef
mkdir msdocs-app-service-sqldb-dotnetcore
cd msdocs-app-service-sqldb-dotnetcore
azd init --template msdocs-app-service-sqldb-dotnetcore
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-app-service-sqldb-dotnetcore/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 le migrazioni del database con dotnet ef database update.
  2. Eseguire l'app con dotnet run.
  3. Quando viene visualizzata la notifica Your application running on port 5093 is available., selezionare Apri nel browser. L'applicazione di esempio dovrebbe essere visualizzata in una nuova scheda del browser. Per arrestare l'applicazione, 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 servizio app, database e cache

In questo passaggio si creano le risorse di Azure. I passaggi usati in questa esercitazione creano un set di risorse sicure per impostazione predefinita che includono servizio app, database SQL di Azure e Cache di Azure. Per il processo di creazione, specificare:

  • 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 .NET 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-core-sql-tutorial.
  2. Area: qualunque area di Azure nelle vicinanze.
  3. Nome: msdocs-core-sql-XYZ dove XYZ è costituito da tre caratteri casuali. Il nome deve essere univoco in Azure
  4. Stack di runtime: .NET 8 (LTS).
  5. Motore: SQLAzure. Il database SQL di Azure è un motore di database PaaS (Platform as a Service) completamente gestito che è sempre in esecuzione nella versione stabile più recente di SQL Server.
  6. Aggiungere la cache di Azure per Redis?: Sì.
  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.
  • Endpoint privati: accedere agli endpoint per l'insieme di credenziali delle chiavi, il server di database e la cache Redis nella rete virtuale.
  • Interfacce di rete: rappresenta gli indirizzi IP privati, uno per ognuno degli endpoint privati.
  • Server di database SQL di Azure: accessibile solo da dietro l'endpoint privato.
  • Database SQL di Azure: un database e un utente vengono creati automaticamente nel server.
  • Cache Redis di Azure: accessibile solo da dietro l'endpoint privato.
  • Insieme di credenziali delle chiavi: accessibile solo da dietro l'endpoint privato. Usato per gestire i segreti per l'app del servizio app.
  • Zone DNS privato: abilitare la risoluzione DNS dell'insieme di credenziali delle chiavi, del server di database e la cache Redis nella rete virtuale.

Screenshot che mostra il processo di distribuzione completato.

3. Proteggere i segreti di connessione

La creazione guidata ha generato la stringa di connettività già come stringhe di connessione .NET e impostazioni 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 riferimenti Key Vault con l'aiuto dei Connettori di servizi.

Suggerimento

Per usare l’autenticazione senza password, vedere Come modificare la connessione al database SQL in modo che usi invece un'identità gestita?

Passaggio 1: nella pagina Servizio app:

  1. Nel menu a sinistra selezionare Impostazioni> Variabili di ambiente > Stringhe di connessione.
  2. Selezionare AZURE_SQL_CONNECTIONSTRING.
  3. Nel campo Valore della stringa di connessione Aggiungi/Modifica trovare la parte Password= alla fine della stringa.
  4. Copiare la stringa della password dopo Password= per usarla in un secondo momento. Questa stringa di connessione consente di connettersi al database SQL protetto dietro un endpoint privato. Le password sono salvate direttamente nell'app del Servizio app, che non è la cosa migliore. Analogamente, la stringa di connessione della cache Redis nella scheda Impostazioni app contiene un segreto. 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-core-sql-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-core-sql-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-core-sql-tutorial.
  9. In Nome, digitare msdocs-core-sql-XYZVvaultEndpoint.
  10. In Rete virtuale selezionare msdocs-core-sql-XYZVnet.
  11. In Subnet, msdocs-core-sql-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-core-sql, quindi la risorsa del Servizio app denominata msdocs-core-sql-XYZ.
  2. Nel menu a sinistra della pagina Servizio app selezionare Impostazioni > Connettore di servizi. Esistono già due connettori, creati automaticamente dalla creazione guidata dell'app.
  3. Selezionare la casella di controllo accanto al connettore Database SQL, quindi selezionare Modifica.
  4. Seleziona la scheda Autenticazione.
  5. In Password, incollare la password copiata in precedenza.
  6. Selezionare Archivia segreto in Key Vault.
  7. 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 Database SQL 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 creare un connettore di servizi di Key Vault.

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. Selezionare Configura regole del firewall per abilitare l'accesso al servizio di destinazione. La creazione guidata dell'app ha già protetto il database SQL con un endpoint privato.
  4. Seleziona Salva. Attendere che venga visualizzata la notifica Aggiornamento completato.

Screenshot che mostra la connessione dell'insieme di credenziali delle chiavi selezionata nel connettore del servizio di database SQL.

Passaggio 7: Nella pagina Connettori di servizio:

  1. Selezionare la casella di controllo accanto al connettore Cache for Redis e quindi selezionare Modifica.
  2. Seleziona la scheda Autenticazione.
  3. Selezionare Archivia segreto in Key Vault.
  4. In Connessione a Key Vault selezionare l'insieme di credenziali delle chiavi creato.
  5. Selezionare Avanti: Rete.
  6. Selezionare Configura regole del firewall per abilitare l'accesso al servizio di destinazione. La creazione guidata dell'app ha già protetto il database SQL con un endpoint privato.
  7. Seleziona Salva. Attendere che venga visualizzata la notifica Aggiornamento completato.

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

Passaggio 8: per verificare le modifiche:

  1. Nel menu a sinistra selezionare di nuovo Variabili di ambiente > Stringhe di connessione.
  2. Accanto a AZURE_SQL_CONNECTIONSTRINGselezionare 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.
  3. Per verificare la stringa di connessione Redis, selezionare la scheda Impostazioni app. Accanto a AZURE_REDIS_CONNECTIONSTRING selezionare Mostra valore. Anche il valore dovrebbe essere @Microsoft.KeyVault(...).

Screenshot che mostra come visualizzare il valore della stringa di connessione .NET in Azure.

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

Passaggio 1: nel menu a sinistra selezionare Distribuzione>Centro di 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-app-service-sqldb-dotnetcore.
  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 selezionando la visualizzazione Chat e quindi selezionando +.
  2. Chiedere "@workspace Come si connette l'app al database e alla cache?" Copilot potrebbe fornire una spiegazione sulla classe MyDatabaseContext e su come è configurata in Program.cs.
  3. Chiedi: "In modalità di produzione, voglio che l'app usi la stringa di connessione denominata AZURE_SQL_CONNECTIONSTRING per il database e l'impostazione dell'app denominata AZURE_REDIS_CONNECTIONSTRING*". 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 nel file Program.cs.
  4. Aprire Program.cs in Esplora risorse e aggiungere il suggerimento del codice. GitHub Copilot non fornisce la stessa risposta ogni volta e non è sempre corretta. Potrebbe essere necessario porre altre domande per ottimizzare la risposta. 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 Program.cs in Esplora risorse.
  2. Trovare il codice commentato (righe 12-21) e rimuovere il commento. Questo codice si connette al database usando AZURE_SQL_CONNECTIONSTRING e si connette alla cache Redis usando l'impostazione dell'app AZURE_REDIS_CONNECTIONSTRING.

Screenshot che mostra un codespace GitHub e il file Program.cs aperto.

Passaggio 5 (opzione 1: con GitHub Copilot):

  1. Aprire .github/workflows/starter-no-infra_msdocs-core-sql-XYZ nello strumento di esplorazione. Questo file è stato creato dalla creazione guidata del servizio app.
  2. Evidenziare il passaggio dotnet publish e selezionare .
  3. Chiedere a Copilot: "Installare dotnet ef, quindi creare un bundle delle migrazioni nella stessa cartella di output".
  4. Se il suggerimento è accettabile, selezionare Accetta. GitHub Copilot non fornisce la stessa risposta ogni volta e non è sempre corretta. Potrebbe essere necessario porre altre domande per ottimizzare la risposta. Per suggerimenti, vedere Cosa è possibile fare con GitHub Copilot nel codespace?.

Screenshot che mostra l'uso di GitHub Copilot in un file del flusso di lavoro GitHub.

Passaggio 5 (opzione 2: senza GitHub Copilot):

  1. Aprire .github/workflows/starter-no-infra_msdocs-core-sql-XYZ nello strumento di esplorazione. Questo file è stato creato dalla creazione guidata del servizio app.
  2. Nel passaggio dotnet publish, aggiungere un passaggio per installare lo strumento Entity Framework Core con il comando dotnet tool install -g dotnet-ef --version 8.*.
  3. Nel nuovo passaggio aggiungere un altro passaggio per generare un bundle di migrazione del database nel pacchetto di distribuzione: dotnet ef migrations bundle --runtime linux-x64 -o ${{env.DOTNET_ROOT}}/myapp/migrationsbundle. Il bundle di migrazione è un eseguibile autonomo che è possibile eseguire nell'ambiente di produzione senza bisogno di .NET SDK. Il contenitore Linux del servizio app ha solo il runtime .NET e non .NET SDK.

Screenshot che mostra i passaggi aggiunti al file del flusso di lavoro GitHub per il bundle di migrazione del database.

Passaggio 6:

  1. Selezionare l'estensione Controllo del codice sorgente.
  2. Nella casella di testo digitare un messaggio di commit come Configure Azure database and cache connections. In alternativa, selezionare e lasciare che GitHub Copilot generi automaticamente un messaggio di commit.
  3. Selezionare Commit e quindi confermare con Sì.
  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 7: tornare alla pagina Centro distribuzione nel portale di Azure:

  1. Selezionare la scheda Log, quindi selezionare Aggiorna per visualizzare la nuova esecuzione della distribuzione.
  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 8: si è eseguiti 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 Operazione riuscita. Ci vogliono circa 5 minuti.

Screenshot che mostra un'esecuzione di GitHub in corso.

5. Generare lo schema del database

Con il database SQL protetto dalla rete virtuale, il modo più semplice per eseguire migrazioni di database dotnet è in una sessione SSH con il contenitore del servizio app.

Passaggio 1: tornare alla pagina Servizio app, nel menu a sinistra selezionare Strumenti di sviluppo>SSH, quindi selezionare Vai.

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

Passaggio 2: nel terminale SSH:

  1. Eseguire cd /home/site/wwwroot. Ecco tutti i file distribuiti.
  2. Eseguire il bundle di migrazione generato dal flusso di lavoro GitHub con il comando ./migrationsbundle -- --environment Production. Se ha esito positivo, il servizio app si connette correttamente al database SQL. Tenere presente che --environment Production corrisponde alle modifiche apportate al codice in Program.cs.

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

Nella sessione SSH solo le modifiche apportate ai file in /home possono essere mantenute oltre i riavvii dell'app. Le modifiche al di fuori di /home non sono persistenti.

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 basata sui dati sicura ASP.NET Core nel servizio app di Azure.

Screenshot dell'app .NET Core in esecuzione nel servizio app.

Suggerimento

L'applicazione di esempio implementa il modello cache-aside. Quando si visita una vista dati per la seconda volta o si ricarica la stessa pagina dopo aver apportato modifiche ai dati, il tempo di elaborazione nella pagina Web mostra un tempo molto più veloce perché carica i dati dalla cache anziché dal database.

7. Eseguire lo streaming dei log di diagnostica

Il Servizio app di Azure acquisisce tutti i messaggi archiviati nella console per facilitare la diagnosi dei problemi con l'applicazione. L'app di esempio restituisce messaggi di log della console in ognuno dei relativi endpoint per illustrare questa funzionalità.

Passaggio 1: nella pagina Servizio app:

  1. Nel menu a sinistra selezionare Monitoraggio>Log di servizio app.
  2. In Application Logging, selezionare File System e quindi 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.

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 Elimina gruppo di risorse nel portale di Azure.

Passaggio 3:

  1. Immettere il nome del gruppo di risorse per confermare l'eliminazione.
  2. Selezionare 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 il servizio app, il database SQL di Azure e Cache Redis di Azure.

Il contenitore di sviluppo ha già l'interfaccia della Azure Developer CLI (AZD).

  1. Dalla radice del repository eseguire azd init.

    azd init --template dotnet-app-service-sqldb-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 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.
    • Endpoint privati: accedere agli endpoint per l'insieme di credenziali delle chiavi, il server di database e la cache Redis nella rete virtuale.
    • Interfacce di rete: rappresenta gli indirizzi IP privati, uno per ognuno degli endpoint privati.
    • Server di database SQL di Azure: accessibile solo da dietro l'endpoint privato.
    • Database SQL di Azure: un database e un utente vengono creati automaticamente nel server.
    • Cache Redis di Azure: accessibile solo da dietro l'endpoint privato.
    • Insieme di credenziali delle chiavi: accessibile solo da dietro l'endpoint privato. Usato per gestire i segreti per l'app del servizio app.
    • Zone DNS privato: abilitare la risoluzione DNS dell'insieme di credenziali delle chiavi, del server di database e la cache Redis nella rete virtuale.

    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

Suggerimento

La stringa di connessione del database SQL predefinita usa l'autenticazione SQL. Per un'autenticazione senza password più sicura, vedere Come si modifica la connessione al database SQL per usare invece un'identità gestita?

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 le impostazioni AZURE_SQL_CONNECTIONSTRING e AZURE_REDIS_CONNECTIONSTRING. Vengono visualizzati solo i nomi delle impostazioni. L'output AZD è simile al seguente:

     App Service app has the following connection strings:
     - AZURE_SQL_CONNECTIONSTRING
     - AZURE_REDIS_CONNECTIONSTRING
     - AZURE_KEYVAULT_RESOURCEENDPOINT
     - AZURE_KEYVAULT_SCOPE

    AZURE_SQL_CONNECTIONSTRING contiene la stringa di connessione al database SQL in Azure e AZURE_REDIS_CONNECTIONSTRING contiene la stringa di connessione alla cache Redis di Azure. È necessario usarli 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.

Problemi? Controllare la sezione Risoluzione dei problemi.

4. Modificare il codice di esempio e ridistribuire

  1. Nel codespace GitHub avviare una nuova sessione di chat selezionando la visualizzazione Chat e quindi selezionando +.

  2. Chiedere "@workspace Come si connette l'app al database e alla cache?" Copilot potrebbe fornire una spiegazione sulla classe MyDatabaseContext e su come è configurata in Program.cs.

  3. Chiedi: "In modalità di produzione, voglio che l'app usi la stringa di connessione denominata AZURE_SQL_CONNECTIONSTRING per il database e l'impostazione dell'app denominata AZURE_REDIS_CONNECTIONSTRING*". 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 nel file Program.cs.

  4. Aprire Program.cs in Esplora risorse e aggiungere il suggerimento del codice.

    GitHub Copilot non fornisce la stessa risposta ogni volta e non è sempre corretta. Potrebbe essere necessario porre altre domande per ottimizzare la risposta. Per suggerimenti, vedere Cosa è possibile fare con GitHub Copilot nel codespace?.

Prima di distribuire queste modifiche, è comunque necessario generare un bundle di migrazione.

Problemi? Controllare la sezione Risoluzione dei problemi.

5. Generare lo schema del database

Con il database SQL protetto dalla rete virtuale, il modo più semplice per eseguire le migrazioni del database è in una sessione SSH con il contenitore del servizio app. Tuttavia, i contenitori Linux del servizio app non hanno .NET SDK, quindi il modo più semplice per eseguire le migrazioni di database consiste nel caricare un bundle di migrazioni autonome.

  1. Generare un bundle delle migrazioni per il progetto con il comando seguente:

    dotnet ef migrations bundle --runtime linux-x64 -o migrationsbundle

    Suggerimento

    L'applicazione di esempio (vedere DotNetCoreSqlDb.csproj) è configurata per includere questo file migrationsbundle. Durante la fase azd package, migrationsbundle verrà aggiunto al pacchetto di distribuzione.

  2. Distribuire tutte le modifiche con azd up.

    azd up

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

  4. Nel terminal SSH, eseguire i comandi seguenti in un terminale:

    cd /home/site/wwwroot
./migrationsbundle -- --environment Production

    Se ha esito positivo, il servizio app si connette correttamente al database. Tenere presente che --environment Production corrisponde alle modifiche apportate al codice in Program.cs.

Nella sessione SSH solo le modifiche apportate ai file in /home possono essere mantenute oltre i riavvii dell'app. Le modifiche al di fuori di /home non sono persistenti.

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 ASP.NET Core con il database SQL in esecuzione in Azure che mostra le attività.

    Si esegue un'app Web nel servizio app di Azure, con connettività sicura al database SQL di Azure.

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 standard per illustrare questa funzionalità, come illustrato nel frammento di codice seguente:

public async Task<IActionResult> Index()
{
    var todoItems = await _cache.GetAsync(_TodoItemsCacheKey);
    if (todoItems != null)
    {
        _logger.LogInformation("Data from cache.");
        var todoList = JsonConvert.DeserializeObject<List<Todo>>(Encoding.UTF8.GetString(todoItems));
        return View(todoList);
    }
    else
    {
        _logger.LogInformation("Data from database.");
        var todoList = await _context.Todo.ToListAsync();
        var serializedTodoList = JsonConvert.SerializeObject(todoList);
        await _cache.SetAsync(_TodoItemsCacheKey, Encoding.UTF8.GetBytes(serializedTodoList));
        return View(todoList);
    }
}

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

La visualizzazione della distribuzione del portale per il database SQL di Azure mostra lo stato del conflitto

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

Location '<region>' is not accepting creation of new Windows Azure SQL Database servers at this time.

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

Nel portale di Azure l'interfaccia utente del flusso di log per l'app Web mostra gli errori di rete

Potrebbe essere visualizzato questo errore:

Unable to open a connection to your app. This may be due to any network security groups or IP restriction rules that you have placed on your app. To use log streaming, please make sure you are able to access your app directly from your current network.

Si tratta in genere di un errore temporaneo all'avvio dell'app. Attendere alcuni minuti e riprovare.

La sessione SSH nel browser mostra SSH CONN CLOSED

L'avvio del contenitore Linux richiede alcuni minuti. Attendere alcuni minuti e riprovare.

La pagina del flusso di log del portale mostra Connected! ma nessun log

Dopo aver configurato i log di diagnostica, l'app viene riavviata. Potrebbe essere necessario aggiornare la pagina per rendere effettive le modifiche nel browser.

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 database SQL di Azure viene creato in un livello serverless generico su hardware di serie Standard con i core minimi. C'è un costo ridotto e può essere distribuito in altre aree. È possibile ridurre al minimo i costi riducendone le dimensioni massime oppure modificando il livello di servizio, il livello di calcolo, la configurazione hardware, il numero di core, le dimensioni del database e la ridondanza della zona. Vedere Prezzi del database SQL di Azure.
  • 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 ci si connette al server di database SQL di Azure protetto dietro la rete virtuale con altri strumenti?

  • Per l'accesso di base da uno strumento da riga di comando, è possibile eseguire sqlcmd dal terminale SSH dell'app. Il contenitore dell'app non è disponibile con sqlcmd, quindi è necessario installarlo manualmente. Tenere presente che il client installato non persiste tra i riavvii dell'app.
  • Per connettersi da un client di SQL Server Management Studio o da Visual Studio, il computer deve trovarsi all'interno della rete virtuale. Ad esempio, potrebbe trattarsi di una macchina virtuale di Azure connessa a 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.

Come funziona lo sviluppo di app locali con GitHub Actions?

Prendere il file del flusso di lavoro generato automaticamente dal servizio app come esempio, ognigit push avvia una nuova esecuzione di compilazione e 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

Come si esegue il debug degli errori durante la distribuzione di GitHub Actions?

Se un passaggio non riesce nel file del flusso di lavoro GitHub generato automaticamente, provare a modificare il comando non riuscito per generare un output più dettagliato. Ad esempio, è possibile ottenere più output da uno dei comandi dotnet aggiungendo l'opzione -v. Eseguire il commit e il push delle modifiche per attivare un'altra distribuzione nel servizio app.

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

Vedere Configurare la distribuzione di GitHub Actions dal Centro distribuzione.

Come si modifica la connessione al database SQL per usare invece un'identità gestita?

La stringa di connessione predefinita al database SQL viene gestita da Service Connector, con il nome defaultConnector e usa l'autenticazione SQL. Per sostituirlo con una connessione che usa un'identità gestita, eseguire i comandi seguenti in Cloud Shell dopo aver sostituito i segnaposto:

az extension add --name serviceconnector-passwordless --upgrade
az sql server update --enable-public-network true
az webapp connection delete sql --connection defaultConnector --resource-group <group-name> --name <app-name>
az webapp connection create sql --connection defaultConnector --resource-group <group-name> --name <app-name> --target-resource-group <group-name> --server <database-server-name> --database <database-name> --client-type dotnet --system-identity --config-connstr true
az sql server update --enable-public-network false

Per impostazione predefinita, il comando az webapp connection create sql --client-type dotnet --system-identity --config-connstr esegue le operazioni seguenti:

  • Imposta l'utente come amministratore di Microsoft Entra ID del server di database SQL.
  • Creare un'identità gestita assegnata dal sistema e concedervi l'accesso al database.
  • Genera una stringa di connessione senza password denominata AZURE_SQL_CONNECTIONGSTRING, che l'app sta già usando alla fine dell'esercitazione.

L'app dovrebbe ora avere connettività al database SQL. Per altre informazioni, vedere Esercitazione: Connettersi ai database di Azure dal servizio app senza segreti usando un'identità gestita.

Suggerimento

Non si vuole abilitare la connessione di rete pubblica? È possibile ignorare az sql server update --enable-public-network true eseguendo i comandi da Azure Cloud Shell integrata con la rete virtuale se si ha l'assegnazione di ruolo Proprietario nella sottoscrizione.

Per concedere all'identità l'accesso necessario al database protetto dalla rete virtuale, az webapp connection create sql è necessaria la connettività diretta con l'autenticazione entra ID al server di database. Per impostazione predefinita, Azure Cloud Shell non ha questo accesso al database protetto dalla rete.

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:

  • Si vuole che questo codice sia eseguito solo in modalità di produzione.
  • Si vuole che questo codice venga eseguito solo nel servizio app di Azure e non in locale.
  • Il parametro --output-path sembra non supportato.

Contenuto correlato

Passare all'esercitazione successiva per informazioni su come proteggere l'app con un dominio e un certificato personalizzati.

 Proteggere con dominio personalizzato e certificato di protezione

In alternativa, consultare altre risorse:

Esercitazione: Connettersi al database SQL da Servizio app senza segreti usando un'identità gestita

Configurare l'app ASP.NET Core