Looking for an English version?

Configuración de Runners de VM Dinámicas

Esta sección está basada en este artículo del blog. Trata sobre cómo usar el Ejecutor Personalizado de GitLab para lanzar VMs de KVM bajo demanda y ejecutar trabajos en ellas. Debería funcionar con cualquier proveedor de VM. El código está en este repositorio. Verás que usa algunos scripts de shell para lanzar las VMs y luego se conecta a ellas por SSH para ejecutar los comandos. No hay ninguna razón por la que los scripts de shell no puedan modificarse para usar otro proveedor de VM o algún proveedor en la nube.

Aquí hay un diagrama de la arquitectura general que puede ser útil.

NOTA Este es un tema avanzado, por lo que asumo que tienes cierta idea de lo que estás haciendo. Hago algunas suposiciones y omito algunos detalles.

Desventajas

• La principal desventaja de este enfoque es que es un poco más complejo.
• Tal como están, los scripts solo funcionan con GitLab y KVM en Linux. Debería ser portable a otras plataformas. Para GitHub, lo investigué y hay un webhook que se activa cuando se pone en cola un nuevo trabajo. Eso podría usarse para ejecutar un script de shell que inicie una VM y la registre en GitHub como un runner efímero. Si logras que eso funcione, avísame.

Ventajas

Este enfoque ofrece varias ventajas.

• VM limpia cada vez: evita que queden residuos de un trabajo al siguiente. Garantiza que hayas incluido todas las dependencias.
• Escalabilidad y ejecución en paralelo: esto te permite ejecutar múltiples VMs diferentes (o iguales) en paralelo.
• Facilidad para configurar nuevas VMs base.
• Mejor utilización de recursos: si tienes varios proyectos, solo necesitas 1 runner escuchando.

Configuración del Host

Yo uso KVM en Linux. Busca en Google cómo configurarlo. Luego clono estos scripts y los coloco en algún lugar accesible por el usuario que ejecuta KVM. También necesitas un directorio lleno de VMs base y un directorio para los clones. Poner todos los clones en un solo directorio facilita el mantenimiento si alguno queda huérfano. Configurar los permisos correctamente puede ser un desafío. Te sugiero empezar con un proyecto con un "hello world" muy simple y lograr que funcione primero. También necesitarás configurar una clave SSH para conectarte a las VMs sin contraseña, ¡así que no protejas la clave con contraseña!

Configuración de las Imágenes de VM Base

Esto es para máquinas Windows. Generalmente instalo Git For Windows y NIPM. Luego configuro SSH y todo lo demás. Después clono esa VM e instalo LabVIEW y VIPM. Eso me da 2 VMs base: una solo con Git y NIPM para poder probar instalaciones, y otra con LabVIEW, VIPM, etc., para ejecutar mis compilaciones.

SSH en Windows

Necesitas configurar el servidor SSH en tu VM de Windows. Consulta este artículo del blog.

Paquetes Necesarios para el Arranque

Necesitarás como mínimo los paquetes G-CLI, VIPM API y VIPC Applier. Con eso puedes usar el VIPC Applier para instalar todo lo demás que necesites. Recuerda que esto ocurre en cada trabajo. Si empieza a tardar demasiado, puedes crear una imagen separada para un proyecto en particular con el VIPC preinstalado. En ese caso, generalmente mantengo el paso del VIPC de todos modos, por si acaso cambio algo como agregar o actualizar un paquete.

GitLab Runner

Técnicamente solo necesitas GitLab Runner en el host de KVM. Sin embargo, si quieres subir artefactos, necesitas gitlab-runner en la VM base y en el path. No lo registras, pero sí tiene que estar en el path.

Configuración del Archivo gitlab-ci.yml

Hay 2 cosas que necesitas agregar a tu archivo yml para ejecutar un trabajo de esta manera. Primero, necesitas una etiqueta para indicarle a GitLab a qué runner enviar el trabajo. Yo uso "kvm" para esto. También necesitas una variable $BASE_VM para indicarle al runner qué VM debe lanzar y en la que ejecutará el trabajo.

Trabajos en Paralelo

Puedes habilitar trabajos en paralelo editando la configuración del runner en el host de KVM. Solo cambia el ajuste de concurrencia.