Integrazione continua con Docker Containers, GitLab Runner e CI/CD Automation for Simulink Check

Introduzione

L'importanza dell'affidabilità e dell'integrità del software continua a crescere man mano che i sistemi diventano più complessi e interconnessi. Nonostante l’adesione alle consolidate best practice ingegneristiche, lo sviluppo di sistemi ad alta integrità rimane un’attività tecnicamente impegnativa e finanziariamente onerosa. Considerato il notevole impegno richiesto da attività di revisione, analisi, test e regressione, gli ingegneri sono costantemente alla ricerca di soluzioni per ridurre gli sprechi migliorando al contempo la qualità complessiva del software. Una delle ultime tendenze è stata la spinta verso soluzioni di integrazione continua e distribuzione continua (CI/CD).

Le pratiche CI/CD hanno trasformato lo sviluppo del software, consentendo la distribuzione rapida e coerente di software di alta qualità. Tuttavia, il rapido progresso di questa tecnologia, unito al numero di strumenti disponibili, può rendere estremamente difficile la creazione di una soluzione CI/CD solida. Questo articolo presenta un approccio completo all'implementazione di pipeline CI/CD utilizzando GitLab^® Runner, Docker^® e CI/CD Automation for Simulink Check™.

Importanza di CI/CD per lo sviluppo e la certificazione di software safety-critical

Le pratiche di CI/CD (integrazione continua e distribuzione continua) sono fondamentali nello sviluppo software moderno, soprattutto per i sistemi safety-critical come quelli utilizzati nei settori sanitario, automotive e aerospaziale. L’implementazione di una soluzione CI/CD efficiente può contribuire a migliorare la qualità e l’affidabilità del software, consentire un’individuazione e una risoluzione più rapide dei problemi e garantire il rispetto continuo degli standard normativi. Poiché anche una singola modifica ai requisiti può innescare una cascata di attività di regressione, disporre di un solido processo CI/CD è essenziale per gestire in modo economicamente sostenibile qualsiasi programma di sviluppo software safety-critical.

Questo articolo presenterà i seguenti passaggi per configurare strumenti esterni all’ambiente di modellazione nativo e integrarli con la suite di strumenti MATLAB^® e Simulink^®:

• Simulink Check Process Advisor
• GitLab e GitLab Runners
  • Configurazione delle pipeline CI/CD di GitLab
• Docker
  • Creazione dell'immagine Docker
  • Argomenti di build
  • Creazione di immagine e avvio del container
  • Esecuzione di GitLab Runner per gestire i lavori
  • Test e risoluzione dei problemi dell'immagine Docker

Simulink Check Process Advisor

L’app Process Advisor, disponibile come parte di CI/CD Automation for Simulink Check, è uno strumento potente per sviluppare una pipeline di Model-Based Design all’interno dell’ambiente MATLAB, che può poi essere utilizzata in un ambiente esterno tramite il file template .yml fornito. Per gli sviluppatori di modelli che desiderano configurare una pipeline di processo all’interno dell’ambiente MATLAB, consultare la seguente documentazione:

1. Impostazione di un modello di processo: Personalizza il tuo modello di processo
2. Automazione della verifica e della validazione del modello: Automatizza ed esegui attività con Process Advisor
3. Best practice per l'utilizzo di Process Advisor: Linee guida per creare modelli di processo

GitLab e GitLab Runners

A questo punto, si è pronti per inserire il proprio modello di processo in una pipeline CI/CD in GitLab. Per garantire che gli aggiornamenti al modello di processo Simulink vengano automaticamente riflessi nella pipeline GitLab, viene utilizzato un approccio unico: invece di ricreare il modello di processo in un file .yml statico, utilizziamo un file .yml che genera un altro file .yml contenente le attività correnti nel modello di processo. Consultare il file di configurazione della pipeline di esempio (.gitlab-ci.yml) in Appendice A. Da notare la presenza di due fasi:

fasi: 
 - SimulinkPipelineGeneration 
 - SimulinkPipelineExecution

La prima fase genera la pipeline per la seconda fase.

In questa fase è importante valutare come concedere in licenza gli strumenti di modellazione e verifica utilizzati nella pipeline. Un approccio consiste nell'utilizzare token batch. Per utilizzare i token batch, è necessario richiederne uno da Batch Licensing Pilot e includerlo nella sezione delle variabili del proprio file .yml.

variabili: 
 MLM_LICENSE_TOKEN: "<MATLAB_BATCH_TOKEN>"

Non tutti i prodotti supportano i token batch. In questi casi, potrebbe essere necessario utilizzare un file di licenza tradizionale (.lic). Puoi trovare maggiori informazioni sui token batch qui: Token di licenza batch MATLAB. È buona norma evitare di codificare i token (e altre informazioni sul tipo di credenziale) nel file .yml o nel Dockerfile. Per un approccio più sicuro, valuta la possibilità di creare la tua immagine Docker utilizzando variabili di ambiente.

