Mar/100
Configurar el firewall de SQL Azure
Si estamos realizando un desarrollo con acceso a una base de datos de SQL Azure, tendremos que configurar una serie de parámetros para que nos funcione.
Para tener acceso a la base de datos remotamente desde nuestro entorno de desarrollo, debemos crear una nueva regla al firewall de SQL Azure – que por defecto está configurado para rechazar todas las peticiones – y habilitar el acceso a nuestra IP. Para esto vamos al portal de gestión de SQL Azure (http://sql.azure.com) y accedemos a la pestaña de Firewall Settings.
Añadimos una nueva regla indicándole nuestra IP, que nos facilita el mismo formulario en la parte inferior.
Si tenemos una IP variable, podemos agregar un rango de valores. Nos advierten que la nueva regla tardará unos 5 minutos en replicarse, y no mienten
Bien, con este cambio ya podemos acceder desde la maquina local, con el Management Studio o desde nuestra aplicación con la cadena de conexión específica, que debería ser de este tipo:
connectionString="Server=tcp:xxxxxxxxxx.database.windows.net;Database=DemoGlopez;User ID=MyUsername;Password=MyPassword;Trusted_Connection=False;Encrypt=True;"
Para verificar esto, en un rol de ASP.NET de un proyecto Cloud Service, ponemos un simple código de acceso a datos, podría servir este:
using (SqlConnection con = new SqlConnection(System.Configuration.ConfigurationManager.ConnectionStrings["DemoConnectionString"].ConnectionString)) { using (SqlCommand com = new SqlCommand("select id, nombre from Demo", con)) { con.Open(); using (SqlDataReader reader = com.ExecuteReader()) { while (reader.Read()) { Response.Write(reader["id"].ToString()); Response.Write(reader["nombre"].ToString()); Response.Write("<br/>"); } } } }
Ejecutamos y vemos que todo funciona bien (debemos crear una tabla en nuestra base de datos y modificar la consulta del command de este ejemplo para adaptarlo a nuestro entorno).
Ahora hacemos un Deploy de esta simple aplicación y veremos que falla (tendremos que deshabilitar los customErrors para que se nos muestre el mensaje de error).
Parece que seguimos teniendo problemas de acceso a SQL Azure, asi que volvemos al panel de gestión y hacemos un Test Connectivity (hay que tener seleccionada la base de datos), comprobamos que la conexión falla desde la IP del servidor dónde está alojada la aplicación.
Volvemos al Firewall Settings y marcamos el check de Allow Microsoft Services access to this server. Repetimos el Test Connectivity y ahora funciona.
Bien, volvemos a ejecutar nuestra aplicación, pero aún sigue fallando!

Cannot open server 'xxxxxxxxxx' requested by the login. Client with IP address '65.52.138.89' is not allowed to access the server.
Esto es un problema de la plataforma, debería funcionarnos, pero parece que hay un fallo con los rangos de IP que tienen permitidos internamente (info: http://tinyurl.com/yf46fxk). Así que nos toca añadir la IP del servidor como regla en nuestro firewall de SQL Azure hasta que esto se solucione.
Debería quedarnos una configuración de firewall así:
Y ahora nuestra aplicación funcionará correctamente.
Existe la posibilidad de administrar las reglas del firewall mediante procedures de la base de datos si no queremos utilizar el portal de gestión. Accedemos a la base de datos master de nuestro SQL Azure y utilizamos las siguientes sentencias:
-- Reglas existentes SELECT * FROM sys.firewall_rules -- Añadir nueva regla de firewall exec sp_set_firewall_rule N'DemoTSQL','0.1.1.0','0.1.1.255' --Modificar una regla de firewall exec sp_set_firewall_rule N'DemoTSQL','0.1.1.1','0.1.1.255' --Eliminar una regla de firewall exec sp_delete_firewall_rule N'DemoTSQL'
Feb/100
Cómo cuenta Azure las horas de proceso de instancia
Cuando empiezas a hacer cálculos sobre estimaciones de costes para subir una aplicación a la nube, enseguida te das cuenta dónde están los costes reales, en las horas de proceso y en el ancho de banda. En una aplicación con un tráfico que empieza a ser considerable ( por ejmeplo, > 5GB/hora). Las horas de proceso, pueden representar el 25% de la factura. Por lo tanto es importante conocer como computa Microsoft las horas que consumimos de proceso.
Lo primero que hay que saber, es que aunque no hagas un uso real de cpu, pagas por todas las horas que tengas tu aplicación levantada, y si tienes la aplicación levantada 5 minutos, pagas una hora completa.
Hasta aquí, no son noticias geniales, pero funciona similar a otros productos como Amazon EC2.
Lo que me ha parecido curioso y creo que es importante conocer, es que cuando mantienes una aplicación en estado de Parada o suspendida, continua computando horas. Eso quiere decir que si mantienes el entorno de producción levantado y el de staging, stopped, estás consumiendo 48h al día!
Para evitar esto, tenemos que eliminar la aplicación.
Si mantenemos un entorno como el de la imagen, gastamos 1h de proceso, si le damos a suspend, continuaremos consumiendo esa hora de proceso, debemos hacer un Delete para dejar de consumir esos recursos. Los dos entornos debería aparecernos como el de Production de la imagen.
Visto en: blog de Ryan Dunn
Ene/100
Ideas para mejorar Windows Azure?
Si eres de los que han podido probar la plataforma windows Azure en este mes de lanzamiento y has encontrado puntos a mejorar o funcionalidades interesantes que te han faltado, los chicos de Microsoft tienen habilitado un espacio para que compartas esas propuestas o votes por las presentadas por otros usuarios. Me parece una gran idea y una buena manera de recibir feedback para un producto nuevo.
www.mygreatwindowsazureidea.com
Leído hoy en el Team Blog de Windows Azure.
Ene/101
Migrar base de datos a SQL Azure
Siguiendo con el tema de la nube, hoy toca comentar alguna cosa sobre SQL Azure.
Vuelvo a enlazar al blog de Gisela Torres como referencia a como configurar y conectarse con SQL Server 2008 R2 November CTP, lo de la versión no es que me haga ilusión, es que es necesario para disfrutar de todas las características.
Sql Azure con Management Studio
A mí me gustaría ampliar la información con un ejemplo de migrar una base de datos existente a SQL Azure.
Accedemos con el management studio a nuestra instancia local, seleccionamos la base de datos que queremos migrar a SQL Azure y vamos a la opción de Tasks -> Generate Scripts
Nos salta un wizard, pasamos la introducción y en la siguiente pantalla nos da la opción de seleccionar que objetos de BD queremos incluir en el script, podemos marcar todos o seleccionar manualmente las tablas, vistas, procedures, etc…
Siguiente pantalla, seleccionamos dónde queremos guardar el resultado y nos vamos a la opción Advance.
Aquí lo más importante es marcar la opción Script for the database engine type a SQL Azure Database.
Este cambio nos deshabilitará varias opciones que no están soportadas en SQL Azure.
Marcamos también la propiedad Types of data to script con a Schema and Data para que genere todos los INSERTS de los datos que contiene la BD y no sólo la estructura.
Con esto, el wizard ya tiene suficiente información, le damos next y nos genera nuestro fichero .sql que podemos utilizar para ejecutar en la BD de SQL Azure.
Recordad crear la BD desde la plataforma de SQL Azure, configurad el firewall!, al conectaros a SSMS especificad la BD a la que os queréis conectar y una vez ejecutado el script, tendremos la migración completa. Toda la información sobre cómo hacer lo descrito en este último párrafo con más detalles en los links mencionados al principio del post.
Ene/101
Añadir una aplicación web existente en Azure
Por temas de trabajo me está tocando ponerme al tanto en Windows Azure, no puedo quejarme
Ya hay buenos artículos sobre cómo crear nuevas aplicaciones web y publicarlas en Azure.
Enlace: Subir una aplicación a Windows Azure
Aquí voy a tratar de explicar cómo publicar una aplicación web que ya teníamos creada.
Lo primero que debemos hacer es preparar nuestro entorno si aún no lo hemos hecho.
Vamos a la página http://www.microsoft.com/windowsazure/ y buscamos el enlace que dice Get Tools & SDK
Nos descargamos el fichero y lo instalamos. Revisad las system requeriments, yo tuve que instalar IIS 7.0 que por defecto no viene en Windows 7.
Después de esto, arrancamos Visual Studio 2008, hay que ejecutarlo en modo administrador para darle permisos al Development Fabric.
Nos vamos a crear un nuevo proyecto, tendremos un nuevo tipo, Windows Azure Cloud Service dentro de la pestaña Cloud Service.
Cuando le demos a aceptar, VS nos lanzara un nuevo wizard:
En este caso, como agregaremos después nuestro proyecto, le damos a Ok sin agregar nada a la solución.
Visual Studio nos ha creado un proyecto:
Que sólo contiene los ficheros de configuración del servicio Azure.
Ahora, agregamos nuestro proyecto web a la solución, botón derecho sobre la solución -> Add -> Existing Project y este es uno de los puntos importantes, y es que actualmente Azure no soporta los Web Site. No podemos hacer uso de Add -> Existing Web Site… Esto quiere decir que nuestra aplicación web debe estar en una ASP.NET Web Application o ASP.NET MVC Web Application.
Una vez agregado el proyecto, nos vamos a la carpeta Roles del cloud service y hacemos botón derecho Add -> Web Role Project in solution
Nos aparece una pantalla con todos los proyectos de la solución, en este caso sólo uno, lo seleccionamos y le damos Ok. Visual Studio ya nos ha creado el enlace y la configuración para la aplicación web. Ya podemos dar F5 y trabajar!
Para publicar en Azure seguid el post enlazo al inicio de ‘Subir una aplicación a Windows Azure’.
















