Todas las entradas de: Carlos Milán Figueredo

Hasta la próxima

Como podéis imaginar por el título de esta publicación, efectivamente se trata de una despedida, una que me cuesta muchísimo escribir. Esta semana del 9 de mayo ha sido la última como mánager del equipo de Enterprise IT y como empleado de Plain Concepts.

Sólo tengo buenas palabras para hablar de Plain Concepts, una empresa pura de ingeniería donde el talento corre por todos y cada uno de sus integrantes. Seguramente sea el peor momento para irme ahora que tenemos por las oficinas unas Microsoft Hololens y unas HTC Vive 🙂

He disfrutado muchísimo en los proyectos y apasionantes retos de esta empresa, de los cuales me he permitido el lujo de compartir detalles con todos los lectores de este blog a través de las publicaciones que he ido haciendo. Y aunque yo me vaya, aquí queda mucho crack: Antonio, Elena, Carlos, Manuel, José María, Jésica… Todos ellos hacen aportaciones interesantísimas en el ámbito de lo que tocan día tras días y consiguen que tenga este sitio en un lugar especial de mi lector RSS. Os echaré mucho de menos.

Inaugurar y escribir en este blog ha sido el más grande de los honores. Como sé que eventualmente nos vamos a ver y que este mundo no es tampoco tan grande, esto no es un adios sino un hasta la próxima.

¡Hasta la próxima cracks!
Carlos

PD: No podía irme sin dejaros algo en PowerShell aquí, así que cortesía de Dave Wilson os pongo algo de música en PowerShell:

Construyendo una VPN Point-to-Site con autenticación RADIUS y AD en Microsoft Azure

Ya hemos comentado en otras ocasiones en este blog cómo establecemos una VPN Point to Site en Microsoft Azure. Aunque es una forma rápida y versátil de dar a equipos cliente acceso a nuestra red virtual de Azure, lo cierto es que nos enfrentamos a algunas limitaciones que en función del proyecto en que nos encontremos pueden ser todo un stopper para nosotros o nuestro cliente. Concretamente son las siguientes:

  • Sólo admiten 128 clientes como máximo. Como sabéis, las conexiones de App Service cuentan como un cliente.
  • El cliente sólo funciona en Windows 7 o superior (32 y 64 bits). Nos olvidamos de otras plataformas.
  • La autenticación se realiza mediante certificados, no hay nombres de usuario y contraseñas.
  • La comunicación normalmente es en un sentido, del cliente a la infraestructura de Azure y no viceversa.

Si estos puntos no nos suponen un gran problema, el P2S que Azure nos ofrece como servicio es una excelente forma de conectarnos a nuestra red virtual. Pero si resulta que lo es… ¿qué podemos hacer?

Alternativa 1: Máquina Virtual con Windows Server 2012 R2 y RRAS

Es lo primero que se nos viene a la cabeza. Pero no me cansaré de repetir que el rol de RRAS de Windows Server 2012 R2 (y versiones anteriores) no está soportado en Azure. Aunque al instalarlo nos de la sensación de que todo está OK, Azure eventualmente reinicia los adataptadores de red sintéticos asociados a dicha máquina, algo que hace que no sobreviva la configuración que hemos hecho del rol.

Los suficientemente valientes pueden probar a crear un script de autoconfiguración del rol que se ejecute cada vez que se encieda la máquina, pero os encontraréis con que el soporte de PowerShell de este rol es realmente pobre (está pensado para DirectAccess más que para VPN) y no os quedará más remedio que recurrir al viejo amigo netsh. Que la fuerza os acompañe.

Aunque consiguiéramos autoconfigurar la máquina en cada inicio esto es algo que considero bien lejos de ser estable y confiable, por lo que debíamos ir a otra alternativa.

La solución: gateway GNU/Linux con SoftEther VPN

Parece que GNU/Linux no se ve afectado por los cambios de adaptador de red de Azure, algo que nos arroja algo de luz al problema. Acto seguido necesitamos decidir con qué software implementar la solución. Decidí que SoftEther VPN era la mejor. Gracias a esto vamos a superar todas las limitaciones que hemos comentado antes.

¿Qué es SoftEther VPN?

