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.

  • Ich schweife mal mit ab:

    ProxMox VE mit Docker Containern


    Funktioniert eigentlich sehr gut. Ich habe bei mir aktuell einen Intel NUC mit 16GB Ram laufen, darauf eine VM für SQL, eine VM für ioBroker, eine VM für TvHeadend/Plex/Kodi und ein paar kleinere zum testen. Mit "Containern" selbst habe ich mich noch nicht beschäftigt, daher kurz in den Raum geworfen -> Unterschied zu einer VM? Ich habe als Unterbau für ioBroker Ubuntu Server gewählt (Bionic Beaver), für TvHeadend ein Debian Minimal Server, ebenso für SQL.

  • 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 =)

  • Bei mir ist der Grund warum ich mich für eine VM entschieden habe ganz einfach. Ich habe quasi ein zugeschnittenes Linux nach meinen Wünschen. Der zweite Punkt ist das ich mich mit der Thematik "Docker" noch nicht auseinander gesetzt habe. Sind Docker Container nicht so performance-lastig wie eine VM? Dann könnte ich z.B. meine SQL VM durch einen Container ersetzen. Naja, bei den VMs muss man ja auch viele Sachen händisch installieren (nano, mc, ntp usw.), aber genau das ist ja der Grund warum wir uns für "Bastellösungen" interessieren, oder? :-) Meine VM´s haben alle eine absolute Minimal Installation, wenn etwas fehlt wird es gezielt nachinstalliert.

  • 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...