Publicar aplicaciones con Azure RemoteApp

Cómo respuesta a la generación de grandes infraestructuras On-Premises para la publicación de aplicaciones para nuestros usuarios remotos y locales, tanto corporativos cómo externos, Microsoft ha puesto a disposición de los clientes de Azure,  un servicio Cloud que permite de una forma sencilla, rápida y sin necesidad de despliegue de ninguna infraestructura local, el acceso a nuestras aplicaciones desde cualquier sitio y prácticamente desde cualquier plataforma, este servicio es RemoteApp.

Las principales características de este servicio cloud son:

· Dar acceso a las aplicaciones corporativas a las plataformas móviles (BYOD)

· Adaptación de la organización a las demandas fijas o temporales de acceso a las aplicaciones.

· Evitar el despliegue de nuevas infraestructuras.

· Adaptarnos a cambios organizativos con muy bajos tiempos de respuesta.

· Acceso a usuarios externos o internos de las aplicaciones corporativas.

· Acceso multiplataforma de Microsoft para Mac, iOS y Android.

Un factor muy importante en la implantación de RemoteApp es elegir el tipo de colección, las opciones son de tipo Cloud o Híbrida, a continuación os comento una pequeña introducción a sus características:

RemoteApp de Azure permite compartir aplicaciones y recursos con usuarios de cualquier dispositivo. Para ello se crean colecciones para contener las aplicaciones y los recursos y, a continuación, se comparten dichas colecciones con los usuarios. Existen dos opciones de colecciones distintas con diferentes opciones de autenticación y red. ¿Cuál es la que más le conviene?

Vamos a examinar las distintas consideraciones y opciones que deberá tener en cuenta para sacar el máximo partido a su colección de RemoteApp de Azure.

Diferencias rápidas entre los tipos de colecciones

 

Nube

Híbrida

Uso de una red virtual existente

Requiere cuentas conectadas a AD (DirSync)

No

Requiere la unión a un dominio

No

Requiere un controlador de dominio disponible para la red virtual

No

Colecciones de nube

· Rapidez de creación: la colección se aprovisiona rápidamente, lo que significa que le resultará más fácil hacer llegar las aplicaciones a los usuarios.

· Ofrecer sus propias aplicaciones o compartir las nuestras. Puede usar una imagen personalizada (creada desde una máquina virtual de Azure) o una de las imágenes incluidas con su suscripción.

· No es necesario configurar ninguna conexión entre la colección y su dominio local.

· Sin embargo, también puede usar su propia red virtual de Azure para proporcionar acceso a su entorno local para compartir datos o usar la autenticación que no es de Windows en recursos como SQL Server (mediante autenticación de base de datos).

Colecciones híbridas

· Incluye el acceso conjunto de dominio para las aplicaciones y los datos. Las aplicaciones remotas se pueden autenticar con Active Directory local. A continuación, podrán tener acceso a los recursos del dominio.

· Habilitar la supervisión y administración avanzadas con las soluciones de System Center existentes y las directivas de grupo de Windows (mediante una imagen personalizada basada en Windows Server 2012 R2)

· Compatibilidad con Express Route para conectar la red virtual de Azure a la red virtual local.

Opciones de autenticación

RemoteApp de Azure admite tanto cuentas de Microsoft como cuentas de Azure Active Directory; aunque no todas las colecciones admiten todos los métodos.

Tipo de cuenta

 

Nube

Nube + red virtual

Híbrida

Cuenta Microsoft

 

No

Azure Active Directory (Azure AD)

       
 

Solo Azure AD

No

 

AD Connect con sincronización de contraseñas

 

AD Connect sin sincronización de contraseñas

No

 

AD Connect con AD FS

 

Proveedores de identidades de terceros compatibles con Azure (por ejemplo, Ping)

Multi-Factor Authentication

 

Nube y nube + red virtual

Con las colecciones de la nube, puede usar cuentas de Microsoft, cuentas de Azure AD o una combinación de ambas. Use las cuentas que funcionan mejor para los usuarios.

No hay ningún requisito específico en cuanto al uso de cuentas Microsoft.

Si desea usar cuentas de Azure AD, deberá asegurarse de que el inquilino de Azure AD coincide con el asociado a su suscripción. Cuando se creó la suscripción de RemoteApp de Azure, el inquilino de Azure AD que estaba usando se asocia automáticamente a su suscripción. Los usuarios de Azure AD a los que conceda permiso deberán usar el mismo inquilino. Si es necesario, puede cambiar el inquilino de Azure AD asociado a su suscripción.

