IoT und Edge Computing: Raspberry Pi und Edge-Nodes mit Polycrate verwalten | Blog

TL;DR

Du kannst mit Ansible hunderte Raspberry Pis und andere Edge-Nodes zentral verwalten – ohne Agent auf den Geräten, nur per SSH.
Polycrate nimmt dir das komplette Ansible-Setup ab: Du brauchst auf deinem Laptop keine Python- oder Ansible-Installation, alles läuft reproduzierbar in einem Container.
Mit einem einzigen Polycrate-Block baust du idempotente OTA-Updates (apt upgrade) inklusive Service-Restart und verteilst Sensor- und Logging-Konfiguration auf deine Geräteflotte.
Über serial: 10 rollst du Updates sicher in Wellen aus, zum Beispiel 50 Raspberry Pis in Gruppen à 10 – ideal für Fabrikhallen, Smart-Home-Flotten oder Industrie-4.0-Setups.
ayedo unterstützt Teams mit praxisnahen Workshops, fertigen Polycrate-Blöcken und Beratung rund um IoT- und Edge-Automatisierung – inklusive Compliance-Themen und sicherer Workspace-Verschlüsselung.

Das IoT-Management-Problem in der Praxis

Stell dir eine typische Fabrikhalle vor:

100 Raspberry Pis als Edge-Nodes an Maschinen
ein paar industrielle Gateways im Schaltschrank
vielleicht noch 20 Sensorboxen im Lager

Alle machen „irgendetwas Wichtiges“: Daten sammeln, in die Cloud senden, Alarme auslösen. Aber:

Updates laufen per Hand („wenn ich mal dazu komme“)
Konfigurationen werden per SCP oder USB-Stick verteilt
Niemand weiß genau, welches Gerät auf welchem Stand ist

Das ist nicht nur unkomfortabel, sondern riskant:

Sicherheitsupdates bleiben liegen
Konfigurationsfehler sind schwer zu finden
Fehler sind nicht nachvollziehbar – kein Audit-Trail

Ansible ist für solche Aufgaben hervorragend geeignet. Aber:
Viele IoT- und OT-Teams scheitern daran, Ansible selbst sauber aufzusetzen: Python-Versionen, Collections, SSH-Konfiguration, ansible.cfg, und so weiter.

Genau hier setzt Polycrate an: Du bekommst eine standardisierte Ansible-Umgebung im Container – ohne Installationsmarathon auf deinem Laptop. Du konzentrierst dich auf deine Geräte, nicht auf dein Tooling.

Ansible für Raspberry Pi und Edge-Nodes – ohne Setup-Stress

Raspberry Pis sind aus IoT- und Edge-Projekten kaum wegzudenken. Für Ansible sind sie ideale Ziele:

Standard-Linux (z. B. Raspberry Pi OS, Ubuntu Server)
SSH-Zugang möglich
Python ist meist vorinstalliert

Wichtig: Die Architektur (armv7, arm64) ist Ansible egal. Ansible steuert die Geräte per SSH, die Module laufen direkt auf dem Zielsystem. Du brauchst also:

auf dem Ziel: SSH + Python
auf deinem Laptop: eine funktionierende Ansible-Umgebung

Mit „plain“ Ansible heißt das für dich:

Python installieren (welche Version?)
Ansible installieren (welche Version passt zu deinem Team?)
Collections nachziehen (z. B. community.general)
ansible.cfg und Inventories pflegen

Und dann funktioniert es auf dem Laptop deines Kollegen anders als bei dir, weil Versionen leicht abweichen.

Mit Polycrate sieht das anders aus:

Ansible läuft in einem Container, den Polycrate für dich startet
Die Versionen von Ansible, Python und Tools sind im Container-Image festgelegt
Alle im Team nutzen dieselbe Toolchain – reproduzierbar auf jedem Rechner

Mehr zur Ansible-Integration findest du in der Polycrate-Dokumentation zur Ansible-Integration.

