Hallo,
ich nutze seit mehreren Jahren Fhem auf einem Raspberry 2. Das System ist Stück für Stück gewachsen. Und seine Aufgaben/Anforderungen. Nun möchte ich auf einen NUC umsteigen und würde mich über ein paar Empfehlungen zum Start freuen.
Ich nutze:
- Conbee Stick für Xiaomi,HUE und Osram
- Cul Stick für HM
- SignalESP für IT
- FTUI
- diverse Fhem Module.
Einige HowTos's habe ich mir angesehen und es gibt wohl viele Wege und Meinungen, ob ein LXC oder Docker Container verwendet werden soll.
Am meisten grüble ich über die Einbindung der USB-Sticks nach. Ist dies für alle ,,problemlos" möglich oder gehen nur bestimmte?
Und natürlich darüber welches Linux ich verwende und wenn die Entscheidung für Docker fällt welches der ,,fertigen" Docker Images ich verwenden sollte.
Angemerkt sei, dass ich das als Hobby sehe und mir mein Wissen erarbeitet habe so weit wie nötig. Also kein Profiwissen.
Ich würde mich über einige Erfahrungen und Empfehlungen von Euch freuen.
Marko
Ich habe mich auf dem NUC für LXC + VMs über Proxmox entschieden.
Gibt hier im Forum viele Beiträge zum Thema USB Stick durchreichen.
Bei Conbee braucht man eine echte VM, LXC geht hier nicht.
Wurde auch im Proxmox Forum schon erörtert.
Habe der VM dann erstmal nur 512MB RAM zugewiesen und das läuft problemlos, daher auch nicht so wild, dass es nicht per LXC ging.
Zu Docker kann ich wenig sagen, somit auch nichts dazu was die Vor- Nachteile von Docker vs. LXC sind.
Proxmox ist auf alle Fälle recht einfach einzurichten gewesen und es ist bei solchen Virtualisierungssystemen sehr angenehm,
dass man Systeme einfach kurz runterfahren und innerhalb 1-2 Minuten ein Backup / Restore machen kann.
Kein leidiger SD-Karten Ausbau + langwieriger Backup Prozess der dann viel zu selten durchgeführt wird. ;)
Moin,
ich kann Thyraz nur recht geben. Ich kenne Docker auch nicht, aber in Proxmox habe ich mich ruckzuck ohne Vorkenntnisse reingefuchst. Wenn man das Prinzip verstanden hat, ist es ganz easy.
Ich habe für jede Aufgabe eine eigene LCX oder VM. Je eine für FHEM, MySQL, Grafana usw.
Dann habe ich noch eigene LCX/VM für OwnCloud, Sqeezebox, eine Maschine nur zum Surfen usw.
Selbst für mein Onlinebanking läuft eine eigene VM mit Hibiscus Jameica (Oberaffengeil, das Teil).
Einfach mal probieren.
Viele Grüße
Ich habe mir vor einem Jahr bei esm-computer einen gebrauchten Fujitsu Esprimo Q520 Core i5 4590T 2,0 GHz für 225,- gekauft.
Und darauf die Konfiguration wie die anderen beiden hier.
Wegen Performance mach ich mir keine Sorgen und habe darum alles, was irgendwie was besonderes will, per VM gemacht weil per Container/LXC das für mein Halbwissen (würde das ähnlich wie das Erstellers bezeichnen) zu kompliziert war: Betrifft Sambafreigaben inkl. Netzwerkmount für einen kleinen Fileserver klein und das Durchschleifen von USB-Devices für FHEM: Jeelink, CUL868, ZigbeeStick
Als LXC glaube ich gerade nur PiHole.
Einmal die Woche wird ein NAS automatisch hochgefahren (Openmediavault) und Backups der Container und VMs gemacht bzw. der Fileserver rsync't sich.
Bei VM/docker besteht immer die Probleme, Hardware durchzureichen. Wurde hier schon erwähnt.
Vorteil von docker: Da keine "echte" VM, mußt Du Speicher nicht "verteilen".
Vorteil von VM: "echter" eigener Rechner mit beliebigem Betriebsystem
Ich persönlich würde bei "kleinen" Geräten auf Docker setzen und versuchen, die Hardware Netzerkfähig zu machen (kein Durchreichen der Hardware)... habe aber auch beruflich damit zu tuen.
Noch Ergänzung:
Hardware:
Warum NUC? Gibt so viele Anbieter für "kleine Rechner", NUC ist nicht der beste. Hier läuft z.B. Problemlos ein ZOTAC ...
Software:
Würde auf Ubuntu 18.04 Server 8Wichtig Server, also ohne Desktop) setzen. Alternativ Debian (Buster, aber nur wenn Hardware nicht zu aktuell) .... es gehen aber auch beliebige andere Distris ...
Was das "Durchreichen der Hardware" bei Docker angeht, ist das jedenfalls nach meinen bisherigen Experimenten mit deCONZ kein größeres Problem. Man muß halt nur - ähnlich wie bei den "by-id"-Definitionen in FHEM für mehrere USB-Geräte (oder der Erstellung von udev-Regeln) - wissen, was man eigentlich wo haben will.
Ich zitiere mich mal selbst:
Zitat von: Beta-User am 30 Juli 2019, 16:08:22
Geht wohl doch mit docker, man muß nur das Device "richtig" an den Container durchschleusen, was so zu funktionieren scheint:
docker run -d --name=deconz --net=host --restart=always -v /etc/localtime:/etc/localtime:ro -v ~/.local/share/dresden-elektronik/deCONZ:/root/.local/share/dresden-elektronik/deCONZ --device=/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE1234567-if00:/dev/ttyACM0 marthoc/deconz
Die by-id-Angabe muß dabei selbstredend an die richtige Seriennummer angepaßt werden...
Was NUC angeht, habe ich damit keine Erfahrung, aber hin und wieder gelesen, dass die jeweils neuesen Vertreter nicht immer gleich "Linux"-kompatibel sind. Das würde ich vorher abchecken, ansonsten war hier ja auch schon der Hinweis zu lesen, dass es ähnliche Geräte auch von anderen Herstellern gibt...
Zitat von: Wernieman am 16 Januar 2020, 10:11:32
Vorteil von docker: Da keine "echte" VM, mußt Du Speicher nicht "verteilen".
Vorteil von VM: "echter" eigener Rechner mit beliebigem Betriebsystem
Beim Einsatz von LXC hast du den Vorteil ja auch. Die Container teilen sich den Systemspeicher und belegen ihn nicht komplett wie eine VM. Sie haben eben nur eine Obergrenze wie viel sie maximal nutzen dürfen.
Du könntest also auf einem 16GB System 100 Systeme mit jeweils 2GB Obergrenze betreiben und hast erst dann Probleme wenn wirklich alle versuchend das auch auszunutzen. ;D
Proxmox hat halt den Vorteil echte VMs und diese Container sehr einfach unter einem Hut und einer Backup/Restore Lösung betreiben zu können.
Wer hat mehr als gefährliches Halbwissen zu Docker vs. LXC? ;)
Und nein, ein echter NUC muss es sicher nicht sein.
Gibt ja gerade im Bereich lüfterlos sehr nette Alternativen.
Ich hatte nur einen sehr günstig bei Ebay Kleinanzeigen geschossen.
Sollte ich anstatt Docker eher Container schreiben ;o)
Ich habe FHEM nativ laufen. Spart jede Menge Probleme beim Durchreichen der Hardware, auch SQL läuft bei mir nativ. Dazu denn noch Nextcloud. Alles andere denn in Docker-Containern.
Wobei das Durchreichen bei LXC im Container nicht schwer ist (und bei einer echten VM noch einfacher).
Im Forum sogar schon für die wichtigsten Geräte mehrfach als Vorlage verfügbar, so dass man nur noch USB IDs vom eigenen Gerät in die Befehle/Configzeilen einfügen muss.
Gerade bei FHEM mit all den nachzuinstallieren Paketen für diverse Hardware oder PERL-Funktionalitäten und Abhänigkeiten von allerlei Fremdsoftware (je nach eingesetzter Hardware im Smarthome) finde ich es angenehm hier für Backup/Restore und Systempflege gerade nicht auf das Hostsystem setzen zu müssen.
Änderungen im Container sind weit weniger riskant was Auswirkungen / Konflikte mit anderer Software angeht und Backup/Restore ist auch einfacher.
Ich habe seit 4 Jahren Proxmox auf dem Intel NUC und darauf eine echte VM laufen, in der wiederum Docker läuft. Docker deshalb, weil die Laufzeitumgebung halt (von mir selbst) damit unabhängig von der virtuellen Maschine an sich ist und man damit auch mal eben schnell die VM neu aufsetzen kann. Ist ist näher am "Infrastructure-as-Code" Ansatz dran, da ich sämtliche Konfigurationsdateien in einem Git Repository habe und die Docker Container sich eben aus der "Cloud" wiederherstellen lassen, um die exakt gleiche Laufzeitumgebung zu haben.
Die Gateway Kommunikation habe ich jedoch auf separaten Systemen belassen (RaspberryMatic, Phoscon/Conbee). Nicht so sehr wegen der Durchreichungs-Problematik, die habe ich testweise ohne Probleme gelöst. Viel mehr wollte ich einzelne Gewerke etwas voneinander trennen, so dass ein Grundbetrieb erstmal für die Gewerke immer gegeben ist, selbst wenn dann mal die Intelligenz für Automationen in FHEM, ioBroker, Node-Red, etc (halt alles, was auf dem NUC läuft) ausfallen sollte. Außerdem wollte ich von den einzelnen Projekten bzw. deren toller Ergebnisse und Entwicklungen wie RaspberryMatic und Phoscon vollständig profitieren. Ja, dort gibt es Entwicklungen diese auch auf dem NUC in Form von Docker oder piVCCU und wie sie alle heißen laufen zu lassen. Das sind aber Erweiterungsprojekte zu den ursprünglichen Projekten und der Fokus liegt dort eben aktuell und IMHO auch noch langfristig, dass Entwicklungen für die RaspberryPi's entwickelt werden.
Mir gehts also hier vor allem auch um maximale Flexibiltät und Redundanz zum minimalen Aufwand mit vertretbaren (Betriebs)Kosten.
Mag jeder sehen wie er mag - das ist zumindest mein Status Quo, ohne Anspruch auf Unveränderlichkeit ;-)
Hallo,
ich hole hier schonmal Popkorn raus. DEN Rat bezüglich was für die jeweilige Situation passt gibt es leider nicht. Fakt ist, bei vielen besteht anscheinend der Wunsch nach einem einfachen Backup und leichter Erweiterbarkeit besteht.
RasPi ist eine tolle Keimzelle, hat aber nur begrenzte Resourcen. Das hat bei mir vor 2 Jahren zu einem J1900 Board geführt. Ich nutze hier Ubuntu und Virtual Box um entsprechende Maschinen zu betreiben. ConBee, Rademacher und zWave laufen hier nebeneinander, die USB-Stick werden an die verschiedenen Maschinen weitergereicht.
Allein die Distribution ist eine Frage für sich, ich würde bei einem Neustart Debian wählen ;-)
Grüße Peter
Das ist ja das schöne an diesem Hobby .. verschiedene Wege führen "nach Rom" und keiner ist falsch (nur manchmal etwas umständlich)
Hallo
ich möchte auch auf ein NUC mit LXC wechseln. Derzeit nutze ich schon fleißig Docker, für meine Umgebung. Da ich gerne auch mal Probiere, und es hin und wieder zu Fehlern in der Programmierung kommen will, möchte ich gerne eine VM für verschiedene Betriebssysteme haben.
Daher wollte ich gerne wissen wie @Loredo, du dein System genau aufgezogen hast. Also was hast du genau in Git Repository hochgeladen?
Was genau benötigt man da für den Upload, um quasi ein "Backup" zu haben. Was schließt du alles aus?
Ich hatte es mal versucht, aber bin an den Log-Files gescheitert, und der Unwissenheit, was notwendig ist. Du scheinst ja schon länger damit zu Arbeiten.
Könntest du ein paar Infos geben, wie man vielleicht erstmal sinnvoll starten sollte, und was vielleicht typische Tücken sind?
Wäre echt Dankbar, für ein wenig Input.
Grüße
Zitat von: kotaro am 27 Januar 2020, 15:43:56
Daher wollte ich gerne wissen wie @Loredo, du dein System genau aufgezogen hast. Also was hast du genau in Git Repository hochgeladen?
Was genau benötigt man da für den Upload, um quasi ein "Backup" zu haben. Was schließt du alles aus?
Ich hatte es mal versucht, aber bin an den Log-Files gescheitert, und der Unwissenheit, was notwendig ist. Du scheinst ja schon länger damit zu Arbeiten.
Könntest du ein paar Infos geben, wie man vielleicht erstmal sinnvoll starten sollte, und was vielleicht typische Tücken sind?
Wäre echt Dankbar, für ein wenig Input.
Den Abschnitt über Git im README.md (https://github.com/fhem/fhem-docker#adding-git-for-version-control-of-your-home-automation-docker-containers) hast du gelesen?
Okay. Habe ich tatsächlich bisher übersehen, oder vergesse... Schande.. und danke für die Info. :)
Aber wie meinst du, das du LXC und eine echte VM am laufen hast?
Das habe ich irgendwie nicht so richtig verstanden O.o
Ich habe kein LXC, sondern Docker. Docker läuft in einer echten VM auf KVM/Qemu Basis.
noch eine kurze Verständniss-Frage
--> Wenn man ein Docker in einem LXC macht, ist es fast wie ein Docker im Docker?
und ist es damit vielleicht sinnvoller, eine VM zu erstellen, und dort seine Docker-Umgebung zu erstellen, oder habe ich dabei in meinem Zielsystem deutlich erhöhten Ressourcenverbrauch?
Welchen Vorteil hat es eigentlich ein LXC vs. VM zu erstellen, außer das ich mein Basissystem "Sauber" halte, da ich alle Umgebungen ja "löschen" kann, wenn ich sie nicht brauche, einfacher ein Backup erstellen, und im Notfall wieder zurückzusetzen/ auf einem neuen Rechner schnell aufzusetzen?
Vielleicht stelle ich mich auch einfach doof an, und denke falsch :o
Ohne es getestet zu haben bezweifel ich dennoch das man ein Docker in einem LXC installieren kann.
Linux Containers (LXC) ist eine Container Virtualisierung unter Linux.
Linux Container basieren auf Kernel Namespaces (http://lxc.sourceforge.net/index.php/about/kernel-namespaces/) für die Ressourcen Isolation und auf Cgroups (http://en.wikipedia.org/wiki/Cgroups) für die Ressourcen Limitierung. LXC kann sowohl für Applikations-Container als auch für komplette System-Container (unterschiedliche Linux Distributionen) verwendet werden.
Wikipedia erklärt eigentlich LXC relativ gut:
https://de.wikipedia.org/wiki/LXC