clip_image002

Híbrida (o nube + Azure AD + AD)

El uso de Azure AD + Active Directory local es un requisito previo para las colecciones híbridas. Debe usar AD Connect para integrar los dos directorios. Sin embargo, tendrá algunas opciones en cuanto a la configuración de AD Connect.

Existen 2 escenarios de AD Connect: uso de sincronización de contraseñas o uso de la federación de AD. Consulte la Información de AD Connect para averiguar cuál de estas opciones es la que más le conviene.

También puede usar Azure AD + AD con una colección de nube. Asegúrese de que seguir los mismos pasos de configuración.

clip_image004

Nuestro primer piloto.

Si queremos realizar nuestra primera publicación seguimos los siguientes pasos, en este ejemplo vamos a publicar aplicaciones Microsoft Office:

1º. Dentro del portal de administración de Azure, seleccionamos Nuevo, Servicio de aplicaciones, RemoteApp y Creación rápida.

clip_image006

Especificamos el nombre del servicio, seleccionamos la región y la plantilla a utilizar.

En mi caso he seleccionado PR1 como nombre del servicio, la región West Europe y una plantilla que contiene aplicaciones office.

Podemos generar múltiples servicios para dar acceso a diferentes tipos de usuarios o perfiles.

clip_image008

Una vez que tenemos el servicio creado, procedemos a publicar la aplicación desde el Inicio rápido y seleccionando la opción publicar aplicación.

clip_image009

Una vez que hayamos seleccionado la opción publicar aplicación, nos aparecerán las aplicaciones disponibles, e iremos eligiendo las que queremos que puedan ser accesibles para nuestros usuarios.

clip_image011

Desde el menú de Publicando vemos todas las aplicaciones que hemos seleccionado cómo aplicaciones publicadas. Desde este menú podemos sumar nuevas aplicaciones o quitar las existentes.

clip_image013

Desde el menú de Acceso de usuario podemos sumar nuevos usuarios o quitar los existentes, los usuarios pueden ser de Azure AD o cuentas Microsoft.

clip_image015

Una vez que hayamos dado acceso a los usuarios, desde el menú Panel podemos acceder a la URL que nos permite descargar el cliente de RemoteApp. Este es el cliente que permite dar acceso a las aplicaciones publicadas.

clip_image016

A través de la URL mencionada, accederemos a un portal que nos permite la descarga del cliente de RemoteApp a local.

clip_image017

Cómo último paso, abrimos sesión con una de las cuentas dadas de alta en el servicio de RemoteApp y veremos todas las aplicaciones disponibles.

clip_image019

Para realizar nuestra prueba hemos seleccionado la aplicación Excel, una vez abierta observamos que se abre una conexión remota contra la aplicación.

clip_image020

Después de unos segundos, tenemos la aplicación Excel a nuestra disposición cómo una aplicación remota.

clip_image022

Espero que os haya sido útil este documento.

100 publicaciones en el blog de Enterprise IT at Plain Concepts

Con la última de Manuel Marín hemos llegado a las 100 publicaciones en el blog del equipo de Enterprise IT en Plain Concepts. Ha pasado un año y medio desde que el 24 de julio de 2014 iniciásemos esta andadura con nuestro Hola Mundo de compartir curiosidades técnicas de nuestro trabajo diário que hemos ido compartiendo a un ritmo aproximado de una semanal.

Son multitud de historias las que os hemos comentado: conectar tu red a Azure, colorizar la PowerShell al estilo GNU/Linux, desplegar un servidor RADIUS con NPS, seguridad del correo electrónico con los SPF, y así un largo etc… Para recapitular os dejamos con una relación de los 10 artículos más leídos del blog hasta la fecha:

  1. Configurar Thunderbird para una cuenta de correo de Office 365
  2. Office GRATIS en Educación
  3. Conversión Físico-A-Virtual
  4. Conectando Microsoft Azure con Amazon Web Services
  5. Túneles Site-2-Site en Azure con Windows Server 2012
  6. Cómo migrar CORREO de Google Apps Gmail a Office 365
  7. Microsoft Azure Site to Site cross-premises usando GNU/Linux (Ubuntu 12.04 LTS) y StrongSwan
  8. Despliegue de Maquinas Virtuales usando SysPrep y discos de diferenciacion
  9. PPT y videos del Desayuno de Infraestructura Microsoft con Plain Concepts
  10. Asegura la legitimidad de tu email con los registros SPF

¡Muchas gracias a todos por seguirnos hasta ahora! ¡Nos leemos en la siguiente publicación!

