Recientemente me topé con una herramienta que aún no es muy popular en el mundo de DevOps: los pipelines de Azure DevOps. Inmediatamente noté la falta de instrucciones o artículos claros sobre el tema; no sé a qué se debe, pero Microsoft definitivamente tiene trabajo por hacer en la promoción de esta herramienta. Hoy construiremos un pipeline para la prueba automatizada dentro de la nube de Azure.

Así que, la tarea es:
Tenemos un software que se compila utilizando Azure DevOps, se construye desde un proyecto en WIX. Si hay interés, podría escribir sobre esta herramienta también. En realidad, es una forma más optimizada de automatizar la creación de instaladores en Windows, reemplazando el estándar InstallShield. Así que, nuestro software se compila con éxito y genera un artefacto, un setup.exe, que instala la aplicación en el sistema Windows. Es necesario instalar esta aplicación en una máquina virtual similar a la de producción, copiar allí las pruebas automatizadas preparadas por el equipo de testing, ejecutarlas y recoger los resultados para determinar si la rama es buena o mala antes de fusionar. Todo como en GitLab, solo que a través de un camino más complicado.

Como entorno de virtualización en el que ejecutaremos nuestras pruebas, usaremos, obviamente, Azure DevTest Labs, una entidad en las suscripciones de Azure diseñada precisamente para ejecutar todo tipo de pruebas por un costo razonable.

1. Integración en el lado de la nube

Para empezar, necesitaremos integrar nuestro DevTest Labs con Azure DevOps, para lo cual necesitaremos un Service Principal, que es esencialmente una cuenta de servicio que permite que los pipelines accedan a la nube y creen/eliminar recursos para sí mismos.

Vamos a la suscripción y encontramos el servicio Azure Active Directory

Buscamos Registraciones de Aplicaciones y hacemos clic en Nueva Registro, esto creará nuestro service principal. No profundizaré en qué configuraciones elegir al crear, ya que puede variar entre diferentes suscripciones.

Ahora necesitamos otorgar permisos a nuestro director de servicio. Para ello, vamos a las suscripciones, el ícono con la llave. Seleccionamos nuestra suscripción.

Luego, en Control de Acceso, hacemos clic en Asignación de Roles y buscamos en la búsqueda con el nombre que acabamos de crear esta cuenta. Le otorgamos el rol de Contribuyente, eso es suficiente.

Luego regresamos a nuestro Service Principal en Azure AD y abrimos sus propiedades. Más tarde necesitaremos todos los ID que hay ahí, así que los guardamos.

Con esto, nuestras configuraciones en el portal han finalizado y pasamos a Azure DevOps.

2. Integración en Azure DevOps

Primero, accedemos a la configuración del proyecto y seleccionamos Conexiones de Servicio. Creamos un nuevo elemento del tipo Administrador de Recursos de Azure.

Ahora necesitaremos todas las ID que hemos anotado. Hacemos clic en usar la versión completa del cuadro de diálogo de conexión de servicio. Introducimos todos los datos que obtuvimos de Service Principal. Hacemos clic en verificar y, si todo está bien, guardamos la conexión. Ahora nuestros pipelines pueden usarla para conectarse a la nube.

3. Creación de un pipeline

Ahora procedemos a la parte más interesante, construir el pipeline en sí. Abrimos el menú Pipelines-Builds

Nos recibe el menú de creación de un nuevo build, que por defecto intentará crear un archivo YAML de configuración apropiado. Cortésmente, rechazamos esto y elegimos la opción clásica. Es comprensible el deseo de Microsoft de hacer las cosas de forma amigable y ofrecer la posibilidad de personalizar al máximo los pipelines a través de YAML, pero la escasa documentación y simplemente la inoperabilidad práctica de muchos módulos nos indican que aún es temprano para usar esta funcionalidad.

De la variedad de plantillas, necesitaremos una Simple Empty Pipeline. Tras su creación, nos encontramos con una ventana de edición vacía, donde pasaremos bastante tiempo.

