Docker auf einem Industrierouter oder separates Edge Gateway: Wann gemeinsam, wann getrennt?

Stellen wir die Frage zunächst in einen realen Anlagenkontext. Im Schaltschrank ist bereits ein Industrierouter vorhanden, nun soll zusätzlich ein Protokollkonverter ausgeführt werden. Da der Router Docker unterstützt, wirkt es naheliegend, den Container dort zu betreiben: ein Gerät weniger, ein Stromanschluss weniger und weniger Verkabelung. Die Antwort ändert sich jedoch schnell, wenn es um eine lokale Datenbank, Videoanalyse oder eine Anwendung mit kontinuierlichem Log-Schreiben geht. Entscheidend ist nicht nur, ob der Container starten kann. Entscheidend ist, ob ein ausgelasteter Prozess, ein volles Laufwerk oder ein fehlgeschlagenes Upgrade gleichzeitig die Standortverbindung beeinträchtigen könnte.

Die wichtigsten Punkte

Der gemeinsame Betrieb ist oft sinnvoll, wenn die Ressourcengrenzen des Containers klar sind, nur begrenzt geschrieben wird, die Berechtigungen reduziert werden können und der Wartungszyklus dem Router folgen darf. Ein separates Edge Gateway ist die sicherere Richtung, sobald die Anwendung dauerhaft CPU oder Arbeitsspeicher beansprucht, größere lokale Datenmengen speichert, erhöhte Host-Berechtigungen benötigt oder ausfallen können muss, während das Netzwerk online bleibt. Die Reihenfolge der Entscheidung ist wichtig: Routing, verschlüsselte Tunnel, Firewall und Fernverwaltung zuerst absichern, die verbleibenden Ressourcen dem Container zuweisen und die Entscheidung anschließend mit Tests für Neustart, Stromausfall, Ausfall der Upstream-Verbindung und Rollback einer fehlerhaften Version überprüfen.

---

Nicht mit Docker beginnen, sondern mit dem Workload

Container können den Eindruck erwecken, dass ein Deployment fast abgeschlossen ist, sobald ein Image geladen wurde und ein Prozess startet. Tatsächlich ist das erst der Einstieg.

Zwei Ebenen werden leicht miteinander vermischt. Das Image beschreibt, wie eine Anwendung verpackt und auf ein Gerät gebracht wird; die Laufzeitumgebung beschreibt, wie sie tatsächlich ausgeführt wird. Die OCI Image Specification und die OCI Runtime Specification definieren diese Ebenen, beantworten aber nicht drei wesentlich praktischere Fragen: Wie viel Reserve bleibt auf dem Host? Wie viele Daten wird die Anwendung schreiben? Und lässt sich eine fehlerhafte Version sicher zurückrollen?

Betrachten wir die beiden Workloads aus dem Eingangsbeispiel. Ein Protokollkonverter mit begrenztem Datenverkehr, wenig Zustand und eng gefassten Berechtigungen kann ein guter Kandidat für den Router sein. Eine lokale Datenbank oder Videoanalyse belastet CPU, Arbeitsspeicher und Speicher dauerhaft, während der eigene Release-Zyklus möglicherweise nicht zum Firmware-Zyklus des Routers passt. Beide werden Docker-Container genannt, sind aus Sicht des Hosts aber völlig unterschiedliche Workloads.

Entscheiden Sie daher nicht anhand der Image-Größe oder allein danach, ob der Prozess startet. Erfassen Sie zunächst Dauer- und Spitzenlast, den Ressourcenanstieg beim Start, das tägliche Schreibvolumen, benötigte Schnittstellen und die geschäftlichen Auswirkungen eines Anwendungsausfalls. Wenn der Workload klar beschrieben ist, wird auch die Platzierungsentscheidung konkret.

Die Ressourcen des Routers gehören zuerst zum Routing

Ein Industrierouter ist kein kleiner Server, der ungenutzt auf Anwendungen wartet. Mobilfunksitzungen, Überwachung der Verbindung, verschlüsselte Tunnel, Firewall, Routing-Protokolle, Webverwaltung und Fernwartung nutzen seine Ressourcen bereits. Dass im Normalbetrieb Reserven sichtbar sind, bedeutet nicht, dass während einer Verbindungswiederherstellung, eines Tunnelaufbaus oder eines entfernten Firmware-Upgrades dieselben Reserven verfügbar bleiben.