Ein Workspace für deine Edge-Flotte

Wir starten mit einem einfachen Polycrate-Workspace für eine kleine Flotte von Raspberry Pis.

Angenommen, dein Workspace liegt in einem Git-Repository und heißt acme-corp-automation. Im Wurzelverzeichnis des Workspaces liegt dein Inventory als YAML-Datei inventory.yml:

# inventory.yml (Ansible-YAML-Inventar)
all:
  children:
    edge:
      hosts:
        pi-01.acme-corp.com:
          ansible_user: pi
        pi-02.acme-corp.com:
          ansible_user: pi
        pi-03.acme-corp.com:
          ansible_user: pi
        pi-04.acme-corp.com:
          ansible_user: pi
        pi-05.acme-corp.com:
          ansible_user: pi

Hinweise:

edge ist die Gruppe, die du im Block über hosts_group: edge ansteuerst.
Das Inventory liegt immer im Workspace-Root als inventory.yml.
Polycrate setzt die Umgebungsvariable ANSIBLE_INVENTORY automatisch auf diese Datei.
Für 50 oder 100 Geräte erweiterst du einfach die Liste unter edge.hosts.

Damit hast du die „Landkarte“ deiner Edge-Flotte zentral an einem Ort.

Als Nächstes definieren wir in Polycrate einen Block, der genau diese Hosts für OTA-Updates und Konfiguration nutzt.

Mehr zu Workspaces steht in der Dokumentation zu Workspaces.

Polycrate-Block für OTA-Updates auf Edge-Nodes

Wir legen jetzt einen Block an, der:

OTA-Updates per apt upgrade durchführt
danach einen Edge-Service neu startet
Updates in Wellen (z. B. 10 Geräte auf einmal) ausrollt

Verzeichnisstruktur (vereinfacht):

acme-corp-automation/
  workspace.poly
  inventory.yml
  blocks/
    registry.acme-corp.com/acme/iot/edge-ota/
      block.poly
      ota-update.yml
      deploy-config.yml
      sensor-config.yml.j2

(Nach polycrate pull registry.acme-corp.com/acme/iot/edge-ota:0.1.0 liegt der Block unter diesem Pfad.)

block.poly für den Edge-OTA-Block

# blocks/registry.acme-corp.com/acme/iot/edge-ota/block.poly
name: registry.acme-corp.com/acme/iot/edge-ota
version: 0.1.0
kind: generic

config:
  hosts_group: edge
  service_name: edge-agent
  serial: 10
  config_path: /etc/edge-agent/config.yml
  logging_level: INFO

actions:
  - name: ota-update
    description: Führe apt-Updates auf allen Edge-Nodes aus
    playbook: ota-update.yml

  - name: deploy-config
    description: Verteile Konfiguration für Sensoren und Logging
    playbook: deploy-config.yml

Wichtig:

config definiert alle veränderbaren Parameter deines Blocks – ideal für unterschiedliche Flotten (z. B. andere Services, andere Pfade).
actions sind benannte Einsprungpunkte. Deine Kolleginnen und Kollegen führen später einfach polycrate run edge-ota ota-update aus, ohne Ansible-CLI-Details kennen zu müssen.

Mehr zu Blöcken findest du unter Blöcke und Actions.

OTA-Updates mit Ansible – idempotent und gestaffelt

Das dazugehörige Ansible-Playbook ota-update.yml liegt im gleichen Block-Verzeichnis:

# blocks/registry.acme-corp.com/acme/iot/edge-ota/ota-update.yml
- name: OTA-Updates für Edge-Nodes
  hosts: "{{ block.config.hosts_group }}"
  serial: "{{ block.config.serial }}"
  become: true
  gather_facts: false

  tasks:
    - name: Paketindex aktualisieren
      ansible.builtin.apt:
        update_cache: true
        cache_valid_time: 3600

    - name: Systempakete aktualisieren
      ansible.builtin.apt:
        upgrade: safe
      notify: Edge-Service neu starten

  handlers:
    - name: Edge-Service neu starten
      ansible.builtin.service:
        name: "{{ block.config.service_name }}"
        state: restarted