SoftEther VPN es un potente software VPN de código abierto desarrollado por la Universidad de Tsukuba (Japón) que se posiciona como una alternativa poderosa a los sistemas de túneling existentes, ya sean los basados en RRAS de Microsoft o bien el extendido OpenVPN. ¿Qué lo hace tan genial?

  • Multi-protocolo. SoftEther VPN soporta L2TP/IPsec, SSTP, OpenVPN y SSL VPN (a través de un cliente propio).
  • Multi-plataforma, ya que corre bajo Windows, OSX, Linux, FreeBSD y Solaris.
  • Multi-arquitectura, soportando x86, x64, ARM, MIPS, SH-4, PowerPC y SPARC.
  • Multi-authentication backend: soportando usuarios y contraseñas locales, certificados X.509, Active Directory (sólo Windows) y RADIUS.

Como podéis ver se trata de un completísimo sistema de VPN que soporta prácticamente todo lo que podamos imaginar.

Autenticando con Active Directory

Os habrá llamado la atención que SoftEther VPN soporta Active Directory como backend de autenticación, pero lamentablemente sólo en el caso de que estemos ejecutando el servidor bajo Windows. Esto en Azure nos devolvería a la casilla de salida, así que tenemos que asumir que estamos en Linux. Sin embargo, en la lista también estaba RADIUS. ¿Tiene Microsoft algún servidor RADIUS que nos haga de pasarela a la autenticación de ADDS? ¡Sí! ¡El Network Policy Server! NPS para los amigos.

Nuestra arquitectura a alto nivel sería la siguiente:

gaw1

Así que dicho y hecho, nuestro escenario de demo se va a componer de tres máquinas en Azure:

  • SoftEther VPN (Linux)
  • NPS + ADDS (Windows)
  • App Server (no es indiferente el sistema operativo).

La última máquina de la lista es solo para comprobar conectividades y representa nuestra infraestructura en Azure.

Inyectando a nuestros clientes VPN P2S en la red de Azure: el adaptador de red TAP de Linux

Uno de los grandes problemas que nos podemos encontrar a la hora de conectar clientes a nuestra red virtual de Azure es que esta no es precisamente muy amiga de eso. Una red virtual de Azure se encuentra gobernada por el DHCP que Microsoft instaura en ella y por tanto si intentamos conectarlos a través de la máquina virtual que hemos desplegado, no obtendremos ningún resultado satisfactorio.

Aquí entra en juego otra de esas capacidades de Linux que hace que nos maravillemos con él cada vez que hacemos temas de networking: el adaptador de red virtual TAP. Este adaptador de red es una interfaz virtual que se encuentra integrada en el kernel de Linux y que puede ser desplegada por las aplicaciones que lo requieran. Tiene infinidad de usos en software de tunneling y virtualización.

Cuando desplegamos el adaptador, obtenemos algo similar a esto:

gaw3

Como se puede ver en la imagen, la máquina virtual de SoftEther se encuentra dentro de la red virtual de Azure, y así lo refleja el adaptador eth0. Pero… ¿y si creamos un nuevo adaptador TAP? Llamémosle tap_vpn0. Este adaptador virtual no se encuentra realmente dentro de Azure: no ve la red virtual, el DHCP de Azure no tiene efecto sobre él y es agnóstico a nuestro entorno. ¡Es el candidato perfecto para unir nuestros clientes P2S!

Sin embargo, una vez unidos los clientes a este adaptador, debemos establecer comunicación con la red virtual de Azure. Esto lo podemos conseguir fácilmente convirtiendo nuestra máquina Linux en un router a su vez (ya sabéis, activar IP forwarding como hemos comentado otras veces). De esta manera el dibujo se convierte en el siguiente:

gaw2

User Defined Routes e IP forwarding a nivel de Azure

Hecho esto, necesitamos que Azure sepa a qué gateway enviar el tráfico dirigido a los clientes VPN y permitir que esa máquina acepte tráfico que no es necesariamente para ella. A día de hoy, esto es perfectamente posible:

  • User Defined Routes (UDR). No es ni más ni menos que una definición de tablas de rutas en una red virtual de Azure. Nos permite dirigir el tráfico a donde nos interese. Este tema merecerá un artículo del blog en exclusiva.
  • IP ForwardingFundamental si usamos tablas de rutas y enviamos el tráfico a una máquina virtual, ya que por defecto está no aceptará ningún packete de red en el que ella no sea la destinataria.
El resultado

Tras todo el proceso deberíamos tener operativo todo un hub de conexiones VPN que además nos permite superar las limitaciones que comentábamos al inicio del artículo.

gaw4

El resumen y To-Do list