Die offizielle Docker-Dokumentation zu Ressourcenbegrenzungen erklärt, dass ein nicht begrenzter Container mit anderen Prozessen auf dem Host um CPU und Arbeitsspeicher konkurrieren kann. Beobachten Sie bei der Bewertung die Netzwerkfunktionen im Normalbetrieb, bei Spitzenlast und während der Wiederherstellung. Prüfen Sie anschließend über die Management-Schnittstelle der Ziel-Firmware oder mit `docker info`, welche CPU-, Speicher- und cgroup-Funktionen tatsächlich vorhanden sind. Erst wenn die Ziel-Firmware die benötigten Kontrollen unterstützt, sollten Sie gemessene Grenzen für den Container festlegen. Ein Container, der läuft, ist nicht automatisch ein isolierter Container.

Arbeitsspeicher fällt eher auf; Speicherplatz wird leichter unterschätzt. Docker-Storage-Treiber verwalten Image-Schichten und die beschreibbare Schicht des Containers. Volumes trennen Daten, die erhalten bleiben müssen, vom Lebenszyklus eines einzelnen Containers. Dokumentieren Sie vor dem Deployment, welche Datenbank-, Cache-, Queue- und Konfigurationsdaten erhalten bleiben müssen und welche neu aufgebaut werden können.

Auch Logs sind Schreibvorgänge. Wenn das Gerät `json-file`, `local` oder einen anderen hostbasierten Logging-Treiber verwendet, belegen Standardausgabe und Fehlerausgabe fortlaufend lokalen Speicher. Eine Anwendung kann ein kleines Image besitzen und über mehrere Monate trotzdem eine große Log-Historie ansammeln. Die Image-Größe ist nur der Ausgangspunkt; dauerhafte Schreibvorgänge und das Wachstum im schlechtesten Fall kommen dem tatsächlichen Risiko an einem unbeaufsichtigten Standort näher.

Die Berechtigungen des Containers reichen bis zum Router

Container bieten nicht dieselbe Isolationsgrenze wie virtuelle Maschinen. Sie teilen normalerweise den Kernel des Hosts. Die Tatsache, dass eine Anwendung containerisiert ist, errichtet daher nicht automatisch eine unabhängige Sicherheitsgrenze zwischen Anwendung und Routing-System. Auf einem gewöhnlichen Server ist dieser Unterschied bereits wichtig; bei einem Industrierouter, der den Netzwerkpfad des Standorts steuert, wird er unmittelbar relevant.

Das Sicherheitsmodell von Dockers Daemon und Socket arbeitet normalerweise mit weitreichenden Host-Berechtigungen. Wer diese Komponenten steuern kann, muss als vertrauenswürdige Instanz behandelt werden. Wird der Socket in einen Business-Container eingebunden, eine ungeschützte Remote-API geöffnet, der privilegierte Modus aktiviert oder werden Host-Verzeichnisse unbedacht eingebunden, kann eine Schwachstelle der Anwendung die Containergrenze überwinden und den Router selbst erreichen.

Sicherer ist es, Herkunft des Images, Laufzeitbenutzer, Linux-Capabilities, Gerätezuordnungen, Netzwerkports und Einbindungen von Host-Verzeichnissen einzeln zu prüfen und jede Berechtigung auf das notwendige Minimum zu reduzieren. Wenn der eingesetzte Docker-Engine-Build seccomp unterstützt und der Host-Kernel die entsprechende Funktion aktiviert, begrenzt das Standard-seccomp-Profil die Systemaufrufe mit einer Positivliste. Prüfen Sie die tatsächlichen Security Options auf dem Zielmodell; gehen Sie nicht davon aus, dass jede Firmware gleich konfiguriert ist. `seccomp=unconfined` kann ein Kompatibilitätsproblem lösen, zugleich aber einen Teil der Sicherheitsgrenze entfernen.

Der NIST-Leitfaden Application Container Security Guide betrachtet Risiken von Image, Registry, Laufzeit, Host und Betrieb gemeinsam. Für ein Anlagenprojekt lässt sich daraus eine praktische Regel ableiten: Wenn ein Container nur Daten nach außen senden muss, sollte er Routing, Firewall-Regeln, Mobilfunkschnittstellen oder verschlüsselte Tunnel nicht verändern dürfen. Werden serielle Zugriffe, Raw Networking oder ein Host-Verzeichnis wirklich benötigt, müssen jede Berechtigung, ihr Zweck sowie das Entziehen der Berechtigung und die Wiederherstellung des Geräts dokumentiert werden.

Automatischer Neustart bedeutet nicht geschäftliche Wiederherstellung

