Pianificare l'app Web statica di Azure
L'obiettivo finale è ospitare l'app in Azure. App Web statiche di Azure si occupa automaticamente del provisioning di tutte le risorse di Azure necessarie.
Tuttavia, prima che l'app possa essere ospitata, è necessario qualcosa per la compilazione dell'app man mano che si apportano modifiche. Queste modifiche possono essere apportate tramite commit o richieste pull al repository. Una caratteristica principale di App Web statiche di Azure consiste nel configurare un flusso di lavoro di GitHub Actions per compilare e pubblicare l'applicazione.
Quando si crea la risorsa di App Web statiche di Azure, viene creato il flusso di lavoro di GitHub Actions. Il flusso di lavoro viene attivato immediatamente e si occupa della compilazione e della pubblicazione dell'app. Il flusso di lavoro viene attivato anche ogni volta che si apporta una modifica al ramo monitorato nel repository.
App Web statiche di Azure
La distribuzione di un'app Web include due aspetti automatizzati. Il primo è il provisioning delle risorse di Azure sottostanti che costituiscono l'app. Il secondo è un flusso di lavoro di GitHub Actions che compila e pubblica l'applicazione.
Pubblicando l'app nel Web con App Web statiche di Azure, si ottiene hosting rapido dell'app Web e API scalabili. Si ottiene anche un flusso di lavoro di compilazione e distribuzione unificato, fornito da GitHub Actions.
Connettere l'istanza di App Web statiche a GitHub
App Web statiche di Azure è progettato per ospitare applicazioni quando il codice sorgente si trova in GitHub. Quando si crea un'istanza di App Web statiche, è necessario accedere a GitHub e specificare il repository contenente il codice dell'app.
È anche necessario specificare tre percorsi di cartella nel repository, in modo che l'app possa essere automaticamente compilata e distribuita:
| Ubicazione | Esempio di percorso | Descrizione | Richiesto |
|---|---|---|---|
| App location (Percorso app) | / | Percorso del codice sorgente per l'app Web | Sì |
| Percorso di output di compilazione dell'app | dist | Percorso dell'output di compilazione dell'app, relativo rispetto al percorso dell'app | No |
| Posizione dell'API | api | Percorso del codice sorgente per l'API | No |
L'output di compilazione dell'app è un percorso relativo rispetto alla directory di output di compilazione dell'applicazione. Ad esempio, si supponga di avere un'app in my-app che restituisce i propri asset di compilazione in una cartella my-app/dist. In questo caso, è necessario specificare dist per questo percorso.
Dal codice sorgente agli asset statici con GitHub Actions
Poiché il repository GitHub contiene il codice sorgente, il repository deve essere creato prima di essere pubblicato.
Quando si crea un'istanza di App Web statiche, Azure crea un flusso di lavoro di GitHub Actions nel repository. Il flusso di lavoro compila l'app ogni volta che si esegue il push delle modifiche o si crea una richiesta pull nel ramo scelto per tenere traccia. Questo processo di compilazione trasforma il codice sorgente in asset statici, gestiti da Azure. Al termine della compilazione, l'azione distribuisce gli asset.
Il flusso di lavoro di GitHub Actions viene aggiunto nel repository nella cartella .github/workflows. È possibile esaminare o modificare questo file nel modo necessario. Le impostazioni immesse quando si crea la risorsa vengono archiviate nel file di GitHub Actions.
API integrata con Funzioni di Azure
Se l'app richiede un'API, è possibile implementarla come progetto di Funzioni di Azure nel repository. L'API verrà distribuita automaticamente e ospitata dall'istanza di App Web statiche. Il flusso di lavoro di GitHub Actions che compila e distribuisce l'app individua l'API nel repository attraverso il nome della cartella specificata.
In genere l'app per le API viene inserita in una cartella denominata api o functions, ma è possibile scegliere il nome che si preferisce.
Se non è disponibile un'API, Nessun problema. Se App Web statiche di Azure non trova un'API nella cartella indicata, non pubblica alcuna API, ma pubblica comunque l'app.
Gestire le route di fallback
L'errore 404 viene generato quando si aggiorna la pagina perché il browser invia una richiesta alla piattaforma di hosting per la visualizzazione di /products. Nel server non è presente alcuna pagina denominata products da rendere disponibile. Fortunatamente, è facile risolvere questo problema creando una route di fallback. Una route di fallback è una route che soddisfa tutte le richieste di pagina senza corrispondenza al server.
App Web statiche di Azure supporta regole di gestione personalizzate definite in un file staticwebapp.config.json facoltativo contenuto nella cartella dell'output di compilazione dell'app.
È possibile configurare l'app per l'uso di regole che implementano una route di fallback, come illustrato nell'esempio seguente che usa un carattere jolly del percorso con filtro file:
{
"navigationFallback": {
"rewrite": "index.html",
"exclude": ["/images/*.{png,jpg,gif,ico}", "/*.{css,scss,js}"]
}
}
Questa regola indica ad App Web statiche di Azure di gestire index.html quando non viene trovata una richiesta per una risorsa, escluse le immagini e i file CSS visualizzati nell'espressione exclude.
Percorso del file della route
App Web statiche di Azure presuppone che il file staticwebapp.config.json si trovi per impostazione predefinita in output_location. Se il processo di compilazione copia il file staticwebapp.config.json in output_location, non è necessario eseguire altre operazioni. Per la maggior parte dei progetti, output_location fa riferimento a app_location.
Il file staticwebapp.config.json per l'applicazione si trova nella cartella angular-app/src/assets.
Il file staticwebapp.config.json si trova nella cartella react-app.
Il file staticwebapp.config.json si trova nella cartella svelte-app/public.
Il file staticwebapp.config.json si trova nella cartella vue-app/public.
Passaggi successivi
Che cosa è dunque necessario per poter pubblicare l'app Web in App Web statiche di Azure? Tutto quello che serve è l'app nel repository GitHub.