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.
Figura 13. Home page di Windows Azure
(clic per ingrandire)
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
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
Sign up now
Figura 14. Scegliere il tipo di subscription
(clic per ingrandire)
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.
Figura 15. Dashboard di Windows Azure
(clic per ingrandire)
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
localhost
81
Figura 16. Applicazione di esempio
(clic per ingrandire)
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
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:
- In questa sede è utile mostrare i passi manuali per comprendere meglio il processo
- Dobbiamo prima creare il servizio su Windows Azure per accogliere la nostra nuova instanza
- 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:
Figura 18. Creare un nuovo Hosted Service
(clic per ingrandire)
Per prima cosa occorre scegliere un nome univoco (globalmente) in quanto riceveremo un indirizzo DNS su .cloudpapp.net
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
Versione 1
L'ultima parte è composta da due file, il Package
Configuration file
.cspkg
È sufficiente premere ok
Riceveremo un warning che è molto utile leggere lentamente e accuratamente
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
Figura 19. Web Role in stato Ready
(clic per ingrandire)
Nell'immagine si vede il servizio thinkaheadtest
DevLeapAzureStorage
Si può cliccare direttamnete sul DNS name oppure aprire un browser e scegliere il nome che avete assegnato con il suffisso .cloudapp.net
Figura 20. La nostra applicazione pubblicata
(clic per ingrandire)
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.