Wenn der Container wieder den Status `running` erreicht, ist das zunächst beruhigend. Ist mit dem Neustart des Prozesses aber auch der Datenfluss zum übergeordneten System sicher wiederhergestellt? Nicht unbedingt.

Dockers Neustart-Richtlinien behandeln hauptsächlich das Beenden eines Containers und den Lebenszyklus des Daemons. Wenn eine Anwendung hängt, der Prozess aber weiterlebt, kann der Container weiterhin als laufend erscheinen. Bei wiederholten Abstürzen startet er möglicherweise nur immer wieder neu. Ein Healthcheck zeigt einen Teil des Zustands, ersetzt aber keine geschäftliche Prüfung. Mindestens drei Ebenen sollten geprüft werden: Läuft der Container? Ist die Anwendung gesund? Erhält das Upstream-System korrekte Daten? Gleichzeitig müssen Mobilfunkverbindung, verschlüsselte Tunnel und Fernverwaltung verfügbar bleiben.

Dasselbe gilt für Upgrades. Für Anwendungs-Image, Konfiguration, persistente Daten und Router-Firmware sollten klare Versionen und Rückfallpfade existieren. Vor dem Deployment müssen Sie beantworten, wo das vorherige Image liegt, wie eine fehlerhafte Version zurückgezogen wird, wie die Wiederherstellung nach einem Stromausfall während des Upgrades funktioniert und ob der entfernte Zugang erhalten bleibt. Ohne einen Engineering-Test auf dem Zielgerät sollten Sie diese Punkte als Validierungsaktionen kennzeichnen und geplante Wiederherstellungsfähigkeit nicht als bereits nachgewiesenes Ergebnis darstellen.

Wann Docker auf dem Router bleiben kann und wann es ausgelagert werden sollte

Auf dem Router bleiben kann eine Aufgabe mit klarer, enger Grenze.

Protokollanpassung, Datenfilterung, Statusmeldungen oder ein Monitoring-Agent passen gut, wenn die Last gering, die Spitzenlast messbar, die Persistenz begrenzt und der Berechtigungsumfang klein ist und wenn der Container gemeinsam mit dem Wartungsfenster des Routers aktualisiert werden kann. Der gemeinsame Betrieb spart ein Gerät ein und bringt die Verarbeitung näher an SPS, Messgeräte oder Kameras. Maßgeblich ist die Grenze der Aufgabe, nicht der Name der Anwendung.

Ein separates Edge Gateway ist sinnvoll, wenn die Anwendung bereits einen eigenen Lebenszyklus hat.

Eine lokale Datenbank, Videoanalyse, mehrere voneinander abhängige Dienste oder Software mit häufigen Releases und weitreichenden Geräteberechtigungen ist in der Regel keine kleine Router-Funktion mehr. Das NIST-Fog Computing Conceptual Model liefert den architektonischen Kontext für die Platzierung von Rechenleistung am Netzwerkrand. Durch die Auslagerung lassen sich die Auswirkungen von Host-Ressourcen, Firmware-Upgrades und Anwendungswartung auf die Fehlerdomäne aufteilen.

Ein zusätzliches Gerät schafft allerdings nicht automatisch Hochverfügbarkeit. Edge Gateway und Router können weiterhin dieselbe Stromversorgung, denselben Switch, dieselbe Upstream-Verbindung und dieselbe Management-Ebene nutzen. Diese gemeinsamen Fehlerpunkte müssen ebenfalls geprüft werden.

Fassen Sie die Entscheidung mit einer Frage zusammen: Muss die Mobilfunkverbindung, müssen verschlüsselte Tunnel und der Fernzugang zur Wiederherstellung verfügbar bleiben, wenn die Anwendung Ressourcen aufbraucht, ihr Image beschädigt ist oder ein Upgrade fehlschlägt? Wenn ja und das aktuelle Gerät keine ausreichende Isolation und Wiederherstellungsreserve nachweisen kann, sollten die Workloads getrennt werden.

Ein Gerät weniger ist ein Vorteil. Eine kleinere gemeinsame Fehlerdomäne ist das eigentliche Designziel.

Deployment vor dem Live-Betrieb validieren

Die Entscheidung aus dem Architekturdiagramm muss letztlich auf dem Zielgerät funktionieren. Erfassen Sie das genaue Modell, die Firmware, die Image-Architektur, normale und maximale CPU- sowie Speichernutzung, persistente Schreibvorgänge, Log-Wachstum, Ports und Geräteberechtigungen, Release-Häufigkeit und Wiederherstellungsziel. Fehlt eine dieser Angaben, lässt sich schwer beurteilen, ob ein Test tatsächlich bestanden wurde.