Wesentliche Punkte:

hosts: "{{ block.config.hosts_group }}"
– wir nutzen die Gruppe edge aus deinem inventory.yml. Du kannst sie im Block bei Bedarf umkonfigurieren.
serial: "{{ block.config.serial }}"
– hier passiert das gestaffelte Rollout: Ansible bearbeitet z. B. immer 10 Hosts gleichzeitig.
So verhinderst du, dass ein Fehler alle 50 Geräte auf einmal ausknockt.
apt-Tasks sind idempotent: Wenn ein Gerät bereits aktuell ist, macht Ansible nichts weiter.
Der Service-Restart wird nur ausgeführt, wenn tatsächlich Pakete aktualisiert wurden (notify-Handler).

Mit „plain“ Ansible müsstest du:

selbst Ansible und Collections installieren
ein passendes Python-Setup bereitstellen
die ansible-playbook-CLI richtig aufrufen (-i inventory.yml ota-update.yml)

Mit Polycrate reicht:

polycrate run edge-ota ota-update

Der Befehl:

startet einen Container mit deiner Ansible-Toolchain
lädt automatisch dein inventory.yml
führt das Playbook gegen deine Edge-Flotte aus

Keine lokale Ansible-Installation, keine Python-Konflikte, kein „funktioniert nur auf meinem Laptop“.

Konfigurationsmanagement: Sensoren und Logging verteilen

Updates sind nur die halbe Miete. Genauso wichtig ist zentrale Konfiguration:

Sensor-Sampling-Intervalle
Logging-Level (z. B. DEBUG vs. INFO)
Zielsysteme für Logs (z. B. Syslog-Server)

Mit Polycrate steuerst du das über denselben Block – eine zweite Action verteilt eine Konfigurationsdatei.

Playbook für Konfigurations-Deployment

# blocks/registry.acme-corp.com/acme/iot/edge-ota/deploy-config.yml
- name: Konfiguration für Edge-Nodes verteilen
  hosts: "{{ block.config.hosts_group }}"
  become: true
  gather_facts: false

  tasks:
    - name: Konfigurationsverzeichnis anlegen
      ansible.builtin.file:
        path: "{{ block.config.config_path | dirname }}"
        state: directory
        owner: root
        group: root
        mode: "0755"

    - name: Konfigurationsdatei aus Template bereitstellen
      ansible.builtin.template:
        src: sensor-config.yml.j2
        dest: "{{ block.config.config_path }}"
        owner: root
        group: root
        mode: "0644"
      notify: Edge-Service neu starten

  handlers:
    - name: Edge-Service neu starten
      ansible.builtin.service:
        name: "{{ block.config.service_name }}"
        state: restarted

Jinja2-Template für Sensor-Config

# blocks/registry.acme-corp.com/acme/iot/edge-ota/sensor-config.yml.j2
sensors:
  sampling_interval_ms: 1000

logging:
  level: "{{ block.config.logging_level }}"
  destination: syslog

edge:
  node_name: "{{ inventory_hostname }}"

Hier siehst du Jinja2-Templates in Aktion:

{{ block.config.logging_level }}
– liest die Konfiguration direkt aus block.config in deiner block.poly.
Änderst du dort INFO auf DEBUG, wird die neue Einstellung auf alle Geräte ausgerollt.
{{ inventory_hostname }}
– bezieht sich auf den Hostnamen aus dem Inventory (pi-01.acme-corp.com etc.).

Die Ausführung ist wieder einfach:

polycrate run edge-ota deploy-config

Mit zwei Actions in einem Block hast du jetzt:

reproduzierbare OTA-Updates
reproduzierbare Konfigurations-Deployments

Alles ist versioniert, gut strukturiert und kann mit deinem Team geteilt werden – das ist der „Sharable Automation“-Gedanke von Polycrate.

workspace.poly: Block einbinden und konfigurieren

Damit Polycrate weiß, welchen Block es in diesem Workspace verwenden soll, trägst du ihn in der workspace.poly ein:

# workspace.poly
name: acme-corp-automation
organization: acme

blocks:
  - name: edge-ota
    from: registry.acme-corp.com/acme/iot/edge-ota:0.1.0
    config:
      hosts_group: edge
      service_name: edge-agent
      serial: 10
      config_path: /etc/edge-agent/config.yml
      logging_level: INFO

Erläuterungen:

from: registry.acme-corp.com/acme/iot/edge-ota:0.1.0
– referenziert den Block in eurer OCI-Registry (fiktives Beispiel); nach polycrate pull … liegt er unter blocks/registry.acme-corp.com/acme/iot/edge-ota/.
config:
– überschreibt oder setzt die Standardwerte aus block.poly. So kannst du z. B. für eine andere Halle einen zweiten Blockeintrag mit anderem Service-Namen anlegen.

Eigene Blöcke kannst du in dieselbe Registry pushen und mit anderen Teams teilen – oder über den PolyHub zugänglich machen. Polycrate unterstützt dich dabei, siehe Registry-Dokumentation und PolyHub-Dokumentation.

Sicherheit und Compliance: Workspace-Verschlüsselung für IoT

Gerade in OT-Umgebungen liegen im Workspace oft sensible Daten:

SSH-Schlüssel für Edge-Nodes
WLAN-Credentials für Remote-Standorte
Zugangsdaten für zentrale Logging- oder Cloud-Systeme

Polycrate bringt eine eingebaute Workspace-Verschlüsselung mit age mit. Du musst keinen externen Secret-Store wie HashiCorp Vault betreiben, kannst ihn aber ergänzend nutzen, wenn du möchtest.

Typischer Ablauf:

Du legst geheime Dateien unter artifacts/secrets/ ab, z. B.:

artifacts/secrets/
  id_ed25519
  id_ed25519.pub

Du verschlüsselst den Workspace:

polycrate workspace encrypt

Vor der Arbeit entschlüsselst du ihn wieder:

polycrate workspace decrypt

Polycrate integriert diese Secrets automatisch, sodass du z. B. in Playbooks über workspace.secrets darauf zugreifen kannst, ohne Pfade hart zu codieren.

Details dazu findest du in der Dokumentation zur Workspace-Verschlüsselung und zur SSH-Integration.

Damit schlägst du die Brücke zwischen IoT-Praxis und Compliance-Anforderungen (z. B. interne Richtlinien, ISO 27001 oder branchenspezifische Vorgaben).

Plain Ansible vs. Polycrate: der Aha-Moment für IoT-Teams

Um den Unterschied klarzumachen, schauen wir auf das, was du mit „plain“ Ansible tun müsstest:

Python lokal installieren und aktuell halten
Ansible und benötigte Collections installieren
Je nach Betriebssystem (Windows, macOS, Linux) unterschiedliche Setups pflegen
ansible.cfg, inventory.yml, Playbooks und Secrets manuell koordinieren
Kolleginnen und Kollegen einarbeiten („Bei dir funktioniert das Playbook wegen Python 3.12 nicht, du brauchst 3.10…“)

Mit Polycrate:

Einmal Polycrate installieren (Binary)
Workspace auschecken
polycrate run edge-ota ota-update oder polycrate run edge-ota deploy-config ausführen

Der Rest passiert im Container – inklusive Ansible, Python und zusätzlicher Tools. Du bekommst:

reproduzierbare Automatisierung
weniger Dependency-Chaos
klare Struktur durch das Block-Modell statt wild gewachsener Playbook-Sammlungen

