Archivio

Archive for the ‘Cloud’ Category

2017: fourteenth Award Microsoft Most Valuable Professional

award_mail

I am very happy and proud to have been awarded as Microsoft Most Valuable Professional for the fourteenth time in a row.

Even for 2017 I’m honored to be part of this selected group of experienced professionals in Microsoft technologies and, particularly, in Cloud and Datacenter Management expertise.

My sincere thanks, as always, to Cristina (@crisgherrero) for promoting my nomination.

Greetings and Happy New Year to all 🙂

2016: thirteenth Award Microsoft Most Valuable Professional

mvplogo

I am very happy and proud to have been awarded as Microsoft Most Valuable Professionalfor the thirteenth time in a row.

Even for 2016 I’m honored to be part of this selected group of experienced professionals in Microsoft technologies and, particularly, in Enterprise Mobility expertise.

My sincere thanks, as always, to Cristina (@crisgherrero) and Marjorie (@thisisjorie) for promoting my nomination.

Greetings and Happy New Year to all 🙂

Microsoft ASP.NET Universal Providers 2.0.0 with SQL Azure

Why GestPay of Banca Sella can’t be used in Azure e-commerce solution ?

Da circa un mese sto costruendo una soluzione di e-commerce basata su Windows Azure.

La scelta di portare nel cloud usa soluzione di e-commerce è dettata da due fondamentali motivazioni:

1) la prima è che l’organizzazione per la quale sto realizzando la soluzione non ha una struttura IT che possa permettersi di tenere “on premises” la soluzione e monitorarla in maniera adeguata;

2) la seconda è che Azure permette di gestire in maniera molto flessibile risorse ridondate che consentono di aumentare il numero di istanze della web app o di diminuirle fino a zero qualora il prodotto venduto non dovesse avere l’appeal necessario per i clienti, il tutto senza fare ingenti investimenti per lo start-up ma pagando solo un modesto canone di utilizzo (pay-per-use).

La scelta del cloud mi ha portato alla soluzione PaaS (Platform as a Service) di Windows Azure.

La soluzione, poiché si propone di vendere un servizio in abbonamento, non necessita di connessione ad un partner che si occupi della logistica e del delivery di prodotti ma solo di un partner che si faccia carico delle transazioni finanziarie.

La scelta iniziale del partner è ricaduta su quello forse più famoso in Italia come piattaforma per transazioni con carta di credito su siti di e-commerce ossia Banca Sella con il suo prodotto specifico denominato GestPay.

Dopo aver realizzato la soluzione di test ed aver fatto il deploy su Azure, sono trascorsi veramente pochi giorni prima di impattare nel problema che risponde alla domanda del titolo e che ora andrò a descrivere.

La prima parte del problema è questa: quando si effettua il deploy di una Web App su Windows Azure, dopo aver scelto l’alias della Web App ossia il nome con cui la mia applicazione sarà raggiungibile su internet, il pacchetto composto da Service e Model viene inviato al Web Portal. Quest’ultimo passa il Model al Fabric Controller, copia il Service su 3 istanze dei web servers nel Datacenter per ridondanza, assegna un VIP – Virtual IP alle tra istanze della web application ed associa sul DNS l’alias scelto in precedenza con il VIP ottenuto dal dhcp. In grafica

azure_deployment

Ovviamente Microsoft per garantire un servizio del genere ad una moltitudine di clienti ha assegnato dei range di indirizzi IP per ogni Datacenter da utilizzare per assegnare il VIP inoltre il Virtual IP non è fisso ma cambia nel tempo perché è il DNS che si preoccupa di mantenere sempre allineato l’alias scelto con il VIP temporaneamente assegnato alle istanze della mia applicazione.

I range di indirizzi IP assegnati ai vari Datacenter di Azure sono disponibili qui

Windows Azure Datacenter IP Ranges

e, in particolare, quelli per il Datacenter di Amsterdam che corrisponde alla zona denominata Europa Occidentale sono i seguenti:

<subregion name=”West Europe”>
<network>157.55.10.0/27</network>
<network>157.55.10.32/27</network>
<network>157.55.10.64/26</network>
<network>157.55.12.0/28</network>
<network>157.55.9.112/28</network>
<network>137.116.192.0/21</network>
<network>137.116.200.0/21</network>
<network>157.55.8.128/28</network>
<network>157.55.8.144/28</network>
<network>157.55.8.160/28</network>
<network>157.55.8.64/26</network>
<network>168.63.0.0/19</network>
<network>168.63.96.0/19</network>
<network>213.199.128.0/21</network>
<network>213.199.136.0/22</network>
<network>213.199.180.112/28</network>
<network>213.199.180.192/26</network>
<network>213.199.180.32/28</network>
<network>213.199.180.96/28</network>
<network>213.199.183.0/24</network>
<network>65.52.128.0/19</network>
<network>94.245.97.0/24</network>
<network>137.117.128.0/17</network>
<network>168.61.56.0/21</network>
</subregion>

