etzeste Posted June 6, 2023 Share Posted June 6, 2023 Hallo, ich möchte mal gerne eine allgemeine Frage zum Thema Docker oder VM stellen, einfach weil ich speziell zum Thema VM noch wenig Erfahrung habe. Ich überlege auf meinem Unraid-Server zukünftig meinen IOBroker Master laufen zu lassen. Aktuell läuft der IOBroker gemeinsam mit Grafana InfluxDB und Redis auf einem RasPi4. Grundsätzlich läufts, nur wirds langsam etwas träge da die Datenbanken usw laufend größer werden. Bisher wollte ich eigentlich alles über Docker Container abbilden und über ein MCVLAN verbinden. Das hätte aber den Nachteil, dass alle Anwendungen dann eigene IPs erhalten, und bei den ersten Tests nicht mehr ohne weiteres aufeinander zugreifen können ( warum auch immer) Jetzt hatte ich die Idee vlt eine Debian oder Ubuntu VM aufzubauen, und alle die Anwendungen wie auch bisher auf einem System als "localhost" laufen zu lassen. Dann müsste ich eigentlich alle Einstellungen vom RasPi 1:1 übernehmen können und ich hoffe das alles funktionert. Soweit meine Theorie. Nun meine Fragen: Würdet Ihr diesen Weg auch gehen? Ist so eine VM von den Ressurcen (Stromverbrauch) wessentlich schlechter als Docker oder egal? Gibt es generell einen Vor-Nachteil den ich nicht bedenke? Freue mich schon auf eure Kommentare. vG Etze Quote Link to comment
Archonw Posted June 6, 2023 Share Posted June 6, 2023 Hi, grundsätzlich halte ich es persönlich so, dass alles was ich in einem Docker laufen lassen kann auch so betreibe. Denn, Vm trieben den Stromverbrauch spürbar in die Höhe solange diese laufen. Zu dem Docker IP Problemen: Du kannst natürlich auch Docker im Bridge Mode laufen lassen. So laufen die Docker alle auf der selben IP. Ob es im Fall von IO-Brocker generelle Bedenken beim Dockerbetrieb gibt kann ich leider aus mangel an Erfahrung damit nicht sagen. Ich würde es mittels Docker machen. Quote Link to comment
FailX Posted June 6, 2023 Share Posted June 6, 2023 Hi, ich habe vor 2 Monaten von einer VM zum Dockerbetrieb umgestellt. Es läuft aufjedenfall Stromsparender, das einzige was etwas nervt ist das wenn's mit irgendwas Probleme gibt und man sich dann im Iobroker Forum meldet die Pauschale Aussage kommt der Docker ist schuld. Beim Backitip Adapter gibts im Dockerbetrieb noch Probleme beim SQL Backup und Restore bei Postgresql aber da bin ich dran. Sonst läuft bei mir alles. Teste es einfach mim Docker aus und wenns nicht zufriedenstellend läuft setz ne VM auf. Grüße Quote Link to comment
etzeste Posted June 6, 2023 Author Share Posted June 6, 2023 Hallo, besten Dank für Eurer Feedback. @FailX Wenn du sagst es läuft in jedem Fall stromsparender, von was reden wir da? aktuell brauchen ich ca 10-12W im Idle wenn nur der Portainer Docker läuft. Was braucht die VM laut eurer Erfahrung? Quote Link to comment
Archonw Posted June 6, 2023 Share Posted June 6, 2023 Ich hab mal testweis meine Windows 10 VM laufen lassen. Nach ein paar Minuten hab ich zwischen 20-30 Watt im Idle mehr Verbrauch. Mit diversen Docker hab ich sonst so um die 20W. Gesendet von meinem Pixel 6 Pro mit Tapatalk Quote Link to comment
alturismo Posted June 6, 2023 Share Posted June 6, 2023 4 hours ago, etzeste said: Was braucht die VM laut eurer Erfahrung? starte doch eine und du siehst es ... das ist einerseits hardware abhängig usw usw ... kommt es noch auf die VM an, Win, Linux, ... 8 hours ago, etzeste said: Jetzt hatte ich die Idee vlt eine Debian oder Ubuntu VM aufzubauen die schlucken in der Regel etwas mehr als eine Win VM aber dafür gäbe es noch LXC zur Info ... ist ein Plugin um beispielsweise einen LXC Debian Container laufen zu lassen und du installierst da dann alles rein ... wäre die leichtere Variante zur VM und flexibler als Docker bei Bedarf ... 8 hours ago, etzeste said: dass alle Anwendungen dann eigene IPs erhalten, und bei den ersten Tests nicht mehr ohne weiteres aufeinander zugreifen können ( warum auch immer) das ist ja gerade das Charmante an br0, du hast sicherlich bei den Ports die gemappten (die für den bridge mode gelten) genommen und nicht die nativen ... im br0 mode gibt es kein port mapping ... Zum Schluss, 10 Leute, 10 Meinungen ... das wirst du schon selbst entscheiden müssen und das Schöne ist doch jetzt, sammel selbst deine Erfahrungen, ist ja schnell gewechselt um jetzt auf die Schnelle zu schauen was für Dich die bessere Variante ist. Docker, VM, LXC ... Quote Link to comment
etzeste Posted June 7, 2023 Author Share Posted June 7, 2023 @alturismo besten Dank für dein Feedback!! an LXC hatte ich bisher noch gar nicht gedacht....klingt von der Idee aber interessant. Werde mich da mal einlesen und dann probieren was am besten für meine Ansprüche läuft. Danke nochmal und ich werde berichten sobald ich Erkenntisse habe. bzgl Docker und dem br0 das du ansprichts verstehe ich leider nicht. Was meinst du damit? Ich habe bei meinen Test mit Docker die Container mittels eines Stacks aufgebaut und in diesem Stack ist auch die Definition eines MACVLANs, das br0 als Parent hat. in dem Stack habe ich einige Ports gemappt, aber immer 1:1 also 8081:8081. ISt das falsch? oder vielleicht sogar unnötig? vG Quote Link to comment
alturismo Posted June 7, 2023 Share Posted June 7, 2023 1 hour ago, etzeste said: ISt das falsch? oder vielleicht sogar unnötig? obsolet ... sprich, hat keine Wirkung, im br0 mode hat jeder Docker ne eigene IP, einen eigenen Netzwerk stack und die Ports sind den laufenden Applikationen entsprechend offen ... zu mappen gibt es also nichts und hat auch keine Relevanz wenn was mapped ist. Prominentes Beispiel, Plex, nutzt nativ Port 32400 mapped (bridge mode) kannst du den ändern auf beispielsweise 123 > 32400, dann wäre Port 123 der Plex Port, wenn du jetzt den Docker umstellst auf br0 mode und das mapping belässt, dann ist das obsolet ... sprich, Port 123 ist "tot" und Plex ist normal über Port 32400 zu erreichen (unter der vergebenen IP). hoffe das war verständlich Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.