Integración continua con contenedores Docker, GitLab Runner y CI/CD Automation for Simulink Check

Introducción

La importancia de la confiabilidad e integridad del software continúa aumentando a medida que los sistemas se vuelven más complejos e interconectados. A pesar de la adhesión a prácticas recomendadas de ingeniería establecidas, el desarrollo de sistemas de alta integridad sigue siendo una tarea técnicamente exigente y financieramente intensiva. Dado el esfuerzo sustancial que implica el trabajo de revisión, análisis, pruebas y regresión, los ingenieros siempre buscan una forma de reducir gastos y al mismo tiempo mejorar la calidad general del software. Una de las últimas tendencias ha sido el impulso hacia soluciones de integración continua y despliegue continuo (CI/CD).

Las prácticas de CI/CD han transformado el desarrollo de software, permitiendo la entrega rápida y consistente de software de alta calidad. Pero el rápido avance de esta tecnología, junto con la cantidad de herramientas disponibles, puede hacer que crear una solución CI/CD robusta sea extremadamente difícil. Este artículo presenta un enfoque integral para implementar cadenas de tareas de CI/CD usando GitLab^® Runner, Docker^® y CI/CD Automation for Simulink Check™.

Importancia de CI/CD para el desarrollo y la certificación de software crítico en materia de seguridad

CI/CD son prácticas esenciales en el desarrollo de software moderno, especialmente para sistemas críticos en materia de seguridad como los que se utilizan en las industrias de atención médica, automoción y aeroespacial. La implementación de una solución CI/CD eficiente puede ayudar a mejorar la calidad y la confiabilidad, proporcionar una detección y solución más rápida de problemas, y garantizar el cumplimiento continuo de los estándares regulatorios. Dado que un solo cambio en los requisitos puede provocar una cascada de trabajo de regresión, contar con un sólido proceso de CI/CD es esencial para gestionar de manera rentable cualquier programa de desarrollo de software crítico en materia de seguridad.

Este artículo presenta los pasos para configurar herramientas fuera del entorno de modelado nativo para integrarlas con el conjunto de herramientas de MATLAB^® y Simulink^®.

• Simulink Check Process Advisor
• GitLab y GitLab Runner
  • Configuración de cadenas de tareas de CI/CD de GitLab
• Docker
  • Crear imagen de Docker
  • Argumentos de compilación
  • Compilar imagen y lanzar contenedor
  • Ejecutar GitLab Runner para esperar tareas
  • Pruebas y solución de problemas de la imagen de Docker

Simulink Check Process Advisor

La app Process Advisor, disponible como parte de CI/CD Automation for Simulink Check, es una herramienta poderosa para desarrollar una cadena de tareas de diseño basada en modelos dentro del entorno de MATLAB que se puede emplear en un entorno externo a través del archivo de plantilla .yml proporcionado. Para desarrolladores de modelos que deseen configurar una secuencia de procesos dentro del entorno de MATLAB, consulte la siguiente documentación:

1. Configuración de un modelo de proceso: Personalizar el modelo de proceso
2. Automatización de la verificación y validación de modelos: Automatizar y ejecutar tareas con Process Advisor
3. Prácticas recomendadas para Process Advisor: Prácticas recomendadas para crear modelos de procesos

GitLab y GitLab Runner

Si ya está listo para trasladar el modelo de proceso a una cadena de tareas CI/CD en GitLab, puede usar un único enforque para garantizar que las actualizaciones de modelo de proceso de Simulink se reflejen automáticamente en la cadena de tareas de GitLab: En lugar de recrear elvmodelo de proceso en un archivo .yml estático, utilizamos un archivo .yml que genera otro archivo .yml que contiene las tareas actuales en el modelo de proceso. Consulte el archivo de configuración de cadena de tareas de ejemplo (.gitlab-ci.yml) en el Apéndice A Tenga en cuenta que hay dos etapas:

stages: 
 - SimulinkPipelineGeneration 
 - SimulinkPipelineExecution

La primera etapa genera la cadena de tareas para la segunda etapa.

En este momento, es importante considerar cómo licenciar las herramientas de modelado y verificación utilizadas en la cadena. Un enfoque es utilizar tokens por lotes. Para utilizar tokens por lotes, debes solicitar uno a la fase piloto de licencias por lotes e incluirlo en la sección de variables de su archivo .yml.

variables: 
 MLM_LICENSE_TOKEN: "<MATLAB_BATCH_TOKEN>"

