Homeserver mit zwei virtuellen Maschinen statt NAS und Raspi

Ganze VMs halte ich für übertrieben. Warum kein Docker?

Ja wieso kein Docker. Habe unRaid auf meinem Server laufen. Hatte mal piHole am laufen(fand es aber nervig) aber es lief super.
Und wenn du so auf VM stehtst kannst du diese auch unter unRaid laufen lassen. Habe selber eine NOTfall Win10 VM am laufen wenn ich mal an meinem Main PC am schrauben bin.

Würde tatsächlich auch eher auf Docker gehen, anstatt auf einzelne VMs

Btw: Warum ist FHEM bei Dir so schwer neu einzurichten? Wenn Du den kompletten /opt/fhem Ordner regelmäßig sicherst ist es meist nur eine Sache von Minuten es wieder lauffähig zu bekommen.

Also eigentlich ist docker viel robuster, wenn du die Configordner nach außerhalb mappst. Und wenn du ein unraidsystem benutzt ist das installieren eines dockers nicht schwieriger als irgendwas aus einem beliebigen softwarestore zu installieren

Das Geld für unRaid auszugeben lohnt sich nur wenn man das System auch gleichzeitig als NAS verwenden will.
Um ein paar Docker laufen zu lassen kann man auch einfach z.B. ein Ubuntu 18.04 nehmen.
Man sollte sich aber dann auch mit der Kommandozeile auseinandersetzen, ein Linux Server braucht keine GUI da sich das meiste schneller und einfacher per SSH erledigen lässt.

Ausserdem kann man Sachen wie Pihole auch ganz Wunderbar nativ (ohne Docker etc.) auf so einem Server laufen lassen. Man muss vorallem im Heimeinsatz nicht alles Containerisieren.

Nix dagegen da auf Ubuntu zu setzen. Der Vorteil der Container ist halt das man für sein Programm eine definierte Umgebung hat. d.h. man zerstört sich sein Grundsystem nicht wenn man mal etwas ausprobiert.

Wenn man was ins heimische LAN verfügbar machen möchte, muss man halt über Lösungen wie MACVLAN nachdenken aber auch das ist kein Hexenwerk.

Docker ist <zensiert>. Was will ich denn die ganzen revisions mit mir rumschleppen und nur komplett muehsam in eine shell in den container reinkommen und mounts haben mit 100 zeichen langen hex-namen. Am ende ist das auch nicht kleiner als eine VM weil man ja das komplette OS im docker container hat. Und wegen version tracking haeufig partial mehrfach. Docker ist in meiner begrenzten Erfahrung viel komplizierter als VMs und eigentlich erst sinnvoll wenn man viele container hat und die dauernd kompliziert pflegen upgraden/downgraden/entwickeln will. Dafuer wurde docker halt auch entwickelt.

Am einfachsten ist deswegen halt IMHO VM, und bei linux unter linux sollte das auch fuer I/O durchsatz mit den paravirtualisierten Treibern auch gut ohne Durchsatzverluste gehen. Da habe ich aber keine eigene Erfahrung.

Was ich mache ist eteas mehr bastelei: Haendisch chroot container aufzusetzen. Mein home-router ist ein j3160 4-lan luefterloser PC mit OpenWRT, und in sowas wollte ich nicht kvm oder GUI installieren. OpenWrt is ein minimales router-linux aber mit kompletten debian kernel. Da habe ich einfach ein komplettes debian in eine chroot Umgebung installiert, und darin halt alles was ich brauche. Derzeit halt bloss unifi controller software und lighttpd fuer externen zugriff auf eine USB platte. Das geht natuerlich auch beliebig mit mehreren solcher chroot-container. Und die kann man auch einfach mit rsync sichern, clonen, etc. pp. Alles was man bei docker neu lernen muss.

Und nachdem der Router eh laufen muss, ist das dann halt auch kein relevanter strom-mehrpreis. Ausserdem braucht die kiste eh bloss 10W im maximalfall.

te36 hast du emby selber laufen?
Ehrlich gesagt ist das NULL Hilfe zur Fragestellung sondern nur ein "Mimimi für mich geht das nicht".
Gerade für Emby ist Docker nur ein paar MB groß, da ist ne ganze VM für übertrieben.
Vor allem kann man leicht Pfade des Home Systems weiter reichen.
Emby auf nen Router ist untermotorisiert..

@witchking
Der Dockeraufruf sieht nicht so schlecht aus.
Wie rufst du den auf?

