Blockly: mehrere Werte automatisiert per MQTT weiterleiten?

Nee, das ist scheinbar doch was anderes. Im Wiki steht sinngemäß, wenn man Docker verwenden möchte, solle man dies innerhalb einer VM tun.

Alternativ müsste aber auch Proxmox als Oberfläche gehen, dann per ssh aufschalten (ist ja auch nur ein debian System mit extra Funktionen), dann docker regulär installieren und die Weboberfläche mit https://www.portainer.io nachrüsten.

Genau, die war das. Super, danke!

Hast Du verschiedene Datenbanken? Bzw. warum eine VM für SQL, wenn es mit VE doch auch per Docker gehen würde? Ich hätte da Docker genommen und wüsste gerne Deinen Grund, das nicht zu tun.

Noch ein NUC dazu hätte ja schon was. Alleine schon für tvheadend (auf einem nur dafür genutzten Pi funktioniert Aufnehmen ganz gut, Streams im Netzwerk kann man aber vergessen).

Das mit den Containern habe ich da eben nur ganz schnell überflogen. Ist wohl fast wie ein Docker Container, bzw. ein seeeehr entschlacktes Grundsystem, auf das man alles selbst nachinstallieren muss. (ohne Gewähr)

DAS nervt mich bei Docker tierisch: wenn man sich mal per cli aufschalten will und ne Datei (die nicht auf einem externen Volume liegt) editieren muss. "Kein vim? Ach klar, muss ja 'vi' nehmen. Ach, auch nicht. Okay, also nano. Häh, das fehlt auch? Grrmpf". Da wäre ne VM dann manchmal doch praktischer

Nachtrag: Moment, in dem Beitrag nehmen die ja auch portainer als WebGUI für docker. Lag ich is gar nicht so falsch =)

Zudem kannst Du einen Docker Container sehr schnell neu aufsetzen, weil Du die Konfigurationsdateien (normalerweise) außerhalb des Containers lagerst. Wenn Deine SQL VM mal "abkackt", hast Du vermutlich sowieso ein Backup und kannst sie neu aufsetzen und danach das Backup einspielen.

Bei Docker würdest Du hingegen einfach einen neuen Container aufsetzen, die Konfigurationsdateien aus dem alten Ordner dem neuen Container "freigeben" (bzw. Du hängst halt den Ordner ein, geht auch nur mit Lese-Rechten), und schon läuft Dein vorheriges Setup.

Je nach Parametern kannst Du auch direkt beim Erstellen des Containers festlegen, was er tun soll (kommt natürlich immer drauf an, was der Entwickler des Containers programmiert hat). Durch sogenannte Environment Variables. Bei mysql kannst Du afaik sowas wie "docker run (... container, port, etc. ...) -E rootpasswort=unfassbargeheim -E database=meinedatenbank -E database=nocheinedatenbank (...)" eingeben. Dann erstellst Du keine leere mysql Instanz, sondern hast schon ein Root-Passwort und zwei Datenbanken ready, sobald der Container startet. Meine Syntax stimmt in dem Beispiel nicht, aber ich hoffe, man versteht, was ich meine.

Zudem kannst Du Docker Container untereinander verlinken. z.B. habe ich Grafana und Influxdb verlinkt. Wenn ich in Grafana auf eine influx Datenbank zugreifen will, muss ich nicht die IP des Containers eintragen, sondern so etwas wie http://tick_influx:8086 (wobei tick_influx der Name des Docker Containers von inflxudb ist und 8086 der Standard Port). Der Traffic verlässt dann auch gar nicht das Gerät, auf dem Docker läuft.

Gegenbeispiel

VM 1 192.156.100.1 mysql

VM 2 192.156.100.22 phpmyadmin

VM 2 greift auf VM 1 zu. Der Traffic geht dann von VM2 der VM Host Machine über den Router zurück zu VM 1 der Host Machine. Bei Docker spart man sich den "Umweg" über den Router und die Container kommunizieren direkt miteinander.

Kann sein, dass das je nach Hypervisor auch mit regulären VM möglich ist. Das brauchte ich bislang nie, deshalb habe ich es nie getestet...