Tag Archives: Azure
Deploy a new IIS Web Site with Azure DevOps Pipelines
I was experimenting with deploying a completely new Web Site to a machine with a brand new IIS installation to see what are the required parameter to do a basic deployment.I share here my findings. The best approach is to deploy with a deployment group job. This way can use the IIS tasks that Microsoft… Continue reading Deploy a new IIS Web Site with Azure DevOps Pipelines
GLV OnAir Febbraio 2019 – Video Link
Qualche settimana fa GLV ha trasmesso il suo episodio di GLV OnAir di febbraio 2019. La puntata è andata in onda col solito formato di 3 sessioni da 30 minuti ciascuna che elenco qui di seguito: GLV OnAir 2019-02- Terraform For Azure: the Good, the bad and the Ugly (Giulio Vian) GLV OnAir 2019-02- DevOps… Continue reading GLV OnAir Febbraio 2019 – Video Link
VSTS for beginners: release your web-app to Azure
In the previous post of this series dedicated to VSTS we talked about continuous integration. Now we’ll talk about publishing our Web-App hosted on Azure with the release management tools provided by VSTS. With this kind of tools we can deploy the latest version of our web-app to Azure in complete automation removing manual procedures […]
Deployare una Web App su Azure con la nuova Build di Visual Studio Online
In questo post vedremo come fare, iniziando da 0, a deployare una nostra soluzione su una Web App di Azure utilizzando la nuova Build di Visual Studio Online.
Per farlo, useremo esclusivamente il portale web di VSO.
Collegare Azure a VSO
Innanzitutto bisogna “far sapere” a Visual Studio Online che abbiamo un account Azure che vogliamo utilizzare come endpoint di deploy per la nostra soluzione.
Per farlo, dobbiamo andare nella parte dei setting del progetto (cliccando sull’apposito bottone presente in alto a destra, dopo essere entrati nella pagina del progetto), cliccare sulla tab “Services“, poi su “Add new Service Connection” ed infine su “Azure“.
A questo punto si aprirà un popup dove dovremo inserire l’ID della sottoscrizione Azure che contiene o conterrà la web app da pubblicare, un nome (anche se il campo si chiama “Subscription Name“, non è necessario usare il nome della sottoscrizione, si tratta di un campo di testo libero che ci servirà per identificare la sottoscrizione nel caso ne collegassimo più di una a VSO) e le modalità di autenticazione.
È possibile utilizzare sia un certificato (reperibile tramite il portale di Azure) sia direttamente le credenziali.
Fatto questo, la nostra subscription di Azure e il nostro account Visual Studio Online saranno collegati (almeno su questo team project).
Creare la build definition
Ora che abbiamo impostato la connessione tra VSO ed Azure, spostiamoci nella sezione Build del progetto e creiamo una nuova build definition di tipo deployment.
Siccome vogliamo deployare su Azure, nella sezione “Deployment” scegliere “Azure Website” come indicato nell’immagine.
Verrà create una nuova build definition con alcuni step da configurare.
Vediamo passo passo come procedere.
Il primo step rappresenta il vero e proprio processo di Build. È completamente configurabile, ma la cosa più importante è quella di definire il file di soluzione che dovrà essere utilizzato come source della build. Va selezionato nella casella indicata dalla freccia rossa.
Nel secondo step vanno inseriti i criteri di esecuzione post-build degli Unit Test. Se non abbiamo degli unit test (male…) oppure non vogliamo eseguirli (male anche questo 
) possiamo eliminare questo step cliccando sulla “X” che compare spostanto il mouse su questo step.
) possiamo eliminare questo step cliccando sulla “X” che compare spostanto il mouse su questo step.Il terzo step è quello che ci interessa di più in quanto è quello che si occupa di fare il deploy del risultato della Build verso la nostra web app su Azure.
Qui troviamo un menu a discesa in cui, se l’associazione della sottoscrizione Azure è andata a buon fine, troviamo le nostre sottoscrizioni collegate a VSO e possiamo scegliere quella che faà da target per il deploy.
Nella casella successiva, denominata “Web App Name” dobbiamo inserire manualmente il nome della Web App di destinazione. Come vedete in realtà si tratta anche in questo caso di una Combo Box, ma al momento attuale le Web App già esistenti non vengono caricate automaticamente (non dimentichiamo che questa nuova build è ancora in preview).
Ecco quindi alcuni consigli e note:
- Se inseriamo un nome di una web app che non esiste nella nostra sottoscrizione e che non esiste nella region selezioanta, verrà creata su Azure nella region selezionata
- Se inseriamo un nome di una web app che non esiste nella nostra sottoscrizione ma che esiste già in quella region, verrà restituito un errore in fase di deploy
- Se inseriamo un nome di una web app che esiste già nella nostra sottoscrizione ma che è in una region diversa, verrà restituito un errore in fase di deploy
- Se inseriamo un nome di una web app che esiste già nella nostra sottoscrizione e che si trova nella region selezionata, il deploy utilizzerà quella web app e la aggiornerà
Quindi attenzione a quello che scriviamo
I due step rimanenti danno la possibilità di indicizzare e pubblicare i simboli della nostra applicazione (consigliato per poter avere informazioni aggiuntive in caso di eccezioni non gestite) e di pubblicare gli artifact risultati dalla build.
Quando abbiamo impostato tutti i parametri, possiamo salvare la nostra build definition assegnandole un nome.
Possiamo anche modificare i vari parametri di default navigando nelle varie tab per personalizzare la build secondo le nostre esigenze.
Deployamo!
Una volta completate le personalizzazioni, è il momento di lanciare la compilazione e di verificare che il processo di deploy vada a buon fine.
Per lanciare la build, utilizziamo il bottone “Queue build” presente nella toolbar della build definition oppure nel menu contestuale della build stessa.
Quando clicchiamo su quel bottone, il sistema accoderà una build su un agente di compilazione presente sui nostri server oppure in un datacente Microsoft (nel caso in cui abbiamo scelgto di utilizzare la build “hosted”)
In ogni caso il progesso sarà visibile nella console real time presente sul web.
Prima verranno eseguiti i task di build e di test:
Poi, al successo di entrambi, il deploy verso azure:
Quando tutto sarà finito, avremo la nostra applicazione funzionante e deployata su Azure. Facile!
Deployare una Web App su Azure con la nuova Build di Visual Studio Online
In questo post vedremo come fare, iniziando da 0, a deployare una nostra soluzione su una Web App di Azure utilizzando la nuova Build di Visual Studio Online.
Per farlo, useremo esclusivamente il portale web di VSO.
Collegare Azure a VSO
Innanzitutto bisogna “far sapere” a Visual Studio Online che abbiamo un account Azure che vogliamo utilizzare come endpoint di deploy per la nostra soluzione.
Per farlo, dobbiamo andare nella parte dei setting del progetto (cliccando sull’apposito bottone presente in alto a destra, dopo essere entrati nella pagina del progetto), cliccare sulla tab “Services“, poi su “Add new Service Connection” ed infine su “Azure“.
A questo punto si aprirà un popup dove dovremo inserire l’ID della sottoscrizione Azure che contiene o conterrà la web app da pubblicare, un nome (anche se il campo si chiama “Subscription Name“, non è necessario usare il nome della sottoscrizione, si tratta di un campo di testo libero che ci servirà per identificare la sottoscrizione nel caso ne collegassimo più di una a VSO) e le modalità di autenticazione.
È possibile utilizzare sia un certificato (reperibile tramite il portale di Azure) sia direttamente le credenziali.
Fatto questo, la nostra subscription di Azure e il nostro account Visual Studio Online saranno collegati (almeno su questo team project).
Creare la build definition
Ora che abbiamo impostato la connessione tra VSO ed Azure, spostiamoci nella sezione Build del progetto e creiamo una nuova build definition di tipo deployment.
Siccome vogliamo deployare su Azure, nella sezione “Deployment” scegliere “Azure Website” come indicato nell’immagine.
Verrà create una nuova build definition con alcuni step da configurare.
Vediamo passo passo come procedere.
Il primo step rappresenta il vero e proprio processo di Build. È completamente configurabile, ma la cosa più importante è quella di definire il file di soluzione che dovrà essere utilizzato come source della build. Va selezionato nella casella indicata dalla freccia rossa.
Nel secondo step vanno inseriti i criteri di esecuzione post-build degli Unit Test. Se non abbiamo degli unit test (male…) oppure non vogliamo eseguirli (male anche questo ) possiamo eliminare questo step cliccando sulla “X” che compare spostanto il mouse su questo step.
) possiamo eliminare questo step cliccando sulla “X” che compare spostanto il mouse su questo step.Il terzo step è quello che ci interessa di più in quanto è quello che si occupa di fare il deploy del risultato della Build verso la nostra web app su Azure.
Qui troviamo un menu a discesa in cui, se l’associazione della sottoscrizione Azure è andata a buon fine, troviamo le nostre sottoscrizioni collegate a VSO e possiamo scegliere quella che faà da target per il deploy.
Nella casella successiva, denominata “Web App Name” dobbiamo inserire manualmente il nome della Web App di destinazione. Come vedete in realtà si tratta anche in questo caso di una Combo Box, ma al momento attuale le Web App già esistenti non vengono caricate automaticamente (non dimentichiamo che questa nuova build è ancora in preview).
Ecco quindi alcuni consigli e note:
- Se inseriamo un nome di una web app che non esiste nella nostra sottoscrizione e che non esiste nella region selezioanta, verrà creata su Azure nella region selezionata
- Se inseriamo un nome di una web app che non esiste nella nostra sottoscrizione ma che esiste già in quella region, verrà restituito un errore in fase di deploy
- Se inseriamo un nome di una web app che esiste già nella nostra sottoscrizione ma che è in una region diversa, verrà restituito un errore in fase di deploy
- Se inseriamo un nome di una web app che esiste già nella nostra sottoscrizione e che si trova nella region selezionata, il deploy utilizzerà quella web app e la aggiornerà
Quindi attenzione a quello che scriviamo
I due step rimanenti danno la possibilità di indicizzare e pubblicare i simboli della nostra applicazione (consigliato per poter avere informazioni aggiuntive in caso di eccezioni non gestite) e di pubblicare gli artifact risultati dalla build.
Quando abbiamo impostato tutti i parametri, possiamo salvare la nostra build definition assegnandole un nome.
Possiamo anche modificare i vari parametri di default navigando nelle varie tab per personalizzare la build secondo le nostre esigenze.
Deployamo!
Una volta completate le personalizzazioni, è il momento di lanciare la compilazione e di verificare che il processo di deploy vada a buon fine.
Per lanciare la build, utilizziamo il bottone “Queue build” presente nella toolbar della build definition oppure nel menu contestuale della build stessa.
Quando clicchiamo su quel bottone, il sistema accoderà una build su un agente di compilazione presente sui nostri server oppure in un datacente Microsoft (nel caso in cui abbiamo scelgto di utilizzare la build “hosted”)
In ogni caso il progesso sarà visibile nella console real time presente sul web.
Prima verranno eseguiti i task di build e di test:
Poi, al successo di entrambi, il deploy verso azure:
Quando tutto sarà finito, avremo la nostra applicazione funzionante e deployata su Azure. Facile!
Aggiungere Azure Application Insights ad un Web Site
Sviluppando una Web Application, è possibile usare Visual Studio 2013.3 per aggiungere automaticamente tutte le librerie e le configurazioni di cui “Azure Application Insights” ha bisogno pre funzionare.
Ma invece per quanto riguarda i Web Sites? Se si crea un Web Site (oppure si vuole modificarne o gestirne uno già esistente) l’opzione per aggiungere l’Application Insights non è presente. Cosa possiamo fare, quindi? Com’è possibile raggiungere lo stesso risultato? Come possiamo integrare Azure Application Insights in un Web Site?
È possibile! Basta seguire questi step:
-
Creare un nuovo servizio “Application Insights” usando il nuovo Azure portal (preview)
-
Copiare lo snippet di codice JavaScript che viene proposto dal portale ed aggiungerlo a tutte le pagine che si vogliono monitorare (oppure alla master page, se ce n’è una)
-
In Visual Studio 2013.3, creare una nuova web application vuota ed aggiungere ad essa Application Insights usando il menu contestuale
-
Copiare i seguenti file dalla cartella “bin” della Web App alla cartella “bin” del Web Site:
Microsoft.ApplicationInsights.dll
Microsoft.ApplicationInsights.Extensibility.RuntimeTelemetry.dll
Microsoft.ApplicationInsights.Extensibility.Web.dll
Microsoft.Diagnostics.Tracing.EventSource.dll
(volendo è possibile anche copiare i relativi file .xml e .pdb) -
Tornare nell’Azure portal (preview), andare nella sezione dell’Application Insights creato precedentemente, cliccare sul bottone “Properties” e copiare il valore della texbox “Instrumentation Key”
-
Copiare il file ApplicationInsights.config dalla root della Web App alla root folder del Web Site
-
In questo file, sostituire il valore della chiave “InstrumentationKey” con quello copiato al punto 5
-
Cambiare il file web.config del website aggiungendo le seguenti righe:
<system.web>
[...]
<httpModules>
[...]
<add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Extensibility.Web.RequestTracking.WebRequestTrackingModule, Microsoft.ApplicationInsights.Extensibility.Web" />
[...]
</httpModules>
[...]
</system.web>
<system.webServer>
[...]
<validation validateIntegratedModeConfiguration="false" />
[...]
<modules runAllManagedModulesForAllRequests="true">
[...]
<remove name="ApplicationInsightsWebTracking" />
<add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Extensibility.Web.RequestTracking.WebRequestTrackingModule, Microsoft.ApplicationInsights.Extensibility.Web" preCondition="managedHandler" />
[...]
</modules>
[...]
</system.webServer>
A questo punto è possibile avviare e testare il Web Site e, dopo qualche secondo, i dati e le statistiche saranno presenti nella blade dell’Application Insights (sempre sul nuovo Azure portal)
Aggiungere Azure Application Insights ad un Web Site
Sviluppando una Web Application, è possibile usare Visual Studio 2013.3 per aggiungere automaticamente tutte le librerie e le configurazioni di cui “Azure Application Insights” ha bisogno pre funzionare.
Ma invece per quanto riguarda i Web Sites? Se si crea un Web Site (oppure si vuole modificarne o gestirne uno già esistente) l’opzione per aggiungere l’Application Insights non è presente. Cosa possiamo fare, quindi? Com’è possibile raggiungere lo stesso risultato? Come possiamo integrare Azure Application Insights in un Web Site?
È possibile! Basta seguire questi step:
-
Creare un nuovo servizio “Application Insights” usando il nuovo Azure portal (preview)
-
Copiare lo snippet di codice JavaScript che viene proposto dal portale ed aggiungerlo a tutte le pagine che si vogliono monitorare (oppure alla master page, se ce n’è una)
-
In Visual Studio 2013.3, creare una nuova web application vuota ed aggiungere ad essa Application Insights usando il menu contestuale
-
Copiare i seguenti file dalla cartella “bin” della Web App alla cartella “bin” del Web Site:
Microsoft.ApplicationInsights.dll
Microsoft.ApplicationInsights.Extensibility.RuntimeTelemetry.dll
Microsoft.ApplicationInsights.Extensibility.Web.dll
Microsoft.Diagnostics.Tracing.EventSource.dll
(volendo è possibile anche copiare i relativi file .xml e .pdb) -
Tornare nell’Azure portal (preview), andare nella sezione dell’Application Insights creato precedentemente, cliccare sul bottone “Properties” e copiare il valore della texbox “Instrumentation Key”
-
Copiare il file ApplicationInsights.config dalla root della Web App alla root folder del Web Site
-
In questo file, sostituire il valore della chiave “InstrumentationKey” con quello copiato al punto 5
-
Cambiare il file web.config del website aggiungendo le seguenti righe:
<system.web>
[...]
<httpModules>
[...]
<add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Extensibility.Web.RequestTracking.WebRequestTrackingModule, Microsoft.ApplicationInsights.Extensibility.Web" />
[...]
</httpModules>
[...]
</system.web>
<system.webServer>
[...]
<validation validateIntegratedModeConfiguration="false" />
[...]
<modules runAllManagedModulesForAllRequests="true">
[...]
<remove name="ApplicationInsightsWebTracking" />
<add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Extensibility.Web.RequestTracking.WebRequestTrackingModule, Microsoft.ApplicationInsights.Extensibility.Web" preCondition="managedHandler" />
[...]
</modules>
[...]
</system.webServer>
A questo punto è possibile avviare e testare il Web Site e, dopo qualche secondo, i dati e le statistiche saranno presenti nella blade dell’Application Insights (sempre sul nuovo Azure portal)
Azure Web Sites Deploy: come funziona?
Gli Azure Web Sites supportano il continuous deployment da strumenti del controllo del codice sorgente e repository com BitBucket, CodePlex, Dropbox, Git, GitHub, Mercurial e TFS/VSO. È possibile infatti utilizzare questi strumenti per manutenere i contenuti ed i sorgenti del sito e poi pubblicare le modifiche in modo semplice e veloce.
 |
