Red de nodos

El primer parámetro al ejecutar nbuild, hace referencia a la configuración de la red de máquinas (-n network.json). Diferenciamos tres categorías:

• Master: Es el nodo donde corre el programa nbuild. Coordina al resto de nodos y ejecuta los flujos de trabajo. No necesita una máquina con grandes capacidades, ya que solo realizará tareas de coordinación. No usa almacenamiento en el disco local y tampoco es necesario incluirlo en network.json.
• Drive: Es el nodo de almacenamiento. Contendrá la colección de archivos fuente, binarios, informes y registros de ejecución. Todo ello se organizará en carpetas representando los estados (o versiones) del repositorio. Se recomienda que este nodo disponga de un dispositivo SSD de gran capacidad.
• Host (o runner): Nodo de compilación. Tendrá pre-instalados los compiladores y CMake. El nodo master activará estas máquinas en función de los trabajos que deba realizar, indicados en workflow.json. No es necesario que estos nodos tengan gran capacidad de almacenamiento, ya que no guardan histórico ni "basura" entre diferentes compilaciones. Tan solo manejan directorios temporales con resultados parciales.

El nodo master controlará la red a través del protocolo SSH (Figura 1). Por lo tanto, es necesario que cada host tenga activo un servidor ssh, con la clave pública de master (id_master_rsa.pub) para poder recibir los comandos de control. De igual forma, el nodo drive necesitará las claves de cada runner (id_runner_rsa.pub) para permitir operaciones de lectura/escritura de archivos.

1. Virtualización

nbuild permite controlar diferentes tipos de máquinas, tanto físicas como virtuales, para llevar a cabo las tareas de compilación y pruebas (Figura 2). Podemos dividirlas en las siguientes categorías:

• metal: Son máquinas físicas dentro de la misma red que nbuild. Podemos utilizarlas directamente como nodos de compilación o para alojar máquinas virtuales. La principal desventaja es la gran cantidad de hardware que necesitaremos si queremos probar nuestro código en multitud de plataformas. También las deberemos encender/apagar manualmente, ya que nbuild no puede hacerlo directamente.
• vbox: Las máquinas virtuales VirtualBox son ideales para crear nodos de compilación Windows y Linux. Podemos tener gran cantidad de plataformas distintas dentro de la misma máquina física. nbuild puede encender/apagar este tipo de máquinas de forma automática cuando se necesiten, con el fin de no exceder las capacidades de las máquinas físicas.
• utm: UTM es una plataforma de virtualización ideal para los sistemas macOS más recientes con procesador ARM. Necesita un mac-ARM para funcionar y ejecuta macOS Monterey y posteriores. Al igual que VirtualBox, nbuild puede encender/apagar estas máquinas bajo demanda.
• vmware: Otra gran solución de virtualización es VMware Fusion. En nbuild se utiliza para correr macOS Intel algo desfasados (desde Sierra hasta Bigsur), ya que es complicado utilizar VirtualBox con estas plataformas. También se encienden/apagan bajo demanda.
• macOS: Estos nodos representan diferentes volúmenes de arranque asociados a una misma máquina física. No son máquinas virtuales. nbuild permite re-arrancar la máquina desde un volumen a otro mediante macos bless. Es la solución ideal para sistemas MacOSX muy antiguos (desde Snow Leopard hasta El Capitan) y requieren de un iMac obsoleto (2011), ya que los más modernos no los soportan. A partir de MacOSX El Capitan, Apple introdujo el SIP (System Integrity Protection) lo que hace muy complicado (o imposible) utilizar macos bless en sistemas Sierra y posteriores. La principal ventaja es que nos ahorramos el software de virtualización (difícil de conseguir), sin olvidar que los nodos correrán en modo nativo, con todos los recursos disponibles.

2. network.json

network.json incluye la configuración de la máquina drive, así como todos y cada uno de los host de compilación (Listado 1). Como ya indicamos, el nodo master no hay que incluirlo, ya que es donde corre el propio proceso nbuild.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

{
"drive" : {
    "name" : "RPi 4 Raspbian 10 Buster",
    "path" : "/media/pi/builds",
    "login" : { "ip" : "192.168.1.5", "user" : "user", "pass" : "pass", "platform" : 3 }
},

"hosts" : [
{
    "name" : "Ubuntu 24.04 VBox",
    "workpath" : "/home/fran",
    "login" : { "ip" : "192.168.1.32", "user" : "user", "pass" : "pass", "platform" : 3 },
    "type" : "vbox",
    "vbox_uuid" : "288d134e-23e3-4546-acc2-ee04056f4c7b",
    "vbox_host" : "i7-13700-WIN11",
    "generators" : ["Unix Makefiles", "Ninja"],
    "tags" : ["ubuntu24", "x64"]
},
...
] }

• name: Nombre de la máquina. Debe ser único.
• ip: Dirección IP.
• user: Usuario con el que se debe conectar a la máquina remota.
• pass: Contraseña.
• platform: Sistema operativo de la máquina: 1 Windows, 2 macOS, 3 Linux.
• path: Solo en drive. Directorio base para el almacenamiento de artefactos.
• workpath: Directorio temporal para tareas de compilación y pruebas.
• type:
• metal para máquinas físicas.
• vbox para máquinas VirtualBox.
• utm para máquinas UTM.
• vmware para máquinas VMware.
• macos para volúmenes de arranque macOS.
• vbox_uuid: Código de la máquina virtual (solo para vbox).
• vbox_host: Nombre de la máquina que aloja a la virtual (solo para vbox). Debe ser de tipo metal.
• utm_uuid: Código de la máquina virtual (solo para utm).
• utm_host: Nombre de la máquina que aloja a la virtual (solo para utm). Debe ser de tipo metal.
• vmware_path: Camino completo al archivo *.vmx que contiene la descripción de la máquina virtual (solo para VMware).
• vmware_host: Nombre de la máquina que aloja a la virtual (solo para vmware). Debe ser de tipo metal.
• macos_host: Nombre de la máquina macOS (solo para macos).
• macos_volume: Nombre del volumen de arranque conectado a la máquina macos_host (solo para macos).
• generators: Lista de generadores CMake soportados en el nodo. "Unix Makefiles", "Ninja", "Xcode", "Visual Studio 17 2022", etc.
• tags: Lista de etiquetas con las características del nodo. Se utilizarán para saber si esta máquina es apta o no a la hora de ejecutar un proceso.
• x86, x64, arm, arm64: Arquitecturas soportadas.
• ubuntu24, ubuntu22, ubuntu20, ubuntu18, ubuntu16, ubuntu14, ubuntu12: Versión de Linux.
• sequoia, sonoma, ventura, monterey, bigsur, catalina, mojave, high_sierra, sierra, el_capitan, yosemite, mavericks, mountain_lion, lion, snow_leopard: Versión de macOS/MacOSX.
• msvc2022, msvc2019, msvc2017, msvc2015, msvc2013, msvc2012, msvc2010: Versiones de Microsoft Visual C++ soportada, necesaria para el uso del generador "Ninja" en Windows.

3. Una red real

En (Figura 3) tenemos todos los nodos, tanto físicos como virtuales utilizados diariamente para generar el proyecto NAppGUI-SDK.