No todos los productos admiten tokens por lotes. En ese caso, deberá utilizar un archivo de licencia común (.lic). Para más información sobre tokens por lotes consulte: Tokens de licencia por lotes de MATLAB. Se recomienda no codificar tokens e información de credenciales en .yml o Dockerfile. Para un enfoque más seguro, considere crear una imagen de Docker usando variables de entorno.

Configuración de cadenas de tareas de CI/CD de GitLab

Configurar un proyecto GitLab para administrar trabajos es sencillo. Primero debe asegurarse de que GitLab sepa dónde encontrar el archivo .yml. En Settings > CI/CD > General cadena de tareass > CI/CD configuration file, proporcione la ruta al archivo .yml del proyecto, denominado “.gitlab-ic.yml” (Figura 1).

A continuación, deberá crear un nuevo ejecutor en GitLab. Esto proporcionará gitlab-runner-token que luego se usa para registrar el contenedor Docker en la instancia de ejecución de GitLab Runner (Figura 2).

En Settings > CI/CD > Runners > New project runner, proporcione una etiqueta y haga clic Create Runner (Figura 3).

Una vez creado el ejecutor, copie y guarde el token de autenticación del ejecutor (Figura 4).

Docker

Crear imagen de Docker

Podría decirse que esta es la parte más difícil del proceso, ya que debe asegurarse de que la imagen de Docker no solo tenga todas las dependencias de herramientas instaladas, sino que también tenga licencia para usar esas herramientas. Cabe señalar que la imagen de Docker puede basarse en cualquiera de las numerosas distribuciones de sistema operativo. Este ejemplo utiliza Ubuntu 22.04.

Comience por instalar todas las herramientas necesarias para ejecutar el modelo de proceso de Simulink y los ejecutores de GitLab. En Dockerfile, extraiga una imagen base de MATLAB:

FROM mathworks/matlab-deps:${MATLAB_DOCKER_RELEASE}

Posteriormente, procederá a instalar algunas de las dependencias básicas necesarias. Tenga en cuenta que las variables de compilación se analizarán más adelante. Vea el Dockerfile de ejemplo en el Apéndice B para el desglose completo de la instalación. El Dockerfile comienza con la instalación de dependencias para MPM, que luego se utilizarán para instalar productos de MATLAB y Simulink necesarios (excepto Simulink Code Inspector™). A continuación, instale las dependencias para matlab-proxy. Una vez instalados, utilice MPM para instalar las herramientas necesarias y configurar el método de licencia. Tenga en cuenta que también necesitará instalar gitlab-runner en la imagen de Docker y regíistrarla usando el gitlab-runner-token guardado anteriormente. El siguiente fragmento muestra cómo instalar y registrar usando las opciones de configuración deseadas:

RUN curl -L 
 "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash && \ 
 sudo apt-get install --no-install-recommends --yes \ 
 gitlab-runner && \ 
 sudo apt-get clean && sudo apt-get autoremove && \ 
 gitlab-runner start && \ 
 sudo gitlab-runner register --non-interactive \ 
 --url "<gitlab-url>" \ 
 --token "${GITLAB_TOKEN}" \ 
 --docker-image ${IMAGE_NAME} \ 
 --executor "shell"

Como se muestra en el Dockerfile, MPM puede instalar todas las herramientas de MATLAB y Simulink necesarias excepto Simulink Code Inspector. Para Simulink Code Inspector, necesitará descargar un archivo .iso desde el sitio web de MathWorks e instalarlo con ese archivo. Consulte mpm install para obtener más información.

Ahora que los productos están instalados, necesita configurar el método de licencia. Actualmente hay tres métodos disponibles para conceder licencias:

• Usar un token por lotes: Instale matlab-batch para habilitar el uso de tokens de licencia por lotes de MATLAB. Tenga en cuenta que Polyspace Code Prover Server™ y Polyspace Bug Finder Server™ no admiten licencias de tokens por lotes y el uso de Polyspace Code Prover™ y Polyspace Bug Finder™ para escritorio en entornos CI/CD infringe el acuerdo de licencia de software. Para instalar matlab-batch, agregue lo siguiente a su Dockerfile:

  • RUN wget -q https://ssd.mathworks.com/supportfiles/ci/matlab-batch/v1/glnxa64/matlab-batch \ 
        && sudo mv matlab-batch /usr/local/bin \ 
        && sudo chmod +x /usr/local/bin/matlab-batch
    

• Usar un servidor de licencias: Especifique el host y el puerto de la máquina que sirve las licencias de red si desea vincular la información de la licencia como una variable de entorno. Esta es la opción preferida para conceder licencias. Puede utilizar lo siguiente:

  • --build-arg LICENSE_SERVER=27000@MyServerName
    

  Alternativamente, puede especificar el servidor de licencias directamente en Dockerfile usando:

  • ENV MLM_LICENSE_FILE=27000@flexlm-server-name
    

