Pubblicare la prima applicazione su Windows Azure

Nel nostro primo Code Snippet abbiamo visto all'opera Microsoft Visual Studio 2010 per la creazione di un semplice progetto; abbiamo poi parlato, nel secondo snippet, del simulatore locale denominato Windows Azure Compute Emulator ovvero l'ambiente che simula il comportamento e fornisce le API del sistema operativo Windows Azure.

In questa lezione pubblicheremo la mini-applicazione realizzata nel primo articolo e testata in locale nel secondo articolo, su Windows Azure.

La prima operazione da fare è ottenere una subscription dal portale di Windows Azure. Fra le varie subscription disponibili ne possiamo trovare alcune grauite che consentono di provare le nostre applicazioni sulla piattaforma senza pagare alculchè a patto di non sforare i limiti indicati.

Come si nota in figura, è possibile utilizzare per 750 ore al mese (e, garantisco... non ci sono mesi con più di 750 ore) una istanza Extra Small. Per avere più potenza o testare l'applicazione su una istanza personale è possible optare per una subscription Introductory (tradotta in italiano, purtroppo, in "per principianti" al posto di introduttiva) che consente di utilizzare per 25 ore al mese una istanza di tipo Small.

Appena effettuaiamo il deployment della nostra applicazioni su Windows Azure, scatta il contatore delle ore di utilizzo. Non appena eliminiamo l'applicazione dall'ambiente il contatore si ferma. Al termine del mese viene computato il numero di ore intere di deployment e, se siamo rimasti sotto i limiti, non dobbiamo pagare niente. Se invece abbiamo provato per più tempo o più istanze pagheremo la differenza.

Per rimanere aggiornati sulle tariffe, le promozioni attive e le condizioni al momento della sottoscrizione, è meglio fare riferimento alla documentazione linkata dalla home page, visto che potrebbero cambiare nel tempo.

Per attivare la subscription è possibile utilizzare il link Sign up now che ci porta direttamente alla scelta delle subscription che vediamo nell'immagine seguente insieme alle varie offerte disponibili al momento della scrittura di questo articolo.

Occorre fornire una carta di credito valida a prescindere dall'offerta, in quanto, come indicato in precedenza, è sempre possibile utilizzare più di quanto abbiamo sottoscritto, pagando la differenza a fine mese.

Ad esempio è possibile utilizzare due istanze in contemporanea: in questo caso, per ogni ora di deployment verranno conteggiate, giustamente, due ore, una per ogni istanza. Se rimaniamo comunque sotto le ore incluse all'interno del mese nessun problema, altrimenti verrà addebitata la differenza.

Ogni subscription è legata all'account Windows Live che ha effettuato il login al sistema di billing che è comune ai vari servizi BPOS che Microsoft offre da tempo.

Una volta sottoscritto l'abbonamento che fa più al caso nostro (se avete MSDN ci sono condizioni particolari) occorre loggarsi al portale di Windows Azure utilizzando lo stesso account Windows Live che abbiamo usato per la subscription: questo account è l'administrator predefinito dei servizi. È poi possibile nominare altri amministratori aggiundo i cosiddetti "co-admin" direttamente dal portale.

Effettuato l'accesso, il portale si presenta con una interfaccia Silverlight ricca di opzioni. Per chi ha fatto qualche prova nel 2010, l'interfaccia basata in HTML è stata mandata in pensione e ha lasciato il passo a questa nuova UX.

In alto troviamo la toolbar di gestione della configurazione, a sinistra la toolbar di accesso alle componenti del sistema operativo e più in basso, l'accesso alle componenti della piattaforma. La parte centrale consente di vedere i servizi in deployment.

Nel nostro caso notiamo una stanza in "V1" (sta per Versione 1) di un Web Role nell'ambiente di produzione.

Nella lezione precedente abbiamo creato un semplice esempio di Web Role che proveremo a mettere nell'ambiente di produzione di Windows Azure. L'esempio, DevLeap.AzureBookManager, si presentava così in locale (notare l'inizio dell'indirizzo che punta a localhost, porta 81).

Avevamo anche richiesto uno spazio di 50 MB sul disco locale per fare caching di risorse e usato il seguente codice per la pagina di default:

<%@ Page Title="Home Page" Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true"
    CodeBehind="Default.aspx.cs" Inherits="DevLeap.AzureBookManager.FrontEnd._Default" %>
<asp:Content ID="HeaderContent" runat="server" ContentPlaceHolderID="HeadContent">
</asp:Content>
<asp:Content ID="BodyContent" runat="server" ContentPlaceHolderID="MainContent">
    <h2>
        Welcome to DevLeap Azure Book Manager
    </h2>
    <p>L'ora corrente nel cloud è <asp:Label ID="lblTime" runat="server" /></p>
    <p>Il nostro spazio su disco è sotto <asp:Label ID="lblStorage" runat="server" /></p>