Gestión de Azure Storage con Azure CLI

Siguiendo un poco la estela de este otro post, me gustaría hablar del tratamiento que ofrece Azure CLI respecto al almacenamiento o Storage.

Con el conjunto de comandos que Azure CLI destina a este apartado, se podrá llevar a cabo una gestión de los diferentes elementos de almacenamiento, los cuales serían los siguientes:

  • Blobs: datos no estructurados, por ejemplo archivos multimedia.
  • Colas: almacenamiento fiable de mensajes.
  • Tablas: datos NoSQL estructurados.
  • Ficheros: compartición de archivos y datos comunes, basado en el protocolo SMB.

Al igual que cuando se introdujo el Azure CLI en el anterior post, la ayuda continua todos los comandos relativos al almacenamiento. Para mostrar dicha ayuda especificando los comandos relativos al almacenamiento, bastaría con escribir:

Azure CLI storage help

Puesto que es bastante extensa, puede ser conveniente refinar más especificando con más detalle el asunto. Así, si por ejemplo se quiere mostrar la ayuda solo referente al elemento blob, entonces:

Hay dos variables importantes que hay que establecer para poder acceder a los elementos: AZURE_STORAGE_ACCOUNT y AZURE_STORAGE_ACCESS_KEY. Esta asignación se puede realizar directamente en un script o en el bash:

La clave de la cuenta (storage access key) se puede descargar desde el portal de Azure. Una vez conectados, para ver las cuentas de almacenamiento de la subscripción seleccionada basta con indicar:

con lo que mostrará todas las cuentas de almacenamiento con que cuenta esa subscripción.

Azure CLI storage account list

Para no ser demasiado exhaustivo, y puesto que la ayuda es autodescriptiva, pondré como ejemplo a los blobs y algunas de sus operaciones.

Los blobs se almacenan en contenedores. La instrucción que crea un contenedor es la siguiente:

Si se quieren ver todos los blobs que hay en un contenedor determinado, la consulta sería la siguiente:

Azure CLI blob list

Por otro lado, para descargar un blob o subirlo, las órdenes respectivas serían la siguientes:

O si se quieren copiar blobs de diferentes cuentas de almacenamiento de forma asíncrona:

y para comprobar el estado de la copia:

Finalmente, para eliminar un blob:

Con respecto a los comandos relativos a los ficheros, tablas y colas, es posible realizar las típicas operaciones sobre estos tipos de elementos (crear, eliminar, mostrar). En la ayuda de Azure CLI se muestra con detalle dichas operaciones, aparte de otras como la gestión de la políticas de acceso de ficheros, tablas y colas, por lo que no es necesario repetirlas.

Y esto es todo por ahora. Espero haber contribuido un poco al conocimiento de esta versátil herramienta.

CRON en Azure App Service (Websites)

Si estáis al día con Microsoft Azure, sabréis que Azure Websites pasó a llamarse Azure App Service, el servicio PaaS donde se integra la plataforma para aplicaciones móviles y web.  Las ventajas de hospedar nuestra aplicación web aquí versus la tradicional máquina virtual son múltiples y muy evidentes:

  • Microsoft se ocupa de la seguridad y actualización del sistema operativo, servidores web y los runtimes (PHP, Java,  .NET, Python…) que se ejecutan sobre él.
  • Podemos escalar el número de instancias dedicadas a servir nuestra aplicación de forma dinámica y en función de la demanda, tanto ascendente como descendente.
  • Soporte de integración continua y slots de deployment, lo que nos permite disponer de un área de producción y otra de pre-producción e intercambiarlas.
  • Sistema de copia de seguridad.
  • Sistema de monitorización.

Sin embargo, hay una parte del sistema operativo que sí que podemos echar en falta cuando nos lanzamos a hospedar nuestra aplicación en Azure App Service: el CRON (UNIX) o bien el Programador de Tareas (Windows).

Conocidas aplicaciones LAMP como podría ser WordPress usan CRON para programar la ejecución de tareas de mantenimiento, como por ejemplo la verificación de actualizaciones de los distintos plugins y themes o la publicación de un post programado. En muchas ocasiones, nuestra aplicación puede llevar integrado un CRON que se ejecuta con las visitas de nuestros usuarios al propio sitio web, cosa que si bien suple la necesidad de un programador de tareas a nivel de sistema operativo, se puede convertir en un problema si nuestra aplicación tiene un tráfico muy denso, ocasionando un importante overhead de consumo de recursos en el servidor.

Ejemplo: creando un Azure WebJob para el CRON de WordPress