| Metodi di deploy supportati |
Usando un repository Git locale è possibile, ad esempio, fare la “promozione” manuale degli aggiornamenti da un progetto locale ad un Azure Web Site; deployando invece da strumenti come BitBucket, CodePlex, Dropbox, GitHub, TFS/VSO o Mercurial è possibile abilitare un processo di continuous deployment in cui sarà Azure stesso a fare il pull update più recenti del progetto.
Entrambi i metodi permettono di deployare i progetti su un Azure Web Site, ma il continuous deployment è utile quando ci sono più persone che lavorano su un progetto e ci si vuole assicurare che l’ultima versione sia sempre pubblicata indipendentemente da chi ha fatto l’aggiornamento più recente. Il continuous deployment è anche utile se viene utilizzato uno degli strumenti di cui sopra come repository centrale per l’applicazione.
Su internet ci sono un sacco di articoli che spiegano come fare il deploy di un Azure WebSite (ad esempio http://azure.microsoft.com/en-us/documentation/articles/web-sites-deploy/) o come implementare delle strategia di Continuous Deployment (es. http://azure.microsoft.com/en-us/documentation/articles/web-sites-publish-source-control/).
Ma come funziona in realtà “dietro le quinte”?
La risposta è “Kudu“.
Kudu è il motore che sta dietro il deployments degli Azure Web Sites, ma può anche funzionare al di fuori di Azure.
Ha un’architettura alquanto insolita, nel senso che è un servizio single-tenant anziché multi-tenant. Questo significa che ogni sito Web Azure ha una propria istanza del servizio Kudu, completamente distinta dalle istanze Kudu utilizzate per altri siti Azure.
Il componente rimane attivo in background e “controlla” se si verificano checkin, commit, nuovi file, build e così via. Quando rileva qualcosa, KuduSync inizia e fare il “lavoro sporco”.
Si tratta di uno strumento piuttosto interessante:
- è un progetto open source disponibile su GitHub (https://github.com/projectkudu/kudu)
- è installato automaticamente per ogni Azure Web Sites
- può utilizzare uno script di distribuzione personalizzato
Ma la cosa più importante (imho) è questa:
Il deployment viene creato nella struttura delle cartelle del sito web e il nuova deployment viene copiato nella root del sito, lasciando intatti i vecchi deployment.
Questo significa che è possibile fare il “rollback” a qualsiasi deploy fatto in passato!
È anche possibile accedere alla dashboard web di Kudu, utilizzando un url del tipo “https://your_website_name.scm.azurewebsites.net/” e le deployment credentials associate (oppure le credenziali di un amminisistratore del servizio).
 |
| Dashboard di Kudu |
Nella dashboard di Kudu è possibile trovare un sacco di informazioni utili sull’ambiente del tuo sito web insieme a una serie di strumenti per gestire il sito e, ultimo ma non meno importante, un set completo di API REST. C’è anche la possibilità di gestire le WebSite extension.
C’è anche un interessante video (in inglese) in cui David Ebbo e Scott Guthrie spiegano come funziona Kudu: http://channel9.msdn.com/Shows/Azure-Friday/What-is-Kudu-Azure-Web-Sites-Deployment-with-David-Ebbo
Azure Web Sites Deploy: come funziona?
Gli Azure Web Sites supportano il continuous deployment da strumenti del controllo del codice sorgente e repository com BitBucket, CodePlex, Dropbox, Git, GitHub, Mercurial e TFS/VSO. È possibile infatti utilizzare questi strumenti per manutenere i contenuti ed i sorgenti del sito e poi pubblicare le modifiche in modo semplice e veloce.
|
| Metodi di deploy supportati |
Usando un repository Git locale è possibile, ad esempio, fare la “promozione” manuale degli aggiornamenti da un progetto locale ad un Azure Web Site; deployando invece da strumenti come BitBucket, CodePlex, Dropbox, GitHub, TFS/VSO o Mercurial è possibile abilitare un processo di continuous deployment in cui sarà Azure stesso a fare il pull update più recenti del progetto.
Entrambi i metodi permettono di deployare i progetti su un Azure Web Site, ma il continuous deployment è utile quando ci sono più persone che lavorano su un progetto e ci si vuole assicurare che l’ultima versione sia sempre pubblicata indipendentemente da chi ha fatto l’aggiornamento più recente. Il continuous deployment è anche utile se viene utilizzato uno degli strumenti di cui sopra come repository centrale per l’applicazione.
Su internet ci sono un sacco di articoli che spiegano come fare il deploy di un Azure WebSite (ad esempio http://azure.microsoft.com/en-us/documentation/articles/web-sites-deploy/) o come implementare delle strategia di Continuous Deployment (es. http://azure.microsoft.com/en-us/documentation/articles/web-sites-publish-source-control/).
Ma come funziona in realtà “dietro le quinte”?
La risposta è “Kudu“.
Kudu è il motore che sta dietro il deployments degli Azure Web Sites, ma può anche funzionare al di fuori di Azure.
Ha un’architettura alquanto insolita, nel senso che è un servizio single-tenant anziché multi-tenant. Questo significa che ogni sito Web Azure ha una propria istanza del servizio Kudu, completamente distinta dalle istanze Kudu utilizzate per altri siti Azure.
Il componente rimane attivo in background e “controlla” se si verificano checkin, commit, nuovi file, build e così via. Quando rileva qualcosa, KuduSync inizia e fare il “lavoro sporco”.
Si tratta di uno strumento piuttosto interessante:
- è un progetto open source disponibile su GitHub (https://github.com/projectkudu/kudu)
- è installato automaticamente per ogni Azure Web Sites
- può utilizzare uno script di distribuzione personalizzato
Ma la cosa più importante (imho) è questa:
Il deployment viene creato nella struttura delle cartelle del sito web e il nuova deployment viene copiato nella root del sito, lasciando intatti i vecchi deployment.
Questo significa che è possibile fare il “rollback” a qualsiasi deploy fatto in passato!
È anche possibile accedere alla dashboard web di Kudu, utilizzando un url del tipo “https://your_website_name.scm.azurewebsites.net/” e le deployment credentials associate (oppure le credenziali di un amminisistratore del servizio).
|
| Dashboard di Kudu |
Nella dashboard di Kudu è possibile trovare un sacco di informazioni utili sull’ambiente del tuo sito web insieme a una serie di strumenti per gestire il sito e, ultimo ma non meno importante, un set completo di API REST. C’è anche la possibilità di gestire le WebSite extension.
C’è anche un interessante video (in inglese) in cui David Ebbo e Scott Guthrie spiegano come funziona Kudu: http://channel9.msdn.com/Shows/Azure-Friday/What-is-Kudu-Azure-Web-Sites-Deployment-with-David-Ebbo
Autoscale delle Virtual Machine con Microsoft Azure
Uno dei principali vantaggi che la piattaforma di Azure offre è la possibilità di scalare rapidamente le applicazioni in the cloud, in risposta alle fluttuazioni di carico.
Normalmente si scalano website o cloud services, ma se invece abbiamo le nostre applicazioni hostate su una Virtual Machine e le vogliamo scalare orizzontalmente? Anche questo è possibile.
Per farlo, vanno effettuati sostanzialmente 2 step: creare una Load Balanced Web Farm epoi configurare il servizio di AutoScale.
Ecco come:
Passaggi:
- Creare una VM Standard ed assegnarla ad un availability set
- Configurare la VM secondo le necessità (IIS, Application server, ftp, ecc…)
- Clonare la VM
- Sysprep
- Cattura
- Ricreare la VM originale ed aggiungere tutti gli endpoint necessari
- Creare la seconda VM senza “endpoint extra”
- Optional – ripetere il punto 3.4 per creare ulteriori VM
- Bilanciare le VM
- Cambiare gli endpoint sulla prima VM per creare un Load-Balanced set
- Aggiungere gli endpoint alla seconda (terza, ecc…) VM sul Load-Balanced set
- Ripetere i punti 4.1 e 4.2 per tutti gli endpoint che devono essere bilanciati
- Fare attenzione al Session State (se necessario)
- Configurare l’Autoscale
Dettagli:
3.1 – Sysprep
La prima cosa da fare quando si clona una VM Windows è il “sysprepping”. Su Linux c’è un’opzione simile sull’Azure agent. Il Sysprep fa in modo che la macchina possa essere clonata in una nuova VM personalizzando le impostazioni come hostname ed indirizzo IP.
Dopo il sysprep, la VM va spenta (se non si è selezionata l’apposita opzione che la spegne automaticamente). Può essere fatto in Remote Desktop, SSH oppure, semplicemente, dall’Azure portal.
3.2 – Cattura
A questo punto, nell’Azure portal bisogna andare sulla dashboard della VM e cliccare il bottone “Capture” per creare un immagine del disco della VM. Diamogli un nome e selezioniamo la checbox vicino a “Yes, I’ve sysprepped the machine” per poter continuare.
Dopo aver cliccato su “OK”, Azure creerà l’immagine del nostro server “originale”.
3.3 – Ricreare la VM originale ed aggiungere tutti gli endpoint necessari
Dopo che l’immagine è stata creata, si noterà che la VM che abbiamo appena “catturato”… non esiste più! È normale: la macchina è stata “smontata” per creare da essa un template. Ora quindi è possibile ricrearla semplicemente usando la nuova VM image appena create invece che uno dei template forniti da Microsoft.
Nella configurazione degli endpoint aggiungiamo di nuovo l’endpoint HTTP in ascolto sulla porta 80 o, comunque, tutti gli endpoint di cui abbiamo bisogno per poter utilizzare la nostra applicazione.
3.4 – Creare la seconda VM senza “endpoint extra”
Per creare la seconda VM nella webfarm basta creare una nuova macchina partendo sempre dall’immagine che è stata creata precedentemente.
Nello step 4 della creazione macchina assicuriamoci di selezionare lo stesso “Cloud Service” del primo server ed inserire la VM nello stesso availability set.
NON aggiungere ancora alla macchinal’endpoint HTTP (o gli altri endpoint configurati al punto 3.3).
Ora abbiamo due macchine “uguali” in esecuzione, ma non sono ancora sotto bilanciamento. Noterete che entrambe le macchine sono già esposte con lo stesso nome host e che condividono lo stesso indirizzo IP pubblico virtuale. Ciò è dovuto al fatto che abbiamo precedentemente linkato le VM selezionando lo stesso Cloud Service. Se non lo fate, non sarete in grado di utilizzare il sistema di bilanciamento di carico che Azure fornisce out-of-the-box. Questo significa anche che l’endpoint per il desktop remoto pubblico dovrà essere diverso per entrambe le macchine: c’è un solo indirizzo IP esposto al mondo esterno quindi dovrete pensare voi a differenziare l’endpoint.
4.1 – Cambiare gli endpoint sulla prima VM per creare un Load-Balanced set
L’ultima sezione per configurare la nostra webfarm è il load balancing. Di fatto, configurarlo è molto semplice.
Come prima cosa, andare sulla pagina “Endpoints” della prima VM, Selezionare un Endpoint che deve essere bilanciato ed andare in modifica.
Selezionare il checkbox “Create a Load-Balance set”.
Nello step 2 della configurazione, dare un nome al Load-Balanced set e configurare i parametri di probe (nell’esempio, ho configurato un endpoint HTTPS, quindi voglio che sia monitorata ogni 15 secondi la risposta della porta 443. Dopo 2 tentativi falliti, il bilanciatore switcherà sull’altra macchina in via esclusiva)
4.2 – Aggiungere gli endpoint alla seconda (terza, ecc…) VM sul Load-Balanced set
Andare sulla dashboard della seconda VM, sull’Azure portal, e selezionare anche in questo caso la tab “Endpoints”. Abbiamo gia aggiunto l’endpoint HTTPS alla prima macchina, quindi per la seconda basta “sottoscrivere” il load balanced set creato:
A questo punto abbiamo attivo il bilanciamento di carico con round-robin, che ogni n secondi verificherà che tutte le macchine e tutti gli endpoint configurati siano attivi e funzionanti. E visto che abbiamo linkato le VM attraverso un availability set, saranno in differenti fault domains nel datacenter riducendo il rischio di malfunzionamenti o errori dovuti a problemi hardware o manutenzione. È possibile anche spegnere tranquillamente una VM. Sostanzialmente, tutto quello che ci si può aspettare da un load balancer (ad eccezione delle sticky sessions).
4.4 – Fare attenzione al Session State (se necessario)
Ora che abbiamo le nostre VM bilanciate, dobbiamo stare attenti a come la nostra applicazione gestisce il session state.
Se, per esempio, stiamo deployando dei web server con sopra delle applicazioni Asp.Net dobbiamo configurare le machine key ed il sessione state nello stesso modo in cui lo faremmo se fossimo in un ambiente on-premise. Su Azure è possibile scegliere di usare la “solita” base dati delle sessioni (quindi Session state memorizzato su un Azure database), oppure usare l’Azure storage o ancora la “nuova” Azure cache.
Visitate questo link su msdn (http://blogs.msdn.com/b/cie/archive/2013/05/17/session-state-management-in-windows-azure-web-roles.aspx) per avere una panoramica della gestione del Session State su Azure.
5 – Configurare l’Autoscale
Ok, è giunto il momento di configurare l’autoscale!
Ora abbiamo le nostre VM attive e bilanciate. Ma abbiamo veramente sempre bisogno di averle tutte attive nello stesso momento? Probabilmente no. Magari abbiamo bisogno di averle tutte attive solo in una determinata fascia oraria oppure solo se il carico sull’applicazione supera una certa soglia…
Ora abbiamo le nostre VM attive e bilanciate. Ma abbiamo veramente sempre bisogno di averle tutte attive nello stesso momento? Probabilmente no. Magari abbiamo bisogno di averle tutte attive solo in una determinata fascia oraria oppure solo se il carico sull’applicazione supera una certa soglia…
Se vi ricordate, quando abbiamo creato le nostre VM abbiamo selezionato per tutte lo stesso Cloud Service. Ebbene, per configurare l’autoscale delle VM basta andare a configurare quello del relativo Cloud Service: andare quindi sulla dashboard del servizio e selezionare la pagina “Scale”.
Da qui è possibile selezionare il tipo di scaling che vogliamo: None (scalign disattivato…), Cpu (in base a delle soglie di utilizzo del processore) o Queue.
Nel mio caso, ho deciso di scalare usando la percentuale di utilizzo della CPU come parametro. Lo slider “Target CPU” riporta che io voglio scalare “in più” quando la media dell’utilizzo della CPU supera l’80% e scalare “in meno” quando riscende sotto il 60%.
Nel mio esempio ho solo 2 VM, quindi posso configurare che in condizioni normali ce ne sia solo 1 attiva e che la seconda venga abilitata solo in caso di “scale up”.
Dalla stessa schermata è anche possibile selezionare che il servizio scali automaticamente in base a delle fasce orarie configurabili.
Login