• Utilizar un archivo de licencia (.lic): No se aconseja colocar un archivo de licencia directamente en un contenedor. No obstante, como alternativa, puede montar una unidad en el contenedor que contenga los archivos de licencia necesarios. Cuando utilice una unidad montada para el archivo de licencia, incluya una de las siguientes líneas en el Dockerfile de ejemplo:

  • COPY ${PATH_TO_LICENSE} /opt/matlab/licenses/
    

  • ADD ${PATH_TO_LICENSE} /opt/matlab/licenses/
    

Por último: en caso de dependencias instaladas, algunos informes requieren una pantalla para imagenes de los modelos. Xvfb proporciona una pantalla virtual para las tareas padv.builtin.task.GenerateSDDReport, padv.builtin.task.GenerateSimulinkWebView, y padv.builtin.task.GenerateModelComparison. Se deben instalar como parte de las dependencias de MPM. Asegúrese de que MPM esté instalado por el usuario que ejecutará la cadena de tareas.

Argumentos de compilación

En este ejemplo, Dockerfile está configurado para aceptar varios argumentos de compilación. Los argumentos de compilación pueden ser valiosos para mantener un Dockerfile que se puede usar para compilar múltiples imágenes o para permitir que los usuarios pasen información de compilación que puede cambiar con el tiempo o que no se desea codificar en el mismo Dockerfile.

Este Dockerfile contiene los siguientes argumentos de compilación (--build-arg):

# docker build      --build-arg MATLAB_DOCKER_RELEASE=<matlab-docker-release> 
#      --build-arg MATLAB_VERSION=<matlab-release> 
# --build-arg GITLAB_TOKEN=<gitlab-token> 
# --build-arg MATLAB_BATCH_TOKEN=<matlab-token> 
# --build-arg IMAGE_NAME=<image-image> 
# --build-arg PATH_TO_LICENSE=<path-to-license>

Al comienzo del Dockerfile, puede especificar el valor predeterminado para cada argumento en caso de que no se proporcione un valor al comando de compilación:

ARG MATLAB_DOCKER_RELEASE=r2023b-ubuntu22.04 
ARG MATLAB_VERSION=r2023b 
ARG MATLAB_BATCH_TOKEN="<USER>|TOKEN_ML|<TOKEN>" 
ARG GITLAB_TOKEN=<TOKEN> 
ARG IMAGE_NAME=matlab_image 
ARG PATH_TO_LICENSE=<PATH_TO_LICENSE>

Despues de la instrucción FROM en el Dockerfile, debe declarar las variables que se utilizarán:

FROM mathworks/matlab-deps:${MATLAB_DOCKER_RELEASE}
 
ARG MATLAB_VERSION
ARG MATLAB_BATCH_TOKEN
ARG GITLAB_TOKEN
ARG IMAGE_NAME
ARG PATH_TO_LICENSE

Tenga en cuenta en el fragmento mencionado que el valor de MATLAB_DOCKER_RELEASE se referencia con la sintaxis ${<var>}.

Compilar imagen y lanzar contenedor

Ahora que Dockerfile está listo, puede crear el primer contenedor desde la terminal Docker:

• Desde la terminal Docker, escriba cd en la ubicación del Dockerfile y verifique:

> cd <path-to-dockerfile> 
> ls

• Crear la imagen de Docker:

> docker build -t <image-name> -f <dockerfile-name>

Si el archivo Docker usa argumentos de compilación, el comando de compilación tendrá este formato:

> docker build --build-arg PATH_TO_LICENSE=<path-to-license> --build-arg GITLAB_TOKEN=<gitlab-runner-token> --build-arg MATLAB_BATCH_TOKEN="<USER>|TOKEN_ML|<TOKEN>" -t <image-name> -f <dockerfile-name>

Una vez creado el contenedor, puede ejecutarlo desde Docker usando la interfaz de usuario o desde la terminal:

> docker run --name <container_name> -v <optional_volume> <image_name>:latest

Dockerfile ya registró la imagen como gitlab-runner. Para confirmarlo, vea el archivo /etc/gitlab-runner/config.toml dentro de Docker y verifique que el ejecutor correcto esté registrado (Figura 5).

Si el registro del ejecutor es incorrecto o necesita cambiarse o reiniciarse, use lo siguiente en la terminal de la imagen de Docker para anular el registro del ejecutor y restaurar el ejecutor correcto:

> sudo gitlab-runner unregister --token "<gitlab_token>" 
> sudo gitlab-runner register --non-interactive --url "<gitlab-url>" --token "<gitlab-runner-token>" --executor "shell"

Ejecutar GitLab Runner para esperar tareas

Ahora que el contenedor está en ejecución y registrado como el ejecutor de GitLab, puede iniciar gitlab-runner y comenzar a esperar tareas (Figura 6). Desde la terminal del contenedor, inicie el ejecutor usando:

> sudo gitlab-runner run

Hay muchas formas de iniciar una cadena de tareas, como compilaciones programadas, manuales o bajo demanda y compilaciones basadas en nuevas confirmaciones en el repositorio de GitLab (Figura 7).

• Compilaciones programadas: En GitLab, utilice Build > Pipeline schedule para programar cuándo se deben ejecutar las cadenas de tareas.
• Compilaciones de confirmación: De forma predeterminada, GitLab ejecuta la cadena de tareas cada vez que se envíe contenido al repositorio. Para controlar cómo se activan las compilaciones, debe modificar el archivo .yml o agregar etiquetas específicas a los mensajes de confirmación. Consulte Controlar cómo se ejecutan los trabajos para más información.
• Construcciones manuales: En GitLab, utilice Settings > CI/CD > Run pipeline para activar compilaciones manuales. Settings > CI/CD > Pipeline trigger tokens contiene información sobre cómo utilizar curl para activar compilaciones desde una terminal.

Una vez que ls cadena de tareas haya terminado de ejecutarse, se pueden ver y descargar los resultados del último trabajo en la cadena de tareas—Collect_Artifacts (Figura 8).

Prueba y solución de problemas de la imagen de Docker

Al configurar la imagen de Docker, es importante poder probar cosas a lo largo del camino. A continuación se muestran algunos pasos útiles que puede realizar en la terminal del contenedor Docker para asegurarse de que todo funciona como se espera:

1. Verifique la instalación de MATLAB desde la terminal del contenedor:

$ matlab-batch "disp('Hello, World.')"

2. Para generar ciertos informes (SDD), MATLAB necesita una pantalla. Para esto, puedes utilizar Xvfb. Para probar Xvfb:

$ sudo xvfb-run -e /dev/stdout -a matlab-batch "disp('Hello, World.')"

3. Ejecute manualmente la cadena de tareas de MATLAB :
   1. Clona el repositorio (es posible que se soliciten credenciales; la autenticación de dos factores requiere tokens de acceso, que se pueden encontrar en GitLab desde la barra lateral izquierda seleccionando su avatar): Seleccione Edit profile > Access Tokens > Add new token)

      $ sudo git clone <gitlab-repo-url> <local-repo>
      $ sudo git clone https://<user>:<access_token>@<gitlab-repo-url> <local-repo>
      

   2. Cambie el directorio a un proyecto de MATLAB:

      $ cd <local-repo>/<project-path>
      

   3. Ejecute la primera etapa de la cadena de tareas:

      $ sudo -E matlab-batch -logfile "MATLAB_LOG_FILE" -nodesktop "cp = openProject(pwd); padv.pipeline.generatePipeline( padv.pipeline.GitLabOptions(PipelineArchitecture = padv.pipeline.Architecture.SerialStagesGroupPerTask, Tags = 'docker-matlab', GeneratedYMLFileName = 'simulink_pipeline.yml', GeneratedPipelineDirectory = fullfile('derived','pipeline'), MatlabLaunchCmd = 'xvfb -a matlab-batch', AddBatchStartupOption = false, EnableArtifactCollection = 'always'));"
      

   4. Verifique la generación del archivo simulink_pipeline.yml:

      $ cd derived 
      $ ls
      

Resumen

La integración de CI/CD es fundamental para mantener altos estándares de calidad, confiabilidad y cumplimiento. Las prácticas de CI/CD agilizan el proceso de desarrollo, lo que permite una entrega rápida y consistente de actualizaciones y, al mismo tiempo, garantiza que todos los cambios cumplan con estrictos requisitos de certificación. Este enfoque no solo mejora la productividad, sino que también reduce significativamente el riesgo de errores e incumplimientos, que son críticos en entornos certificados.

Al aplicar las herramientas y prácticas analizadas en este artículo, las empresas podrán configurar un entorno sólido utilizando Docker y GitLab Runner para crear una cadena de tareas de CI/CD eficiente y económica. Este proceso facilita un ciclo de desarrollo optimizado, confiable y compatible y, en última instancia, ayuda a entregar sistemas certificables de alta calidad con mayor confianza y eficiencia.