Para solucionar este problema en Azure App Service, disponemos de Azure WebJobs. Ten en cuenta que para Azure soporte lo que vamos a contar aquí, es indispensable habilitar Always On en la configuración de nuestro App Service.

Hacer uso del mismo es bastante sencillo. En primer lugar deberemos crear un script para ejecutar de forma programada, el cual puede ser un ejecutable de línea de comandos (.cmd, .bat, .exe), PowerShell (.ps1), bash (.sh), PHP (.php), Python (.py), NodeJS (.js) o Java (.jar).

En el caso del CRON de WordPress voy a crear un sencillo archivo BAT con la siguiente línea:

Ya sabemos lo que queremos ejecutar, así que ahora nos toca programar cuándo queremos ejecutarlo. Para ello creamos un archivo llamado settings.job, que tendrá formato JSON con un único atributo schedule cuyo valor será una expresión cron. Hay una explicación estupeda aquí, que viene a decirnos que una expresión CRON nos permite especificar una programación recurrente de forma compacta. A groso modo:

  • Tiene el formato: {segundos} {minutos} {horas} {días} {meses} {días de la semana}
  • Los operadores soportados son: , – * /
  • Cada campo puede tener un valor específico (1), un rango (1-10), un set de valores (1,2,3), todos los valores (*), un intervalo (/2 equivale a 0,2,4,6,…) o una mezcla de todas estas formas.
  • Ten en cuenta que un valor representa un punto muy concreto en el tiempo. Por ejemplo, “0 15 * * * *” significa el minuto 15 y no cada 15 minutos.

Aquí podemos encontrar algunos ejemplos de expresiones CRON:

Ahora que conocemos la sintaxis, podemos volver a nuestro archivo settings.job y poner la programación que queramos, digamos que queremos ejecutar la tarea cada 15 minutos de forma continuada. El aspecto sería el siguiente:

Hecho esto empaquetamos wp-cron.bat y settings.job en un archivo ZIP y ya estamos listos para crear la tarea programada en Azure.

Creando la tarea programada en Azure App Service

Sólo tenemos que acceder a nuestra suscripción de Azure, ir a nuestra aplicación en App Service y desplegar la configuración de WebJobs.

image

Ahora debemos agregar nuestro webjob y… sí, aquí viene la parte confusa: en how to run hay que seleccionar On Demand. La configuración que va implícita en el settings.job hara que a pesar de tener esto especificado se ejecute de forma programda. Si pasáis el ratón por la (i) de ayuda se vuelve más confuso, ya que nos comenta que los WebJobs programados estarán disponibles en el futuro, pero ¡en realidad los tenemos ya disponibles!

image

Con el webjob creado, ya podemos verlo en la tabla con un enlace al log de ejecución:

image

Los webjobs dados de alta y su programación se pueden consultar también bajo la consola de Kudu, en la URL https://<tudominio>.scm.azurewebsites.net/api/webjobs, sustituyendo <tudominio> por el nombre de la implementación.

Deshabilitando el CRON integrado de WordPress

Como hemos tomado este ejemplo con WordPress, no sería justo acabar el artículo sin explicar cómo deshabilitamos su CRON integrado, ya que hemos pasado a configurarlo de forma más eficiente en Azure y ya no dependemos de las visitas a nuestro sitio web para su ejecución.

Para ello buscamos el archivo wp-config.php y agregamos la siguiente línea:

Es una modificación tan simple que la podemos llevar a cabo desde Visual Studio Online.

Y con esto eliminamos uno de los posibles stoppers a la hora de llevar la implementación de nuestra aplicación a Azure App Service. ¡Espero que os resulte ilustrativo!

Happy AppServicing!

Enlace relacionado: Documentación oficial de Azure para la ejecución de tareas en segundo plano

Webinar: Balanceo de carga en entornos híbridos con KEMP y Azure

Soy consciente de que avisamos con muy poca antelación, pero a posteriori estará disponible la grabación del evento que podréis ver con tranquilidad.

  • Título: Balanceo de carga en entornos híbridos con KEMP Technologies y Microsoft Azure
  • Fecha: martes, 12 de enero de 2015
  • Hora:  11:00 – 12:00
  • Ubicación: Webinar online
  • Abstract: En este webinar usted será capaz de comprender las ventajas que le ofrece la nube de Microsoft con MS Azure y a su vez solucionar las principales dudas que surgen al cambiar a un escenario híbrido gracias al balanceo de carga en entornos híbridos junto con KEMP Technologies.
  • Registro : Enlace de acceso
  • Ponente: Carlos Milán Figueredo – Enterprise Team Lead (Plain Concepts)

