Recientemente, me encontré con una bestia no tan popular en el mundo de DevOps, las tuberías de Azure DevOps. Inmediatamente sentí la ausencia de instrucciones o artículos claros sobre el tema, no sé con qué está conectado, pero Microsoft claramente tiene algo en qué trabajar en términos de popularización de la herramienta. Hoy construiremos una tubería para pruebas automatizadas dentro de la nube de Azure.

Entonces, la tarea:
Hay un software que se construye con el mismo Azure DevOps, se ensambla a partir de un proyecto en WIX. Si hay interés, escribiré sobre esta herramienta. De hecho, esta es una forma más automatizada de construir instaladores de Windows, que reemplaza el InstallShield estándar. Por lo tanto, nuestro software crea y genera con éxito un artefacto, un determinado setup.exe, que coloca la aplicación en un sistema Windows. Es necesario poner esta aplicación en una máquina virtual similar a un producto, copiar las pruebas automatizadas preparadas por el equipo de prueba allí, ejecutarlas y recopilar los resultados para considerar que la rama es buena o mala antes de fusionarse. Todo es como en GitLab, solo a través de w ...

Como un entorno de virtualización donde ejecutaremos nuestras pruebas, obviamente usamos Azure DevTest Labs, una entidad en las suscripciones de Azure, que fue creada para torcer todo tipo de tonterías de prueba por dinero razonable.

1. Integración del lado de la nube

Primero, necesitamos integrar nuestros DevTest Labs con Azure DevOps, para lo cual necesitamos un Service Principal, esencialmente una cuenta de servicio que le permita ir a las tuberías en la nube y crear / eliminar recursos allí para nosotros mismos.

Vaya a la suscripción y busque el servicio Azure Active Directory



Encontramos registros de aplicaciones y hacemos clic en Nuevo registro, esto creará nuestro principal de servicio. No repasaré qué configuración elegiré al crear, esto puede diferir para diferentes suscripciones.



Ahora debemos otorgar derechos a nuestro director de servicio. Para hacer esto, vaya al icono de suscripción con una clave. Elige nuestra suscripción.



A continuación, en Control de acceso, haga clic en Asignación de roles y busque esta cuenta en la búsqueda por el nombre que acaba de crear. Le damos el rol de Colaborador, esto es suficiente.



Luego, regrese a nuestro Service Principal en Azure AD y abra sus propiedades. Más tarde, necesitaremos todas las ID que estén allí, las guardaremos.

Aquí es donde termina la configuración de nuestro portal y vamos a Azure DevOps.

2. Integración del lado de Azure DevOps

En primer lugar, vamos a la configuración del proyecto y seleccionamos Conexiones de servicio. Cree un nuevo elemento de tipo Azure Resource Manager.



Ahora necesitamos todas las ID que grabamos. Haga clic en usar la versión completa del cuadro de diálogo de conexión de servicio. E ingrese todos los datos que recibimos del Director del Servicio. Haga clic en verificar y si todo está bien, mantenga la conexión. Ahora nuestras tuberías pueden usarlo para conectarse a la nube.

3. Crear una tubería

Ahora procedemos a lo más interesante, la construcción de la tubería en sí. Abra el menú de construcción de tuberías



Nos recibe un menú para crear una nueva compilación, que por defecto intentará crear un archivo YAML para nosotros con una configuración adecuada. Rechazamos cortésmente esto y elegimos la versión clásica. El deseo de Microsoft de hacer todo como las personas y dar la oportunidad de personalizar las canalizaciones a través de YAML tanto como sea posible, pero la escasa documentación y la inoperancia práctica de muchos módulos nos dice que es demasiado pronto para usar esta funcionalidad.



De la variedad de plantillas, necesitamos una tubería vacía simple. Después de su creación, nos recibe una ventana de edición vacía, en la que pasaremos mucho tiempo.



Por lo tanto, haga clic en + y acceda a una determinada tienda de módulos, desde donde necesitaremos los siguientes componentes de la lista.



Antes de continuar con la configuración de la tarea de canalización, necesitamos crear y poner varios archivos en el proyecto. Esta será la plantilla ARM de nuestra máquina virtual, que generaremos en Azure DevTest Labs, el script para obtener la máquina IP después de que se haya creado y, si lo desea, los scripts de nuestras pruebas o lo que queremos ejecutar en el host.

4. Generación de plantillas ARM

Para crear una máquina virtual, primero tendremos que generar una plantilla para ella, un archivo json, que colocamos en el código del proyecto para que pueda ser leído desde allí por la tubería.

Vamos a nuestro laboratorio y buscamos el menú Fórmulas (bases reutilizables), hacemos clic para crear uno nuevo.



