ADMIN

2023

04

2023-03-30T12:00:00

Storage

PRAXIS

040

Linux

IoT

Mit Osbuild-Composer Linux im IoT ausrollen

Weit draußen

von Andreas Stolzenberger

Veröffentlicht in Ausgabe 04/2023 - PRAXIS

Rechner am Edge des Netzwerks steuern heute Maschinen und Sensoren. Statt proprietärer Betriebssysteme und Programme kommen dabei immer öfter Linux-Systeme mit Applikationen in Containern zum Einsatz. Angepasste Linux-OS-Images für Edge-Devices erstellt das Tool Osbuild-Composer in wenigen Schritten. Wir zeigen, wie die Abbilder sicher auf die Geräte gelangen und dort aktuell bleiben.

Zu den aktuellen Trends in der IT-Branche zählen neben den Dauerbrennern KI und Containerisierung vor allem Internet of Things (IoT) und Edge Computing. Die vier Themen sind dabei enger miteinander verbunden, als es vielen IT-Verantwortlichen bewusst ist.
Zusamenspiel IoT und Edge
Beim IoT geht es in erster Linie darum, dass Geräte mit anderen IT-Komponenten vernetzt arbeiten und dazu keine proprietären Kommunikationskanäle verwenden. Der Begriff "Internet" verwirrt dabei oft, denn nur sehr wenige IoT-Geräte sind tatsächlich direkt mit dem Internet verbunden. Das "I" steht viel mehr für die Internetprotokolle, die bei der Netzwerkkommunikation zum Einsatz kommen. Die "Dinge" haben also eigene IP-Adressen und setzen Standardprotokolle wie HTTPS für die Kommunikation mit anderen Maschinen und den Kontrollcomputern ein.
Früher standen in Fertigungsbetrieben voll- oder teilautomatische Maschinen ohne Netzwerkanbindung. Sollte ein Teil A gefertigt werden, musste der Facharbeiter das zugehörige CNC-Programm direkt an der Maschine über ein geeignetes Medium einspielen – von der Lochkarte über Bänder bis hin zu Floppy-Disks gab es je nach Hersteller verschiedene Wege dazu. Heute stecken in den Fertigungsmaschinen Computer, die intern mit der Maschinensteuerung über serielle Schnittstellen wie RS-422, RS-232, CAN- oder I2C-Bus kommunizieren. Nach Außen redet der Steuercomputer nun aber via Ethernet oder WiFi. Die CNC-Programme kann der Facharbeiter nun entweder über den Computer an der Maschine aus dem LAN laden (pull) oder umgekehrt von einem Verwaltungsrechner aus den CNC-Code in die Maschine schicken (push). Andererseits kann damit auch die Maschine ihren Produktionsfortschritt und -status über eine Rest-API im LAN verfügbar machen. Zu den Maschinendaten kann der Steuercomputer beispielsweise auch gleich Bilder einer Überwachungskamera beisteuern.
Zu den aktuellen Trends in der IT-Branche zählen neben den Dauerbrennern KI und Containerisierung vor allem Internet of Things (IoT) und Edge Computing. Die vier Themen sind dabei enger miteinander verbunden, als es vielen IT-Verantwortlichen bewusst ist.
Zusamenspiel IoT und Edge
Beim IoT geht es in erster Linie darum, dass Geräte mit anderen IT-Komponenten vernetzt arbeiten und dazu keine proprietären Kommunikationskanäle verwenden. Der Begriff "Internet" verwirrt dabei oft, denn nur sehr wenige IoT-Geräte sind tatsächlich direkt mit dem Internet verbunden. Das "I" steht viel mehr für die Internetprotokolle, die bei der Netzwerkkommunikation zum Einsatz kommen. Die "Dinge" haben also eigene IP-Adressen und setzen Standardprotokolle wie HTTPS für die Kommunikation mit anderen Maschinen und den Kontrollcomputern ein.
Früher standen in Fertigungsbetrieben voll- oder teilautomatische Maschinen ohne Netzwerkanbindung. Sollte ein Teil A gefertigt werden, musste der Facharbeiter das zugehörige CNC-Programm direkt an der Maschine über ein geeignetes Medium einspielen – von der Lochkarte über Bänder bis hin zu Floppy-Disks gab es je nach Hersteller verschiedene Wege dazu. Heute stecken in den Fertigungsmaschinen Computer, die intern mit der Maschinensteuerung über serielle Schnittstellen wie RS-422, RS-232, CAN- oder I2C-Bus kommunizieren. Nach Außen redet der Steuercomputer nun aber via Ethernet oder WiFi. Die CNC-Programme kann der Facharbeiter nun entweder über den Computer an der Maschine aus dem LAN laden (pull) oder umgekehrt von einem Verwaltungsrechner aus den CNC-Code in die Maschine schicken (push). Andererseits kann damit auch die Maschine ihren Produktionsfortschritt und -status über eine Rest-API im LAN verfügbar machen. Zu den Maschinendaten kann der Steuercomputer beispielsweise auch gleich Bilder einer Überwachungskamera beisteuern.
IoT steht hier für die Anbindung der Maschine an das Netzwerk des Betriebs. Der Steuercomputer in der Maschine selbst ist dabei das viel zitierte Edge-Device. Solche Lösungen lassen sich sehr häufig auch bei älteren Maschinen nachrüsten, sowohl im industriellen als auch privaten Bereich. Ein praktisches Beispiel für eine solche Architektur ist ein 3D-Drucker. Dabei packt der Anwender sein Modell als G-Code-Programm auf eine SD-Karte und startet den Druck direkt über die Druckersteuerung. Alternativ schließt der Nutzer einen Raspberry Pi via USB an den Drucker an. Dort läuft dann ein Tool wie das freie Octoprint, das so ziemlich jeden 3D-Drucker steuern kann. Der Anwender lädt dann nur noch das Modell via HTTP zum Edge-Device und überwacht den Druck aus der Ferne.
Was sich also gegenüber früheren Maschinensteuerungen maßgeblich geändert hat, ist, dass Linux-Rechner jetzt proprietäre Steuercomputer mit speziellen Betriebssystemen und Programmen ersetzen. Das bietet vor allem den Vorteil, dass die Software ganz oder teilweise isoliert von der darunter liegenden Hardware in einem Container läuft. Der Edge-Computer mit der IoT-Anbindung bleibt somit flexibel und lässt schnelle unkomplizierte Softwareupdates zu. Dank der generischen
Edge-Hardware kann ein und derselbe Rechnertyp mit dem gleichen Betriebssystem zum einen in einer Ladenkasse, zum anderen in einer CNC-Drehbank stecken. Den Unterschied macht lediglich die Anwendungssoftware im Container.
Besonderheiten eines Edge-Betriebssystems
Bevor Sie sich jedoch darüber Gedanken machen, mit welcher Container- und Managementtechnologie Sie die Applikationen auf Ihren Edge-Devices verwalten [1], müssen Sie sich zunächst für ein Betriebssystem entscheiden. Die Art und Weise, wie Sie Linux auf einem Edge-Device betreiben und installieren, unterschiedet sich von einer Desktop- oder Serverinstallation.
Jede Fertigungsmaschine verfügt über einen roten "Not-Aus"-Knopf. Im Falle einer Störung trennt dieser in Sekundenbruchteilen das System vom Strom – inklusive dem Steuercomputer. Ein sanfter OS-Shutdown findet also nicht statt, was zu Schäden im Dateisystem führen kann. Das OS sollte also auf solche Probleme gefasst sein und wichtige Dateisystembereiche als Read-Only mounten. Im Notfall muss das Edge-Device auch ein zweites oder Notfall-OS-Image starten können, falls das Haupt-OS zu stark beschädigt ist.
Ferner arbeiten viele Edge-Devices ohne Maus, Monitor und Tastatur. Die komplette Wartung von Applikationen und dem OS selbst muss per LAN/WLAN-Fernsteuerung möglich sein. Im Gegenzug bleibt das OS-Setup sehr spartanisch und bringt nur die nötigsten Funktionen mit, um die eigentlichen Apps in Container zu starten. Auf einen Paket-Manager wie yum, dnf oder apt verzichtet ein Edge-OS gänzlich. Mit einem /usr-Dateisystem im Read-Only-Mode lassen sich ohnehin keine Pakete nachinstallieren. Es gibt eine ganze Reihe von Tools, um das eigene "imutable"-Linux-Image zu bauen, wie etwa "Buildroot" oder "Ostreee". Wir beschreiben hier, wie Sie mit Fedora oder EL-Derivaten ein Ostree-Image für die Edge bauen.
Mit Ostree Images bauen
Das Konzept von Ostree lehnt sich am Versionskontrollsystem Git an. Hier "comittet" der Nutzer einen vorgegebenen Datenbestand als "Checkpoint" in einem Objekt-Dateisystem, kann aber über die Liste vergangener Commits auch auf frühere Versionen zugreifen. Ostree verwaltet nach diesem Konzept startbare OS-Abbilder nebst Dateisystem.
Um das OS auf einem Edge-Device upzudaten, schicken Sie diesem einfach die neue Version des Ostree-Images. Der Updateprozess überschreibt dabei jedoch nicht das bestehende Image, sondern comitted das Update als separaten Checkpoint. Das Device kann auch danach noch das ältere Image booten. Stellt sich in der Praxis beispielsweise heraus, dass das Gerät nach einer Betriebssystem-Aktualisierung nicht wie gewünscht funktioniert, sind Sie jederzeit zu einem Rollback auf eine frühere Ostree-Variante in der Lage.
Um ein Ostree-Image zu bauen und upzudaten, benötigen Sie das Tool "Osbuild-Composer" [2]. Für den Workshop nutzen wir eine CentOS-9-Streams-VM als Build-System. Theoretisch genügt dazu eigentlich auch ein CentOS-9-Streams-Container. Allerdings benötigt Composer den im Hintergrund laufenden Builder-Dienst. Ein regulärer Container verwendet normalerweise aber keinen systemd als init-Daemon, der Hintergrunddienste verwaltet. Daher müssten Sie eine Container-Vorlage mit systemd verwenden. Eine VM als Build-System ist daher der simplere Weg. In der CentOS-9-Streams-VM richten Sie zunächst die benötigten Dienste ein:
dnf install osbuild-composer composer-cli bash-completion -y
 
