UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[kaile45]

Hallo,

Gibt es einen Unterschied zwischen der Installation von ioBroker auf einer VM und auf einem Docker? Was macht da mehr Sinn? Ich bin mir nicht ganz sicher was für mich am besten/unkompliziertesten wäre, da ich noch sehr neu auf dem Gebiet bin.

[Codierknecht]

@kaile45
Nur mein gefährliches Halbwissen und auch nur ganz rudimentär:
Eine VM emuliert eine komplette Maschine. Das heißt, dass Du u.a. auch selbst für die Administration derselben verantwortlich bist.
Ein Docker abstrahiert das vorhandene OS und ist dadurch wesentlich schlanker.
Wenn Du ein ":latest" Image verwendest, sollte IMHO ein Neustart des Containers die Updates durchführen bzw. die letzte (und damit aktuellste) Version des Image ziehen.

Da ich von Linux so gut wie keinen Schimmer habe, habe ich mich für Docker entschieden (von dem ich ebenfalls nicht wirklich Ahnung habe).
Netterweise läuft das auf meinem NAS, das ja eh 24/7 läuft und sich sonst langweilt ;-)

[haus-automatisierung]

@kaile45 sagte in Unterschiede zwischen Docker und VM:

Gibt es einen Unterschied zwischen der Installation von ioBroker auf einer VM und auf einem Docker

Klar gibt es Unterschiede. Docker arbeitet mit Containern. Da werden die Ressourcen über den Kernel des Hosts geteilt. Bei einer VM hast du ein komplett eigenständiges Betriebssystem und die Hardware wird emuliert. Das heißt, dass Du z.B. auch Windows laufen lassen kannst. Das geht in einem Container nicht.

Das heißt: Wenn Dein Container nur 50MB RAM braucht, dann ist der Rest noch für andere Container verfügbar. Bei einer VM müsstest Du einen bestimmten Bereich reservieren (z.B. direkt 2GB).

Docker ist nur eine Container-Technologie von vielen. Dort packt man eigentlich einzelne Applikationen in eigene Container. Also z.B. ein Container für ioBroker, einen für den MQTT-Broker, einen für Node-RED, einen für InfluxDB, einen für Grafana usw.

Aber: Man sollte sich auf jeden Fall mit den Basics beschäftigen, um keine Daten zu verlieren. Also: Wie speichert man persistent Daten auf dem Host (Stichwort Volumes), welche Network-Modes gibt es, wie werden Ports gemappt usw.

Und ganz wichtig: Man sollte sich in jedem Fall trotzdem mit der Applikation auskennen, welche in den Container gepackt wurde! Viele denken immer, dass man dadurch nix mehr von irgendetwas wissen muss...

Man könnte z.B. zig Verschiedene Versionen der gleichen Applikation als Container auf dem gleichen Host starten, ohne dass diese voneinander wissen. Als native Installation eines Dienstes in einer VM ist das nur schwer möglich (kommt auf die Anwendung an).

Genauso arbeitet man mit Containern komplett anders. Man geht z.B. nicht in einen Container und installiert da wild irgendwelche Pakete nach oder aktualisiert von Hand die nodejs-Version.

[Codierknecht]

@kaile45

@haus-automatisierung sagte in Unterschiede zwischen Docker und VM:

Docker ist nur eine Container-Technologie von vielen. Dort packt man eigentlich einzelne Applikationen in eigene Container. Also z.B. ein Container für ioBroker, einen für den MQTT-Broker, einen für Node-RED, einen für InfluxDB, einen für Grafana usw.

Man könnte auch sagen: Jeder Container löst seine eigenen Abhängigkeiten auf. Er abstrahiert das darunter liegende OS und bringt alles mit, was er für den Betrieb der in ihm laufenden Applikation so braucht.
Nicht mehr und nicht weniger,
Aber auch nur für seine Applikation. Benötigt man für z.B. einen Container mit Grafana jetzt eine Datenbank - z.B. MySQL - dann setzt man einen eigenen Container mit MySQL auf. Die beiden dürfen sich dann miteinander unterhalten.
Man sollte niemals, never, auf keinen Fall auf die Idee kommen, im Grafana-Container MySQL zu installieren!

@haus-automatisierung sagte in Unterschiede zwischen Docker und VM:

Aber: Man sollte sich auf jeden Fall mit den Basics beschäftigen, um keine Daten zu verlieren. Also: Wie speichert man persistent Daten auf dem Host (Stichwort Volumes), welche Network-Modes gibt es, wie werden Ports gemappt usw.

Wenn man das sauber aufgesetzt hat, sollte man jederzeit einen Container löschen und durch einen neuen ersetzen können. Man könnte jetzt dreist behaupten: Ein Container ist eine Art Schmalspur-VM zum Wegwerfen ;-)
In einer "echten" VM geht sowas nicht.

[haus-automatisierung]

@codierknecht sagte in Unterschiede zwischen Docker und VM:

In einer "echten" VM geht sowas nicht.

Ja, deswegen bin ich auch Fan von Docker und habe alle meine Webseiten usw. in Containern laufen. Ich weiß auch nicht, warum so viele lieber eine VM nutzen. Ist wahrscheinlich einfacher zu verstehen, weil es sich wie ein natives System verhält. Aber am Ende ist man damit auch nicht sehr flexibel.

Wenn man eigene Docker-Images schreibt, dann dokumentiert sich die Installation quasi selbst automatisch mit. Wenn man einen Dienst von einer VM auf eine andere umziehen möchte, ist das praktisch unmöglich und extrem individuell.

[Codierknecht]

@haus-automatisierung sagte in Unterschiede zwischen Docker und VM:

Ich weiß auch nicht, warum so viele lieber eine VM nutzen. Ist wahrscheinlich einfacher zu verstehen, weil es sich wie ein natives System verhält. Aber am Ende ist man damit auch nicht sehr flexibel.

Und ressourcenschonend auch nicht unbedingt ;-)

[Homoran]

@codierknecht sagte in Unterschiede zwischen Docker und VM:

ressourcenschonend

das ist bei heutiger Hardware aber eher akademisch

[Codierknecht]

@homoran sagte in Unterschiede zwischen Docker und VM:

das ist bei heutiger Hardware aber eher akademisch

Sehe ich etwas anders.
Einer VM muss ich z.B. explizit sagen, wieviel RAM sie sich krallen darf. Und die sind dann weg - ob die Maschine die gerade benötigt oder nicht.
OK, beim Plattenplatz ist das heute nicht mehr soooo kritisch, aber da gilt im Prinzip das Gleiche.

[Homoran]

@codierknecht sagte in Unterschiede zwischen Docker und VM:

Einer VM muss ich z.B. explizit sagen, wieviel RAM sie sich krallen darf. Und die sind dann weg - ob die Maschine die gerade benötigt oder nicht.

das wäre tatsächlich ein Hindernis bei Rechnern mit (zu) wenig RAM, aber meines Wissens kann man bei Proxmox den RAM überprovisionieren so dass die Summer des RAMs in allen VMs höher ist als das wirklich vorhandene. Proxmox verteilt es dann nach Bedarf.

Beim Plattenplatz darf man das jedoch auf keinem Fall machen und auch nicht den Eigenbedarf von Proxmox vergessen.