Ho capito che l’idea di fondo espressa da questo servizio è: questa è l’immagine docker (o il set di immagini) del mio applicativo, mandala in esecuzione senza tediarmi eccessivamente con troppe configurazioni.

Il mondo docker, docker compose, kubernetes è meraviglioso e si può fare tutto, e il contrario di tutto, ma certamente non è facile da configurare in modo corretto: le competenze necessarie a mettere un set di servizi con questi strumenti non sono affatto banali.

E’ proprio in questo contesto che si pone questo servizio: nella possibilità di mandare in esecuzione un’immagine o un set di immagini con poco sforzo e quasi nessuna competenza degli strumenti citati prima.

Certo: occorre anche dire che questo servizio permette di ottenere tutto questo senza usare un’infrastruttura complessa, in modalità serverless, ma direi che sono tutte variazioni sul tema principale che Vi ho esposto: ACA è semplice e banale da usare. O almeno questo è quello che ho percepito io….

Però non si sta parlando di una nuova modalità di esecuzione di container: al di sotto di questo servizio continuano a girare Kubernetes & C.

Per questo motivo è possibile pensare a servizio Azure Container App come a un wrapper intorno a un set di servizi Kubernetes & C. che semplifica in modo drammatico le configurazioni necessarie per il suo funzionamento.

Questa esemplificazione ha un costo, che si ripercuote nelle seguenti limitazioni (che a mio parere… non sono così limitanti per applicazioni classiche).

• E’ in grado di eseguire solo immagini linux/amd64
• Non può mandare in esecuzione “privileged containers”
• Le connessioni dall’esterno sono possibili solo usando i seguenti protocolli.
  • Http/Https
  • WebSocket
  • gRPC

Per esporre il funzionamento di questo servizio nerl dettaglio lascio la teoria alla linkografia in allegato, che certamente sono in grado di esporre l’argomento in modo molto più chiaro e completo di come sarei in grado di fare io.

In questo post, invece, esporrò un semplice progetto pratico il quale usa in modo efficente non uno, bensì due servizi ACA: uno delegato a fornire servizi di front-end, e un’altro che fornisce solo servizi di backend.

Partiamo dal front-end: vedendo Https+WebSocket cosa Vi viene in mente ?? Ma certo: Blazor Server.

Infatti il front-end è costituito da un progetto creato usando questa tecnologia, che chiameremo BlazorServerWeather-FrontEnd.

Qui i dati presentati saranno i soliti dati che simulano le previsioni del tempo: diversamente dal template ufficiale, però, i dati saranno prelevati da un servizio di backend.

Quest’ultimo progetto, il cui nome è (in modo assolutamente originale) BlazorServerWeather-Backend, è un semplice WebAPI Rest.

In linkografia trovate i link al repo githib, per cui qui esporrò solo i punti principali.

Iniziamo dal codice notevole del frontend.

Tralasciando i fronzoli il frontend preleva i dati con una chiamata Http al backend, il cui codice è esposto nel seguito.

Oss.: Vi faccio notare che occorre ancora dotare il frontend dell’URL assegnato al backend: lo faremo a brevissimo.

I nostri progetti sono entrambi dotati di Dockerfile: qui non Ve lo riporto perchè questi sono banalissimi e penso che non aggiungano nulla all’esposizione.

Fatto questo non ci resta che pubblicare i due progetti su un docker container: per semplicità qui ho usato Dockerhub.

Anche qui non mi dilungo molto perchè so che il processo di cui parlo è arciconosciuto, e non voglio appesantire troppo la trattazione.

Diciamo che nel mio caso i due contenitori si chiamano gptucci/blazorserverweatherfrontend e gptucci/blazorserverweatherbackend.

Ora passiamo a trafficare su Azure, pubblicando per prima cosa il frontend.

Dal portale creare un nuova risorsa Contanier App, che troviamo in sotto la categoria Containers.

Le domande che ci vengono poste all’inizio sono abbastanza eloquenti: la subscription, il resource group, il nome e infine la regione. Nulla di preoccupante.

Vi faccio notare, in fondo, la voce Container Apps Environment: è un servizio supplettivo Azure collegato a questo, e che ora ci viene creato per noi in automatico (ma è anche possibile crearlo manualmente usando in basso la voce “Create New”).

Ne parleremo a breve: per ora tenetevi segnato da parte la stringa identificativa proposta che identifica il Container Apps Environment.

Le cose si fanno interessanti quando si seleziona la tab App Settings: in questo punto c’è il vero cuore della configurazione degli ACA, ed è qui che è possibile apprezzare l’estrema semplicità del servizio.

Iniziamo l’esposizione dei parametri proposti partendo da flag Use quickstart image: lasciando questa impostazione selezionata si autoconfigurerà per noi un in’inutile applicativo di test.

Nel nostro caso abbiamo levato la spunta, e configurato manualmente il container da porre in esecuzione.

In particolare abbiamo assegnato un nome (ad uso interno), e quindi impostato che come sorgente l’immagine deve essere presa dal repository pubblico di Docker Hub.

L’immagine direi che è abbastanza esplicativa, e ritengo sia inutile aggiungere altro.

Sul fondo della pagina di impostazioni è possibile vedere le configurazioni relative a ingress, e cioè: il nostro container è raggiungibile dall’esterno ?? Su che porte ??

In particolare l’opzione HTTP Ingress imposta se è possibile o meno raggiungere via rete dall’esterno il container, mentre Ingress traffic indica se la sorgente può essere un qualsivoglia ip pubblico, oppure se l’accesso è limitato ad altri servizi posti in azure.

Questa seconda possibilità ci sarà utile a breve: infatti il backend è assolutamente inutile sia raggiungibile dall’esterno. Ma lo vedremo a breve.

Una volta confermato ecco che il servizio ci viene creato: nella seconda puntata di questa piccola serie vedremo come impostare il backend e faremo le considerazioni finali.

Grazie per avermi seguito.

Linkografia
Azure Container Apps overview
GitHub: link al codice