Seremos recibidos por una larga lista de imágenes como base, la elección del tamaño de la máquina, todo lo mismo que cuando se crea una máquina virtual. En esta etapa, no nos detendremos, pasaremos de inmediato al último elemento de las propiedades de la máquina, a saber, los artefactos. Puede usar cualquier configuración que sea necesaria para su entorno. Por ejemplo, agrego una máquina al dominio y le agrego una cuenta de servicio como administrador para que la tubería pueda acceder a esta máquina con esta cuenta. Todo esto puede variar, pero para una prueba exitosa del código necesitamos un artefacto, en el que nos detendremos con más detalle. Para poner la última versión del software que probamos en nuestra máquina, utilizaremos el artefacto Descargar Azure Pipelines Artifact y Run Script. ¿Recuerdas que al principio dije que en algún lugar una compilación va con el instalador de la aplicación? Ahora necesitamos decirle a la máquina virtual, o más bien a la plantilla, para que vaya y tome este artefacto. Y no solo lo recogí, sino que también lo configuré, para lo cual completamos campos especiales que indican el proyecto, el nombre de la compilación 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 almacena en Secretos en su laboratorio. Hay una pequeña advertencia, en Secrets la guardaremos, pero no está fría ni caliente, se lanzará desde otro usuario como parte de la tubería, por lo tanto, tendremos que ingresar manualmente la clave secreta en la plantilla nuevamente.

Otro artefacto que debe incluirse es "Configurar WinRM", lo necesitaremos para el acceso posterior a la máquina. Solo hay un parámetro, nombre de host. Como no lo sabemos de antemano, utilizaremos la variable% COMPUTERNAME%.



Así que hemos agregado todos los artefactos necesarios, pasaremos a por qué vinimos aquí. Obtenemos la plantilla ARM generada en la pestaña Avanzado de la misma ventana de creación de fórmulas.



Copie el contenido de la página en el archivo VMtemplate.json y póngalo en la raíz del proyecto. Ya no necesitamos la nube, estamos regresando a la tubería.

5. Configuración de tubería

Comencemos con lo más importante e interesante, crear una máquina virtual, por eso hicimos todas estas integraciones y plantillas. En la suscripción de Azure RM, seleccionamos nuestra conexión de servicio, que configuramos en el párrafo 2. A continuación, aparecerá el entorno de laboratorio disponible. Luego seleccionamos json que generamos y definimos algunas variables obligatorias. El nombre de usuario y la contraseña del automóvil se pueden configurar directamente o con variables, pero no estoy seguro de que funcione, sea lo que sea que escriba allí, no podría ingresar al automóvil con estos créditos, lo principal es configurar el nombre del automóvil para que siempre sea posible Único Para esto, uso la variable de entorno de compilación.



A continuación, establecemos otro punto importante. Después de que el auto despegue, también necesitamos conocer sus parámetros de alguna manera, y es mejor no para nosotros sino para la línea de pago. Para hacer esto, creamos un script, por ejemplo GetLabVMParams.ps1 y lo ponemos allí, en el proyecto. Tomé el texto del script en el sitio web de Microsoft, pero lo corregí ligeramente para mi entorno, porque tomó máquinas PublicIP y FQDN. No tengo ninguno, pero hay PrivateIP que no es tan fácil de obtener, así que agregué una pieza.

Param( [string] $labVmId) $labVmComputeId = (Get-AzureRmResource -Id $labVmId).Properties.ComputeId # Get lab VM resource group name $labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName # Get the lab VM Name $labVmName = (Get-AzureRmResource -Id $labVmId).Name # Get lab VM public IP address # $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress # Get lab VM FQDN # $labVMFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).DnsSettings.Fqdn # Get lab VM private IP address $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 # Set a variable labVmRgName to store the lab VM resource group name Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName" # Set a variable labVMIpAddress to store the lab VM Ip address Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress" # Set a variable labVMFqdn to store the lab VM FQDN name Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn" Write-Output $labVMIpAddress Set-Item wsman:\localhost\client\trustedhosts * -Force 

De todo lo que lee el script, solo necesitamos la variable labVMIpAddress. Bueno, esto es para mí, tal vez necesites algo más, para esto no eliminé nada y solo comenté el exceso.

También explicaré la última línea del script, permite que nuestro equipo de compilación acceda a cualquier host a través de WinRM.

El siguiente paso, ejecutamos nuestro maravilloso script. Necesitará la misma conexión a la nube, la variable de entrada con la ID de la máquina, que para ese momento ya se conocerá del paso anterior. Como? Aquí es necesario mencionar algo tan maravilloso como Variables de salida. Cada paso puede tener una lista de variables que se pasan a los siguientes pasos de canalización. En consecuencia, para nuestro súper script, dicha variable será labVMIpAddress, no olvide indicar esto.



Además, hago cosas bastante simples que, además, pueden variar de un caso a otro. Ejecuto un script remoto con la creación de bolas, en el que luego cargaré mis scripts.

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

Por el nombre de las coles, está claro que luego copiamos algún script de muestra a la máquina y lo ejecutamos en un paso más. Como la dirección de la máquina remota, nuestra variable $ (labVMIpAddress) es útil para nosotros. A continuación, usamos la tarea "recoger el artefacto de las bolas" y copiamos los resultados del script a nuestro entorno de compilación, luego guardamos estos archivos en el artefacto de compilación con la misma tarea estándar. Después de que ya no necesitamos el automóvil, lo matamos con el último paso. La principal dificultad, como se puede ver en el volumen del artículo, es integrarse con la nube y establecer contacto con la máquina virtual que creó, entonces ya puede divertirse tanto como sea necesario.

Este es mi primer artículo, así que no juzgues estrictamente, los comentarios son bienvenidos.