Owntracks mit Gladys 4 nutzen!

Ich denke, man sollte eine Stufe höher nachdenken:

Warum verwenden wir Docker?

In Gladys 3 erinnere ich daran, dass wir Gladys direkt auf der Maschine ohne Docker ausgeführt haben, daher hatte Gladys Zugriff auf die gesamte Maschine.

In Gladys 4 verwenden wir Docker, um das Packaging, den Deployment und das Update der Gladys-Instanzen zu erleichtern. Da wir im Bereich der eingebetteten Systeme arbeiten und auf Peripheriegeräte (USB, GPIO, Kamera Pi über den Kamera-Bus zum Beispiel) zugreifen müssen, ist es durchaus sinnvoll, Gladys vollen Zugriff auf die Maschine zu geben, wie es der Fall wäre, wenn wir das Programm einfach direkt auf dem Raspberry Pi ausführen würden.

Wir sind nicht in der Situation eines Cloud-Providers, der die Ausführung von nicht vertrauenswürdigem Code isolieren möchte, den Zugriff auf die physische Maschine einschränken und die Ressourcennutzung eines Drittanbieters begrenzen möchte.

Hier führt der Benutzer auf seiner eigenen Maschine ein eingebettetes Programm aus, das intensive Nutzung externer Peripheriegeräte und Hardware erfordert. Im Gegenteil: Wir wollen die Superkräfte des Raspberry Pi nutzen und die gleichen Funktionen haben, als würden wir Gladys direkt auf dem Host wie die meisten Programme ausführen.

Wie @VonOx sagt, ist es optional, und wenn du Gladys in einem Rahmen verwendest, in dem du keine Hardware benötigst, kannst du die --privileged-Option entfernen. Der Gewinn an « Sicherheit » ist in diesem speziellen Anwendungsfall von Docker meiner Meinung nach eher gering oder sogar null. (Keine Verallgemeinerung, ich spreche hier von diesem Fall.)