Contenedorización de Entornos de Compilación y Ejecución para Pruebas de Hardware en el Bucle

Últimamente he recibido muchas preguntas sobre la contenedorización de entornos para pruebas automatizadas cuando se utilizan sistemas de Integración Continua. Si no entendiste la mayoría de esa oración, no te preocupes porque vamos a profundizar en los contenedores, Docker y cómo aprovecharlos en tu entorno embebido y pruebas de hardware en el bucle.

¿Qué son los Contenedores?

Hay muchos excelentes artículos sobre contenedores, incluyendo este de Docker (uno de los motores de ejecución de contenedores más populares que existen). Los contenedores en entornos de construcción (es decir, sistemas embebidos) y entornos de prueba (es decir, pruebas de hardware en el bucle) nos dan la capacidad de abstraer toda la configuración complicada cada vez que queremos iniciar una nueva máquina. Esto no solo se relaciona con nuevas máquinas de prueba sino también con escalar nuestra operación en la nube también para la construcción de firmware embebido.

No importa el tamaño de la operación que estés ejecutando estos días, muchas empresas aprovechan la nube para evitar tener que mantener servidores físicos. En los principios de DevOps siempre queremos asegurarnos de que cualquier software que escribamos pueda construirse y ejecutarse en cualquier lugar, en cualquier momento, en cualquier lugar. Estar constantemente iniciando nuevas máquinas en la nube e instalando software de compilación, bibliotecas y otros paquetes de software no escala bien. Esto es, precisamente, por qué la contenedorización se ha vuelto tan popular. Podemos tomar nuestro entorno de construcción (o entorno de ejecución), empaquetarlo en una máquina virtual muy ligera y entregarlo a cualquier máquina para ejecutarlo, ya sea en la nube o en nuestro propio ordenador personal.

Creando y Usando Contenedores

Exploraremos cómo crear y usar estos contenedores en tus proyectos. Cuando comenzamos a crear una imagen de contenedor, tenemos que empezar con una “imagen base” existente. En la mayoría de los casos, alguna variante de un sistema operativo Linux, como Debian, Ubuntu o Alpine, será suficiente. Una vez que creas tu Dockerfile, te refieres a la imagen así:

FROM ubuntu:latest

Esto indica que el sistema operativo base estará ejecutando la última imagen Docker de Ubuntu. Después de eso, necesitaremos instalar las bibliotecas necesarias para nuestro entorno de construcción o de prueba. En un repositorio de ejemplo, he instalado el IDE de Arduino usando el gestor de paquetes de Debian (Apt) y luego agregué más capas instalando los controladores de la placa Arduino Sam también. Ejecutando este contenedor en modo privilegiado (o pasando el punto de montaje del volumen al dispositivo) puedo compilar y subir un sketch de Arduino a través de la línea de comandos en una máquina completamente nueva que solo contiene Docker (es decir, sin IDE ni controladores).

Podemos hacer lo mismo con máquinas que están conectadas a nuestros dispositivos bajo prueba. En este contenedor Docker que he preparado, instalo todas las dependencias y el software necesario para ejecutar un dispositivo Analog Discovery 2. En teoría, puedo iniciar el contenedor Docker en una máquina completamente nueva (que solo contiene Docker) y comenzar a comunicarme con el Analog Discovery 2 sin complicaciones. Con el Analog Discovery 2 puedo escribir pruebas para validar mis ADCs, DACs, o enviar comandos I2C/SPI a diferentes chips en mi placa (junto con una miríada de otras capacidades).

Escalando con Integración Continua

Ahora, hablemos de cómo los contenedores pueden mejorar los sistemas de Integración Continua para aumentar la eficiencia y la escalabilidad. La verdadera magia ocurre cuando comenzamos a usar contenedores en conjunto con sistemas de Integración Continua (CI). Podemos tener docenas, si no cientos de máquinas de prueba físicas o acceso a miles de máquinas en la nube para nuestros servidores de prueba y construcción. Para escalar de manera práctica, como se mencionó anteriormente, no podemos configurar cada máquina individual a medida que se conectan. Entregar un contenedor con cada ejecución de CI nos da no solo una forma sistemática y repetible de realizar compilaciones y pruebas, sino que también nos libera de tener que reconfigurar una máquina cada vez que la iniciamos (lo cual, en la nube, ocurre en casi cada ejecución de CI). Al aprovechar los contenedores para compilaciones embebidas y pruebas de hardware físico, nos proporcionamos a nosotros mismos y a nuestras empresas un cierto nivel de escala que las generaciones anteriores solo podían soñar.

Conclusión

En este artículo, hemos destacado el papel crucial de los contenedores en el desarrollo de sistemas embebidos, especialmente para entornos de construcción y pruebas consistentes a través de diferentes tipos de infraestructura. Su integración con sistemas de integración continua no solo agiliza el desarrollo, sino que también aumenta la escalabilidad y la fiabilidad del producto. A medida que la tecnología de contenedores avanza, su adopción se volverá cada vez más importante para los desarrolladores. Profundiza y experimenta con diferentes configuraciones visitando algunos repositorios de ejemplo en https://gitlab.com/docker-embedded.