Configurazione delle pipeline CI/CD di GitLab

Configurare il tuo progetto GitLab per gestire i lavori è semplice. Per prima cosa devi assicurarti che GitLab sappia dove trovare il tuo file .yml. In Settings > CI/CD > General pipelines > CI/CD configuration file, fornisci il percorso al file .yml del tuo progetto, idealmente denominato “.gitlab-ic.yml” (Figura 1).

Successivamente, dovrai creare un nuovo runner in GitLab. In questo modo otterrai un gitlab-runner-token che potrai utilizzare in seguito per registrare il tuo container Docker all’istanza GitLab Runner (Figura 2).

In Settings > CI/CD > Runners > New project runner, fornisci un tag e clicca Create Runner (Figura 3).

Una volta creato il runner, copia e salva il token di autenticazione del runner (Figura 4).

Docker

Creazione dell'immagine Docker

Questa è probabilmente la parte più difficile del processo, poiché è necessario assicurarsi che l’immagine Docker non solo contenga tutte le dipendenze degli strumenti installate, ma sia anche correttamente autorizzata all’uso di tali strumenti. È anche importante notare che l'immagine Docker può essere una qualsiasi delle distribuzioni del sistema operativo. In questo esempio verrà utilizzato Ubuntu 22.04.

Inizia installando tutti gli strumenti necessari per eseguire il modello di processo Simulink e i runner GitLab. Nel tuo Dockerfile, estrai un'immagine MATLAB di base:

DA mathworks/matlab-deps:${MATLAB_DOCKER_RELEASE}

Successivamente, si procederà direttamente all'installazione di alcune delle dipendenze di base richieste. Le variabili di build saranno discusse più avanti. Vedi l'esempio Dockerfile in Appendice B per la ripartizione completa dell'installazione. Il Dockerfile inizia con l'installazione delle dipendenze per MPM, che verranno poi utilizzate per installare i prodotti MATLAB e Simulink richiesti (ad eccezione di Simulink Code Inspector™). Quindi, installa le dipendenze per matlab-proxy. Una volta installati, utilizza MPM per installare gli strumenti necessari e configurare il metodo di licenza. Nota che dovrai anche installare gitlab-runner sulla tua immagine Docker e registrala utilizzando gitlab-runner-token che hai salvato prima. Il frammento seguente mostra come installare e registrare con le opzioni di configurazione desiderate:

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"

Come mostrato nel Dockerfile, MPM può installare tutti gli strumenti MATLAB e Simulink richiesti, ad eccezione di Simulink Code Inspector. Per Simulink Code Inspector, dovrai scaricare un file .iso da il sito web MathWorks e installarlo da quel file. Consulta la documentazione installazione mpm per ulteriori informazioni.

Ora che i tuoi prodotti sono installati, devi configurare il metodo di licenza. Attualmente sono disponibili tre metodi per la concessione delle licenze:

• Utilizzare un token batch: installare matlab-batch per abilitare l'uso dei token di licenza batch MATLAB. Si noti che Polyspace Code Prover Server™ e Polyspace Bug Finder Server™ non supportano la licenza tramite batch token e che l’uso di Polyspace Code Prover™ e Polyspace Bug Finder™ per desktop in ambienti CI/CD viola i termini del contratto di licenza del software. Per installare matlab-batch, aggiungi quanto segue al tuo 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
    

• Utilizzare un server di licenze: specificare l’host e la porta della macchina che fornisce le licenze di rete se desiderate impostare le informazioni sulla licenza come variabile d’ambiente. Questa è l'opzione preferita per la concessione della licenza. È possibile eseguire la compilazione utilizzando quanto segue:

  • --build-arg LICENSE_SERVER=27000@MyServerName
    

  In alternativa, è possibile specificare il server delle licenze direttamente nel tuo Dockerfile utilizzando:

  • ENV MLM_LICENSE_FILE=27000@flexlm-server-name
    

• Utilizzare un file di licenza (.lic): Si sconsiglia vivamente di inserire un file di licenza direttamente in un container. In alternativa, è possibile montare sul container un'unità contenente i file di licenza richiesti. Quando si utilizza un'unità montata per il file di licenza, includere una delle seguenti righe nel Dockerfile di esempio:

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

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

Un'ultima nota sulle dipendenze installate: alcuni report richiedono un display per acquisire screenshot dei modelli. Xvfb fornisce un display virtuale per attività come padv.builtin.task.GenerateSDDReport, padv.builtin.task.GenerateSimulinkWebView e padv.builtin.task.GenerateModelComparison. Dovrebbe essere installato come parte delle dipendenze MPM. Assicurarsi che MPM sia installato dall'utente che eseguirà la pipeline.

Argomenti di build

In questo esempio, il Dockerfile è configurato per accettare diversi argomenti di build. Gli argomenti di build possono essere utili per mantenere un unico Dockerfile in grado di generare più immagini o per consentire agli utenti di fornire informazioni di build che possono variare nel tempo o che non è consigliabile inserire direttamente nel Dockerfile.