Führen Sie Fehlertests zuerst auf einem nicht produktiven Ersatzgerät oder in einer isolierten Laborumgebung durch. Exportieren Sie vor Beginn die Gerätekonfiguration und persistente Daten, bereiten Sie eine lokale Konsole oder einen unabhängigen Out-of-Band-Zugang vor und bestätigen Sie ein bekannt funktionierendes Image samt Rollback-Verfahren. Nutzen Sie für Speicherdrucktests kontrollierte Quoten und Warnungen; füllen Sie die Systempartition nicht wirklich. Stromausfalltests dürfen nur durchgeführt werden, wenn der Hersteller sie erlaubt, kein Firmware-Schreibvorgang läuft und eine lokale Wiederherstellung möglich ist. Lösen Sie jeweils nur einen Fehler aus und beobachten Sie Routing, Tunnel, Firewall und Fernverwaltung gleichzeitig.

Nach aktueller interner Produktbestätigung können alle Industrierouter der Wavetel-Serie 6 Docker ausführen. Für die Prüfung eines konkreten Modells kann die deutsche Übersicht zu industriellen IoT-Routern als Einstieg dienen. Wenn ein Projekt diese Serie bewertet, sollten vor der Auswahl eines konkreten Modells Image-Architektur, CPU- und Speicherspitze, erwartetes Schreibvolumen, Schnittstellenberechtigungen und Wiederherstellungsziel vorliegen. Mit diesen Angaben lassen sich Gerät und Validierungsplan aufeinander abstimmen.

FAQ

Welche Geräteinformationen sollten vor der Docker-Bereitstellung bestätigt werden?

Bestätigen Sie Zielmodell, Firmware-Version, CPU-Architektur, verfügbaren Arbeitsspeicher und Speicherplatz, Container-Laufzeit und Image-Architektur. Prüfen Sie anschließend Ressourcenbegrenzungen, Persistenzpfade, Log-Rotation, Berechtigungen für Geräteschnittstellen und Rollback-Verfahren. Erst zusammen mit gemessenen Workload-Kurven zeigen diese Gerätedaten, ob der gemeinsame Betrieb geeignet ist.

Wie viel CPU, Arbeitsspeicher und Speicherplatz sollte für einen leichten Container reserviert werden?

Es gibt keine einheitliche Zahl für jedes Image und jedes Modell. Messen Sie zunächst die Netzwerkfunktionen des Routers im Normalbetrieb und während der Fehlerwiederherstellung. Messen Sie anschließend Startspitze, Dauerlast, Log-Wachstum und Wachstum persistenter Daten des Containers. Beide Datensätze zusammen sollten die Reservierung bestimmen.

Kann ein Docker-Container Routing, verschlüsselte Tunnel oder die Upstream-Umschaltung beeinflussen?

Ja. Ein Container, der CPU, Arbeitsspeicher oder Speicherplatz erschöpft, das Host-Netzwerk verändert oder übermäßige Berechtigungen erhält, kann Netzwerkdienste auf demselben Gerät beeinträchtigen. Validieren Sie die tatsächlichen Auswirkungen mit kontrollierter Fehler-Injektion und Langzeitbetrieb auf Zielmodell, Firmware und Konfiguration. Ein erfolgreicher Containerstart reicht nicht aus.

Sollen Containerdaten in der Image-Schicht, einem Volume oder externem Speicher liegen?

Ein Image sollte erneut abrufbar oder reproduzierbar sein. Daten, die eine Neuerstellung, ein Upgrade oder das Löschen des Containers überleben müssen, sollten nicht nur in der beschreibbaren Schicht liegen. Verwenden Sie ein Daten-Volume oder einen externen Speicher, der auf Kapazität, Backup und Konsistenz nach Stromausfall ausgelegt ist.

Welche Signale sprechen für ein separates Edge Gateway?

Dauerhaft hohe Last, umfangreiche lokale Persistenz, mehrere voneinander abhängige Dienste, weitreichende Host- oder Geräteberechtigungen, ein unabhängiger Release-Zyklus und die Forderung, dass das Netzwerk bei einem Anwendungsausfall verfügbar bleibt, sind starke Signale. Ein separates Edge Gateway kann die Auswirkungen von Host-Ressourcen, Firmware und Anwendungswartung aufteilen. Gemeinsame Abhängigkeiten bei Stromversorgung, LAN, Upstream und Management-Ebene müssen jedoch weiterhin separat geprüft werden.