Best Practices zur Strukturierung von Blöcken und Workspaces findest du in den Best Practices.

Häufige Fragen

Brauche ich auf den Raspberry Pis einen speziellen Agent für Polycrate oder Ansible?

Nein. Ansible arbeitet agentlos. Du brauchst auf den Geräten:

einen SSH-Server
einen Benutzer mit ausreichenden Rechten (z. B. pi mit sudo)
Python (bei gängigen Linux-Distributionen auf dem Raspberry Pi bereits vorhanden)

Polycrate ändert daran nichts – es kümmert sich nur darum, dass Ansible bei dir sauber läuft. Auf den Edge-Nodes selbst musst du nichts Zusätzliches installieren.

Was passiert, wenn ein Edge-Node während des Updates nicht erreichbar ist?

Ansible meldet den Host als „unreachable“, bricht aber nicht dein gesamtes Rollout ab – besonders in Kombination mit serial.
Mit serial: 10 werden z. B. 10 Hosts auf einmal behandelt. Fällt einer davon aus, laufen die anderen 9 weiter. Der Host, der nicht erreichbar war, bleibt im Report sichtbar und kann später erneut angesteuert werden.

Weil die Playbooks idempotent sind, kannst du denselben Polycrate-Befehl einfach noch einmal ausführen, wenn die Netzwerkverbindung wieder steht. Ansible aktualisiert dann nur, was noch fehlt.

Kann ich Polycrate auch in bestehende OT-/IT-Umgebungen integrieren?

Ja. Typische Einsatzszenarien sind:

auf dem Laptop von OT-/IoT-Ingenieur:innen, die unabhängig Updates ausrollen möchten
auf einem zentralen Linux-Server im Werk, der als Automatisierungs-Hub dient
in CI/CD-Pipelines, um regelmäßig Health-Checks oder Config-Drifts zu prüfen

Weil Polycrate containerbasiert arbeitet, bekommst du überall die gleiche Umgebung. Du kannst schrittweise anfangen – z. B. nur mit einem OTA-Block – und später weitere Blöcke (Monitoring, Security, Backups) ergänzen.

Weitere Fragen? Siehe unsere FAQ

Von der Routine zur reproduzierbaren Flotte

In diesem Beitrag hast du gesehen, wie du aus einer unübersichtlichen Sammlung von Edge-Nodes eine steuerbare Flotte machst:

Du verwaltest Raspberry Pis und andere Edge-Nodes zentral über ein YAML-Inventory.
Du nutzt einen Polycrate-Block, um wichtige Routineaufgaben wie OTA-Updates und Konfigurations-Deployments zu kapseln.
Du führst alles mit einfachen Befehlen aus, ohne dich mit Ansible-Installationen und Python-Versionen herumschlagen zu müssen.
Du profitierst von eingebauter Workspace-Verschlüsselung und einer klar strukturierten, teilbaren Automatisierung.

Für viele IoT- und OT-Teams ist genau dieser Schritt entscheidend:
Weg von „jemand loggt sich ein und macht das schon irgendwie“ – hin zu nachvollziehbaren, versionierten und wiederholbaren Abläufen, die auch in einem Jahr noch funktionieren und prüfbar sind.

Bei ayedo unterstützen wir dich genau dabei:

mit praxisnahen Workshops zu IoT- und Edge-Automatisierung (inklusive Hands-on mit Polycrate und Ansible),
mit vorkonfigurierten Blöcken für typische Aufgaben wie OTA-Updates, Logging, Monitoring und Security,
und mit individueller Beratung, wie du Polycrate in deine bestehende OT- und IT-Landschaft einbettest – von der Fabrikhalle bis zur Cloud.

Wenn du deine eigene Edge-Flotte strukturiert und sicher automatisieren möchtest, starten wir am besten gemeinsam mit einem fokussierten Workshop – Übersicht und Anmeldung: Workshops.