Intégration continue avec les conteneurs Docker, GitLab Runner et CI/CD Automation for Simulink Check

Introduction

L'importance de la fiabilité et de l'intégrité des logiciels ne cesse de croître à mesure que les systèmes deviennent plus complexes et interconnectés. Malgré le respect des meilleures pratiques d'ingénierie établies, le développement de systèmes à haute intégrité demeure une entreprise techniquement exigeante et financièrement coûteuse. Compte tenu des efforts considérables que représentent les revues, les analyses, les tests et les travaux de régression, les ingénieurs cherchent constamment à réduire le gaspillage tout en améliorant la qualité globale des logiciels. L'une des tendances les plus récentes est la promotion des solutions d'intégration continue et de déploiement continu (CI/CD).

Les pratiques CI/CD ont transformé le développement logiciel, permettant une livraison rapide et cohérente de logiciels de haute qualité. Mais l'évolution rapide de cette technologie, ainsi que le nombre d'outils disponibles, peuvent rendre la création d'une solution CI/CD robuste extrêmement difficile. Cet article présente une approche globale de la mise en œuvre de pipelines CI/CD à l'aide de GitLab^® Runner, Docker^® et CI/CD Automation for Simulink Check™.

Importance de l'intégration continue et de la livraison continue (CI/CD) pour le développement et la certification des logiciels critiques pour la sécurité

L'intégration continue et la livraison continue (CI/CD) sont des pratiques essentielles dans le développement logiciel moderne, en particulier pour les systèmes critiques pour la sécurité, tels que ceux utilisés dans les secteurs de la santé, de l'automobile et de l'aérospatiale. Le déploiement d'une solution CI/CD efficace peut contribuer à améliorer la qualité et la fiabilité, à accélérer la détection et la résolution des problèmes et à garantir une conformité continue aux normes réglementaires. Étant donné qu'une simple modification des exigences peut entraîner une cascade de corrections en temps réel, la mise en place d'un processus CI/CD robuste est essentielle pour gérer de manière rentable tout programme de développement logiciel critique pour la sécurité.

Cet article présente les étapes décrites ci-dessous, pour configurer les outils en dehors de l'environnement de modélisation natif, afin de les intégrer à la suite d’outils de MATLAB^® et Simulink^® :

• Simulink Check Process Advisor
• GitLab et GitLab Runners
  • Configuration des pipelines CI/CD GitLab
• Docker
  • Création de l'image Docker
  • Construire des arguments
  • Créer une image et lancer le conteneur
  • Lancer GitLab Runner pour écouter les tâches
  • Tests et dépannage de l'image Docker

Simulink Check Process Advisor

L'application Process Advisor, disponible dans le cadre de CI/CD Automation for Simulink Check, est un outil puissant pour développer un pipeline de Model-Based Design dans l'environnement MATLAB, qui peut ensuite être utilisé dans un environnement externe via le fichier modèle .yml fourni. Pour les développeurs de modèles souhaitant configurer un pipeline de processus dans l'environnement MATLAB, veuillez consulter la documentation suivante :

1. Mise en place d'un modèle de processus : Personnaliser votre modèle de processus
2. Automatisation de la vérification et de la validation des modèles : Automatiser et exécuter des tâches avec Process Advisor
3. Meilleures pratiques d'utilisation de Process Advisor : Meilleures pratiques pour la création de modèles de processus

GitLab et GitLab Runners

À ce stade, vous êtes prêt à intégrer votre modèle de processus dans un pipeline CI/CD dans GitLab. Pour garantir que les mises à jour de votre modèle de processus Simulink soient automatiquement reflétées dans le pipeline GitLab, une approche unique est utilisée. Au lieu de recréer votre modèle de processus dans un fichier .yml statique, nous utilisons plutôt un fichier .yml qui génère un autre fichier .yml contenant les tâches actuelles du modèle de processus. Consultez l'exemple de fichier de configuration de pipeline (.gitlab-ci.yml) dans l’annexe A. Notez qu'il y a deux étapes :