systemctl enable osbuild-composer.socket
 
systemctl restart osbuild-composer
Möchten Sie Ihre Images grafisch in einer Web-UI zusammenbauen, installieren Sie zusätzlich die Pakete "cockpit-composer" [3] und "cockpit" [4]. Für den Workshop bleiben wir jedoch auf der Kommadozeile, da diese für uns völlig ausreicht.
Eine Web-UI für Osbuild-Composer liefert Cockpit – hier der Image-Builder auf einem Raspberry Pi 4 mit RHEL 9.
Blueprints erzeugen
Für ein Ostree-Image erzeugen Sie zunächst einen sogenannten Blueprint mit einer Konfigurationsdatei im TOML-Format. Dort beschreiben Sie das Image, geben die zu installierenden Pakete und optional weitere Informationen wie Userdaten und Schlüssel an. Unsere Beispieldatei "bp1.toml" beginnt mit der Image-Deklaration:
name = "bp1"
description = "blueprint one"
version = "0.0.1"
modules = [ ]
groups = [ ]
Jedes Mal, wenn Sie Änderungen am Blueprint vornehmen, müssen Sie auch die Versionsnummer hochzählen. Auf den Header folgt die Liste der zu installierenden RPM-Pakete:
[[packages]]
name = "vim"
version = "*"
[[packages]]
name = "podman"
[[packages]]
name = "cockpit"
version = "*"
[[packages]]
name = "cockpit-podman"
version = "*"
[[packages]]
name = "tmux"
version = "*"
[[packages]]
name = "nginx"
version = "*"
Dabei sind Sie in der Lage, über die Angabe der "version" eine bestimmte Paketversion zu erzwingen. Der Platzhalter "*" steht im Beispiel stellvertretend für die neueste Version. Die Kernpakete oder Abhängigkeiten müssen Sie dabei nicht angeben, die ermittelt Composer automatisch. Das Tool greift nicht auf die RPM-Paketquellen des Systems zu ("/etc/yum.repositories.d"), sondern verwendet seine eigenen Paketquellen. Die sichert es im Verzeichnis "/usr/share/osbuild-composer/repositories". Die Repositories werden darin im JSON-Format beschrieben und nicht als ".repo". Das Os- tree-Projekt offeriert eine Liste vordefinierter Repository-Dateien auf [5]. Um eigene Repositories oder zusätzliche Quellen wie rpmfusion einzubinden, konvertieren Sie bestehende REPO-Dateien nach JSON.
Im weiteren Verlauf der TOML-Datei legen Sie über "customization"-Statements beispielsweise Benutzer und Gruppen an. In unserem Setup rollen wir das Image später über eine Kickstart-Datei aus und nutzen dessen Funktionen für diese Aufgabe. Das bietet mehr Flexibilität, falls Ihr Image beispielsweise auf verschiedenen Zielplattformen mit unterschiedlichen Nutzern und Zugängen landen soll. Nutzen Sie den Composer jedoch, um VM-Images für AWS, GCP, KVM oder vSphere zu erstellen, sollten Sie die Benutzerkonfiguration direkt im Blueprint vornehmen.
Mit der fertigen TOML-Datei erstellen Sie den Blueprint über composer-cli blueprints push bp1.toml. Anschließend erscheint die neue Definition in der Blueprint-Liste (composer-cli blueprints list) und die Details zur aktuellen Blaupause zeigt Composer mit dem Kommando composer-cli blueprints show bp1 auf. Im nächsten Schritt prüfen Sie, ob das Build-System die angegebenen Pakete nebst den Abhängigkeiten findet und installieren kann:
composer-cli blueprints depsolve bp1
Der Osbuild Composer beschränkt sich nicht auf Edge-Devices und Ostree-Installationen. Es kann aus dem Blueprint auch VM-Images für diverse Plattformen erstellen. Das Kommando composer-cli compose types liefert Ihnen die vollständige Liste der verfügbaren Image-Typen. Für diesen Workshop interessieren uns dabei nur die Typen "edge-commit" und "edge-container".
Via "edge-commit" erstellen Sie das Install-Repository für das Ostree-Setup. Den Commit platzieren Sie dann auf einem Webserver in dem LAN, in dem Sie das Edge-Device installieren. Der Build-Type "edge-container" erzeugt zusätzlich zum Repository noch einen simplen HTTP-Container für diesen Webserver. In unserem LAN gibt es bereits einen zentralen Webserver für verschiedene Dienste. Daher können wir auf den Container verzichten und das fertigen Image-Build später einfach in ein Unterverzeichnis der Maschine packen. Starten Sie den Bau des Images mit
composer-cli compose start bp1 edge-commit
Der Hintergrunddienst des Osbuild-Composers stellt den Auftrag nun in seine Warteschlange. Um zu sehen, ob der aktuelle Build bereits fertig ist, können Sie den Status über composer-cli compose status abfragen. Nach ein paar Minuten sollten Sie hier eine Ausgabe im Stil von "<uuid> FINISHED <Zeit/Datum> bp1 0.0.1" sehen. Über die UUID laden Sie das Image als TAR-Datei:
composer-cli compose image <uuid>
Kickstarter-Datei anlegen
Die resultierende Datei kopieren Sie in ein Unterverzeichnis Ihres Webservers und entpacken sie dort (in unserem Beispiel "/var/www/html/ce9ed"). Nach dem Entpacken des Archivs findet sich dort die compose.json-Datei mit Informationen zum Image und das eigentliche Repository im Unterverzeichnis "repo". Für die Kickstart-Installation erstellen Sie im ce9ed-Verzeichnis jetzt das Kickstart-File "kick.ks". Dieses beginnt mit:
text
zerombr
clearpart --all --initlabel
autopart
reboot
keyboard de-latin1-nodeadkeys
timezone Etc/UTC --isUtc
lang en_US.UTF-8
Das veranlasst die OS-Installation im Textmodus ohne GUI, löscht die Festplatte des Zielsystems und legt eine neue Partitionierung an. Eine Warnung an dieser Stelle: Die Plattenkommandos löschen unwiederbringlich alle Daten auf dem Zielsystem ohne weitere Rückfrage. Mit "Reboot" legen Sie fest, dass das System am Ende des Kickstart-Vorgangs automatisch neu startet.
Die folgenden Zeilen müssen Sie Ihren Anforderungen anpassen:
firewall --disabled
services --enabled= NetworkManager,sshd,podman --disabled=kdump,network,libvirtd
Da es sich hier zunächst um einen Test handelt, schalten wir die Firewall auf dem Edge-Device ab. In einer produktiven Umgebung bleibt diese natürlich eingeschaltet und Sie geben hier nur die zu öffnenden Ports an. Wir wollen die Applikationen auf dem Edge-Gerät später per Podman laufen lassen, also stellen wir hier sicher, dass dieser Dienst automatisch startet.
Wie bereits erwähnt erstellen Sie den Benutzeraccount des Edge-Devices via Kickstart. Die folgende Zeile darf so ebenfalls nur in einer Testumgebung vorkommen:
user --name=<edgeuser> --group= <wheel> --password=<secret> --plaintext
Anstelle des Klartextpassworts sollten Sie hier in produktiven Umgebungen ein verschlüsseltes hinterlegen. Statt "--plaintext" geben Sie dann "--iscrypted" an. Das verschlüsselte Passwort erhalten Sie beispielsweise über folgendes Kommando:
python3 -c 'import crypt,getpass; pw=getpass.getpass();print(crypt.crypt(pw) if (pw==getpass.getpass ("Confirm: ")) else exit())'
Das Python-Kommando fragt ein Passwort zweimal auf der Kommandozeile ab. Wenn beide Eingaben übereinstimmen, erhalten Sie die verschlüsselte Version als Ausgabe.
Der zu erstellende Benutzer muss Mitglied der Gruppe "wheel" sein, wenn Sie über diesen Benutzer Root-Rechte auf dem Edge-System erhalten wollen. Alternativ könnten Sie in der Kickstart-Datei auch ein Passwort für den Root-User deklarieren (rootpw --plaintext password). Und auch hier sollten Sie bevorzugt "--iscrypted" statt "--plaintext" verwenden. In produktiven Setups sollte ohnehin kein Password-Login für den User "Root" existieren.
Die eigentliche Installation von Ostree lösen Sie mit der folgende Zeile aus:
ostreesetup --nogpg --osname=centos --remote=edge --url=http://<Webserver-IP-ADresse>/ce9ed/repo/ --ref=centos/9/x86_64/edge
Dort geben Sie die Quelle des Edge-Repos, den OS-Namen und -Typ an. Die Informationen für "--ref" finden Sie in der compose.json-Datei. Sollten Sie via Composer anstelle eines CentOS-Streams beispielsweise ein Fedora-Image erstellen oder ein Edge-Commit für eine Arm-Plattform, müssen Sie die "--ref"-Zeile entsprechend anpassen. An diesem Punkt der Installation ist es nicht unbedingt sicher, dass Ihr Device bereits korrekt DNS-Namen auflösen kann. Daher empfiehlt es sich, die IP-Adresse des Webservers anzugeben.
An das Ende der Kickstart-Datei können Sie nun noch eigene Bash-Kommandos anhängen. Eine Sektion namens "%pre" führt Kommandos vor der Ostree-Installation aus, die Sektion "%post" läuft dementsprechend danach. Möchten Sie beispielsweise, dass auf dem Edge-Device der Cockpit-Dienst läuft, nutzen Sie folgendes Kommando:
%post --interpreter /usr/bin/bash
systemctl enable cockpit.socket &
%end
Das funktioniert übrigens nur mit dem "%post"-Kommando und nicht in der Sektion "services", da der Cockpit-Dienst über seinen "Socket" und nicht über den "Service" aufgerufen wird.
Installation via USB
Um das Edge-Gerät zu installieren, benötigen Sie einen bootfähigen USB-Stick. Der muss dabei nicht zwangsweise die exakt selbe OS-Version beherbergen, aber zumindest die passende OS-Familie. Am besten passt hier das "Boot-ISO"-Image von [6]. Das Abbild dürfte ohnehin bereits vorliegen, denn damit haben Sie die Build-VM mit dem osbuild-composer erstellt. Schreiben Sie das ISO-Image via dd oder einem USB-Image-Writer-Tool auf den Stick und starten das Edge-System damit. Sobald sie das Auswahlmenü sehen, tippen Sie auf die -Taste und machen somit die Boot-Kommandozeile sichtbar. Löschen Sie den Schalter "quiet" und fügen stattdessen die Kickstart-Angabe ein:
inst.ks=http://<Webserver-IP-Adresse>/ce9ed/kick.ks
Die Installation lädt dann das angegebene Kickstart-File und führt das Setup vollautomatisch durch. Wie schon erwähnt formatiert dabei der Kickstart-Prozess ohne weitere Rückfrage die Festplatte des Zielsystems neu.
Installation via LAN
Den Umweg über den USB-Stick ist nur bei ersten Testinstallationen gangbar, denn dazu benötigen sie einen Bildschirm und eine Tastatur am Edge-Device. In der Praxis starten Sie die Installation der Edge-Geräte dann aber über das Netzwerk mit PXE, was komplett ohne Tastatur oder Bildschirm funktioniert. Dazu müssen Sie natürlich die BIOS-Settings der Edge-Systeme so einstellen, dass diese das LAN als erste Startoption verwenden beziehungsweise über das LAN starten, wenn sie kein gültiges OS auf der Platte/SD-Karte vorfinden.
Für den PXE-Start des Edge-Devices sind einige Dateien von der Boot-CD erforderlich. Aus dem Verzeichnis "images/ pxeboot" kopieren Sie den Kernel "vmlinuz" und die initiale Ramdisk "initrd.img" auf Ihren PXE/DHCP-Server. Zudem überspielen Sie das stage2-Abbild "install. img" aus dem Verzeichnis "images" auf den Webserver und platzieren es neben dem Edge-Install-Repository unter /var/ www/html/ce9ed/".
Je nachdem, ob Sie den Netzwerkstart über UEFI oder den Legacy-BIOS-Modus initiieren, müssen Sie für Ihre Edge-Maschine für UEFI eine "grub.cgf-01-<MAC-Adresse des Edge-Device>"- und für BIOS eine "pxelinux.cfg/01_<MAC-Adresse des Edge-Device>"-Datei auf Ihrem DHCP/PXE-Server erstellen. Darin verweisen Sie auf den Kernel und "initrd.img" sowie auf die Kickstart-Datei und "install.img".
In unserem Setup, das den Web- und PXE/DHCP-Server auf derselben Maschine betreibt, sieht der passende Abschnitt im BIOS-Boot-File des PXE-Servers so aus:
label CE9ed
      menu label ^Centos9 Edge
      linux ce9-vmlinuz
      append initrd=ce9-initrd.img
      inst.text ksdevice=bootif
      inst.ks=http://192.168.2.12/ce9ed/kick.ks
      inst.stage2=http://192.168.2.12/ce9ed
