Zentrale Steuerung der globalen Edge-Flotte

In einem unserer aktuellen Projekte werden Edge Devices in allen weltweit verteilten Industriemaschinen des Kunden installiert, um Prozessdaten zu erfassen. Für den Start wurde entschieden, die gleiche Linux-Distribution und das gleiche Config Management Tool wie im Rechenzentrum einzusetzen. Der Workload läuft in Containern, diese werden mit Docker Compose gehostet, das wiederum über das Config Management Tool verwaltet wird. Die Edge Devices verfügen nur über sehr begrenzte Hardware-Ressourcen (2 Cores, 8 GB Arbeitsspeicher). In den meisten Werken gibt es kein dediziertes IT-Personal, die Edge Devices werden vom Instandhaltungsteam installiert. Sollte eines der Geräte defekt sein, so wird es durch ein funktionierendes ersetzt.

Mit der steigenden Anzahl von Edge Devices treten in zunehmendem Maße auch die folgenden Herausforderungen auf:

• Es existieren Konfigurationen, die nicht über Config Management ausgerollt wurden.
• Der Softwarestand auf den Edge Devices ist teilweise unterschiedlich.
• Der Config Management Agent benötigt während eines Durchlaufs 100 % der CPU-Ressourcen. Einfache Konfigurationsänderungen dauern daher einige Minuten.
• Die Aktualisierung und Verteilung des Base-Images ist aufwändig und kompliziert.
• Wenn Edge Devices durch ein fehlerhaftes Betriebssystem-Update nicht mehr erreichbar sind, müssen sie komplett neu installiert werden.

Zudem laufen die Container auf den Edge Devices mittels Docker Compose. Im zentralen System wird jedoch auf Kubernetes gesetzt, aber sowohl die Entwickler als auch das Ops-Team würden einen einheitlichen Ansatz bevorzugen.

Edge-Umfeld erfordert entsprechende Tools und Prozesse

Für das Deployment beziehungsweise die Entwicklung einer Applikation wird seit Jahren erfolgreich auf das Layer-basierte Container Image gesetzt. Mit Red Hat Image Mode beziehungsweise dessen Upstream-Projekt bootc können Ops-Team und Entwickler OS-Images mit den gleichen Tools verwalten, die auch für Container Images verwendet werden. Die Container Images beinhalten einen Linux-Kernel, der es ermöglicht, diese zu booten. bootc basiert auf dem ostree-Projekt, das seit Jahren für stabile OS-Upgrades eingesetzt wird.

Das Upgrade eines Hosts, der mit Image Mode installiert ist, funktioniert wie folgt:

1. Ein neues Image ist verfügbar, dieses wird im Hintergrund automatisch heruntergeladen.
2. Beim nächsten Reboot wird auf das neue Image gewechselt
3. Bootet dieses erfolgreich – alles gut. Wenn nicht, wird automatisch auf das alte Image gewechselt.

Standardmäßig ist das Filesystem komplett beschreibbar. Wir empfehlen jedoch, dies so weit wie möglich einzuschränken und beispielsweise nur das Verzeichnis /var beschreibbar zu machen. Bei einem Update werden nämlich alle im Image enthaltenen Files als „neue Wahrheit“ übernommen. Das bedeutet, dass eventuell manuell vorgenommene Änderungen an Konfigurationsdateien überschrieben werden. Das Verzeichnis /var bleibt dabei unangetastet. Sollen andere Verzeichnisse beschreibbar sein, so ist dies möglich und sollte explizit definiert werden. 

Wie baue ich nun so ein bootc Image? Ganz einfach:

1. Erstelle ein OCI Container File oder ein Docker File. Wichtig ist, dass das Base Image, auf das mit FROM referenziert wird, bereits einen Linux-Kernel enthält.
2. Modifiziere das Image wie gewohnt nach deinen Anforderungen mit RUN, COPY, etc. In diesem Beispiel wird MicroShift installiert, eine Konfigurationsdatei hinzugefügt und systemd für den automatischen Start von MicroShift konfiguriert.

3. Image mit Podman, Docker etc. bauen und auf eine Container Registry hochladen.
4. Die „Installation“ auf einem Device kann zum Beispiel mittels kickstart erfolgen.

Upgrade der bestehenden Edge Devices auf Image Mode

Mit dem Hinzufügen eines neuen Default-Eintrags im bestehenden grub bootloader kann das bestehende Linux einfach mittels kickstart durch das neue Deployment-Modell ersetzt werden. 

Was ist das Ergebnis dieser Lösung?

• Inplace Upgrade der vorhandenen Devices, ohne diese anfassen zu müssen.
• Verwendung der gleichen Tools für Applikations- und OS-Images ermöglicht zum Beispiel Scans nach CVEs vor dem Deployment mit existierenden Tools aus der Applikationswelt.
• OS-Updates mit Fallback im Fehlerfall.
• Workloads auf den Edge Devices werden über die K8s-API „gesteuert“.