El primer Camp coordinado por el TechClub del área de sistemas del curso MCSA-MCSE de este año 2017-18 ha sido el titulado: “Best Practices de Powershell para MS Azure”, presentado por Antonio López Márquez, Enterprise Engineer y doctorado europeo Cum Laude en Computación.

Este Camp ha generado mucha expectación: el sitio EventBrite del evento tuvo que colgar el cartel de “Entradas agotadas” más de una semana antes de la presentación.

Antonio López Márquez estuvo a cargo de la ponencia

¿Best Practices?

Es un poco complicado describir lo que serían “buenas prácticas” en un ámbito en el que se espera que la infraestructura “funcione”, pero se podría decir que una infraestructura puede “funcionar” en el escenario, de cara al usuario o al cliente, pero también hay que optimizarla en el backstage que es la administración de sistemas e infraestructura: ¿Estamos reduciendo el número de iteraciones? ¿Estamos usando cmdlets obsoletos, actuales o en pruebas? ¿Estamos llevando la información con plantillas más “ligeras” o más “pesadas”?

En esta MasterClass se ha mostrado, desde lo más sencillo de los cmdlets de powershell, hasta scripts de despliegue de infraestructura en Azure. Microsoft está apostando fuerte para que Powershell sea la próxima interfaz multiuso para la gestión de infraestructuras Windows, tanto en entornos on-premise como integrándola en Azure con su propia consola en Azure Resource Manager (ARM).

Para todos los que se decantaron por sistemas antes que programación para evitar la programación, hay malas noticias: El futuro de la gestión de Windows no solo tiene más forma de línea de comandos que de consola gráfica, sino que los scripts de PowerShell pueden convertirse en el arsenal de “weapons of choice” del SysAdmin del futuro.

PowerShell. O “Regreso al CLI”

Probablemente, el futuro de la administración de sistemas a gran escala tenga este aspecto

Windows: Ventanas. Ese salto cualitativo allá por los años 80, para pasar de una línea en MS-DOS a un mundo en el que el ratón iba conquistando el protagonismo que hasta entonces habían tenido los teclados, fue gigantesco. Las Ventanas surgían, y poco a poco iban ganando fuerza. Se solapaban, se hacían más complejas, más completas. Los Wizards más comunes dejaban de ser un “prompt” de sí o no y pasaban a ser menús con desplegables y botones, hasta dejar a esa ventana de CMD relegada a comandos de sintaxis propias de cada comando, hechos para configuraciones excepcionales o incluso por el hobby de volver a esa sensación “retro”.

Los tiempos cambian. La gestión de sistemas se mueve con este devenir. Un servidor ya no es ese monstruo con cientos de servicios en ejecución. Un servidor puede ser una máquina virtual a la que llegamos conectándonos a la nube, corriendo sobre un CPD que contiene cientos o miles de máquinas virtuales similares. La idea de “un servidor para controlarlos a todos” ya quedó obsoleta. Los servidores ahora son legión. Llevan menos servicios, la infraestructura se atomiza, se clona, gana en redundancia, gana en fault-tolerance y llegar a nuestra “legión de servidores” particular requiere de una herramienta escalable, capaz de llevar una misma orden a cada una de nuestras máquinas lanzando servicios. Las interfaces gráficas, aunque cómodas, no siempre son escalables.

PowerShell sí.

Y no solo puede llegar a todos, sino que permite lanzar una misma tarea muchas veces, integrando elementos de programación para facilitar la gestión de sistemas: bucles, arrays, contadores. Variables de toda índole, se pueden crear, manipular y transformar en un script de Powershell para poder gestionar los “ejércitos” de servidores, y Microsoft no solo está apostando fuerte para que Powershell sea la nueva interfaz de administración de sistemas, sino que los servidores se van escapando de nuestro CPD on premise, volando hacia la nube, y Microsoft tampoco quiere perderse esa transformación. Por eso la integración de Powershell con Azure, el servicio cloud de Microsoft, se hace inevitable, y ofrece interesantes sinergias, por lo que la gestión de la infraestructura Windows del futuro vuelve a estar, al igual que en los tiempos de MS-DOS, sobre un teclado, más que sobre un ratón.

PowerShell, esa nueva interfaz de línea de comandos, con una sintaxis bastante más estandarizada, y que implementa políticas de seguridad y ejecución más “tuneables”, permite crear entornos powershell dentro de entornos powershell, construir un flujo de datos a través de distintas tuberías y permite (que en realidad esto es lo importante para un Sysadmin) hilar muy fino a la hora de crear, modificar o configurar máquinas y servicios tanto a nivel local como de manera remota.

No puedes escapar de la programación

Y no nos engañemos, esto significa en mayor o menor medida, programar con cmdlets de powershell. Programar para todo. Aunque lo hayamos “evitado” hasta ahora, lo hemos estado usando, incluso para freír un huevo.

¿Freir un huevo también es programar? Antonio nos demostró que sí

“tenemos que freír un huevo, así que ponemos una sartén, echamos aceite y lo ponemos a calentar. Ya tenemos una variable: la temperatura del aceite. Si la temperatura del aceite alcanza un nivel, se cumple una condición. Echamos el huevo y comienza a procesarse. Si el huevo se va poniendo amarillo, es otro indicador con otra condición, que nos hace sacarlo, porque se nos quema”

 