Questo Dockerfile contiene i seguenti argomenti di build (--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>

All'inizio del Dockerfile, puoi specificare il valore predefinito per ciascun argomento nel caso in cui non venga fornito un valore al comando di build:

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>

Dopo l’istruzione FROM nel vostro Dockerfile, è necessario dichiarare le variabili che verranno utilizzate:

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

Notare nel frammento sopra che il valore MATLAB_DOCKER_RELEASE è accessibile utilizzando la sintassi ${<var>}.

Creazione di immagini e avvio del container

Ora che il tuo Dockerfile è pronto, puoi creare il tuo primo container dal terminale Docker:

• Dal terminale Docker, digitare cd nella posizione del Dockerfile e verificare:

> cd <path-to-dockerfile> 
>ls

• Creazione dell'immagine Docker:

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

Se il tuo file Docker utilizza argomenti di build, il tuo comando di build potrebbe essere più simile a:

> 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 volta creato il container, puoi eseguirlo da Docker tramite l'interfaccia utente o dal terminale:

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

Il tuo Dockerfile ha già registrato la tua immagine come gitlab-runner. Per confermarlo, visualizza il file /etc/gitlab-runner/config.toml all'interno di Docker e verifica che sia registrato il runner corretto (Figura 5).

Se la registrazione del runner non è corretta o deve essere modificata o riavviata, utilizza quanto segue nel terminale dell'immagine Docker per annullare la registrazione del runner e quindi ripristinare il runner corretto:

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

Esecuzione di GitLab Runner per gestire i lavori

Ora che il container è in esecuzione e registrato come runner GitLab, puoi avviare gitlab-runner e iniziare a gestire i lavori (Figura 6). Dal terminale del container, avvia il runner utilizzando:

>sudo gitlab-runner run

Esistono diversi modi per avviare la vostra pipeline, tra cui build pianificate, build manuali o su richiesta, e build attivate da nuovi commit nel vostro repository GitLab (Figura 7).

• Build pianificate: In GitLab, usa Build > Pipeline schedule per programmare quando eseguire le pipeline.
• Build attivate da commit: per impostazione predefinita, GitLab eseguirà la pipeline ogni volta che viene effettuato un push sul repository. Per controllare come vengono attivate le build, dovrai modificare il file .yml o aggiungere tag specifici ai messaggi di commit. Vedere Control how jobs run per maggiori informazioni.
• Build manuali: in GitLab, usa Settings > CI/CD > Run pipeline per attivare build manuali. Settings > CI/CD > Pipeline trigger tokens contiene informazioni su come utilizzare curl per avviare build da un terminale.

Una volta terminata l'esecuzione della pipeline, i risultati possono essere visualizzati e scaricati dall'ultimo lavoro nella pipeline:Collect_Artifacts (Figura 8).

Test e risoluzione dei problemi dell'immagine Docker

Quando si imposta e si configura l'immagine Docker, è importante poter eseguire test lungo il percorso. Ecco alcuni passaggi utili che puoi eseguire nel terminale del container Docker per assicurarti che tutto funzioni come previsto:

1. Verificare l'installazione MATLAB dal terminale del container:

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

2. Per generare determinati report (SDD), MATLAB necessita di un display. Per questo puoi usare Xvfb. Per testare Xvfb:

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

3. Esecuzione manuale della pipeline MATLAB:
   1. Clona il repository (potreste essere invitati a inserire le credenziali: l’autenticazione a due fattori richiede access token, che possono essere trovati in GitLab cliccando sull’avatar nella barra laterale sinistra e selezionando: Seleziona 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. Accesso alla directory in un progetto MATLAB:

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

   3. Esecuzione della prima fase della pipeline:

      $ 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. Verifica la generazione del file simulink_pipeline.yml:

      $ cd derived 
      $ ls
      

Conclusione

L'integrazione di CI/CD è fondamentale per mantenere elevati standard di qualità, affidabilità e conformità. Le pratiche CI/CD semplificano il processo di sviluppo, consentendo una distribuzione rapida e coerente degli aggiornamenti e garantendo al contempo che tutte le modifiche soddisfino rigorosi requisiti di certificazione. Questo approccio non solo aumenta la produttività, ma riduce anche significativamente il rischio di errori e non conformità, che sono critici negli ambienti certificati.

Applicando gli strumenti e le pratiche illustrate in questo articolo, le organizzazioni dovrebbero essere in grado di configurare un ambiente solido con Docker e GitLab Runner, creando una pipeline CI/CD efficiente e in grado di ridurre i costi. Questa pipeline dovrebbe facilitare un ciclo di sviluppo semplificato, affidabile e conforme e, in ultima analisi, contribuire a fornire sistemi certificabili di alta qualità con maggiore sicurezza ed efficienza.