stages: 
 - SimulinkPipelineGeneration 
 - SimulinkPipelineExecution

La première étape génère le pipeline pour la deuxième étape.

Il est important, à ce stade, de réfléchir à la manière d'acquérir les licences nécessaires pour les outils de modélisation et de vérification utilisés dans le processus. Une approche consiste à utiliser des jetons par lots. Pour utiliser les jetons de lot, vous devez en demander un au Projet pilote de licences par lots et l’inclure dans la section des variables de votre fichier .yml.

variables: 
 MLM_LICENSE_TOKEN: "<MATLAB_BATCH_TOKEN>"

Tous les produits ne prennent pas en charge les jetons de traitement par lots. Dans de tels cas, vous devrez peut-être utiliser un fichier de licence traditionnel (.lic). Vous trouverez plus d'informations sur les jetons de lot ici : Jetons de licence par lots MATLAB. Notez qu'il est préférable d'éviter d'intégrer en dur les jetons (et autres informations d'identification) dans votre fichier .yml ou Dockerfile. Pour une approche plus sécurisée, envisagez de construire votre image Docker en utilisant des variables d'environnement.

Configuration des pipelines CI/CD GitLab

Configurer votre projet GitLab pour gérer les tâches est simple. Vous devez d'abord vous assurer que GitLab sait où trouver votre fichier .yml. Sous Settings > CI/CD > General pipelines > CI/CD configuration file, indiquez le chemin d'accès au fichier .yml de votre projet, idéalement nommé « .gitlab-ic.yml » (Figure 1).

Ensuite, vous devrez créer un nouveau runner dans GitLab. Cela vous donnera un gitlab-runner token que vous utiliserez plus tard pour enregistrer votre conteneur Docker auprès de votre instance GitLab Runner (Figure 2).

Sous Settings > CI/CD > Runners > New project runner, fournissez une étiquette et cliquez Create Runner (Figure 3).

Une fois le runner créé, copiez et enregistrez le jeton d'authentification du runner (Figure 4).

Docker

Création de l'image Docker

C’est sans doute la partie la plus difficile du processus, car vous devez vous assurer que votre image Docker possède non seulement toutes les dépendances d’outillage installées, mais également les licences nécessaires pour utiliser ces outils. Il est également important de noter que votre image Docker peut correspondre à n'importe quelle distribution de système d'exploitation. Cet exemple utilisera Ubuntu 22.04.

Commencez par installer tous les outils nécessaires à l'exécution de votre modèle de processus Simulink et de vos runners GitLab. Dans votre Dockerfile, récupérez une image MATLAB de base :

FROM mathworks/matlab-deps:${MATLAB_DOCKER_RELEASE}

Vous passerez ensuite directement à l'installation de certaines des dépendances de base requises. Notez que les variables de compilation seront abordées ultérieurement. Voir l'exemple de Dockerfile dans l’annexe B pour le descriptif complet de l'installation. Le Dockerfile commence par installer les dépendances pour MPM, qui seront ensuite utilisées pour installer vos produits MATLAB et Simulink requis (à l'exception de Simulink Code Inspector™). Ensuite, installez les dépendances pour matlab-proxy. Une fois ces éléments installés, utilisez MPM pour installer les outils nécessaires et configurer votre méthode de licence. Notez que vous devrez également installer gitlab-runner sur votre image Docker et l’enregistrer en utilisant le gitlab-runner token que vous avez enregistré lors d’une sauvegarde précédente. L'extrait ci-dessous montre comment installer et enregistrer le logiciel avec les options de configuration souhaitées :

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"