¡No os perdáis tampoco el post de Antonio López Márquez sobre cómo mander notificaciones Push a móviles desde PowerShell!

PowerShell: Disco duro libre y notificaciones PUSH

Un nuevo año, una nueva semana, y un nuevo artículo sobre PowerShell. En el artículo anterior se hablaba sobre un sistema que enviaba mensajes de email cuando un website de una lista no estaba online. Eso está bien para casos en los que se necesita un informe de estado periódico. Pero si lo que interesa es actuar sobre una emergencia… que está ocurriendo en este mismo instante, tal vez sea necesario tomar una aproximación más inmediata.

En el script de hoy, el objetivo es saber si una máquina de la granja de servidores de la empresa se está quedando sin espacio libre en disco. Para ello se hará uso de una consulta WMI, el programador de tareas de Windows y un servicio PUSH de notificaciones a teléfonos móviles.

El código

Paso a Paso

Acceso a información de discos locales

Desde powershell, esto se puede ver fácilmente con el siguiente comando: “gwmi win32_volume -Filter ‘drivetype = 3’”, que devuelve una lista detallada de parámetros para cada uno de los discos del sistema. Esto constituye la primera pieza del puzzle que toca resolver.

get-drives

El DriveType indica el tipo de disco que se desea consultar. En este caso, el DriveType = 3 hace un filtrado para mostrar únicamente los discos duros locales. Para cada uno de los discos que devuelve, se quiere procesar los que tengan una capacidad superior a 0 para descartar cualquier unidad de CD/DVD que pudiera haber pasado el filtro.

Entran en escena los servicios PUSH

Hay multitud de proveedores de servicios PUSH, como PushOver, Slack, PushBullet, NotifyMyAndroid… Cada uno tiene sus ventajas e inconvenientes: Los hay con diferentes modelos de licenciamiento, desde licencia por plataforma en la que se instale, hasta la compra de paquetes de mensajes cuando se llega al límite máximo de mensajes mensuales.

De todos los nombrados anteriormente, hay uno que tiene cliente móvil para las tres grandes plataformas (Android, IOS y Windows Phone) y que además tiene la segunda pieza necesaria: una API REST con la que poder enviar notificaciones: Slack

De la API, que incluye funciones para infinidad de tareas, la parte interesante es la que envía un mensaje al chat. Por limpieza y reusabilidad del código, esta parte se ha separado en una función aparte llamada “Send-SlackMessage” que acepta como parámetros el canal al que se desea enviar el mensaje, el nombre de usuario que aparece como “agente publicador”, y el mensaje en sí. Esta función se puede sacar del código y utilizar como notificador en cualquier otro script PowerShell, como procesos que tardan horas en completar, o cualquier otra situación en la que se considere que sea necesario recibir notificaciones.

La parte más importante, y de la que depende que todo esto pueda funcionar, es el token de cliente. En este caso, desde la web de Slack se puede solicitar un token de usuario desde el que enviar notificaciones de una forma muy sencilla y automatizada, sin necesidad de tener que implementar ningún tipo de esquema de autenticación.

¿Por algún motivo el token queda expuesto y empiezan a llegar mensajes de spam? Simplemente se genera un nuevo token, y listo.

get-token

Programando tareas

Nada de esto tendría sentido si no hay una forma de hacer una comprobación periódica del estado del disco. Esto se puede lograr muy fácilmente con el Task Scheduler de Windows. En primer lugar se programa el trigger para que se ejecute diariamente cada 10 minutos.

new-task

Y en segundo lugar se especifica la acción a realizar. En este caso, lanzar una PowerShell –file “nombreFichero.ps1”, que es donde está guardado el script que acompaña a este artículo.

new-task2

Comprobación y Conclusiones

Finalmente, toca comprobar que todo ha funcionado correctamente, y que la notificación se ha recibido en los diferentes medios (Android, Windows Phone, PC,…)

message

Screenshot_Android   Screenshot_WP

Como se puede ver, aunque Slack proporciona clientes para todas las plataformas la interfaz de usuario y la organización de los mensajes cambia dependiendo de la plataforma.

En conclusión, mediante el uso de sistemas de mensajería Push, se pueden enviar notificaciones a canales específicos lo que permite avisar a un equipo completo de trabajo de que algo está pasando con los servidores, al tiempo que la bandeja de entrada de correo electrónico se puede mantener algo más limpia de mensajes. Esto puede permitir una interacción más ágil entre los miembros de un equipo para coordinarse en la resolución del problema.