A continuación os dejo los materiales del evento de TenerifeDev “Desarrollando WebApps en la nube”. Felicidades a todos los que se llevaron obsequio de nuestros patrocinadores PluralSight y Telerik.
Imágenes del evento
Vídeo completo de la sesión
domingo, 16 de octubre de 2011
viernes, 14 de octubre de 2011
Conectar una Azure Cloud Drive directamente a tu equipo
Y es que desde mi última entrada sobre cómo editar los contenidos de un VHD en Azure y pensando que aún así debería haber un método más fácil para actualizar los contenidos de un VHD, empecé a barajar la idea de usar el actual servidor SMB del DNN Azure Accelerator mezclado con Windows Azure Connect.
¿Qué es Windows Azure Connect?
Hace tiempo que ya escribí una entrada sobre este servicio de Windows Azure –aún en CTP y gratuito de momento- pero por simplificar, resumámoslo en que es un componente para poder crear redes virtuales entre “tu mundo” y Windows Azure. Con ello consigues, por ejemplo, ver las máquinas que están en la nube como si estuvieran en tu red local: les puedes hacer un ping, puedes ver el equipo a través de la red si tiene habilitada su regla en el firewall...¿cómo? ¿qué puedes ver los equipos en Windows Azure por la red y ver sus ficheros?
Y ahí está el quid de la cuestión. Si ya en el mismo DNN Azure Accelerator los web roles acceden por la red para publicar los contenidos del worker role SMB, ¿por qué no podría conectarme desde mi equipo a esa misma unidad compartida para modificar los contenidos a través de una red virtual creada por Windows Azure Connect?
La respuesta es: ¡Y por qué no! Sí, por supuesto que se puede. Y esta entrada trata de explicar los pasos para configurarlo de forma manual.
¿Qué necesito?
Para poder conectar tu equipo a una unidad VHD en Azure, necesitarás lo siguiente:
- Una suscripción activa a Azure sobre la que vas a desplegar tanto los servicios de computación (servidor de ficheros) como el almacenamiento. Puedes crearte una en http://www.windowsazure.com.
- Un servidor worker role que monte la unidad VHD y la comparta, habilitando el tráfico SMB (puerto 445). La forma más sencilla es montar el paquete DNN Azure Single and ExtraSmall del DNN Azure Accelerator. Si quieres construirte tu propio servicio te recomiendo le eches un vistazo a este post de Dinesh Haridas.
Pasos a seguir
1) Habilitar en la suscripción el servicio Windows Azure Connect. Como ahora mismo aún está en CTP, deberás solicitar su activación a través del menú de “programas BETA” en la consola de administración de Windows Azure. La parte buena es que mientras está en CTP, este servicio es gratuito.
2) Usar el “Relay” de Connect más cercano a tus servicios. Para ello, pulsa sobre el botón “Relay Region” e indica la región más cercana. Supuestamente también usarás la misma región para desplegar tu servidor más adelante.
3) Instalar el cliente de Connect en tu equipo local (o desde donde quieras acceder a tu unidad compartida en la nube). Para ello, accede desde la sección “Red Virtual” de la consola de administración de Azure, y selecciona la suscripción. pulsa sobre el botón “Instalar extremo local”, siguiendo las instrucciones en pantalla.
Una vez instalado, podrás ver en el área de notificación de la barra de tareas de Windows el icono correspondiente al servicio.
4) Obtener un token de activación de Azure para el servidor SMB que se desplegará en Azure. Para ello, pulsamos el botón “Obtener Token de Activación” de la misma consola de Windows Azure. Copiamos el “guid” que nos devuelve en el portapapeles porque lo vamos a usar en el paso siguiente.
5) Desplegar el servidor SMB en Azure conectado con Windows Azure Connect. Tal y como se comentó anteriormente, una forma rápida es usar el paquete DNN Azure Single and ExtraSmall del DNN Azure Accelerator. Sin embargo, el paquete que está compilado e incluido dentro de la descarga, no tiene habilitado Windows Azure Connect –sí lo estará en la próxima versión del Accelerator. Mientras tanto, puedes descargar la última versión del código fuente y abrirlo en Visual Studio 2010, modificando las propiedades de Red Virtual del paquete antes de volver a generarlo.
6) Una vez que hemos desplegado el paquete en Azure (hay un excelente video al respecto, por lo que me voy a saltar esa parte), volvemos a la sección de Red Virtual de la consola de administrador de Windows Azure para habilitar la interconexión entre nuestro equipo y el rol desplegado, creando un nuevo grupo. En la imagen siguiente se muestra un ejemplo donde conecto con dos servidores SMB distintos ubicados en dos servicios distintos (realmente 2 instancias de DotNetNuke en Azure):
7) Con esto, ya deberíamos ver el equipo remoto en la nube ejecutando un simple ping. Para ello, copiamos la dirección IPv6 del equipo remoto de la misma consola de administración, y en una consola de comandos de DOS escribimos ping <direccionIPv6>.
No os asustéis por el ping de la imagen. En el momento de la captura estaba conectado a través de una red 3G y me estaba dando más del doble de tiempo de conexión.
NOTA: en caso de que no haya respuesta de ping, puede ser que nuestro equipo local no tenga habilitada la regla en el firewall. Para ello ejecutamos el comando siguiente:
netsh advfirewall firewall add rule name="ICMPv6" dir=in action=allow enable=yes protocol=icmpv6
Para resolver más problemas de conectividad, puedes consultar el enlace siguiente: http://msdn.microsoft.com/en-us/library/gg433016.aspx
8) Mapear la unidad de red a nuestro equipo local. Para ello, abrimos en el explorador de Windows la ventana de “Conectar nueva unidad de red...”, introduciendo la ruta: \\<IPv6>.ipv6-literal.net\<carpeta>, donde <IPv6> es la dirección remota a la que hemos hecho ping en el paso anterior sustituyendo el carácter “:” por “-“ (es la nomenclatura para el comando “net use”), y <carpeta> es el nombre del recurso compartido. Las credenciales usadas son las mismas que usamos al desplegar el servicio en Azure (ver fichero de configuración del servicio desplegado).
Opcional: yo he usado el archivo c:\windows\system32\drivers\etc\host, añadiendo un alias para la IPv6 con un nombre más común. Así sé qué unidad es de cada servidor sin tener que recordar la IPv6. También hay que tener en cuenta que esta IPv6 puede cambiar al reiniciarse el servidor por cualquier motivo, por lo que éste último paso 8 habría que repetirlo de nuevo. Una opción podría ser crear una aplicación cliente que detectara estos cambios y que hiciera un “remap” de las unidades automáticamente.
Conclusiones
El resultado es el poder modificar el contenido del VHD directamente desde nuestro equipo. Las posibilidades se me amontonan en la cabeza. Siempre hay que tener en cuenta que trabajaremos con nuestro ancho de banda a Internet –que por cierto, va impresionantemente bien con una conexión lenta-, por lo que para operaciones “grandes” de copia/pega de archivos sobre la misma unidad, compresión masiva de carpetas, etc. es recomendable conectarse al servidor SMB vía escritorio remoto.
Respecto al DNN Azure Accelerator, comenzaré a trabajar para poner un paso en el asistente para no tener que volver a recompilar el paquete en Visual Studio, tal y como hice con el paso de configuración RDP. En breve estará disponible.
Algunas reflexiones
- Sabiendo que la facturación del espacio consumido por los VHD (Page Blobs) es por “espacio ocupado” (las páginas vacías del VHD no se cobran), ¿te has parado a pensar que podrías tener unidades virtuales en Azure Storage de 1Tb (1.000Gb) cada una en la que Microsoft sólo te cobraría por el espacio utilizado? Si borras ficheros del disco (y lo mantienes desfragmentado), te baja la factura
- ¿Qué tal funcionarán los sistemas de backups tradicionales con una unidad de red montada de este modo? Está claro que aquí el cuello de botella lo impone el ancho de banda de tu conexión a Internet, pero normalmente los programas de copias de seguridad realizan modificaciones incrementales ==> Esto tengo que probarlo
- Tal y como comentó Joe Brinkman, actualizar tu web de DotNetNuke se convierte en cosa de niños simplemente copiando y pegando archivos a través del mismo explorador de Windows:
- ¿Qué tal funcionaría una instancia ExtraSmall si sólo es para servir ficheros a través de la red?
Ya sólo faltaría algún método de alta disponibilidad para el servidor SMB...pero eso también está a punto de llegar...
Espero que sea de utilidad. Para mí lo es...¡y mucho!
domingo, 2 de octubre de 2011
Modificar las credenciales RDP en los roles de Azure sin Visual Studio
Y es que aunque Visual Studio nos automatiza mucho esta tarea, hay perfiles “no desarrolladores” (por ejemplo, nuestros compis de IT) que no suelen tener instalado Visual Studio en sus equipos, aunque posiblemente sí se tengan que encargar del depliegue y gestión de roles en Azure (¿ha llegado ese momento?).
Para ello usaremos:
- Utilidad makecert.exe, para generar los certificados
- Consola de comandos de PowerShell
NOTA: el paquete “cspkg” a desplegar en Azure estará “compilado” como que tiene RDP habilitado (es decir, que el fichero de definición del servicio tiene importado los espacios de nombres de RemoteAccess, etc.). Aquí lo que se trata es de poder usar otras credenciales que las que se crearon en tiempo de compilación, así como otro certificado.
Generando manualmente el certificado X509
1) Crear un certificado a través de línea de comandos con la utilidad “makecert.exe”, haciendo exportable la clave:
makecert.exe -r -pe -a sha1 -ss My -len 2048 -sky exchange -n "CN=Azure Deployment" mycertificate.cer
Es importante indicar el parámetro “-sky exchange” ya que si no nos encontraremos con el error “The remote desktop certificate with thumbprint ‘xxx’ does not have a type of key exchange and cannot be used for decryption” al intentar usar este certificado en Azure.
2) Exportar el certificado en formato “PFX” para subirlo y asociarlo al servicio en Azure. Para ello:
- Abrimos el gestor de certificados desde una consolad e comandos tecleando “certmgr.msc”
- Localizamos el certificado que acabamos de generar y pulsamos el botón “Exportar” para abrir el asistente de exportación
- Seguimos las instrucciones del asistente, exportando la clave privada así como todas las propiedades extendidas del certificado
- Finalmente introducimos una contraseña que usaremos en el momento de importarlo en Azure y un nombre de fichero “.pfx”
3) Importar el certificado en Windows Azure a través de la consola de administración de Azure. Importamos el certificado pulsando botón derecho sobre el servicio y agregando el fichero y su contraseña que hemos generado:
Generar la contraseña encriptada
El siguiente paso, es generar la contraseña que deseemos para nuestras credenciales RDP. Una de las formas más sencillas, para los amantes de PowerShell, es a través de la consola usando los pasos siguientes:
1) Abrir una consola de comandos PowerShell, a través de Inicio>Accesorios>Windows PowerShell (ejecutar como “Administrador” pulsando el botón derecho sobre el icono)
2) Ejecutar los comandos siguientes pulsando Enter después de cada línea:
[Reflection.Assembly]::LoadWithPartialName("System.Security")
$pass = [Text.Encoding]::UTF8.GetBytes("<Password>")
$content = new-object Security.Cryptography.Pkcs.ContentInfo –argumentList (,$pass)
$env = new-object Security.Cryptography.Pkcs.EnvelopedCms $content
$env.Encrypt((new-object System.Security.Cryptography.Pkcs.CmsRecipient(gi cert:\CurrentUser\My\<Thumbprint>)))
[Convert]::ToBase64String($env.Encode())
Recuerda cambiar el valor "<Password>” por la contraseña que desees. También debes modificar el valor “<Thumbprint>” por la huella del certificado que generaste en la sección anterior. La forma más sencilla de encontrar este valor es en el panel de control de Windows Azure, seleccionando el certificado y viendo las propiedades en la barra lateral derecha:
3) Copia esa información en el Notepad, eliminando los caracteres de nueva línea.
Introduciendo los valores en el fichero de configuración del servicio
Finalmente, con los valores anteriores, abrimos el fichero de configuración del servicio (.cscfg) y modificamos los valores solicitados:
Indicar que la fecha de expiración de la cuenta debe estar en formato ISO 8601 “yyyy'-'MM'-'dd'T'HH':'mm':'ss'.'fffffffK”.
Conclusión
Como hemos visto, hemos realizado todo el proceso sin tener que tocar Visual Studio. Del mismo modo, todo este proceso puede automatizarse programáticamente a través de .NET, creando una simple utilidad para facilitar las labores a nuestros compañeros.
Un ejemplo de esta implementación, es el nuevo paso en el asistente del DNN Azure Accelerator en el que se simplifica la generación del certificado, se solicitan estas credenciales y se encriptan en un sólo paso (idéntico al que está en Visual Studio 2010!!).
Os dejo con dos capturas de pantalla como avance. Lo subiré a CodePlex en breve:
Espero que sirva de ayuda.
Un saludo a todos.
miércoles, 28 de septiembre de 2011
[Evento] Desarrollando aplicaciones web en la nube
AVISO: Cambio de hora a las 16:00 GMT+0 y con posibilidad de verlo por webcast en directo. Ver detalles más abajo.
Si tienes problemas con el enlace del correo de confirmación del webcast, usa este (se abre a las 15:30) https://www.livemeeting.com/cc/_XML/wwe_uk/join?id=1032496233&role=attend&pw=97480C47
Si alguien asistió a la charla en la TLP2k11 o al CMS Azure RoadShow de Julio que no se preocupe, porque esta vez nos centraremos en aspectos más técnicos: cómo crear una extensión para DotNetNuke con Visual Studio 2010 –o sea, una aplicación sobre DNN-, cómo desplegarla en Azure y/o distribuirla e incluso cómo llegar a ganar dinero con ello.
Por supuesto veremos algunas de las mayores novedades de DNN 6.0 (C#, jQuery, acelerador para Windows Azure, etc.) y como no, sortearemos algunos regalos de nuestros patrocinadores. Recordar que en la última charla Telerik repartió licencias de su suite de controles para ASP.NET y Windows Phone 7. Felicidades a C. Martin y Marcos G.D. que fueron los agraciados. Pluralsight no se quedó atrás y repartió 1 mes de regalo de toda su oferta de cursos en línea a todos los asistentes.
Os dejo los detalles de la charla. No podéis faltar.
P.D. la de Windows 8…en breve, cuando a Alberto deje de caérsele la baba
Evento TenerifeDev - Desarrollando aplicaciones web en la nube
Fecha y hora: 7 de octubre de 2011, de 16:00 a 17:30 GMT+0
Lugar: Salón de grados de la Escuela Técnica Superior de Ingeniería Informática (ETSII)
Descripción: DotNetNuke es un proyecto open source, la plaforma de gestión de contenidos para la construcción de sitios y aplicaciones web basada en Microsoft .NET más ampliamente adoptada a nivel global. Las organizaciones usan DotNetNuke para desarrollar y desplegar rápidamente sitios web interactivos y dinámicos, intranets, extranets y aplicaciones web. Con el soporte para granjas de servidores y el DotNetNuke Azure Accelerator, se presenta sobre Windows Azure como una solución de gestión elástica de contenidos en la nube.
Ponente: David Rodríguez
https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032496233&Culture=es-ES
sábado, 3 de septiembre de 2011
Modificar el contenido de un VHD en Azure
Según tengo entendido, mucha gente está realizando esta operación descargando localmente una copia del VHD, actualizándolo en el entorno de desarrollo y volviendo a subir de nuevo el VHD a Azure. Personalmente no use este método, pero explicaré cómo realizarlo y luego los pasos que sigo yo para actualizar mis instancias.
Descargar, modificar, subir
Si deseas realizar el trabajo mediante la descarga local del VHD realizando los cambios en tu entorno de desarrollo, necesitarás una herramienta capaz de descargar/subir PAGE BLOBS. A diferencia de los blobs normales –block blobs-, las VHD usan otro tipo de blobs que normalmente no todas las herramientas que trabajan con Azure lo soportan.
Método 1: Usa una herramienta de interfaz gráfica
Cerebrata está trabajando en una herramienta específica para esta tarea llamadaAzure Page Blob Manager. Puedes descargarla aquí (todavía está en beta y puedes descargarla y usarla).
Características
Esta utilidad está específicamente diseñada para administrar Page Blobs de Windows Azure. A muy alto nivel, esto es lo que puedes hacer con esta herramienta:
- Puedes ver los contenidos de un page blob montado como una Azure Drive. Probablemente este es uno de las mejores características de esta utilidad. Básicamente esta utilidad crea un VHD vacío en tu equipo local y descarga las páginas ocupadas del page blob para finalmente montar el VHD localmente como una unidad para que puedas ver los ficheros que contiene el page blob.
- Puedes subir VHDs a Windows Azure como page blobs.
- Puedes descargar page blobs.
- Puedes ver el tamaño total del page blob así como el espacio ocupado actualmente por el page blob (que te debería indicar cuánto te están facturando actualmente por este page blob en particular).
- Puedes ver cuántas páginas están ocupadas en el page blob están ocupadas (las cajas azules en la captura de pantalla). Cada caja representa 1/400avo del total del tamaño total del page blob. Pulsando sobre una caja azul te dirá cuántos bytes están ocupados.
- Esta utilidad sólo listará los page blobs.
Método 2: usa una herramienta de línea de comandos
También puedes descargar/subir el VHD usando una herramienta de línea de comandos como “AccelCon.exe” que fue incluida en el paquete original de DNN Azure Accelerator (desarrollada por Slalom Consulting). Esta herramienta no está incluida en el último distribuible así que la he puesto a descarga en este enlace:
Puedes subir el VHD como un page blob usando esta sintáxis:
accelcon.exe /u /v ".\DotNetNuke.vhd" "azure-accelerator-drives/dotnetnuke.vhd"
Método 3: ¿Por qué descargar el VHD?
Si habilitas RDP (escritorio remoto), puedes copiar/pegar contenidos y muchas otras tareas. Personalmente, cuando necesito actualizar los contenidos por un cambio de versión de DNN, normalmente::
- conecto vía RDP a una instancia
- navego a Codeplex y descargo el paquete de actualización (se puede navegar desde dentro de los roles)
- descomprimo la actualización dentro de la unidad
Normalmente copio los contenidos a otra carpeta en la unidad (para backup) y creo una copia de seguridad de la base de datos (T-SQL: create database … as copy of …), de manera que pueda repetir/deshacer rápidamente la operación si algo va mal. Todo esto vía RDP. Para habilitar RDP, actualmente necesitas recompilar el paquete a desplegar en Azure para introducir los credenciales y el certificado con el que se encriptan (ver documentación), pero es algo altamente recomendable para ésta y otras tareas.
En breve se anunciarán nuevas carcterísticas del DNN Azure Accelerator respecto a estas tareas de actualización, así que permanece en sintonía.
Un saludo.
Suscribirse a:
Entradas (Atom)