Da wir den Kernel und die initrd via TFTP-Protokoll übermitteln, haben wir beide Dateien direkt nach "/var/lib/tftp-boot" kopiert und so umbenannt ("vmlinuz" zu "ce9-vmlinuz"), dass wir verschiedene Kernel für unterschiedliche Distri- butionen und Versionen im TFTP-Root-Verzeichnis lagern können. Für den Parameter "stage2" genügt das Verzeichnis, in dem die install.img-Datei liegt.
Updates einspielen
Um das Image des Edge-Devices zu aktualisieren, erstellen Sie zunächst eine neue Version des Blueprints:
1. TOML-Datei anpassen
2. Version hochzählen
3. Blueprint pushen, bauen und als TAR-Datei mit einer neuen UUID herunterladen.
Mit dem Inhalt der neuen TAR-Datei überschreiben Sie das Verzeichnis "/var/ www/html/ce9ed" auf Ihrem Webserver. Das Update stoßen Sie auf dem Edge-Device über rpm-ostgree upgrade an. Beim nächsten Neustart bootet das Edge-Device auf die aktualisierte OS-Version. Sollte diese nicht funktionieren wie gewünscht, schalten Sie über rpm-ostree rollback auf die vorhergehende Version zurück. Das Kommando rpm-ostree status zeigt, welche beiden Images aktuell auf dem Gerät zur Verfügung stehen.
ARM statt x86
Edge-Rechner arbeiten nicht zwingend mit Intel-kompatiblen CPUs. Kleincomputer wie der Raspberry PI erledigen Edge-Aufgaben ebenfalls sehr gut und kommen mit viel weniger Strom aus. Der ostree-composer funktioniert auch auf Systemen mit der ARM-v8-64-Bit-Architektur (aarch64), wie sie beispielsweise der Raspberry PI 4 verwendet. Das setzt jedoch voraus, dass der Rechner eine UEFI-Firmware für den Start verwendet. Die meisten älteren 32-Bit-ARM-Computer (PI 2 oder 3) mit der Architektur "armhf" nutzen noch das "Universal Boot Loader Project" (U-Boot), das der Composer nicht unterstützt. Prinzipiell kann U-Boot ein ostree-basiertes OS starten. Der Build-Prozess ist dabei allerdings nicht so leicht und komfortabel wie mit dem osbuild-composer.
Um ein Aarch64-Image zu bauen, benötigen Sie jedoch einen Build-PC oder eine Build-VM, die selbst auf Aarch64 läuft. Das kann dann ein bestehender PI 4 mit einer regulären CentOS-9-Streams-Installation oder alternativ eine ARM-basierte VM auf einer Cloudplattform wie AWS sein.
Fazit
Der Osbuild-Composer erstellt in wenigen Schritten sichere OS-Images für Ihre Edge-Devices. Ob Sie die Applikation dann direkt in dieses Abbild integrieren oder es separat mit einer Container-Plattform betreiben, bleibt dabei völlig Ihnen überlassen. Der Composer beherrscht dabei auch 64-Bit-Kleincomputer mit ARM-Architektur, sodass sie problemlos Raspberry-Pi-4-Systeme oder vergleichbare Einplatinen-Computer für Ihre Edge-Geräte einsetzen können.
(jp)
Link-Codes
[5] Liste vordefinierter Repository-Dateien: https://github.com/osbuild/rpmrepo/tree/main/repo/