Zitat von SkyBird1980

te36 hast du emby selber laufen?
Ehrlich gesagt ist das NULL Hilfe zur Fragestellung sondern nur ein "Mimimi für mich geht das nicht".
Emby auf nen Router ist untermotorisiert..

Nee, kein Emby. damit hat der OP ja wohl auch Probleme. Ich habe mich nur auf Docker native bezogen.

Das ist ja schoen, wenn Emby die Nutzung von Docker vereinfachen kann (wenn ich das richtig verstehe), aber wenn mal was schief-geht und man troubleshooting machen will muss man ja doch docker verstehen. Deswegen mein (treffend von dir characterisiertes) "mimimi, docker ist mit kanonen auf spatzen schiessen".

Zitat von SkyBird1980

Nix dagegen da auf Ubuntu zu setzen. Der Vorteil der Container ist halt das man für sein Programm eine definierte Umgebung hat. d.h. man zerstört sich sein Grundsystem nicht wenn man mal etwas ausprobiert.

Das gilt aber noch mehr fuer VMs. Deswegen habe ich mich in dieser Diskussion halt auch mal fuer VMs gemeldet. Sag doch mal einen echten Vorteil von Docker gegen e.g.: VirtualBox fuer das Problem vom OP. Kleiner ist Docker nicht in meiner Erfahrung. Und resourcenschonender fuer die Anwendungen vom OP eher auch nicht.

Ansonsten war halt mein letzter Hinweis darauf bezogen, dass der OP sich ja um seine Stromrechnung sorgt, und deswegen der Ansatz halt alles als container in den router reinzuknallen, so wie ich das gemacht habe.

Zitat von te36

Sag doch mal einen echten Vorteil von Docker gegen e.g.: VirtualBox fuer das Problem vom OP.

Docker läuft mit einer definierten Umgebung für den Container, bzw andersrum der Container ist eine definierte Umgebung. Bei einer VM hat man immer seinen eigenen Patchstand.
Hatte ich aber auch schon in der von dir gequoteten Aussage schon angeführt.
Dazu ist ein Docker Recourcenschonender. Und zwar weil du in einer VM deine Recourcen ja normalerweise pro VM reservieren musst.

Zitat von SkyBird1980

Docker läuft mit einer definierten Umgebung für den Container, bzw andersrum der Container ist eine definierte Umgebung. Bei einer VM hat man immer seinen eigenen Patchstand.Hatte ich aber auch schon in der von dir gequoteten Aussage schon angeführt.
[quote]

Gib mal ein Beispiel, was Du mit "patchstand" meinst, das ist mir nicht klar.

Ein Container verwendet den Kernel vom Host, also ist erst mal der Container abhaengiger von Veraenderungen des Hosts als eine VM die ihren eigenen Kernel mitbringt. Paravirtualisierte Treiber machen diese Unterscheidung natuerlich schwieriger.

[quote='SkyBird1980','https://www.kodinerds.net/index.php/Thre…2404#post552404']
Dazu ist ein Docker Recourcenschonender. Und zwar weil du in einer VM deine Recourcen ja normalerweise pro VM reservieren musst.

Jo, aber wenn man da zwei "kleine-server-VMs" braucht ist das IMHO nicht relevant. Hatte ich ja auch andersrum schon gesagt (container sind prima wenn man skalieren will).

Wie gesagt, container selbst sind schon gut wenn man weiss was man damit kriegt. Die von mir beschriebene chroot-methode ist ja die trivialste container-methode. Mich nervt an Docker ja vor allem, das das ein Containersystem mit forciertem git-artigen versionsmanagement system ist.

Zitat von witchking

Nabend allerseits,

nachdem ja Docker diverse Male empfohlen wurde, dachte ich mir, probier es einfach mal aus. Leider komme ich Emby als Docker Container nicht zum laufen unter Ubuntu und hoiffe, dass mir jemand helfen kann.

Ich habe eine Anleitung gefunden die folgenden Befehl zum starten des Containers empfiehlt:

Code

docker run -d \
--name emby-server \
--restart unless-stopped \
--network="host" \
--volume /home/phoenix/embyconf:/config \
–-volume /mnt/Filme:/mnt/share1 \
--volume /mnt/Serien:/mnt/share2 \
--device /dev/dri/renderD128 \
--publish 8096:8096 \
--publish 8920:8920 \
--env UID=1000 \
--env GID=100 \
--env GIDLIST=100 \
emby/embyserver:latest