Como el artículo ha constituido una explicación de alto nivel de cómo conseguir en Azure una VPN P2S autenticada mediante ADDS, os dejo con una serie de pasos de alto nivel para hacer la solución más fácil de seguir:

  1. Crear una nueva red virtual de Azure y asignarle un direccionamiento. En nuestro ejemplo 172.16.0.0/24.
  2. Crear máquinas para hospedar los siguientes servicios: SoftEther VPN (Linux), NPS (Windows), ADDS (Windows). Configurar todas las IPs privadas como estáticas.
  3. Configurar SoftEther VPN de la siguiente manera:
    1. Local Bridge hacia un adaptador TAP.
    2. Autenticación basada en RADIUS contra el servidor NPS.
    3. Activar protocolos L2TP/IPsec y SSTP. Opcionalmente podemos activar OpenVPN.
    4. Generar los certificados necesarios para SSTP y distribuirlos en los clientes que vayan a acceder. Recuerda que deben coincidir con el nombre del dominio al que conectas.
  4. Elegir un direccionamiento para nuestro adaptador TAP y asignarle una IP dentro de ese direccionamiento. En nuestro ejemplo 172.17.0.0/24 y el adaptador 172.17.0.1.
  5. Instalar y configurar un servidor DHCP (a mi me encanta dnsmasqque debe ejecutarse tras arrancar SoftEther VPN para que exista la interfaz TAP. Esto es importante porque sólo debe estar enlazado (binding) a la interfaz TAP y NUNCA a eth0, donde entraría en conflicto con el de Azure. Debe servir IPs en el rango del adaptador TAP.
  6. Activar IP forwarding en la máquina Linux en /etc/sysctl.conf.
  7. Activar IP forwarding a nivel de Azure en la máquina virtual Linux.
  8. Crear una UDR que haga que el tráfico para 172.17.0.0/24 se dirija a la IP privada de la máquina virtual con SoftEther.
  9. ¡Listos para funcionar!
Explicándolo en directo

Alberto Marcos y servidor explicamos y demostramos todo esto en directo en la Global Azure Bootcamp 2016. Si te la perdiste tienes la oportunidad de ver en HD la grabación de la sesión justo aquí: https://channel9.msdn.com/Events/Microsoft-Spain-Events/Global-Azure-BootCamp-2016/Construyendo-una-VPN-Point-to-Site-con-autenticacin-RADIUS-y-AD-en-Microsoft-Azure

Happy networking!

Migrando de Azure Classic (ASM) a Azure Resource Manager (ARM)

Aunque esta publicación la materializa servidor, he de comentar que es un trabajo del equipo completo de Enterprise IT de Plain Concepts, donde todos y cada uno de nosotros estuvimos involucrados con las distintas tareas que voy a comentar aquí.

Llevamos ya unos cuántos meses contándoos la potencia y enormes ventajas del nuevo modelo de recursos de Azure, que cambia nuestra forma de entender y trabajar con la plataforma… y lo hace para muy bien. Sin embargo, hacemos una confesión pública en estas líneas: el core de la infraestructura de Plain Concepts aún se encontraba en el modelo clásico. Y es que aunque seguimos totalmente un modelo customer first, lo coherente es predicar con el ejemplo, mas sea dicho que estábamos ansiosos de disponer de todas las ventajas de ARM en nuestro entorno productivo.

No queriendo dilatar más la situación planificamos la migración de toda la infraestructura. ¿Cómo procedimos a ello? Es justamente lo que os voy a contar en esta publicación.

¿Qué servicios necesitan migrarse?

Los servicios sobre los que vamos a tener que trabajar son sobre todo los basados en IaaS y todos los que de alguna manera estén relacionados con los mismos. A continuación os voy a enumerar los más importantes:

  • Storage Accounts.
  • Virtual Machines.
  • Virtual Networks, incluyendo gateways, network security groups, reservas de direcciones IP, etc…
  • Cloud Services. Cuidado aquí, porque si estáis utilizando máquinas virtuales auto-escaladas debéis pasar a utilizar los Azure VM Scale-Sets, que quedan fuera del ámbito de este artículo.
  • Traffic Manager.
  • Backup.

La mayor parte de los servicios basados en PaaS no necesitan atención alguna, ya que automáticamente pasan a beneficiarse del modelo ARM. Entre estos servicios encontramos App Service o SQL Database.

También es interesante mencionar servicios que de momento sólo funcionan en el modo clásico, como StorSimple o Azure Site Recovery.

Estrategias de migración

Muchos ya habréis adivinado lo que voy a comentar a continuación: no hay un botón mágico ni una forma automatizada de mover servicios entre ASM (modo clásico) y ARM. Por tanto, cuando afrontamos un movimiento implica crear de nuevo el servicio en ARM y mover toda la información en un proceso bastante manual.

Hay dos formas de afrontar la migración:

  • Utilizar los scripts de PowerShell de FullScale180 que Microsoft menciona en su documentación oficial. Estos se encuentran en un repositorio de GitHub, justamente aquí.
  • Preparar nosotros mismos un proceso adaptado a las necesidades del entorno.

Después de examinar los scripts y reconocer el enorme trabajo que se llevó a cabo con los mismos, decidimos que era mejor optar por llevar a cabo el proceso de forma manual, fundamentalmente motivados por tener un mayor control.  Los scripts migran una única máquina virtual por ejecución y realizan una serie de asunciones sobre las redes virtuales, los network security groups y los discos que preferíamos tener más controlados. ¡No obstante no dejes de echarles un vistazo por si se adaptan a tus necesidades y te ahorran mucho trabajo!

Para nuestra migración nos marcamos una serie de requisitos:

  • Copiar el entorno 1:1, es decir un clon idéntico del que tenemos en ASM. Esto implica que no vamos a redesplegar y reconfigurar servicios.
  • Como consecuencia del punto anterior, debe mantener el mismo direccionamiento IP y subredes que ya teníamos definidas en la red virtual de ASM.
  • Como no podía ser de otra forma, también debemos tener una configuración similar en la puerta de enlace VPN que creemos en el servicio.

Estos requisitos nos llevan a una estrategia de irremediable corte de servicio, planificado a una hora fuera de oficina. Con otro tipo de requisitos podríamos hacer el movimiento sin prácticamente ningún corte. Y con estos puntos en mente ya podíamos elaborar nuestro backlog particular.

El backlog

Que a alto nivel consistía en lo siguiente:

  1. Asegurarnos de que tenemos acceso administrativo a Azure y Office 365 sin necesidad de ADFS. Dado que nuestros ADFS se encuentran en Azure y ASM, siendo parte de la infraestructura que vamos a migrar, sería muy divertido apagarlos y que se nos cierre o caduque la sesión que tenemos abierta.
  2. Crear el o los grupos de recursos de ARM donde vamos a alojar todos los nuevos elementos de nuestra infraestructura.
  3. Crear las Storage Account necesarias en ARM, tanto las estándar como las premium.
  4. Crear la red virtual en ARM y configurarle el direccionamiento análogo al que ya teníamos en ASM.
  5. Realizar el corte de servicio fuera de oficina y comenzar con la intervención oficial.
  6. Copiar todos los VHDs de las máquinas virtuales existentes de las Storage Account ASM a ARM.
  7. Crear en ARM las máquinas virtuales utilizando los discos que hemos copiado en el paso 6.
  8. Crear los balanceadores de carga internos y externos.
  9. Restablecer las conexiones Site to Site con las distintas localizaciones on-premises de Plain Concepts.
  10. Realizar los cambios DNS oportunos.
  11. Comprobar el funcionamiento del entorno.

Copiando VHDs entre ASM y ARM

La primera tarea es una de las más triviales, pero quizás la que más dolor de cabeza nos dio. Consiste en copiar los VHDs de las máquinas virtuales de una Storage Account basada en ASM a otra que lo esté en ARM. Ambas cuentas de almacenamiento operan de forma indistinta y por tanto se utilizan igual. La herramienta altamente recomendada para esta tarea es AzCopy, que realiza una copia asíncrona entre las cuentas sin necesidad de descargárnosla a nuestra máquina. Su sintaxis es extremadamente simple:

¿Qué nos dio dolor de cabeza? Que la copia fue más lenta de lo que habíamos estimado originalmente, cosa que no nos ocurrió con todas nuestras Storage Account. Es posible, que tal y como advierte TheCodeJunkie es este post, estuviéramos trabajando sobre una Storage Account muy antigua que no tenía ciertas capacidades, pero es un tema en el que no entramos en profundidad. Nos tocó ser pacientes sin más.

Como detalle recordad que copiamos discos y no plantillas de máquinas virtuales. No se trata de imágenes con sysprep aplicado.

Creando máquinas virtuales con nuestro disco como disco del sistema

Cuando ya tenemos nuestros discos en la Storage Account ARM, podemos proceder a crear las máquinas virtuales. Sin embargo, lo primero con lo que nos encontramos es que a día de hoy no hay ninguna opción en el portal para crear una máquina virtual ARM utilizando un disco existente en lugar de las plantillas de la galería. Afortunadamente, la capacidad sí que se encuentra ahí y podemos utilizarla, sólo que para ello tendremos que utilizar una plantilla JSON.

Si vamos al repositorio GitHub de la Azure Quickstart Templates, encontraremos una que nos llama mucho la atención: 101-vm-from-user-image. ¡Justo lo que necesitamos! Si examinamos la plantilla veremos que promete, pero que se nos queda corta para nuestras necesidades debido a que:

  • Está preparada para crear una máquina virtual desde una imagen con sysprep a modo de plantilla, no una VM ya existente.
  • Crea una red virtual por cada máquina que creemos.
  • No especifica dirección IP privada para la máquina.
  • No especifica Storage Account para los diagnósticos.
  • No especifica grupo de disponibilidad.
  • Los nombres de los recursos no se adaptan a nuestra nomeclatura.

¡Pero esto no es ningún problema! La plantilla nos da un estupendo punto de partida para modificarla y adaptarla a nuestras necesidades, que tras pasar por nuestro particular taller quedó así:

ATENCIÓN: Esta plantilla está preparada para máquinas de un solo disco (el del sistema). Necesita una ligera adaptación muy trivial para máquinas donde se usa más de un disco para que estos se desplieguen junto con el resto. ¿Y no nos valdría esta plantilla y ya adjuntamos el resto de discos después? La respuesta es NO. La razón es que al introducir la plantilla en Azure y ejecutarla, este aprovisiona la VM y la arranca. Si al arrancar el sistema no encuentra las unidades donde espera encontrar datos –como por ejemplo, las bases de datos de un controlador de dominio-, la máquina se puede volver inconsistente, pudiendo llegar a perderla.

Aplicando plantillas JSON en Azure

Nada más sencillo que acudir al portal y buscar el elemento Template deployment.

image

Tras lo cual copiamos y pegamos nuestra plantilla en el editor de texto:

image

Tras guardar la plantilla, Azure comprobará que la sintaxis JSON es correcta y en caso afirmativo, nos permitirá pasar a los parámetros. Que quedan tal y como hemos definido:

image

Y tras ello Azure comenzará con el trabajo de implementación de la máquina. Como comentamos en otra ocasión, la potencia de ARM nos permitirá guardar la plantilla que generamos para futuros usos. Es importante reseñar que pueden producirse errores de ejecución en la plantilla, que solo veremos al aplicarla (ej: nombres de recursos que ya se encuentran en uso). Si tenemos el infortunio de caer en esta situación, no tendremos más remedio que eliminar manualmente los elementos creados (o bien el grupo de recursos si trabajábamos de nuevas con él) y comenzar de nuevo.

Conclusiones

Mover infraestructura de ASM a ARM no es a día de hoy un trabajo automático y requiere de un extenso análisis y elaboración de estrategia en función del tamaño y la criticidad del entorno. Las ventajas del movimiento a ARM son evidentes y hacen que en la mayoría de los casos compense el esfuerzo. Por otro lado y desde el punto de vista de seguridad, dado que nunca eliminamos en el entorno original de ASM, siempre existe la posibilidad de hacer rollback si las cosas llegasen a ponerse muy feas durante el proceso.

¿Te ha resultado interesante? ¡Déjanos un comentario si nos quieres decir algo!

Happy ARMing!

Mantén tu Azure PowerShell al día con PowerShell Get

Probablemente mientras estoy escribiendo estas líneas, un nuevo servicio o característica está apareciendo en Azure. Para mantenernos a la par con este ritmo tan frenético de evolución necesitamos tener las herramientas con las que operamos en Azure igualmente actualizadas. Mi compañero Manuel Marín dedica la mayoría de sus publicaciones a las herramientas de línea de comandos multiplataforma, disponibles para Windows, OSX y GNU/Linux; mientras que servidor se centra en PowerShell. Actualmente las herramientas de Azure para PowerShell se pueden instalar de dos formas:

  • Mediante Web Platform Installer, WebPI para los amigos. Se trata de una herramienta que nos permite instalar automáticamente componentes, en su gran mayoría para uso con IIS. En ocasiones encontramos paquetes individuales no relacionados necesariamente con el mundo web, como es el caso de las herramientas de administración de Azure a través de PowerShell. Esta forma de instalación es realmente intuitiva, amena y se hace mediante interfaz gráfica.
  • Desde la Galería de PowerShell, usando PowerShell Get. Esta forma de instalación es también trivial e incluso más rápida que la basada en WebPI, pero se realiza a través de línea de comandos desde la propia PowerShell. Nos vamos a centrar en este método, ya que es mucho más sencillo de mantener al día.

Dado que nos vamos a centrar en el método de la Galería de PowerShell, conviene no mezclar ambos métodos de instalación. Así que en el caso de que hayamos instalado las herramientas mediante WebPI, las desinstalaremos convenientemente desde Programs and Features. Una vez desinstalado procedemos con PowerShell.

La Galería de PowerShell

La Galería de PowerShell no es ni más ni menos que un repositorio central de scripts y módulos de PowerShell, disponibles para descargarse al estilo apt-get desde nuestra línea de comandos. Para poder descargar estos elementos, se vale a su vez de un módulo llamado PowerShellGet. ¿Cómo lo obtenemos? Dependerá de nuestra versión de Windows:

  • Windows 10 / Windows Server 2016. No es necesario hacer nada, ya tienes todo lo necesario.
  • Windows 7 SP1 / Windows Server 2008 R2 SP1 , Windows 8.1 / Windows Server 2012 (R2). Hay dos opciones:

image

Instalando los módulos de Azure

Teniendo ya nuestro PowerShellGet preparado –recuerda que si estás en Windows 10, ¡no tenías que hacer nada!-, instalar las herramientas de Azure es completamente trivial. Basta con ejecutar este script como administrador del sistema:

Esto nos debería dar una salida por pantalla pantalla similar a la siguiente:

image

¿Hecho? Empezar a trabajar con Azure desde PowerShell será tan sencillo como:

Actualizando o desinstalando módulos

Y esto es lo mejor, ya que mantener al día nuestra herramienta se vuelve realmente trivial:

Y la desinstalación:

Sabiendo esto, es incluso posible programar una tarea que vele por que nuestras herramientas se mantengan actualizadas ejecutando los cmdlets necesarios en los momentos adecuados.

¡Happy PowerShell y Azure!

Enlace relacionado: Cómo instalar y configurar Azure PowerShell

Evento: Conectando Microsoft Azure con Amazon Web Services (Almería)

¡El próximo jueves 18 de febrero vuelvo a las tierras del sur donde estaré dando una reedición de la sesión que Alberto Marcos y servidor dimos en el Global Azure BootCamp 2015!

  • Título: Conectando Microsoft Azure con Amazon Web Services
  • Fecha: jueves, 18 de febrero de 2016
  • Hora:  12:15 – 14:15
  • Ubicación: Sala de Grados del Edificio de Gobierno – Universidad de Almería, Almería
  • Abstract: ¡Microsoft Azure y Amazon Web Services pueden vivir juntos! En esta charla mostraré cómo podemos establecer un escenario híbrido que nos permita conectar ambas plataformas de cloud computing y una serie de escenarios de ejemplo donde podemos aprovechar esta integración.
  • Registro: No es necesario registrarse, ¡entrada libre!
  • Ponente: Carlos Milán Figueredo – Enterprise Team Lead (Plain Concepts)

¡Allí os espero!

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!

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!

Cuando el esfuerzo y el trabajo duro superan al talento

La palabra con la que me quedo de este 2015 es esfuerzo, y me gustaría hacerlo contrastar con el talento. Según la RAE, el esfuerzo es el “empleo enérgico del vigor o actividad del ánimo para conseguir algo venciendo dificultades”. Ese algo que conseguimos puede ser desplazar el sofá de una habitación a otra o bien la resolución de un fallo en un complicado algoritmo. En contraste con el esfuerzo tenemos el talento, que todos entendemos como una aptitud, la mayoría de las veces innata para desempeñar una determinada actividad. ¿Cuántas veces no hemos escuchado “se le da muy bien hacer eso”? Es una frase muy común de reconocimiento de talento.

A este efecto me gustaría haceros llegar el genial discurso del archiconocido Gran Maestro del ajedrez, Garry Kasparov que dio el pasado 16 de mayo en la universidad de St. Louis:

clip_image001

Discurso de Garry Kasparov en la St. Louis University, 16 de mayo de 2015 (minuto 9:04)

(…) It’s never too late to dream. You often hear in chess and in other sports that “this” player is more talented but “that” player works harder. This is a fallacy. Hard work IS a talent. The ability to keep trying when others quit is a talent and hard work is NEVER wasted. No matter what career you end up with or even if you have dozen different careers. (…) Human beings cannot upgrade their hardware, that is our DNA, but it is hard work what can definitely upgrade our mental software.

Traducción: (…) Nunca es demasiado tarde para soñar. Siempre escuchamos en el ajedrez y otros deportes que “este” jugador tiene más talento pero que “ese otro” trabaja más duro. Eso es una falacia. El trabajo duro ES talento. La habilidad de intentarlo una y otra vez cuando los demás abandonan es un talento y el trabajo duro NUNCA es inútil. No importa la carrera con la que acabes o incluso si tienes docenas de carreras diferentes. (…) Los seres humanos no pueden actualizar su hardware, eso es nuestro ADN, pero es el trabajo duro lo que definitivamente puede actualizar nuestro software mental.

No podría estar más de acuerdo con Kasparov. Incluso Winston Churchill ya decía que “El éxito consiste en ir de fracaso en fracaso sin perder el entusiasmo”. No caigamos nunca en la trampa de pensar que el talento es algo con lo que se nace o no y que está totalmente fuera de nuestro alcance el modificar este hecho. Ese es el pensamiento fácil y cómodo, me atrevería a decir que incluso de zona de confort; pero que al mismo tiempo no nos llevará nunca a cumplir nuestros sueños.

En mi experiencia con multitud de situaciones personales y profesionales en las que me he visto envuelto este año, puedo decir rotundamente que los logros y los éxitos que he obtenido han sido en base a trabajar mucho, con pasión y entusiasmo. Estoy bien lejos de considerarme a mí mismo un genio o una persona con algún talento especial, sino que todo es cuestión de intentarlo una y otra vez sin abandonar en ningún momento.

Os invito a lo mismo. Os invito a actualizar nuestro software mental durante el próximo 2016 y a perseguir nuestros sueños con todas nuestras fuerzas.

¡Feliz Navidad y Próspero Año 2016!

Azure Resource Manager, el nuevo paradigma de Azure

Últimamente estamos escuchando hablar mucho de ARM en un contexto de Azure, y pese a que inicialmente nos sugiera la conocida arquitectura de procesadores, nada más lejos de la realidad, puesto que nos referimos a Azure Resource Manager, que es el nuevo paradigma sobre el que se estructura toda la administración de Microsoft Azure. Como hemos mencionado en otras ocasiones, Azure consta de una gran cantidad de componentes: máquinas virtuales, redes virtuales, almacenamiento, bases de datos, etc… que podemos combinar para ofrecer el servicio que queramos desplegar. Hasta ahora, en Azure estos distintos componentes constituían entidades discretas sin ninguna relación administrativa entre ellas, a pesar de que colaborasen entre sí para ofrecer una determinada solución; como lo es el caso en que un servidor web y una base de datos trabajan conjuntamente para hospedar un CMS como Drupal.

¿Qué es Azure Resource Manager?

Azure Resource Manager cambia este paradigma con el que hemos trabajado hasta ahora para componentenizar todos los elementos de Azure. Todos los componentes de Azure son ahora recursos, ya hablemos de una máquina virtual, su adaptador de red, una IP pública, una base de datos o un sitio web. Estos componentes se organizan en agrupaciones lógicas conocidas como grupos de recursos, que nos permiten aglutinarlos bajo una únidad administrativa que contiene la solución.

Así pues, imaginemos que queremos implementar un sistema de WordPress en IaaS. ¿Qué componentes necesitamos?

  • 2 máquinas virtuales: az-wp-apache, az-wp-mysql
  • 2 interfaces de red, una para cada máquina virtual: az-wp-apache-nic1, az-wp-mysql-nic2
  • 1 red virtual: az-wp-vnet1
  • 2 grupos de seguridad de red, uno para interfaz de red o máquina virtual: az-wp-apache-nsg1, az-wp-mysql-nsg2
  • 1 cuenta de storage: az-wp-st01
  • 1 dirección IP pública: az-wp-apache-pip

Todos estos componentes los podemos agrupar bajo un mismo grupo de recursos llamado az-wp-rg. Con ello hemos conseguido crear una unidad administrativa común para ellos. ¿Qué nos permite esta nueva unidad?

  • Desplegar el mismo conjunto de recursos tantas veces como necesitemos, creando distintas instancias de WordPress con su correspondiente base de datos. Esto es posible gracias a que podemos extraer una plantilla con la definición completa de los elementos que hemos creado.
  • Definir dependencias entre recursos de forma que se desplieguen en el orden correcto.
  • Aplicar control de acceso basado en roles (RBAC) al grupo de recursos, de forma que podemos definir administradores de Azure sólo para esta solución, en lugar de para toda la suscripción como ocurría hasta ahora.
  • Aplicar etiquetas a cada uno de los distintos recursos, lo que nos permite organizarlos mejor en la suscripción.
  • Monitorizar el estado de salid de la solución completa que se encuentra contenida en el grupo de recursos.
  • Ver los costes de la solución como conjunto, en lugar de la suma de los elementos separados.
  • Eliminar todos los recursos de la implementación especificando a Azure que queremos borrar el grupo de recursos correspondiente. Hasta ahora, debíamos eliminar individualmente cada servicio y era fácil que se nos olvidase algo.

¿Cón qué hemos estado trabajando hasta ahora?

Hasta ahora el modelo de Azure con el que se trabajaba estaba orientado a servicio y se conoce como Azure Service Manager (ASM). Estas son las principales diferencias entre ambos modelos:

Azure Service Manager Azure Resource Manager
Portal antiguo No
Portal nuevo
API REST XML JSON
RBAC No
Tags No
Automatización Procedural (PowerShell y XML) Declarativa (JSON)
Grupos de recursos No
Recursos enlazados Muy limitado

A continuación podemos ver el aspecto de la administración de un grupo de recursos desde el nuevo portal de Azure. Como se observa en la captura, se trata de un grupo de recursos para hospedar un entorno de AD Connect y ADFS.

image

Plantillas JSON

Una de las grandes novedades y potencias del nuevo Azure Resource Manager son las plantillas JSON que nos permiten desplegar recursos de Azure de forma declarativa, encargándose la propia plataforma de las tareas implicadas en su despliegue. Estas plantillas están descritas con gran nivel de detalle aquí y se pueden observar multitud de ejemplos en este repositorio oficial de Microsoft en Github. Otra alternativa es visitar la galería de plantillas JSON de Azure donde se nos muestra el repositorio organizado gráficamente y con descripciones de cada una de ellas; ¡incluso podemos desplegarlas en nuestra suscripción con un sencillo clic de ratón!

Si vamos a construir una plantilla desde 0, es posible que nos resulte algo indigesto, así que para hacerlo sencillo lo mejor es valernos de la Azure Tools para Visual Studio (válido también para la versión gratuita Community). Al crear un nuevo proyecto tenemos opción a crear un nuevo Grupo de Recursos de Azure.

image

Tras lo cual se nos mostrará una serie de plantillas predefinidas en las que podemos basarnos para construir nuestro entorno. Si elegimos la de desplegar una máquina virtual con Ubuntu Server…

image

Veremos que en el Solution Explorer se nos crea la plantilla predefinida para llevar a cabo la implementación:

image

Con el siguiente código, que podemos modificar a nuestro gusto:

Trabajar con ello desde Notepad o Vim podría ser indigesto, pero Visual Studio nos da una serie de ayudas para que la experiencia sea mucho más llevadera, como el explorador JSON, que nos muestra todos los parámetros, variables y recursos de Azure presentes en el código. ¡Anímate a probarlo!

image

Azure Resource Explorer

Aunque no sea especialmente conocido y se encuentre el Preview, Azure Resource Manager dispone de una herramienta llamada Azure Resource Explorer, a la que podemos acceder desde https://resources.azure.com. Tras validarnos con nuestras credenciales, la herramienta nos permite navegar por todos y cada uno de los recursos de nuestras subscripciones y hacer pruebas de llamadas a la API REST para realizar operaciones. Si ya tienes grupos de recursos en tu suscripción de Azure y quieres obtener el JSON para desplegarlos en otros entornos (todavía no disponible), esta herramienta resulta realmente útil. Pinta tal que así:

image

Azure Service Manager o Azure Resource Manager, ¿con cuál trabajo?

La opción por defecto debería ser Azure Resource Manager. El modelo ASM es a extinguir y aunque por razones obvias va a continuar teniendo soporte por parte de Microsoft durante mucho tiempo, todos los nuevos trabajos deberíamos hacerlos mediante ARM. Sin embargo, si hasta ahora has trabajado con ASM y quieres pasar a ARM, es importante que hagas las dos siguientes lecturas:

Y eso ha sido todo por ahora. Espero que este post os sirva para ilustraros el mar de posibilidades que el nuevo modelo basado en recursos de Azure nos provee tanto a los profesionales de infraestructura como a los desarrolladores a la hora de sacar el máximo partido de la nube.

¡Felices Fiestas!