18

Apr

Windows Azure – Applicazioni in ASP.NET pt.2 – DNS e IIS

DNS

Quando pubblichiamo una applicazione su Windows Azure otteniamo sia l’IP del balancer (utile per mappare i DNS) sia un URL del tipo: applicazione.cloudapp.net.

Questo URL è l’indirizzo del server di produzione, mentre quello di staging è generalmente nel formato: [guid].cloudapp.net. Benchè sia utile avere un url amichevole da ricordare per arrivare alla nostra applicazione, bisognerà mappare i DNS all’IP del load balancer: l’approccio che consiglio è di creare un record A per l’host name che si vuole (per esempio il proprio dominio) che punti a tale IP. L’alternativa è creare un CNAME che punti proprio all’URL *.cloudapp.net dell’applicazione appena creata.

Nota: l’approccio consigliato da Microsoft è proprio il secondo in quanto non supportano ufficialmente il mapping dei record A. Questa soluzione però non è buona in quanto richiede due lookup IP (uno per il cname, l’altro per il dominio *.cloudapp.net). La giustificano dicendo che l’IP è locale allo slot di deployment e così facendo si eviterebbero i problemi di downtime relativi alla ri-propagazione dei DNS. Un’altra criticità della soluzione proposta da MS è che non si può mappare un CNAME alla root del dominio, quindi non sarà mai possibile avere un http://dominio.com che punti ad un *.cloudapp.net.

Al fine di agevolare i deploy frequenti e di velocizzare il processo di propagazione dei DNS (anche in seguito a feedback massivi degli utenti) il TTL dei sottodomini di cloudapp.net è di 10 secondi, che ne facilita il remapping frequente.

 

IIS

Con il supporto a Full IIS, ora l’applicazione Azure (il RoleEntryPoint) gira sotto WaIISHost, mentre i siti web girano sul processo w3wp.exe al solito. Questo permette di fare il deploy di siti web multipli per ogni ruolo e di caricare ogni modulo IIS si voglia; in particolare possiamo mappare più host name sullo stesso ruolo ed avere una classica situazione multi-tenant su IIS.

Il caricamento dei moduli dovrebbe infine semplificare quelle applicazioni web costruite molto in sinergia con IIS.

image

 

Problemi noti: FileUpload

Nelle istanze Azure il FileSystem root ha pochissimo spazio disponibile su disco (nell’ordine delle poche centinaia di MB). Questo, che può sembrare un dettaglio, è un problema quando usiamo un multipart per fare upload di file dall’applicazione. Infatti tutti i dati temporanei della POST, incluso gli allegati multipart, vengono salvati per forza in una directory temporanea e non c’è possibilità di ridirezionarli ad un LocalStorage o ad un drive/blob. L’unico modo ad oggi possibile sembra bypassare il sistema naturale di upload (e quindi anche il controllo FileUpload di ASP.NET) in favore di Silverlight, Javascript e/o comunque una tecnologia client che bypassi tale sistema.

by Roberto Freato on 4/18/2011
Post archive