Seite 3: OTA-Updates – ein Ablauf in mehreren Schritten

Grundsätzlich ähneln sich bei allen drei Kandidaten die Schritte, ein Gerät mit OTA-Updates zu versorgen. Im Folgenden sollen sie am Beispiel Mender kurz umrissen werden, da dies keine Installation eines Backends benötigt, sondern mit einem kostenlosen Trial-Account funktioniert. Diese Schritte sind nicht im Detail ausformuliert, sondern sollen nur die Konzepte verdeutlichen. Sie sind in ähnlicher Form auch bei SWupdate/RAUC und Hawkbit nötig.

Am Anfang steht immer ein Linux-Image für das Zielgerät, meist mit Yocto gebaut. Das Listing zeigt eine YAML-Datei, die einen vollständigen Yocto-Build über das Tool kas definiert. Der Aufruf

kas build ota.yml

stößt den Build an. Achtung: Wie jeder Yocto-Build kann dies mehrere Stunden und viele Gigabyte Festplattenplatz erfordern. Nach Abschluss finden sich im Verzeichnis /tmp/deploy/images/raspberrypi4 diverse Ausgabedateien, wobei zum Verständnis nur zwei davon notwendig sind. Die .sdimg-Datei dient als Startpunkt – im Sprachgebrauch von Herstellern die Provisionierung von Geräten. Diese Art von Images beinhaltet das Partitionslayout sowie den vorbereiteten Bootloader und wird im Falle des Raspberry Pi üblicherweise auf die SD-Karte geschrieben, zum Beispiel mit dem balena Etcher. Die .mender-Datei ist ein Artifact, das sich in einem laufenden System als Update einspielen lässt.

header:
  version: 11

distro: poky

machine: raspberrypi4

defaults:
  repos:
    refspec: dunfell

repos:
  poky:
    url: https://git.yoctoproject.org/git/poky
    layers:
      meta:
      meta-poky:
      meta-yocto-bsp:

  meta-openembedded:
    url: https://git.openembedded.org/meta-openembedded
    layers:
      meta-oe:

  meta-mender:
    url: https://github.com/mendersoftware/meta-mender.git
    layers:
      meta-mender-core:
      meta-mender-demo:
      meta-mender-raspberrypi:

  meta-raspberrypi:
    url: https://github.com/agherzan/meta-raspberrypi.git

local_conf_header:
  base: |
    CONF_VERSION = "1"
    PACKAGE_CLASSES = "package_ipk"
    INHERIT += "mender-full"
    INIT_MANAGER = "systemd"

  raspberrypi: |
    RPI_USE_U_BOOT = "1"
    ENABLE_UART = "1"
    MENDER_BOOT_PART_SIZE_MB = "100"
    IMAGE_INSTALL:append = " kernel-image kernel-devicetree"
    IMAGE_FSTYPES:remove = " rpi-sdimg"

  heise_developer: |
    MENDER_ARTIFACT_NAME = "heisedeveloper1"
    IMAGE_INSTALL:append = ""

target:
  - core-image-minimal

Das gebootete System verhält sich wie ein normales Linux. Um mit OTA-Updates versorgt zu werden, muss es im Backend registriert werden. Im einfachsten Fall für Mender folgt man der interaktiven Registrierung per mender setup auf der Kommandozeile. Es empfiehlt sich, die Frage nach dem verkürzten Polling-Intervall mit Y zu bestätigen. In realen Projekten werden mehrere Minuten bis Stunden benötigt, was während der Evaluation oder Entwicklung unangenehm träge ist.

Nun muss die Anfrage des Geräts auf der Verwaltungsoberfläche des Backends bestätigt werden. Im Anschluss erscheint der Raspberry Pi im Dashboard, und das zeigt den aktuellen Softwarezustand des Systems. Diese Darstellung heißt im IoT-Jargon meist Inventory.

Zum Ausrollen eines Updates muss man es in das Repository des Backend hochladen. Hier kommt die oben erwähnte .mender-Datei ins Spiel. Sie enthält ein per OTA verteilbares Linux-System. Es definiert als Metadaten ein oder mehrere kompatible Geräte sowie die enthaltene Softwareversion. Theoretisch könnte man das im ersten Build erstellte Artifact verwenden. Da es allerdings dieselbe Softwareversion trägt und dasselbe System enthält wie das bereits auf der SD-Karte laufende Linux, ist dieses Update wenig sinnvoll.

Eine einfache Änderung besteht darin, die Variable MENDER_ARTIFACT_NAME in der kas-Datei auf einen beliebigen anderen Wert zu ändern und den Build anschließend neu zu starten. Falls gewünscht, kann man die Zeile

IMAGE_INSTALL:append = " "

um ein zu installierendes Paket ergänzen. Zur Verdeutlichung der neuen Softwareversion kann beispielsweise der Kommandozeilenrechner bc installiert werden. Dazu fügt man dem append-String die Variable bc hinzu, wobei das Leerzeichen davor immer erhalten bleiben muss. Yocto kann bei fortgesetzten Builds große Teile wiederverwenden, deshalb ist hier jetzt mit deutlich weniger Zeitaufwand zu rechnen. Anschließend stehen je eine neue .sdimg- und .mender-Datei bereit, letztere lässt sich ins Backend hochladen.

Als letzter Schritt wird ein Deployment erstellt. Dazu wählt man in der Detailansicht der Releases das eben hochgeladene Artifact aus und folgt dem Dialog "create deployment with this release". Nach Bestätigung wird das Update im nächsten Polling-Zyklus eingereiht und innerhalb einiger Minuten inklusive Neustart installiert.