Einführung in die Balena Cloud

Der Einplatinencomputer Raspberry PI ist seit jeher ein solides System für Software und Hardware Projekte.
Obwohl die aktuelle Verfügungbarkeit immer noch sehr schlecht ist, habe ich immer noch einige PIs unterschiedlicher Generationen bei mir im Einsatz.
Mein Ziel ist es, hier einige der Projekte vorzustellen und step-by-step Anleitungen zu dokumentieren.

Mein Hauptproblem bei einem PI Setup war für mich lange Zeit die Verlässlichkeit der verwendeten SD-Card.
Nach einigen Betriebsjahren, tauchten im Log immer mal wieder Lese-/Schreibproblem auf, die darauf hin deuteten, dass es mal wieder Zeit ist, das komplette PI Setup neu aufzusetzen. Dies passiert natürlich immer zum ungünstigsten Zeitraum.

Ein erster Schritt ist dann gewesen, die vollständige Konfiguration in ein GIT Repository einzuschecken.
So war zumindest gewährleistet, dass das einmalige Konfigurationssetup erhalten bleibt.

Ausgehend von dem bekannten Tool „Balena Etecher“, habe ich mich dann irgendwann auch mit der Balena Cloud näher befasst.
Im Free Tier sind bereits ausreichend viele Funktionen enthalten, um die eigene PI Flotte pflegen zu können.

Einfach gesagt, ist Balena Cloud ein Service, in dem Fleets, Devices und Releases verwaltet werden können. Eine Fleet ist Sammlung von mehreren Devices, ein Device ist z.B. ein PI, welches dieser Fleet zugeordnet ist und mehrere Anwendungen ausführen kann. Eine Anwendung hat jeweils ein aktuelles Release.

Ein Device hat jeweils ein Image mit dem BalenaOS. Dieses OS ist Linux basiert und enhält mehrere Tools, u.a. ein Supervisor, der dafür sorgt, dass die konfigurierten Anwendungen jeweils in der aktuellen Version laufen, eine Container Runtime, welche die Container der Anwendungen ausführt. Weiterhin werde die Logs via VPN an die Balena Cloud gestreamt.
Optional kann eine Anwendung, die auf dem PI läuft ebenfalls über eine externe URL erreichbar gemacht werden, welche dann über die Services von Balena getunnelt wird.

Das Deployment von neuen Anwendung erfolgt mit Hilfe von Docker Files (Dockerfile, docker-compose.yml).
Hierbei erfolgt optional auch ein Build der Image über die Balena Infrastruktur.

Alle Anwendungen laufen aber jeweils lokal auf dem Raspberry PI und benötigen zum Betrieb keine Verbindung zur Balena Cloud.
Wie löst Balena Cloud nun das Problem mit dem SD-Karten?

Der Vorteil ist, dass man einmalig eine Fleet konfiguriert (System-Architektur, Anwendungen, Releases).
Danach lässt sich ein Image für ein Device dieser Fleet herunterladen, welches sich per Etcher auf eine SD-Card bringen lässt.
Nach dem einmaligem Boot sorgt nun das Balena Setup dafür, dass das neue Device mit der aktuellen Konfiguration versehen wird.
Das heißt, sollte eine SD-Card defekt sein, reich es aus, eine neue SD-Card mit dem bisherigem Image zu versehen und das Device neu zu starten.

initiales Setup

Der erste Schritt ist die Erstellung einer Fleet. Darin lassn sich dann Devices und Releases kapseln:

Eine Fleet ist immer spezifisch für eine Architektur. Für unser Beispiel wählen wir hier den Raspberry PI 3.

Nachdem wir die Fleet erstellt haben, können wir nun unser erstes Device hinzufügen:

Eine Verbindung über Ethernet sollte immer möglich sein. Je nach gewählter Platform ist aber auch die Konfiguration einer WLAN Verbindung möglich. In unserem Beispiel ist dies ein offener Freifunk Knoten von Freifunk München. Es lassen sich natürlich aber auch geschützte WLAN-Netze konfigurieren.
Wir wählen aus, dass wir das resultierende Image herunterladen wollen.

Der Vorgang, das Image dann auf eine SD-Card zu schreiben, sollte bekannt sein. Der Balene Etcher ist ein beliebtes Tool im Raspberry PI Ökosystem.

Wir booten nun von der SD-Card und nach einiger Zeit sollte das neue Device unter den Devices der Fleet auftauchen. Das initiale Setup dauert ein paar Minuten. Am Ende sollte das Device den Status online haben.

Die Device Details geben Auskunft über die deployten Anwendungen und die Auslastung des Devices.

Als letzten Schritt konfigurieren wir noch das Balena CLI Tool.
Unter MacOS lässt sich dies via Homebrew sehr einfach installieren:

brew install balena-cli

Für unser erstes Projekt legen wir ein Verzeichnis mit dem identischen Namen der Fleet an.
Zuletzt erstellen wir für das CLI Tool eines Session, über den Web Login, damit wir ein neues Release deployen können:

philipp@Imotep % mkdir balena
philipp@Imotep % cd balena
philipp@Imotep balena % mkdir test-app
philipp@Imotep balena % cd test-app
philipp@Imotep test-app % balena login
 _            _
| |__   __ _ | |  ____  _ __    __ _
| '_ \ / _` || | / __ \| '_ \  / _` |
| |_) | (_) || ||  ___/| | | || (_) |
|_.__/ \__,_||_| \____/|_| |_| \__,_|


Logging in to balena-cloud.com
? How would you like to login? (Use arrow keys)
❯ Web authorization (recommended)
  Credentials
  Authentication token
  I don't have a balena account!

Es öffnet sich nun eine Seite im Browser. Sind wir bereits im Balena Dashboard angemeldet, können wir nach einer kurzen Bestätigung die Seite wieder schließen. Das CLI Tool sollte nun eine gültige Session haben.

Deployment einer Beispielanwendung

Als initiales Beispiel verwenden wir einen Standard nginx Service.
Hierbei nutzen wir eine docker-compose Datei und das nginx default Docker Image.
Am Rande sei erwähnt, dass dies nur problemlos funktioniert, weil das nginx Image in den unterschiedlichen Architekturen (x86, ARM) zur Verfügung steht.
Wäre dies nicht der Fall, müssten wir unsere Image erst selbst zusammenbauen. Dies wird Teil von späteren Blog Posts sein.

Der Inhalt der docker-compose.yml Datei ist recht übersichtlich – wir erstellen ein Deployment, welches über den Host Port 80 erreichbar ist.

version: '2.1'

services:
  web:
    image: nginx
    ports:
    - "80:80"
    environment:
    - nginx_PORT=80

Ein Deployment wird per balena push <fleet name> angestoßen:

philipp@Imotep test-app % balena push gh_phaus/test-app

Per Hook können wir nun den Build des neuen Releases verfolgen. Dies geschieht auf einen der Build Knoten von Balena. Würden wir ein eigenes Docker Image erstellen, würde dies ebenfalls hier durchgeführt werden.
Am Ende erhalten wir eine Zusammenfassung über die gebauten Artifakte und ein Einhorn :-).

Über die Device Detail Ansicht können wir nun das Deployment unseres ersten Releases verfolgen.

Die einzelnen Artifakte eines neuen Releases werden erst komplett heruntergeladen, bevor sie deployt werden.
Am Ende sollten alle Services den Status running haben.

nginx sollte nun bereits unter der lokalen IP Adresse des Raspberry PIs erreichbar sein.
Soll der Service ebenfalls von außen erreichbar sein, muss der Toggle Public device URL auf On gestellt werden.