Comme le montre le Dockerfile, MPM peut installer tous les outils MATLAB et Simulink requis, à l'exception de Simulink Code Inspector. Pour Simulink Code Inspector, vous devrez télécharger un fichier .iso depuis le site web de MathWorks et l’installer à partir de ce fichier. Pour plus d'informations, veuillez consulter la documentation relative à l’installation de mpm

Maintenant que vos produits sont installés, vous devez configurer votre méthode de licence. Il existe actuellement trois méthodes d'obtention de licence :

• Utiliser un jeton de lot : Installez matlab-batch pour permettre l'utilisation des jetons de licence par lots MATLAB. Veuillez noter que Polyspace Code Prover Server™ et Polyspace Bug Finder Server™ ne supportent pas la licence de jeton par lots, et que l'utilisation de Polyspace Code Prover™ et Polyspace Bug Finder™ pour les postes de travail dans les environnements CI/CD enfreint le contrat de licence du logiciel. Pour installer matlab-batch, ajoutez ce qui suit à votre 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
    

• Utiliser un serveur de licences : Spécifiez l'hôte et le port de la machine qui gère les licences réseau si vous souhaitez inclure les informations de licence en tant que variable d'environnement. Il s'agit de l'option privilégiée pour l'octroi de licences. Il est possible de compiler en utilisant les éléments suivants :

  • --build-arg LICENSE_SERVER=27000@MyServerName
    

  Vous pouvez également spécifier directement le serveur de licences dans votre Dockerfile en utilisant :

  • ENV MLM_LICENSE_FILE=27000@flexlm-server-name
    

• Utiliser un fichier de licence (.lic) : Il est fortement déconseillé de placer un fichier de licence directement dans un conteneur. Vous pouvez également monter sur votre conteneur un lecteur contenant les fichiers de licence requis. Lorsque vous utilisez un lecteur monté pour votre fichier de licence, incluez l'une des lignes suivantes dans l'exemple de Dockerfile :

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

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

Un dernier point concernant les dépendances installées : Certains rapports nécessitent un écran pour capturer des captures d'écran des modèles. Xvfb fournit un affichage virtuel pour des tâches telles que padv.builtin.task.GenerateSDDReport, padv.builtin.task.GenerateSimulinkWebView, et padv.builtin.task.GenerateModelComparison. Cela devrait être installé dans le cadre des dépendances MPM. Assurez-vous que MPM est installé par l'utilisateur qui exécutera le pipeline.

Construire des arguments

Dans cet exemple, le Dockerfile est configuré pour accepter plusieurs arguments de construction. Les arguments de construction peuvent s'avérer précieux pour maintenir un seul Dockerfile pouvant servir à construire plusieurs images ou pour permettre aux utilisateurs de transmettre des informations de construction susceptibles d'évoluer au fil du temps ou qu'il serait préférable de ne pas intégrer directement dans le Dockerfile.

