Nella scorsa puntata abbiamo introdotto il servizio Azure Container Apps ed abbiamo eseguito il deploy dell’immagine che esegue il frontend, scritta in Blazor Server.
In questa puntata ci occuperemo di fare il deploy del container del backend: un semplice progetto WebAPI Rest Dot Net Core, il cui compito è solo quello di fornire i dati di funzionamento al frontend.
Iniziamo creando il servizio ACA con le stesse modalità viste nella puntata precedente: soffermiamoci un attimo sulla pagina iniziale del wizard di configurazione.
Di recente al Build 2022 si è parlato, tra le altre mille cose, del servizio Azure Container App (per gli amici: ACA), e del fatto che è stato rilasciato in versione stabile.
Devo dire che è già da un pò di tempo che sto sperimentando questo nuovo servizio Azure, e in questi due post Vi farò vedere come utilizzarlo per fare il deploy di un’applicatvo Blazor Server dotato di relativo backend.
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.
Come saprete certamente recentemente Google ha cambiato il formato con cui è possibile sottoporre le app al suo store: il vecchio formato apk va in pensione in favore del nuovo e scintillante aab.
I vantaggi di questo “pensionamento” sono molteplici, e qui non mi dilungherò: lascio in particolare in linkografia alcuni documenti che ho trovato utili per comprenderne qualcosa in più.
Comunque pur avendone letto negli scorsi mesi devo ammettere che ho continuato a pubblicare le nuove versioni delle app alle quali lavoro sempre in apk, ma solo per sciatteria, lasciandomi il battesimo con aab alla prima occasione utile.
Infatti da quello che ho potuto verificare sino alla data odierna aggiornamenti di app esistenti accettano ancora il vecchio e glorioso formato apk: nuove app devono giocoforza usare aab.
Qualche giorno l’occasione di usare questo nuovo formato è arrivata, e devo dire che arrivare in fondo, e riuscire a pubblicare la mia nuova app con il nuovo formato, non è stato affatto semplice o banale: anzi è stato un vero e proprio percorso a ostacoli.
Piccola/grande nota:so perfettamente che devops nonchè anche le buone norme di programmazione intimano che il deploy dovrebbe essere automatico e quindi che il processo di cui parlo in queste righe dovrebbe essere completamente automatico.
Però io ho inziato a programmare ai tempi ai tempi in cui se eri ricco avevi ben 64 KB di memoria, altrimenti se eri poveraccio (come il sottoscritto) dovevi accontentarti di 8 KB: per questo alcune operazioni preferisco farmele ancora a mano, “alla vecchia maniera”.
Proprio per questo ho deciso di scrivere questo post per aiutare i tapini come me in questo processo, non certo complicato, ma che nasconde alcune insidie: al termine di queste note potrete vantarVi anche Voi in giro di usare aab per le Vostre app.
La prima operazione da fare è convincere Visual Studio a produrre il file di setup di Android nel formato corretto.
