Mise en conteneur des environnements de construction et d'exécution pour les tests en boucle fermée sur le matériel

J'ai reçu beaucoup de questions dernièrement sur la conteneurisation des environnements pour les tests automatisés lors de l'utilisation de systèmes d'Intégration Continue. Si vous n'avez pas compris la majorité de cette phrase, ne vous inquiétez pas car nous allons plonger en détail dans les conteneurs, Docker, et comment les utiliser dans votre environnement embarqué et les tests en boucle fermée.

Qu'est-ce que les Conteneurs ?

Il existe de nombreux excellents articles sur les conteneurs, y compris celui-ci de Docker (l'un des moteurs d'exécution de conteneurs les plus populaires). Les conteneurs dans les environnements de construction (c.-à-d. systèmes embarqués) et les environnements de test (c.-à-d. tests en boucle fermée) nous donnent la possibilité d'abstraire toute la configuration compliquée chaque fois que nous voulons démarrer une nouvelle machine. Cela ne concerne pas seulement les nouvelles machines de test mais aussi l'expansion de notre opération dans le cloud également pour la construction de firmware embarqué.

Peu importe la taille de l'opération que vous gérez ces jours-ci, de nombreuses entreprises utilisent le cloud pour éviter de conserver des serveurs physiques. Dans les principes DevOps, nous voulons toujours nous assurer que tout logiciel que nous écrivons peut être construit et exécuté n'importe où, à tout moment, en tout lieu. Lancer constamment de nouvelles machines dans le cloud et installer des logiciels de compilation, des bibliothèques et d'autres paquets logiciels ne passe pas à l'échelle facilement. C'est précisément pour cette raison que la conteneurisation est devenue si populaire. Nous pouvons prendre notre environnement de construction (ou d'exécution), le conditionner dans une machine virtuelle très légère, et le livrer à n'importe quelle machine pour exécution, que ce soit dans le cloud ou sur notre propre ordinateur personnel.

Créer et Utiliser des Conteneurs

Explorons comment créer et utiliser ces conteneurs dans vos projets. Lorsque nous commençons à créer une image de conteneur, nous devons partir d'une “image de base” existante. Dans la plupart des cas, une variante d'un système d'exploitation Linux, tel que Debian, Ubuntu ou Alpine, suffira. Une fois que vous créez votre Dockerfile, vous vous référez à l'image ainsi :

FROM ubuntu:latest

Cela indique que le système d'exploitation de base exécutera la dernière image Docker d'Ubuntu. Après cela, nous devrons installer les bibliothèques nécessaires pour notre environnement de construction ou de test. Dans un exemple de dépôt, j'ai installé l'IDE Arduino en utilisant le gestionnaire de paquets Debian (Apt) puis j'ai ajouté plus de couches en installant les pilotes de la carte Arduino Sam également. En exécutant ce conteneur en mode privilégié (ou en passant le point de montage du volume à l'appareil), je peux compiler et télécharger un sketch Arduino via la ligne de commande sur une machine toute neuve qui contient uniquement Docker (c.-à-d. pas d'IDE ou de pilotes).

Nous pouvons faire la même chose avec des machines qui sont connectées à nos dispositifs en test. Dans ce conteneur Docker que j'ai préparé, j'installe toutes les dépendances et logiciels nécessaires pour faire fonctionner un dispositif Analog Discovery 2. En théorie, je peux lancer le conteneur Docker sur une machine toute neuve (qui contient uniquement Docker) et commencer à communiquer avec l'Analog Discovery 2 sans aucun problème. Avec l'Analog Discovery 2, je peux écrire des tests pour valider mes ADCs, DACs, ou envoyer des commandes I2C/SPI à différents puces sur mon circuit imprimé (en plus d'une myriade d'autres capacités).

Mise à l'échelle avec l'Intégration Continue

Maintenant, discutons de comment les conteneurs peuvent améliorer les systèmes d'Intégration Continue pour augmenter l'efficacité et la scalabilité. La vraie magie se produit lorsque nous commençons à utiliser des conteneurs en conjonction avec les systèmes d'Intégration Continue (CI). Nous pouvons avoir des dizaines, sinon des centaines de machines de test physiques ou accéder à des milliers de machines dans le cloud pour nos serveurs de test et de build. Afin de mettre à l'échelle de manière pratique, comme mentionné ci-dessus, nous ne pouvons pas configurer chaque machine individuellement à mesure qu'elles sont mises en ligne. Livrer un conteneur avec chaque exécution de CI nous donne non seulement une manière systématique et répétable d'exécuter des builds et des tests mais nous libère également de devoir reconfigurer une machine chaque fois que nous la lançons (ce qui, dans le cloud, arrive presque à chaque exécution de CI). En tirant parti des conteneurs pour les builds embarqués et les tests matériels physiques, nous nous offrons ainsi qu'à nos entreprises un certain niveau de scalabilité dont les générations précédentes ne pouvaient que rêver.

Conclusion

Dans cet article, nous avons souligné le rôle crucial des conteneurs dans le développement de systèmes embarqués, en particulier pour des environnements de build et de test cohérents à travers différents types d'infrastructures. Leur intégration avec les systèmes d'intégration continue ne simplifie pas seulement le développement mais augmente également la scalabilité et la fiabilité du produit. À mesure que la technologie des conteneurs progresse, son adoption deviendra de plus en plus importante pour les développeurs. Plongez plus profondément et expérimentez avec différents setups en visitant quelques dépôts d'exemple à https://gitlab.com/docker-embedded.