Gli App Service rappresentano il servizio principale da utilizzare per chi vuole fare hosting di una web app, perché rappresenta un'offerta PaaS molto completa, affidabile e scalabile.
Il suo scopo è quello di servire prettamente servizi web, HTML e API, ed espone molteplici metodi per poter pubblicare la nostra soluzione: FTP, Web Deploy, Git, servizi di storage esterni. Di recente però è stato introdotto anche il supporto a Docker, consentendoci quindi di pubblicare sfruttando direttamente un'immagine disponibile presso un registro. Questa soluzione unisce i pregi della containerazzione, come l'indipendenza della piattaforma e la gestione dei settings, con quelli di App Service, come il facile setup e la relativa gestione.
Pubblicare un solo container non è però molto utile, perché spesso gli applicativi, soprattutto se basati su architetture a micro servizi, dispongono di più container, costringendoci a creare più web app che sfruttino lo stesso service plan. Per ovviare a questo limite è stata aggiunta la possibilità di sfruttare Docker Compose, cioè la sintassi del file di configurazione che questo engine è in grado di comprendere per orchestrare più di un container. Per sfruttarlo è sufficiente scegliere la relativa voce quando di crea una nuova web app, oppure accedere alla sezione container settings. Dobbiamo inserire solamente la configurazione, tramite file o direttamente, come mostrato nella figura seguente.

Fatto questo il sistema si prende in carica il download e l'avvio dei container. Tornando nella stessa sezione possiamo poi vedere il log ed eventualmente ottenere un webhook da invocare per aggiornare il deployment.

Da notare che solo un container può essere esposto sulla porta 80 o 8080, mentre gli altri container rimangono servizi per uso interno. Questa funzionalità offerta, infatti, è sicuramente comoda ma limitata, da non contrapporte ad un orchestratore come Kubernetes, per il quale è disponibile un servizio apposito (AKS). Se decidiamo di scalare in più istanze, tutti i container scalano in egual numero e per default ognuno di essi dispone di uno storage isolato. E' possibile condividerlo sfruttando la variabile d'ambiente WEBAPP_STORAGE_HOME anche se è consigliabile sfruttare i container come se fossero stateless e utilizzare altre soluzioni, se vogliamo scalare con uno storage condiviso.
Dato che il supporto a Docker Compose è di fatto una simulazione del motore, rimandiamo alla documentazione per capire cosa possiamo utilizzare.
https://blogs.msdn.microsoft.com/appserviceteam/2018/05/07/multi-container/
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Health monitoring con Azure Container App
Ottenere il contenuto di una cartella FTP con la libreria FluentFTP
Ricevere avvisi su metriche dei server Azure Arc
Sopprimere gli errori di concorrenza quando si elimina una entity con Entity Framework 7
Intercettare gli eventi di creazione degli oggetti con Entity Framework 7
Ottimizzare serializzazione e deserializzaione tramite le options con System.Text.Json
Definire una tabella come memory optimized su Sql Server tramite EF Core
Pubblicare un pacchetto di NuGet nel feed di GitHub
Utilizzare HiLo per ottimizzare le insert in un database con Entity Framework
Creare un router per Single Page Application con l'evento navigate
Elencare le container images installate in un cluster di Kubernetes
I più letti di oggi
- Rilasciata la versione 1.0 di ASP.NET MVC
- Abilitare HTTP/3 in ASP.NET Core 7.0
- Seconda preview per i Dynamic Data Control 4.0
- Ecco la roadmap di ASP.NET 5: il rilascio definitivo nel corso del primo trimestre 2016
- Rilasciato il Service Pack 3 di SQL Server 2005
- Rilasciata la versione 1.0 di ASP.NET Core
- Questionario sulla qualità di VS 2005
- Disponibile il SP1 di SQL Server 2008