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 WebSite, Cloud Service e Virtual Machine: quale scegliere?

Capita, a volte, di dover iniziare un nuovo sviluppo o di dover pianificare una pubblicazione sul cloud, su Azure, ma di non sapere nel dettaglio che tipo di servizio è meglio utilizzare: dovrei usare un WebSite, un Cloud Service o una Virtual Machine? Che tipi di vantaggi / svantaggi ho in un caso o nell'altro?

Vediamo quelle che sono le principali differenze.

Attenzione: questo post è aggiornato con le info disponibili al 5 agosto 2014.

Innanzitutto uno schema, che usa Microsoft nella documentazione ufficiale di Azure, per comparare i 3 servizi:

Courtesy of Microsoft

In questa immagine è abbastanza chiaro il livello di semplicità vs possibilità di controllo che offrono le tre soluzioni. Volendo essere estremamente sintetici:

• WebSite:
• Soluzione estremamente semplice da utilizzare, che offre comunque un buon set di strumenti a supporto (monitoring, alerts, scale, ecc) ma a discapito del livello di personalizzazione e controllo sulla configurazione.
• In applicazioni multi-tier, fornisce il supporto alla solo web tier
• Cloud Service:
• Meno semplice da utilizzare e deployare rispetto ai Websites, fornisce un livello di controllo molto maggiore.
• Anche in questo caso ci sono diversi strumenti di monitoraggio e supporto già inclusi
• È possibile utilizzare sia i WebRole (che di fatto sono delle VM dedicate con installato IIS) sia i WorkerRole (sempre delle VM dedicate, ma senza IIS. È possibile paragonare un WorkerRole ad un Windows Service)
• In scenari multi-tier, è possibile utilizzare una combinazione di WebRole e WorkerRole per implementare sia il web tier che il middle-tier che il backend 
• In scenari multi-tier, è possibile scalare il frontend ed il backend in modo indipendente
• Virtual Machine:
• Lascia la configurazione e la personalizzazione completamente in mano all'utente, quindi è più complicata da gestire ma fornisce il massimo livello di controllo possibile, come con i server on-premises.
• Si possono utilizzare per qualsiasi tipo di applicazione ed architettura
• È necessario occuparsi manualmente della gestione del sistema, quindi anche di aggiornamenti, policy di sicurezza ecc ecc
• È la scelta ideale in scenari particolarmente complessi o quando si ha necessità di hostare servizi o software che non sono supportati nelle altre modalità.

Questa è la tabella ufficiale con la comparazione dei tre tipi di servizio:

FEATURE	WEB SITES	CLOUD SERVICES (WEB ROLES)	VIRTUAL MACHINES
Access to services like Service Bus, Storage, SQL Database	X	X	X
Host web or web services tier of a multi-tier architecture	X	X	X
Host middle tier of a multi-tier architecture		X	X
Integrated MySQL-as-a-service support	X	X 1	X
Support for ASP.NET, classic ASP, Node.js, PHP, Python	X	X	X
Scale out to multiple instances without redeploy	X	X	X 2
Support for SSL	X 3	X	X
Visual Studio integration	X	X	X
Remote Debugging	X	X	X
Deploy code with TFS	X	X	X
Deploy code with GIT, FTP	X		X
Deploy code with Web Deploy	X	4	X
WebMatrix support	X		X
Near-instant deployment	X
Instances share content and configuration	X
Scale up to larger machines without redeploy	X
Multiple deployment environments (production and staging)	X	X
Network isolation with Azure Virtual Network		X	X
Support for Azure Traffic Manager	X	X	X
Remote desktop access to servers		X	X
Ability to define/execute start-up tasks		X	X
Automatic OS update management	X	X
Integrated Endpoint Monitoring	X	X	X
Seamless platform switching (32bit/64bit)	X	X

1 Web or worker roles can integrate MySQL-as-a-service through ClearDB's offerings, but not as part of the Management Portal workflow.

2 Although Virtual Machines can scale out to multiple instances, the services running on these machines must be written to handle this scale-out. An additional load balancer must be configured to route requests across the machines. Finally, an Affinity Group should be created for all machines participating in the same role to protect them from simultaneous restarts from maintenance or hardware failures.

3 For Web Sites, SSL for custom domain names is only supported for standard mode. For more information on using SSL with Web Sites, see Configuring an SSL certificate for an Azure Web Site.

4 Web Deploy is supported for cloud services when deploying to single-instance roles. However, production roles require multiple instances to meet the Azure SLA. Therefore, Web Deploy is not a suitable deployment mechanism for cloud services in production.

Per vedere la comparazione completa dei tre servizi, costantemente aggiornata, è possibile consultare la guida ufficiale sulla documentazione di Azure