mentre quelli per il Datacenter di Dublino che corrisponde alla zona denominata Europa del Nord sono i seguenti:

<subregion name=”North Europe”>
<network>213.199.160.0/20</network>
<network>213.199.184.0/21</network>
<network>137.116.224.0/19</network>
<network>157.55.230.160/27</network>
<network>157.55.3.0/24</network>
<network>168.61.80.0/20</network>
<network>168.61.96.0/19</network>
<network>168.63.32.0/19</network>
<network>168.63.64.0/20</network>
<network>168.63.80.0/21</network>
<network>168.63.92.0/22</network>
<network>65.52.224.0/22</network>
<network>65.52.228.0/22</network>
<network>65.52.248.0/21</network>
<network>65.52.64.0/20</network>
<network>94.245.104.0/21</network>
<network>94.245.112.0/20</network>
<network>94.245.88.0/21</network>
<network>137.116.224.0/19</network>
<network>157.55.230.160/27</network>
<network>157.55.3.0/24</network>
<network>168.61.80.0/20</network>
<network>168.61.96.0/19</network>
<network>168.63.32.0/19</network>
<network>168.63.64.0/20</network>
<network>168.63.80.0/21</network>
<network>168.63.92.0/22</network>
<network>65.52.224.0/22</network>
<network>65.52.228.0/22</network>
<network>65.52.248.0/21</network>
<network>65.52.64.0/20</network>
<network>94.245.104.0/21</network>
<network>94.245.112.0/20</network>
<network>94.245.88.0/21</network>
<network>137.135.128.0/17</network>
</subregion>

Come potete vedere sono parecchi e senza dimenticare la possibilità di ridondare il servizio su Datacenter lontani in America o in Asia.

La seconda parte del problema è quella che ci mette Banca Sella, la quale, adducendo improbabili motivi di sicurezza stabilisce che l’indirizzo ip pubblico dal quale il sito di e-commerce contatta il server di GestPay deve essere registrato nella configurazione di base dell’esercente del negozio virtuale utilizzando questa pagina

gespay_ip

dove, come si può vedere, posso inserire al massimo 10 indirizzi ip o meglio 10 sottoreti di indirizzi ip di classe C se utilizzo la wildcard * al posto dell’ultimo ottetto.

A questo punto è evidente che, se il VIP della mia applicazione su Azure può prendere dinamicamente un indirizzo ip appartenente ad un numero maggiore di range rispetto a quelli che posso definire nella pagina di configurazione di GestPay mostrata qui sopra, si otterrà prima o poi un fallimento nelle transazioni.

La soluzione sarebbe semplice se GestPay consentisse di definire l’alias del sito di e-commerce e non l’ip ma purtroppo così non è.

E’ stato inutile obiettare che,

  • essendo basate su stringhe criptate le comunicazioni tra web server del sito di e-commerce e server di GestPay
  • e potendo le transazioni generate solo immettere somme sul conto dell’esercente e non prelevarle,

era una precauzione inutile dover impostare come fissi gli indirizzi ip del sito di e-commerce quando poteva essere sufficiente definire l’alias…

… ma ovviamente Banca Sella non può adeguare così rapidamente il suo sistema all’evoluzione del cloud targato Microsoft quindi può solo essere il partner di commercianti virtuali che hanno il negozio “on premises” o in server farm con un indirizzo ip ben definito.

Alla prossima.

La mia prima applicazione nel Cloud

Volevo provare il brivido del Cloud perciò ho deciso di cimentarmi con la prima applicazione di test da pubblicare su Windows Azure ed ho utilizzato una buona guida per sviluppare e deployare una applicazione Asp.Net MVC 3 con connessione a SQL Azure.

La guida step-by-step è disponibile a questo link:

https://www.windowsazure.com/it-it/develop/net/tutorials/web-app-with-sql-azure/

Il primo step è solo quello di creare una applicazione ASP.NET MVC 3 predefinita, cambiare il titolo e pubblicarla in Azure. Parto quindi da Visual Studio 2010 con un’applicazione MVC 3 in cui ho cambiato solo il titolo in .Layout.vbhtml e, dopo l’autenticazione, inizio il deployment in Azure direttamente da Visual Studio

contemporaneamente dalla console di Azure si vede l’inizializzazione del ruolo e dell’istanza

In Visual Studio è possibile seguire passo passo il deployment