Entonces, hacemos clic en + y entramos en una especie de tienda de módulos, de donde necesitaremos los siguientes componentes.

Antes de que comencemos a configurar las tareas del pipeline, necesitamos crear y añadir al proyecto varios archivos. Estos serán la plantilla ARM de nuestra máquina virtual, que generaremos en Azure DevTest Labs, un script para obtener la IP de la máquina después de que se haya creado, y, opcionalmente, scripts para nuestras pruebas o lo que queremos ejecutar en el host.

4. Generación de la plantilla ARM

Para crear la máquina virtual, necesitaremos primero generar una plantilla, un archivo json que vamos a incluir en el código del proyecto, para que el pipeline pueda leerlo desde allí.

Vamos a nuestro laboratorio y encontramos el menú Fórmulas (bases reutilizables), hacemos clic en crear una nueva.

Nos recibe una larga lista de imágenes como base, la selección del tamaño de la máquina, todo igual que al crear la máquina virtual. En esta etapa no nos detendremos, pasaremos directamente al último punto de las propiedades de la máquina, es decir, los artefactos. Puedes usar cualquier configuración que sea necesaria para tu entorno. Por ejemplo, estoy añadiendo la máquina a nombre de dominio y agrego una cuenta de servicio como administrador para que el pipeline pueda acceder a esta máquina con esta cuenta. Todo esto puede variar, pero para una prueba de código exitosa necesitamos un artefacto, del cual hablaremos con más detalle. Para que se instale la última versión del software que estamos probando en nuestra máquina, utilizaremos el artefacto 'Descargar el artefacto de Azure Pipelines y ejecutar script'. Recuerden que al principio mencioné que en algún lugar se está generando el build con el instalador de la aplicación? Ahora debemos decirle a la virtual, más exactamente al template, que vaya y recoja este artefacto. Y no solo que lo recoja, sino que lo instale, para lo cual llenamos campos especiales indicando el proyecto, el nombre del build y la clave secreta. La clave secreta, como en todos los sistemas de este tipo, se genera en la cuenta, en este caso en Azure DevOps y se guarda en Secrets en su laboratorio. Hay una pequeña aclaración, en Secrets la guardaremos, pero al template no le afectará, él se ejecutará bajo otro usuario en el marco del pipeline, por lo que la clave secreta tendremos que ingresarla nuevamente manualmente en el template.

Otro artefacto que debe incluirse es 'Configurar WinRM', que necesitaremos para acceder a la máquina posteriormente. Solo hay un parámetro, hostname. Dado que no lo sabemos de antemano, usaremos la variable %COMPUTERNAME%.

Así que hemos agregado todos los artefactos necesarios, ahora pasamos a la razón por la que estamos aquí. Extraemos el Template ARM generado en la pestaña Avanzado de la misma ventana de creación de la fórmula.

Copiamos el contenido de la página en el archivo VMtemplate.json y lo colocamos en la raíz del proyecto. No necesitamos más de la nube, volvemos al pipeline.

5. Configuración del pipeline

Comencemos con lo más importante e interesante: la creación de la máquina virtual, para eso hicimos todas estas integraciones y plantillas. En el apartado de Azure RM Subscription, seleccionamos nuestra conexión de servicio que configuramos en el punto 2. Luego debería aparecer el entorno de laboratorio disponible para nosotros. Después seleccionamos el JSON que generamos y definimos algunas variables obligatorias. Se puede establecer el inicio de sesión y la contraseña de la máquina directamente o mediante variables, pero no estoy seguro de que eso funcione; independientemente de lo que escriba, no he podido acceder a la máquina con esas credenciales. Es importante asignar un nombre a la máquina que siempre sea, en la medida de lo posible, único. Para ello, uso la variable de entorno de la construcción.

