Beiträge von tuxflo

    Ich bin mir nicht ganz sicher was du mit Konsole und Terminal meinst, aber falls du den Button innerhalb der Container Station meinst, dann kann ich dir sagen: nein das wird so nicht funktionieren. Der Button sorgt dafür, dass du ein Terminal innerhalb des jeweiligen Containers bekommst. Das ist zum Debuggen oder dem Kopieren von Daten aus dem Container geeignet, nicht aber um Docker oder docker-compose Befehle auszuführen.

    Gibt es eine Doku dazu wie ich über SSH auf die Qnap einsteige und mir z.B. config-files anlege für Container? finde dazu leider auch nichts

    Was genau soll es da groß zu dokumentieren geben? Du gibst ssh admin@meine_nas_ip gefolgt von deinem Passwort und schon bist du drauf. In aktuellen QTS Versionen wirst du dann mit einem Menü begrüßt, welches du über die entsprechenden Tastendrücke (q für quit, dann Y für yes) verlassen kannst. Danach kannst du einfach in das Verzeichnis wechseln, in dem du eine Config ablegen willst und dort dann z.B. das docker-compose File anlegen. Dann brauchst du nur noch ein docker-compose up -d aufrufen und fertig :cup:

    Die so erstellten Container werden nach dem initialen Start auch in der Container Station angezeigt und du kannst diese dort z.B. stoppen oder löschen.


    Update:
    Ich sehe gerade, dass man mittlerweile auch direkt in der Container Station GUI die docker-compose.yml eintragen kann. Du musst dich also theoretisch gar nicht mit SSH befassen.

    Wer kann mir hier helfen und/oder Tipps geben?

    Hast du dich mal im Terminal auf dem entsprechenden Container eingeloggt und mal geschaut, wie die Rechte bzw. Verzeichnisse innerhalb des Containers aussehen? In der Containerstation kannst du dass einfach per Klick auf "Terminal" machen, oder per ssh mit dem Befehel

    docker exec -it <Container_ID> /bin/bash.

    können zwei docker auf die gleichen pfade verweisen sodass man so ggf. ein fallback initiieren kann?

    Ja das können sie, es darf aber logischerweise immer nur ein Container gestartet sein, beide mit den gleichen Mountpoints gleichzeitig zu starten ist keine gute Idee. Aber ja, falls mit dem "neuen" Container was nicht läuft kannst du diesen einfach wieder stoppen und den alten anwerfen. Zumindest spricht aus Sicht von Linux und den Containern nichts dagegen, wenn sich natürlich in der Anwendung was grundlegendes wie ein Datenbankschema oder ähnliches ändert, ist das "Rollback" nicht so ohne weiteres möglich. Aber falls du diesen Fall auch noch abdecken willst, kopierst du dir einfach die Ordner die du in den Container reinreichst an eine andere Stelle.

    Kann ich das neue Image einfach reinladen und mit dem gestoppten Container geknüpfen

    Nein kannst du nicht, so funktionieren Container nicht. Was du stattdessen machen musst ist: den alten Container löschen, ein neues Image herunterladen (docker pull) und mit dem frischen Image einen neuen Container starten. Wenn alle entsprechenden Verzeichnisse auf den Host gemappt sind, wie du ja geschrieben hast, dann sollte das Problemlos so klappen.

    Ja, wollte dich genauso wenig zu irgendwas überreden, mir kamen die Vergleiche nur falsch vor und ich wollte das für Nachlesende nicht unwiedersprochen stehen lassen. Wenn du mit VMs besser zurecht kommst ist das auch vollkommen OK für mich.

    Für Administrationsaufgaben ist beides schnell genug, und für grafiklastige Anwendungen ist beides ungeeignet, da das NAS im Keller steht und keinen Monitorausgang hat.

    Das ist genau der Unterschied den ich hervorheben wollte: in der Linux Station kann man auf den Modellen mit HDMI Ausgang durchaus normale "grafiklastige" Anwendungen verwenden wenn man einen Monitor anschließt und das eben möchte. Ich schaue darüber jeden Abend fern (TV Livestreams, Netflix, Mediathek und Co) und spiele ab und an sogar Computerspiele darauf, auch wenn die schon etwas betagter sind (via RetroPie auf Super Nintendo und N64 Emulatoren).
    Solche Sachen sind mit der Linux Station duch die bessere Resourcennutzung eben möglich und mit einer VM eben nicht :)


    Eine Sache die mich an der Implementierung der VMs im QTS noch massiv gestört hat ist, dass dort USB Geräte nicht automatisch erneut zugewiesen werden, wenn die VM bzw. das NAS mal aus war. Das ist zum Glück bei der LS auch nicht der Fall, alles was dort in der entsprechenden Konfigurationsdatei hinterlegt wird ist auch Reboot-resistent.

    Ich musste Ubuntu, Linux Station löschen, einen neuen virtuellen Switch anlegen, LS und Ubuntu neu installieren

    Keine Ahnung was da schief gelaufen ist, aber ich kann dir versichern, dass diese Probleme rein gar nichts mit KDE zu tun haben.

    Also KDE nicht möglich.

    Das ist schon ziemlich subjektiv, ich nutze die Linux Station quasi seit dem sie veröffentlicht wurde ausschließlich mit KDE und habe keine Probleme. Sowohl früher mit Ubuntu 18.04 als auch später dann mit 20.04.

    Diese Smartphone-GUI von Ubuntu kann ich nicht ausstehen,

    Es gibt in der Linux Welt auch nicht nur KDE und Gnome, sondern z.B. auch noch Xfce oder diverse Tiling Window Manager, dann hat man auch keine "Smartphone GUI".


    ist bei einem NAS ohne Grafikkarte und ohne Bildschirm ohnehin nicht sinnvoll)

    Genau das macht aber den größten Unterschied aus. Während die Linux Station mit einer grafischen Benutzeroberfläche ganz gut nutzbar ist (bei mir ist das quasi mein "Fernseher") sieht die Sache bei einer ausgewachsenen VM deutlich anders aus. Das Windows, was ich in einer VM betreiben muss um meinen Scanner verwenden zu können ist um ein vielfaches träger und langsamer als die Linux Station. Du siehst ja Windows als einen Vorteil der VM und da frage ich mich schon wie du das komplett ohne grafische Benutzeroberfläche verwalten willst.


    Auch denke ich, dass man eine VM leichter auf ein anderes NAS oder einen anderen Rechner übernehmen kann.


    Denken != Wissen. Einen exportierten Container kann man genau so einfach auf ein anderes System migrieren und hat dabei sogar noch den Vorteil, dass die Dateigrößen des Exportes in der Regel wesentlich kleiner sind, weil sie sich besser komprimieren lassen und nur den Speicher einnehmen, der auch belegt ist.


    Daher meine Antwort: verallgemeinere persönliche Probleme nicht auf ganze Technologien und habe kein blindes Vertrauen in Werte, die dir Benchmarks liefern es gibt z.B. auch Benchmarks die deutlich zeigen, dass Containertechnologien deutlich performanter sind als Vollvirtualisierungen (https://de.slideshare.net/Bode…nchmarking-with-openstack), was ja auch logisch ist, wenn man bedenkt, dass ein Container nicht noch Geräte emulieren muss und einen eigenen Kernel bereitstellen muss.

    Ich würde beim Thema VPN empfehlen einfach ein weiteres Gerät zu verwenden und die notwendige Freigabe dann darauf einrichten. Dann ist zumindest das NAS nicht "direkt" über das Internet zu erreichen. So ein Gerät kann z.B. ein Raspberry Pi sein, der mittels PiVPN die Verbindung bereitstellt. Als Protokoll würde ich Wireguard empfehlen. Da gibt es Clients für alle Betriebsysteme (auch Android und iOS) und weil Wireguard "Romaning" beherrscht, bemerkt man gar nicht, dass man sich nicht im Heimnetz befindet.


    Als DynDNS Privider nutze ich Dynv6 mit einer eigenen Domain.

    Aber mit Treibern hat doch ein Docker Container auch gar nix am Hut. Der verwendet ja den Treiber von Hostsystem. Ich würde eher vermuten, dass es an irgendwelchen Rechten auf dem Device liegt. Andre77 bist du dir eigentlich sicher, dass --privileged ausreichend ist? Ich kenne es bisher nur in der Form --privileged=true.

    Also wenn die Container einmal gestartet wurden, tauchen sie auch "ganz normal" in der Container Station auf und können dort z.B. gestoppt oder neugestartet werden. Es wäre also nur das initiale docker-compose up was du per SSH machen müsstest.

    Also im Verzeichnis der Container Station habe ich kein Repo hinterlegt. Eigentlich spielt das Verzeichnis auch gar keine Rolle, denn er liest ja nur bei der Erstellung der Container die Konfiguration ein und legt dann die Container in deinem Standard Pfad an, also unter einem "normalen" Linux irgendwo unter /var/lib/docker und im QTS eben unter dem Pfad der Container Station. Du könntest sogar eine ganz normale Ordner Freigabe, wie z.B. den Public Ordner, nehmen, von deinem Rechner aus editieren und dann einfach nur auf dem NAS docker-compose up ausführen.

    Ok mit Remote Zugriff ist also der Webserver/Client gemeint, das war mir vorher nicht so klar. Tatsächlich benötigt der wirklich ein paar mehr Ressourcen, bei mir dauert dort die Erstellung der Vorschaubilder immer recht lang. Aber auch hier direkt nochmal der Hinweis: nur weil es möglicherweise "Remote Zugriff" heißt, sollte man den Dienst keinesfalls "einfach so" von außen zugänglich machen. Auch für diesen Einsatzzweck könnte die von mir oben genannte VPN Lösung hilfreich sein.

    Allerdings möchte ich auch schon gerne von unterwegs auf meine Dokumente zugreifen, was hier durch die Ausstattung der kleinen Beere wohl als erschwert anzusehen ist.

    Den Zusammenhang verstehe ich nicht so ganz. Was hat denn der Zugriff von außen mit der Leistungsfähigkeit des Raspis zu tun?

    Ich würde sogar behaupten, dass der Zugriff mit einem Rapsi einfacher ist, weil du dort mit Wireguard/piVPN ziemlich einfach ein VPN einrichten kannst, mit dem du dann sicher von außen auf die Dienste in deinem Heimnetz zugreifen kannst. Dieses Verfahren würde ich dir selbst mit dem neuen NAS ans Herz legen, bitte nicht "mal eben Portfreigaben an das NAS einrichten, damit man von außen zugreifen kann".


    Ich habe übrigens ein 251+ und war anfangs auch vom hohen Einstiegspreis abgeschreckt, muss aber jetzt nach einigen Jahren sagen, das es sich gelohnt hat.

    In der docker-compose.yml ist bei "app" der Port 80 vom Host auf den Port 80 vom Container gemappt. Ich vermute mal, dass Port 80 bereits von QNAP verwendet wird. Teste dort mal ob du z.B. Port 8888 nehmen kannst und dann über http://nas-IP-Adresse:8888 zugreifen kannst.

    Was genau hat denn deine Frage mit der Linux Station zu tun? Ich glaube es könnte sinnvoll sein diesen Beitrag zu verschieben.

    Müßte ich da am besten die IP Adressen der Clients freigeben oder noch besser

    IP-Adressen Bereiche ?

    Wenn du deinen Netzwerkteilnehmer:innen nicht vertraust, dann ja. Die Abgrenzung von IP Adressen ist ein zusätzlicher Schutz. In den meisten Heimnetzen ist das aber gar nicht möglich, weil dort die IP Adressen per DHCP zugeordet werden.


    Zur Frage ob NFS oder Samba: ich glaube heutzutage sind die Unterschiede ziemlich gering, es hält dich also nicht wirklich etwas davon ab auch mit dem QNAP NAS Samba zu verwenden.


    Zur Frage der Version: das kommt halt auf deine Clients an, aber ja in der Regel ist v4 schon eine gute Wahl, weil dort nützliche Features, wie z.B. server side copy, mit enthalten sind.


    Generell gibt es beim Thema NFS noch zu erwähnen, das der jeweilige mount im Kernel stattfindet. Das hat zwar den Vorteil, dass es äußerst performant sein kann, aber auch den entscheidenden Nachteil, dass die Systeme sich äußerst merkwürdig verhalten können, falls der Host mal nicht erreichbar ist. Das ist für mich der Grund warum ich auch auf Linux Systemen fast ausschließlich Samba einsetze.