e, fino a quando l’istanza in Azure non viene messa in “up and running”, sotto Visual Studio continuiamo a vedere un “unknown state” ma, dopo un po’ di minuti, otteniamo un “Complete” come mostrato qui sotto

e finalmente la “bozza” di applicazione è pubblicata nel Cloud.

A questo punto bisogna aggiungere il controller con il nome di HomeController e creare la nuova istanza di SQL Azure configurando opportunamente il firewall di Azure per permettere l’accesso all’istanza di SQL.

Fatto ciò è opportuno disporre delle due trasformazioni del file Web.config che introducono le variazioni della configurazione base qualora si stia provando l’applicazione in debug o si usi l’applicazione rilasciata in produzione.

Le due trasformazioni dovrebbero già essere presenti in un progetto MVC 3 con i nomi Web.Debug.config e Web.Release.config ma se non lo fossero è possibile crearle facendo tasto destro sul Web.config e scegliendo “Add Config Transforms”.

Purtroppo nel mio caso l’opzione “Add Config Transforms” era disabilitata e i file per inserire le trasformate di configurazione non erano disponibili.

Che fare ?

La soluzione è stata recuperata qui

http://stackoverflow.com/questions/3577931/web-config-transformation-option-is-greyed-out

ed è la seguente:

I couldn’t see the transform files because vb.net in its infinite wisdom decided not to natively show the associated config files. Apparently there is no choice but to select “show all files” in order to see them.”

Una volta visibile il file Web.Release.config ho potuto scrivere la trasformazione indicata all’interno del file stesso.

A questo punto ho preso in considerazione quanto indicato nella nota che riporto integralmente:

“Nota: l’utente amministrativo ha accesso a tutti i database nel server. Per creare un utente di SQL Azure con autorizzazioni più limitate, effettuare i passaggi in Aggiunta di utenti al database di SQL Azure. Modificare la stringa di connessione per poter utilizzare la password e il nome utente appena creati anziché la password e il nome utente di amministratore.”

Poichè SQL Azure non dispone ancora di sufficienti strumenti di amministrazione per la manipolazione di utenti, il blog-post linkato è perfetto per quanto riguarda le informazioni necessarie alla creazione di utenti e per l’attribuzione a questi utenti di uno o più ruoli nel database, purtroppo non è corretto nel link necessario a connettersi a SQL Azure usando Sql Server Management Studio infatti il link riportato rimanda qui

http://blogs.msdn.com/b/sqlazure/archive/2010/05/18/10014309.aspx

mentre ho trovato le informazioni necessarie e precise a questo link

http://blogs.msdn.com/b/ramaprasanna/archive/2009/09/04/connecting-to-sql-azure-from-sql-management-studio-2008.aspx

Ovviamente, affinchè la connessione vada a buon fine è necessario modificare ancora la configurazione del firewall a protezione di SQL Azure andando ad aggiungere tra gli indirizzi consentiti anche l’ip della vostra macchina di sviluppo su internet.

A questo punto ho potuto procedere alla pubblicazione facendo notare che le modifiche alla ConnectionString sono state apportate solo nella trasformata We.Release.config e pertanto la pubblicazione su Azure va modificata mettendo

  • Environment: Production
  • Build configuration: Release

Una volta pubblicata in Azure l’applicazione non funzionava ancora perchè purtroppo nella guida si sono dimenticati di precisare in questo punto

  1. Nella sezione <configuration> / <connectionStrings> sostituire tutti gli elementi come indicato di seguito. Sostituire il segnaposto <serverName> con il nome del server creato. Per <user> e <password> immettere la password e il nome utente di amministratore creati in precedenza.

<connectionStrings> <add name=”ToDoDb” connectionString=”data source=<serverName>.database.windows.net;Initial Catalog=ToDoDb;User ID=<user>@<serverName>;Password=<password>;Encrypt=true;Trusted_Connection=false;MultipleActiveResultSets=True” providerName=”System.Data.SqlClient”/> <add name=”DefaultConnection” connectionString=”data source=<serverName>.database.windows.net;Initial Catalog=ToDoDb;User ID=<user>@<serverName>;Password=<password>;Encrypt=true;Trusted_Connection=false;MultipleActiveResultSets=True” providerName=”System.Data.SqlClient”/> </connectionStrings>

che all’interno di ciascuna connectionsString modificata va aggiunto anche

xdt:Transform=”SetAttributes” xdt:Locator=”Match(name)”

e questo alla fine permette l’uso delle connectionStrings modificate quando l’applicazione viene pubblicato come “Build configuration: Release” nel Cloud infatti a questo punto ho potuto inserire la mia prima attività nella lista

Ciao e buon Azure a tutti.

Categorie:Azure, Cloud, Developer, Sviluppo