Alles anzeigen

Soweit ich das nachvollziehen konnte, ich habe das entsprechend meiner Bedürfnisse angepasst. Leider kommt immer die Meldung:
docker: invalid reference format.
was für mich jetzt ziemlich nichtssagend ist. Hat da jemand einen Tip?

Auf den ersten Blick sieht der Aufruf gut aus, aber irgendwas scheint mit der Syntax doch nicht zu passen. Ich kann es heute Abend bei mir auch mal ausprobieren.

Würde spontan mal versuchen, den Befehl komplett in eine Zeile zu packen und die Backslashes (" \ ") zu entfernen, vielleicht zickt es wegen den Zeilenumbrüchen rum. Die Anführungszeichen bei --network=host brauchst normal auch nicht zwingend, lass auch mal weg.
/dev/dri/renderD128 existiert so bei dir auch?

Generell: für dein Vorhaben finde ich Docker wie für gemacht. Die negativen Punkte von te36 kann ich absolut nicht nachvollziehen, liegt vermutlich (wie er selbst sagt) an seiner "begrenzten Erfahrung".

Zitat von olfolfolf

Generell: für dein Vorhaben finde ich Docker wie für gemacht. Die negativen Punkte von te36 kann ich absolut nicht nachvollziehen, liegt vermutlich (wie er selbst sagt) an seiner "begrenzten Erfahrung".

Meine erste Erfahrung mit Docker war halt, eine app die selbst vielleicht 50Mb gross war (Logitechmediaserver), die angeblich Ubuntu brauchte, unter Docker zu installieren, und dann war das Docker am Ende 1 GB gross. Dann die zweite App, die war nur 1 MByte gross, und der zweite Docker container war halt wieder 1 GByte gross. das war halt vor genug jahren, dass mit meine erste teure SSD ganz boese angeschaut hat ob des verschwendeten Plattenplatzes. Und dann habe ich muehseliv versucht unnoetiges aus dem Docker Ubuntu zu entfernen (via apt uninstall ode so), aber dadurch wurde halt das docker nicht kleiner, weil sich das halt wie git die historie gemerkt hat, also musste man da noch im docker die historie aufraeumen.

Wenn man da gleich weiss, dass man docker fuer apps nimmt, fuer die man auch unter docker einfach ein minimales linux installieren kann und dann auch keine fehler macht und mal was deinstalleren muss, dann ist dieses Problem erstmal nicht gegeben, aber dann will man vielleicht zum troubleshooten mal eine shell im container haben. Damit hatte ich dann auch probleme. Ging irgendwie wenn ich mich recht erinnere, war aber merkwuerdig/kompliziert.

@witchking
Wenn ich deinen run-Befehl copy & paste bei mir ausführe, bekomme ich den gleichen Fehler.
Die Syntax ist aber eigentlich ok..
Hab es mal runtergebrochen, muss irgendwo bei den Volumes liegen - aber keine Ahnung wo sich da ein böses Zeichen versteckt .. vielleicht würde ein Hex-Editor mehr zeigen, aber naja..das wird jetzt zu aufwändig.

Hab deinen Befehl nochmal kurz von Hand abgetippt, läuft jetzt. --publish hab ich direkt weg gelassen, benötigst du bei Verwendung des Host-Netzwerkes nicht.

docker run -d \
--name emby-server \
--restart unless-stopped \
--network="host" \
--volume /home/phoenix/embyconf:/config \
--volume /mnt/Filme:/mnt/share1 \
--volume /mnt/Serien:/mnt/share2 \
--device /dev/dri/renderD128 \
--env UID=1000 \
--env GID=100 \
--env GIDLIST=100 \
emby/embyserver:latest

@te36
Die Größe vom Container ist natürlich Abhängig davon, welche Anwendung im Container läuft und wie das Image gebaut wurde.
Mit Alpine als Basis z. B. würde es vermutlich deutlich kleinerer sein, als mit einem (kompletten?) Ubuntu.
Aber jeder wie er mag Ich find die Isolierung von Anwendungen in Container einfach super, die Anwendung (und all ihre Abhängigkeiten und was zur Ausführung benötigt wird) ist gekapselt und nichts kommt sich in die Quere. So schnell wie der Container gestartet ist, so schnell ist er auch wieder (rückstandslos) entfernt.
Ich denke bei Gelegenheit solltest du der Dockerei nochmal eine Change geben