Ce Dockerfile contient les arguments de construction suivants (--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>

Au début de votre Dockerfile, vous pouvez spécifier la valeur par défaut de chaque argument au cas où aucune valeur ne serait fournie à la commande de construction :

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>

Après l’instruction FROM dans votre Dockerfile, vous devez déclarer les variables qui seront utilisées :

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

Notez dans l'extrait ci-dessus que la valeur MATLAB_DOCKER_RELEASE est accessible en utilisant la syntaxe ${<var>}.

Constuire l’image et lancer le conteneur

Maintenant que votre Dockerfile est prêt, vous pouvez créer votre premier conteneur depuis le terminal Docker :

• Depuis le terminal Docker, saisissez la commande cd dans le répertoire contenant le Dockerfile et vérifiez :

> cd <path-to-dockerfile> 
> ls

• Construire l'image Docker :

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

Si votre fichier Docker utilise des arguments de construction, votre commande de construction pourrait ressembler à ceci :

> 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>

Une fois le conteneur créé, vous pouvez l'exécuter depuis Docker via l'interface utilisateur ou depuis le terminal :

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

Votre Dockerfile a déjà enregistré votre image comme votre gitlab-runner. Pour le confirmer, consultez le fichier /etc/gitlab-runner/config.toml dans Docker et vérifiez que le bon runner est enregistré (Figure 5).

Si l'enregistrement du runner est incorrect, doit être modifié ou redémarré, utilisez la commande suivante dans le terminal de l'image Docker pour désenregistrer le runner, puis restaurez le runner correct :

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

Lancer GitLab Runner pour écouter les tâches

Maintenant que le conteneur est en cours d'exécution et enregistré comme votre runner GitLab, vous pouvez démarrer le gitlab-runner et commencez à écouter les tâches (Figure 6). Depuis le terminal du conteneur, démarrez le runner en utilisant :

> sudo gitlab-runner run

Il existe de nombreuses façons de lancer votre pipeline, notamment les builds planifiés, les builds manuels ou à la demande, et les builds basés sur de nouveaux commits dans votre dépôt GitLab (Figure 7).

• Builds programmés : Dans GitLab, utilisez Build > Pipeline schedule pour planifier le moment où les pipelines doivent s'exécuter.
• Lors des builds de commit : par défaut, GitLab exécutera le pipeline à chaque fois que le dépôt sera mis à jour. Pour contrôler le déclenchement des builds, vous devrez modifier le fichier .yml ou ajouter des balises spécifiques aux messages de commit. Consulter la section Contrôlez l’exécution des tâches pour plus d'informations.
• Builds manuels : Dans GitLab, utilisez Settings > CI/CD > Run pipeline pour déclencher des builds manuels. Settings > CI/CD > Pipeline trigger tokens contient des informations sur la façon d'utiliser curl pour déclencher des compilations depuis un terminal.

Une fois le pipeline exécuté, les résultats peuvent être consultés et téléchargés à partir de la dernière tâche de votre pipeline, à savoir Collect_Artifacts (Figure 8).

Test et dépannage de l'image Docker

Lors de la mise en place et de la configuration de votre image Docker, il est important de pouvoir effectuer des tests au fur et à mesure. Voici quelques étapes utiles que vous pouvez effectuer dans le terminal du conteneur Docker pour vous assurer que tout fonctionne comme prévu :

1. Vérifiez l'installation de MATLAB depuis le terminal du conteneur :

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

2. Pour générer certains rapports (SDD), MATLAB a besoin d'un écran. Pour cela, vous pouvez utiliser Xvfb. Pour tester Xvfb :

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

3. Exécutez manuellement le pipeline MATLAB :
   1. Clonez le dépôt (il se peut que l'on vous demande des informations d'identification ; l'authentification à deux facteurs nécessite des jetons d'accès, que vous trouverez dans GitLab en allant dans la barre latérale gauche et en sélectionnant votre avatar) : sélectionnez 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. Transformez le répertoire en un projet MATLAB :

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

   3. Exécutez la première étape du 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. Vérifiez la génération du fichier simulink_pipeline.yml :

      $ cd derived 
      $ ls
      

Conclusion

L'intégration CI/CD est primordiale pour maintenir des normes élevées de qualité, de fiabilité et de conformité. Les pratiques CI/CD rationalisent le processus de développement, permettant une livraison rapide et cohérente des mises à jour tout en garantissant que toutes les modifications répondent à des exigences de certification strictes. Cette approche permet non seulement d'améliorer la productivité, mais aussi de réduire considérablement les risques d'erreurs et de non-conformité, qui sont essentiels dans les environnements certifiés.

En appliquant les outils et les pratiques présentés dans cet article, les organisations devraient être en mesure de mettre en place un environnement robuste utilisant Docker et GitLab Runner pour créer un pipeline CI/CD efficace et économique. Ce processus devrait faciliter un cycle de développement simplifié, fiable et conforme, et contribuer en fin de compte à fournir des systèmes certifiables de haute qualité avec plus de confiance et d'efficacité.