Azure nos permite crear MVs. Estas MVs se valen de recursos: almacenamiento, interfaces, ACLs o redes virtuales, y dichos recursos pueden configurarse y conectarse a máquinas virtuales a través de la consola PowerShell integrada en el portal de Azure. La palabra Recursos (Resources) es más importante de lo que parece a la hora de comprender los cmdlets relacionados.

Crear una máquina virtual requiere tener antes un “Resource Group” creado. Ese Resource Group puede ser cualquier elemento de los mencionados antes, y para crearlo también nos podemos valer de un Script para automatizar este proceso o incluso para futuras operaciones similares, siempre que controlemos los objetos implicados, e incluso estratificarlo por fases con tuberías para ir controlando cada paso del proceso. Crear una red virtual en la infraestructura Azure se convierte en algo así:

  • Una fase new-azurermresourcegroup
  • Una fase new-azurermvirtualnetwork que apunte a ese resource group cargada en una variable
  • Una fase set-azurermvirtualnetwork que tenga como –virtualnetwork la variable anterior

Antes, la configuración de MVs por powershell se basaban en plantillas XML. Eso ahora está quedando obsoleto, y las plantillas vienen en JSON. Mucho más ágil de cara a la fase de despliegue. De hecho, se genera un JSON en las distintas fases de creación de elementos que nos sirven para modificar y configurar estos resourcegroups dentro de nuestra infraestructura en azure.

Los aspectos básicos para controlar la creación de MVs desde Powershell, es ir “al revés” de lo que sería una sintaxis al uso, definiendo en variables los detalles que incluiremos en las opciones de un cmdlet final que es el que engloba todas las variables previas para lanzar un comando en el que el control se debe tener sobre el contenido de las variables, pudiendo reproducir el funcionamiento del cmdlet modificando únicamente unos pocos o incluso un solo valor en las variables, en vez de reproducir todo el cmdlet paso a paso, incluyendo las opciones “a mano” sin agregarlas a través de variables ya cargadas en la sesión.

Ademas hay que empezar por el tejado, definiendo los detalles de las variables antes de lanzar el cmdlet

Un script puede ser inviable para levantar una sola MV, pero ofrece posibilidades interesantes a medida se va incrementando el número de recursos implicados. Para levantar 20 VMs puede venirnos bien. Para levantar cientos, se hace necesario. Además, permite controlar variables y opciones difíciles de visualizar si tecleáramos los comandos uno a uno. Las variables se van agregando a un script, y de ese modo siempre las tendremos en cuenta a la hora de ejecutar el script, mientras que, tecleando un solo comando repetidas veces, podría suceder que dejáramos algún detalle, opción o parámetro en el tintero.

Hay que tener ciertas precauciones con las variables que cargamos en el entorno PowerShell: No son persistentes. Si cargamos variables en la consola para lanzar scripts automatizados usando esas variables y cerramos la consola, esas variables se perderán.

Desplegar por plantillas y controlar la infraestructura a través de scripts nos hace trascender hacia un concepto de Infrastructure as code. Esto acerca al Sysadmin a un rol más cercano a un Devops, al tener que “codear” lo necesario para un despliegue de infraestructura. Esta labor de coding facilita despliegues amplios, permite afinar variables y parámetros optimizando el esfuerzo invertido a medida se amplía el volumen de la infraestructura a desplegar.

Una ventaja añadida de Azure es que nos permite implementar scripts de despliegue automatizado desde el portal, controlando y documentando los distintos pasos que implica un despliegue por plantillas.

Las plantillas JSON son potentes, pero también peligrosas. Se pueden bajar las llamadas “quick starter templates”, documentación oficial de Microsoft: aproximadamente 650 plantillas JSON para diferentes operaciones, para que, sin conocer muy a fondo la sintaxis de una plantilla JSON, podamos trabajar sobre una base en la que, sustituyendo una serie de valores dentro de un archivo .json, pueda servirnos como plantilla para un despliegue un poco más “tailor-made”.

Los detalles para las MVs se pueden definir en una plantilla que de base, tiene esta forma

Antonio recomienda, para desplegar por plantillas creadas por nosotros, usar Powershell, más que la interfaz con el portal de Azure RM, recomendada si usamos las quick starter templates.

Conclusión.

Este Camp va tocando a su fin. Ha sido un viaje desde el get-help más sencillo hasta crear una máquina sin haber clicado el ratón más que para verificar que la máquina se ha creado en la consola de AzureRM, pasando por puntos interesantes como crear nuestro propio “help”, nuestra propia función o revisando alguna plantilla JSON.

Este Camp, que debía durar 3 días, ha durado una mañana, y en algunos momentos sí ha sido intenso en términos de seguir la pista a Antonio, pero la audiencia estaba esperando el momento en el que Powershell toma contacto con Azure para crear y gestionar recursos, y en la segunda mitad, en la que hemos salido de “indicaciones para powershell”, y entrado en “powershell para azure”, es cuando el operar por variables, pipes, bucles y arrays ha cobrado sentido.

¡Hasta la próxima!

 

Documentación del Camp:

Parte 1. PowerShell y Azure

Parte 2. PowerShell y Azure

Parte 3. PowerShell y Azure

 

Autor: Gabriel Piuzzi Martínez

Coordinador Tech Club Tajamar

Alumno Máster Microsoft MCSA Windows Server 2016 + MCSE Cloud Platform & Infrastructure.

Año académico: 2017-2018