</asp:Content>

Dal codice del metodo PreRender avevamo valorizzato le label.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Microsoft.WindowsAzure.ServiceRuntime;
namespace DevLeap.AzureBookManager.FrontEnd
{
    public partial class _Default : System.Web.UI.Page
    {
        protected void Page_PreRender(object sender, EventArgs e)
        {
            lblTime.Text = DateTime.Now.ToString();
            lblStorage.Text = RoleEnvironment.GetLocalResource("MyStorage").RootPath;
        }
    }
}

Prima di pubblicare l'applicazione assicuratevi di aver rimesso "1" sul valore delle istanze e di aver scelto la dimensione corretta dell'istanza in base alla vostra subscription. Capita spesso, infatti, di fare prove in locale con 25 istanze e poi pubblicare sul cloud l'applicazione che, in questo caso, mangerebbe 25 ore per ogni ora di deployment.

Per pubblicare la nostra applicazione è sufficiente premere il tasto destro del mouse sul progetto cloud e scegliere publish:

Come si nota dalla figura è possibile effettuare direttamente il deploy da Visual Studio. Non eseguiremo questa operazione per tre motivi:

1. In questa sede è utile mostrare i passi manuali per comprendere meglio il processo
2. Dobbiamo prima creare il servizio su Windows Azure per accogliere la nostra nuova instanza
3. Occorre fare l'upload di un certificato digitale prima di poter usare Visual Studio per fare publish diretto: altrimenti chiunque potrebbe fare l'upload sul nostro progetto

Per creare un Hosted Service che accolga la nostra soluzione è sufficiente premere il relativo tasto in alto a sinistra dal portale per attivare questa maschera:

Per prima cosa occorre scegliere un nome univoco (globalmente) in quanto riceveremo un indirizzo DNS su .cloudpapp.net. È possibile poi creare un alias dal nostro dominio ovviamente.

Scelto il nome, occorre indicare la regione dove inserire la nostra macchina: nel mio caso ho scelto Anywhere Europe. È anche possibile creare gruppi di macchine per "tenere vicine" le applicazioni e i dati fra di loro evitando la latenza di richieste fra data center diversi.

Scegliendo Deploy to production enviroment indichiamo al portale di creare l'ambiente reale per l'instanza che sta per creare. La versione Versione 1 è una label che ci consente poi di sapere cosa abbiamo messo in deployment.

L'ultima parte è composta da due file, il Package e il Configuration file: il secondo è il file di configurazione che abbiamo descritto nel precedente snippet, mentre il primo file è il risultato della "pubblicazione" effettuata da Visual Studio; si tratta di un file con estensione .cspkg (Cloud Service Package) che contiene, in binario, tutti i file necessari all'esecuzione dell'applicazione.

È sufficiente premere ok per ottenere la pubblicazione sul cloud; non ci sono altre operazioni da fare!

Riceveremo un warning che è molto utile leggere lentamente e accuratamente: Windows Azure ci segnala che con una sola istanza non è in grado, giustamente, di garantire il 99,95% di uptime; in caso di crash, la nostra applicazione viene immediatamente messa nuovamente in deploy su un'altra macchina ma, ovviamente il sistema, senza altre istanze attiva, può avere un tempo di down in un anno superiore allo 0,05% previsto dal SLA.

Ovviamente, per effettuare prove, questo "warning" è ininfluente: potete quindi proseguire e controllare lo stato di avanzamento dall'interfaccia.

Dopo circa 5-10 minuti, a seconda anche della velocità della linea su cui avete fatto l'upload, il nostro nuovo Web Role si dovrebbe presentare in stato Ready.

Nell'immagine si vede il servizio thinkaheadtest che contiene il progetto esposto come DevLeapAzureStorage (sotto DNS name).

Si può cliccare direttamnete sul DNS name oppure aprire un browser e scegliere il nome che avete assegnato con il suffisso .cloudapp.net:

In pratica, il modello descrive a Windows Azure il numero e la tipologia di instanza, il fatto che abbiamo richiesto 50 MB di disco locale per fare caching. Il nome del servizio è stato invece definito in fase di crezione dell'hosted service così come la regione dove eseguire il deploy.

Una volta messa in deploy, l'applicazione può essere aggiornata direttamente oppure possiamo effettuare un deploy nell'ambiente di staging, testare l'applicazione ed effettuare l'operazione di Swap tramite un semplice pulsante dal portale. Lo swap inverte la produzione con lo staging in tempo reale.