A continuación, configuramos otro aspecto importante. Después de que la máquina se levante, necesitamos conocer sus parámetros, o mejor dicho, el pipeline necesita conocerlos. Para ello, creamos un script, por ejemplo GetLabVMParams.ps1, y lo colocamos en el proyecto. El texto del script lo tomé del sitio de Microsoft, pero lo modifiqué un poco para mi entorno, ya que buscaba PublicIP y FQDN de la máquina. No tengo ninguno de los dos, pero tengo PrivateIP, que no es tan fácil de obtener, por eso añadí una sección.

Param( [string] $labVmId)

$labVmComputeId = (Get-AzureRmResource -Id $labVmId).Properties.ComputeId

# Obtener el nombre del grupo de recursos de la máquina virtual del laboratorio
$labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName

# Obtener el nombre de la máquina virtual del laboratorio
$labVmName = (Get-AzureRmResource -Id $labVmId).Name

# Obtener la dirección IP pública de la máquina virtual del laboratorio
# $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress

# Obtener el FQDN de la máquina virtual del laboratorio
# $labVMFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).DnsSettings.Fqdn

# Obtener la dirección IP privada de la máquina virtual del laboratorio
$VmNetworkdetails= (((Get-AzureRmVM -ResourceGroupName $labVmRgName -Name $labVmName).NetworkProfile).NetworkInterfaces).Id
$nicname = $VmNetworkdetails.substring($VmNetworkdetails.LastIndexOf("/")+1)
$labVMnetwork = (Get-AzureRmNetworkInterface -Name $nicname -ResourceGroupName $labVmRgName)|Select-Object -ExpandProperty IPConfigurations 
$labVMIpAddress = $labVMnetwork.PrivateIpAddress

# Establecer una variable labVmRgName para almacenar el nombre del grupo de recursos de la máquina virtual del laboratorio
Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName"

# Establecer una variable labVMIpAddress para almacenar la dirección IP de la máquina virtual del laboratorio
Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress"

# Establecer una variable labVMFqdn para almacenar el nombre FQDN de la máquina virtual del laboratorio
Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn"

Write-Output $labVMIpAddress

Set-Item wsman:localhostclienttrustedhosts * -Force

De toda la información que lee el script, solo necesitamos la variable labVMIpAddress. Bueno, eso es lo que necesito; tal vez necesiten algo más, así que no eliminé nada y solo comenté lo que sobraba.

También explicaré la última línea del script; permite que nuestra máquina de construcción tenga acceso a cualquier host a través de WinRM.

En la siguiente etapa, lanzamos nuestro magnífico script. Requerirá la misma conexión a la nube, y la variable de entrada con el ID de la máquina, que ya será conocida a partir del paso anterior. ¿Cómo? Aquí es necesario mencionar algo maravilloso como las Variables de Salida. Cada paso puede tener una lista de variables que se transmiten a los siguientes pasos del pipeline. Por lo tanto, para nuestro super script, esa variable será labVMIpAddress, no olviden especificarla.

A continuación, hago cosas bastante simples, que además pueden variar de caso a caso. Ejecuto un script remoto creando un recurso compartido, donde luego cargaré mis scripts.

New-Item “C:test" –type directory
New-SMBShare –Name “test” –Path “C:test”  –FullAccess everyone

Por el nombre de las tareas, está claro que luego copiamos un cierto script de ejemplo a la máquina y en un paso adicional lo ejecutamos. Como dirección de la máquina remota, nos será útil nuestra variable $(labVMIpAddress). Luego, utilizamos la tarea ‘recoger artefacto del recurso compartido’ y copiamos los resultados de la ejecución del script a nuestro entorno de construcción, luego, con la misma tarea estándar, guardamos esos archivos en el artefacto de construcción. Después de que ya no necesitemos la máquina, en la última etapa la destruimos. La principal dificultad, como se puede ver en la longitud del artículo, es integrarse con la nube y establecer contacto con la máquina virtual que has creado; después de eso, ya se puede divertirse todo lo que se necesite.

Este es mi primer artículo, así que no sean muy duros, se agradecen los comentarios.

Fuente: habr.com