SDK Multiplataforma en C logo

SDK Multiplataforma en C

Red de compiladores

❮ Anterior
Siguiente ❯

Al ejecutar nbuild:

 
nbuild -n network.json -w workflow.json -s secrets.json

El primer parámetro network.json indica la configuración de la red de nodos encargada de generar y probar el proyecto. En esta red destacamos tres tipos de nodos (Figura 1):

  • 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 empaquetados, los binarios, los informes y los 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: Nodo de compilación (o runner). 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.
  • Gráfico que contiene diferentes nodos en una red de ordenadores orientados a tareas de compilación CI/CD.
    Figura 1: Configuración de una red de nodos nbuild.

1. Contenido de 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.

Listado 1: Ejemplo de configuración de red.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
{
"drive" : {
    "name" : "RPi 4 Raspbian 10 Buster",
    "path" : "/media/pi/builds",
    "login" : {
    "ip" : "192.168.1.5",
    "user" : $SECRET{drive_user},
    "pass" : $SECRET{drive_pass},
    "platform" : 3 }
},

"hosts" : [
{
    "name" : "Ubuntu 24.04 VBox",
    "workpath" : "/home/fran",
    "login" : {
        "ip" : "192.168.1.32",
        "user" : $SECRET{host_user},
        "pass" : $SECRET{host_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.
  • login::ip: Dirección IP.
  • login::user: Usuario con el que se debe conectar a la máquina remota.
  • login::pass: Contraseña.
  • login::platform: Sistema operativo de la máquina: 1 Windows, 2 macOS, 3 Linux.
  • path: Solo en drive. Directorio base para el almacenamiento de artefactos.

Los siguiente parámetros solo existen para máquinas host:

  • workpath: Directorio temporal para tareas de compilación y pruebas.
  • type:
    • metal para máquinas físicas.
    • vbox para máquinas VirtualBox.
    • macos para máquinas macOS. Estas máquinas soportan múltiples discos de arranque con diferentes sistemas operativos y configuraciones.
  • 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.
  • 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, highsierra, sierra, elcapitan, yosemite, mavericks, mountainlion, lion, snowleopard: Versión de macOS/MacOSX.
Por el momento, no se soportan máquinas macOS virtualizadas.

2. Protocolo SSH

nbuild utiliza el protocolo SSH (Secure Shell) para coordinar y comunicar las diferentes máquinas de la red. El nodo master lanzará comandos ssh a los hosts de compilación, y estos se comunicarán con drive para mandar los binarios. Antes de empezar a trabajar con nbuild deberemos configurar la red, que no es más que instalar las claves públicas RSA en los hosts y drive:

  • Cada host necesita conocer la identidad de master (su id_rsa.pub), para dejarle ejecutar comandos remotos.
  • Drive necesita conocer la identidad de master y de cada host para autorizarle a que almacene archivos.

2.1. Generar e instalar claves RSA

Para evitar que ssh esté pidiendo constantemente contraseñas (hecho que se lleva muy mal con la automatización), vamos a instalar el certificado de master en los hosts (Figura 2).

Gráfico que ilustra la comunicación de dos computadores mediante ssh.
Figura 2: Ejecución de un comando ssh, conociendo la clave pública del emisor.
  • Lo primero será crear el certificado. Desde master, abre un terminal y teclea ssh-keygen. Esto generará dos certificados rsa en .ssh uno privado, que se quedará en master y otro público que irá al host.
  • Generando el certificado rsa en master.
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    
    fran~>ssh-keygen
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/fran/.ssh/id_rsa):
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /home/fran/.ssh/id_rsa.
    Your public key has been saved in /home/fran/.ssh/id_rsa.pub.
    The key fingerprint is:
    SHA256:Up6KjbnEV4Hgfo75YM393QdQsK3Z0aTNBz0DoirrW+c fran@192.168.1.24
    The key's randomart image is:
    +---[RSA 2048]----+
    |    .      ..oo..|
    |   . . .  . .o.X.|
    |    . . o.  ..+ B|
    |   .   o.o  .+ ..|
    |    ..o.S   o..  |
    |   . %o=      .  |
    |    @.B...     . |
    |   o.=. o. . .  .|
    |    .oo  E. . .. |
    +----[SHA256]-----+
    
  • Copia el archivo id_rsa.pub en el directorio /USER/.ssh de cada host.
  • Paso del certificado rsa del master al host
    1
    2
    
    cd .ssh
    scp id_rsa.pub fran@192.168.1.27:/home/fran/.ssh
    
  • Abre un terminal en el host remoto y teclea:
  • Instalando el certificado rsa
    1
    2
    3
    4
    5
    
    cd .ssh
    type id_rsa.pub >> authorized_keys   (Host Windows)
    ...
    cd .ssh
    cat id_rsa.pub >> authorized_keys    (Host macOS/Linux)
    
  • Si todo ha ido bien, ya podemos ejecutar un comando ssh desde master a host sin que nos pida contraseña. Hacemos la prueba desde master:
  • Probando ssh sin contraseña desde master.
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    
    fran~>ssh fran@192.168.1.27 ls
    Desktop
    Documents
    Downloads
    Library
    Movies
    Music
    Pictures
    Public
    ...
    

2.2. Activar SSH

Tanto los nodos host como drive deben tener instalado y activado un servidor SSH, de lo contrario no podrán aceptar comandos remotos.

SSH en Windows 11/10

Windows 11 incluye soporte para SSH, pero no está activo por defecto. Debes activarlo en Settings->Apps->Manage Optional Features->Add a Feature->OpenSSH Client/Server. Para asegurar que servicio está funcionando ejecuta services.msc y arranca OpenSSH SSH Server si no está corriendo ya.

SSH en macOS

SSH también está incluido en los sistemas operativos de Apple. Para activarlo:

  • Abre System Preferences desde el menú Apple y haz clic en el panel Sharing.
  • Activa la opción Remote Login.
  • Esto arrancará instantáneamente varios servicios, incluidos SFTP y SSH.

Por razones de seguridad, SSH no accede a todas las variables de entorno del shell bash en macOS. Esto puede provocar que un comando remoto falle, pero que tecleado desde un terminal en la propia máquina sí que funcione. Por ejemplo, esto ocurre al intentar ejecutar cmake o svn de forma remota. Para subsanarlo:

  • Añadimos las rutas necesarias a la variable PATH en /.ssh/environment.
  • Modificación de PATH en /.ssh/environment
    1
    
    PATH=$PATH:/bin:/usr/bin:/usr/local:/usr/local/bin:/Applications/CMake.app/Contents/bin
    
  • Editamos el archivo /private/etc/ssh/sshd_config o /etc/ssh/sshd_config, habilitando la variable PermitUserEnvironment PATH,LANG.
  • Paramos y re-lanzamos el servicio mediante el check Remote Login de Sharing.

SSH en Linux

Por defecto, SSH no está incluido en Ubuntu. Para esta distribución y otras basadas en Debian, el servicio se instala y activa con este comando.

1
sudo apt-get install openssh-server -y
❮ Anterior
Siguiente ❯