Containerisierung von Build- und Laufzeitumgebungen für Hardware-in-the-Loop-Tests

Ich bekomme in letzter Zeit viele Fragen zum Thema Containerisierung von Umgebungen für automatisierte Tests, wenn Continuous Integration Systeme verwendet werden. Wenn Sie den Großteil dieses Satzes nicht verstanden haben, machen Sie sich keine Sorgen, denn wir werden uns ausführlich mit Containern, Docker und deren Einsatz in Ihrer eingebetteten Umgebung und Hardware-in-the-Loop-Tests beschäftigen.

Was sind Container?

Es gibt viele ausgezeichnete Artikel über Container, einschließlich diesem von Docker (einer der beliebtesten Container-Laufzeitumgebungen). Container in Build-Umgebungen (z.B. eingebettete Systeme) und Testumgebungen (z.B. Hardware-in-the-Loop-Tests) geben uns die Möglichkeit, die gesamte unordentliche Einrichtung jedes Mal zu abstrahieren, wenn wir eine neue Maschine hochfahren wollen. Dies bezieht sich nicht nur auf neue Testmaschinen, sondern auch auf die Skalierung unserer Operation in der Cloud für den Bau von eingebetteter Firmware.

Unabhängig von der Größe der Operation nutzen heutzutage viele Unternehmen die Cloud, um das Vorhalten von Bare-Metal-Servern zu vermeiden. In den DevOps-Prinzipien wollen wir immer sicherstellen, dass jede Software, die wir schreiben, jederzeit und überall gebaut und ausgeführt werden kann. Ständig neue Maschinen in der Cloud hochzufahren und Kompilierungssoftware, Bibliotheken und andere Softwarepakete zu installieren, skaliert nicht gut. Genau deshalb ist die Containerisierung so beliebt geworden. Wir können unsere Build- (oder Laufzeitumgebung) in eine sehr leichte virtuelle Maschine verpacken und sie auf jeder Maschine ausführen lassen, sei es in der Cloud oder auf unserem eigenen persönlichen Computer.

Erstellen und Verwenden von Containern

Lassen Sie uns erkunden, wie man diese Container in Ihren Projekten tatsächlich erstellt und verwendet. Wenn wir mit der Erstellung eines Container-Images beginnen, müssen wir mit einem vorhandenen „Basis-Image“ starten. In den meisten Fällen wird eine Variante eines Linux-Betriebssystems, wie Debian, Ubuntu oder Alpine, ausreichen. Sobald Sie Ihre Dockerfile erstellt haben, beziehen Sie sich so auf das Image:

FROM ubuntu:latest

Dies zeigt an, dass das Basis-Betriebssystem das neueste Ubuntu Docker-Image ausführen wird. Danach müssen wir alle notwendigen Bibliotheken für unsere Build- oder Testumgebung installieren. In einem Beispielrepository habe ich die Arduino IDE mit dem Debian-Paketmanager (Apt) installiert und dann weitere Schichten hinzugefügt, indem ich die Arduino Sam Board-Treiber installiert habe. Wenn ich diesen Container im privilegierten Modus ausführe (oder den Volume-Mount-Punkt an das Gerät weitergebe), kann ich einen Arduino-Sketch über die Befehlszeile auf einer brandneuen Maschine kompilieren und hochladen, die nur Docker enthält (d.h. keine IDE oder Treiber).

Wir können dasselbe mit Maschinen machen, die mit unseren zu testenden Geräten verbunden sind. In diesem Docker-Container, den ich zusammengestellt habe, installiere ich alle Abhängigkeiten und die benötigte Software, um ein Analog Discovery 2 Gerät zu betreiben. Theoretisch kann ich den Docker-Container auf einer brandneuen Maschine starten (die nur Docker enthält) und ohne Umstände mit dem Analog Discovery 2 kommunizieren. Mit dem Analog Discovery 2 kann ich Tests schreiben, um meine ADCs, DACs zu validieren oder I2C/SPI-Befehle an verschiedene Chips auf meinem Board zu senden (zusammen mit einer Vielzahl anderer Fähigkeiten).

Skalierung mit Continuous Integration

Jetzt diskutieren wir, wie Container Continuous Integration-Systeme verbessern können, um Effizienz und Skalierbarkeit zu steigern. Die eigentliche Magie beginnt, wenn wir anfangen, Container in Verbindung mit Continuous Integration (CI)-Systemen zu nutzen. Wir könnten Dutzende, wenn nicht Hunderte von physischen Testmaschinen haben oder Zugang zu Tausenden von Cloud-Maschinen für unsere Test- und Build-Server. Um praktisch zu skalieren, wie oben erwähnt, können wir nicht jede einzelne Maschine konfigurieren, wenn sie online geht. Die Bereitstellung eines Containers mit jedem CI-Lauf bietet uns nicht nur eine systematische, wiederholbare Art, Builds und Tests durchzuführen, sondern befreit uns auch davon, eine Maschine jedes Mal neu konfigurieren zu müssen (was in der Cloud bei fast jedem CI-Lauf passiert). Durch den Einsatz von Containern für eingebettete Builds und physische Hardwaretests bieten wir uns und unseren Unternehmen ein gewisses Maß an Skalierbarkeit, von dem frühere Generationen nur träumen konnten.

Fazit

In diesem Artikel haben wir die entscheidende Rolle von Containern in der Entwicklung eingebetteter Systeme hervorgehoben, insbesondere für konsistente Build- und Testumgebungen über verschiedene Arten von Infrastrukturen hinweg. Ihre Integration in Continuous Integration-Systeme vereinfacht nicht nur die Entwicklung, sondern steigert auch die Produkt-Skalierbarkeit und -Zuverlässigkeit. Mit dem Fortschritt der Container-Technologie wird ihre Adoption für Entwickler zunehmend wichtiger. Tauchen Sie tiefer ein und experimentieren Sie mit verschiedenen Setups, indem Sie einige Beispiel-Repositories unter https://gitlab.com/docker-embedded besuchen.