Einschränkungen (fehlende Parameter o.ä.) vorhanden?

[Marino]

Hi,

ich Überlege, ob ich mir eine Synology zulege. Eine 718+/918+ wäre es wohl.

Allerdings würde ich gerne Docker nutzen (mit der Hauptgrund für eine neue Synology) und müsste hierzu USB-Geräte dem Docker zuweisen. Nun habe ich schon schon mehrfach gelesen, dass Synology nicht alle Parameter unterstützt (z.B. hier: http://blog.pavelsklenar.com/how-to-install-and-use-docker-on-synology/). Allerdings nie mit offiziellen Quellenangaben und auch schon knapp 1,5-2 Jahre her. Vielleicht hat sich da ja etwas geändert.

Den Parameter "--device" würde ich z.B. dazu benötigen, um die USB-Devices weiterzureichen. Dann las ich, dass es mit privileged/hohe Priorität funktioniert, aber wohl nicht unbedingt einen Neustart übersteht, was ich ungünstig fände.

Wie ist das, kann man wirklich nicht alle Parameter nutzen? Und wenn ja, gibt es dazu eine offizielle Liste?

Oder gibt es da immer noch Probleme und die Synology wäre in Hinsicht auf Dockernutzung mit USB-Geräten, für mich die falsche Variante?

Ich hoffe, jemand kann ein wenig Licht ins Dunkel bringen, denn richtige Aussagen finde ich ansonsten kaum dazu.

Viele Grüße
Nils

 

[haydibe]

Synologies Docker ist
- veraltet: während Syno noch auf 17.05 rumlungert, ist der Rest der Welt schon bei 18.09 angekommen
- stark eingeschränkt: was die UI nicht kennt schmeisst sie aus der Container konfiguration + der Kernel enthält nicht alle für Docker notwendigen Kernel-Erweiterung´

Quelle: eigene Erfahrung!

Wann Docker wirklich der Hauptgrund ist, dann solltest Du lieber dein aktuelles NAS behalten und ein Intel NUC (NUC8i3BEK oder NUC8i5BEK, NUC8i7BEK lohnt den Mehrpreis nicht)..für den Einsatz mit Docker dazustellen. Damit hast Du deutlich mehr Dampf unter der Haube und kannst immer das aktuellste Docker-CE verwenden.

 

[Marino]

Komisch, meine Antwort ist verschwunden.

Danke für die Erfahrung. Unter diesen Gesichtspunkten liest sich das gar nicht mehr so gut. Docker scheint dann nett zu sein, wenn man eh die Hardware hat, aber wohl nicht, wenn man es dafür anschafft.

Muss man so etwas wirklich selber rausfinden, ohne dass Synology irgendwo darauf hinweist?

Danke auch für die Empfehlungen (NUC). Ich suche auch nebenbei nach NUC oder einem Board mit CPU, wie z.B. dem ASRock J5005.

 

[haydibe]

Die neue NUCs haben eine höheren Grundtackt als die älteren, plus Teilweise mehr Kerne Der i3-8109U hat 2 Kerne + HT (Passmark 6167), der 5-8259U hat 4 Kerne + HT (Passmark 10927). Beide CPUs besitzen ebenfalls eine iGPU, die bspw. bei Plex für Hardware-Transcoding verwendet werden kann...

Wenn man selber bastelt ist man zumindest flexibler, was die Erweiterbarkeit angeht. Nur Preislich wird es sicherlich nicht deutlich günstiger + der Strombedarf wird wohl eher nicht so gering ausfallen, wie bei den NUCs.

Zum Vergleich die Intel Celeron J3455 aus dem DS918+ hat 4 Kerne und einen Passmark von lediglich 2144 - und damit gehört sie bereits zu den stärksten CPUs im Segment der bezahlbaren NAS-Geräte.

Docker auf ner Syno ist ganz nett für die üblichen Server-Anwendungen, die neben CPU, RAM, Storage nichts weiteres brauchen... Beispielweise verbrauchen bitwarden_rs (die in Rust geschriebene alternativ-Implementierung der Bitwarden API) oder gitea kaum ressourcen.

 

[Marino]

Danke für die ganzen Tipps.

Da ich 2 Server habe, die ich bei Bedarf anschalten kann und welche noch >10TB frei haben und zudem mit ein bis zweifacher Parität fahren, habe ich mich gegen Synology und dem ASRock J5005 entschieden. Letztes ist momentan auch gerade nicht so toll verfügbar und ich hätte wieder ein Gehäuse benötigt, was auch nicht klein ist und und und.

Nun habe ich einen NUC8i5BEH mit 250GB M.2 und 8GB DDR4-2400 Ram. Ein weiterer 8GB passt noch rein. Dazu kommt noch eine 2TB 2,5" HDD. Leider scheint 2TB die Grenze zu sein, 3, 4 und 5TB immer gleich 15mm hoch sind und der NUC nur 9,5mm aufnehmen kann. 1TB ist davon schon belegt, schade, aber wenig benötigtes muss halt auf einen der beiden Server.
So habe ich Luft nach oben und extern kann ich ja auch noch eine HDD anschließen, zur Not.

Insgesamt hätte mich ein ASRock J5005 mit Gehäuse knapp 25% weniger gekostet, bei deutlich weniger Leistung, einem deutlich größeren Gehäuse, aber der Möglichkeit der Anbindung 3,5" HDD.

Nun muss ich nur noch rausfinden, wie ich (z.B. für Plex) die Freigabe der Server mounte (möglichst automatisch), wenn der NUC immer läuft, die Datenserver aber nur bei Bedarf...

 

[haydibe]

Gratulation. Das NUC8i5BEH ist schon eine ganz schöne performance Sau! Allerdings würde ich dem Teil eher schon zu beginn 16GB als einzelnes Modul zur Verfügung stellen, da Du die CPU jede Menge Container vertragen wird. Dann kannst Du bei Bedarf immer noch auf 32gb hoch gehen.

Der leichteste Weg um Freigaben in einen Container reinzubekommen ist über NFS (kann man im compose.yml direkt angeben!).
Ein weiterer Punkt ist, dass Remote-Shares die NACH dem Container-Start gemountet werden innerhalb eines Containers nicht sichtbar sind. Stell dir vor das ein Zeiger auf ein Verzeichnis in den Container gemapped wird. Wenn Du nun ein Remote-Share in ein Verzeichnis mountest, wird der Zeiger im OS ersetzt und man kann den Remote-Inhalt. Doch leider bekommt der Container nichts vom neuen Zeiger mit und kennt weiterhin nur den alten Zeiger... sprich: nur der alte Inhalt wird angezeigt. Nach einem Container-Neustart würde der neue Zeiger verwendet werden und der Inhalt des Remote-Shares zu sehen sein...

Ausgerechnet Plex kann es nicht leiden, wenn die Freigaben zwischendurch verschwinden - du musst dann in jedem Fall die automatische Bereinigung nach den Scans ausschalten.
Evtl. hilft es wenn die Mountverzeichnisse über unionfs abstrahiert werden und das unionfs Verzeichnis in den Container gemountet wird. Je nach Verfügbarkeit des NFS-Servers wären dann die darus bezogenen Verzeichnisse im Unionfs-Verzeichnis nicht verfügbar, aber der Zeiger auf das gemappte Verzeichnis wäre weiterhin valide.

 

[Marino]

Ich habe halt gedacht, dass das NUC8i3BEH knapp das gleiche kostet, wie der J5005 (mit allem drum und dran) und dass man dann nur 2 Kerne hat (+ HT). Wenn man visualisieren möchte, ist das dann irgendwann grenzwertig und später ärgert man sich immer, dass man nicht doch das bessere gekauft hat.

Installiert habe ich nun Ubuntu Server und brauche damit 1,3GB Ram bisher. Da ich eigentlich hauptsächlich Docker verwenden wollte, dachte ich 8GB reichen eigentlich und mit Option auf 16GB sollte locker reichen.

Mit compose.yml habe ih bisher nicht gearbeitet, hatte mir aber bereits überlegt, ob es nicht schlauer ist, wenn das im Docker erledigt wird, denn warum muss das Hostsystem unnötigerweise Zugriff haben?
Die Remoteshares wären ausschließlich nach Container-start gemountet, da der NUC durchläuft, ich den Plex-Docker nicht stoppen würde, die Datenserver aber ja aus sind, wenn nicht gebraucht. Also hätte das ja gar keinen Sinn.
Ich dachte bisher, dass autofs mit mount bei Zugriff funktionieren könnte. Das wäre mein nächster Punkt gewesen, den ich getestet hätte. unionfs kannte ich bisher nicht und muss mir das mal anschauen.

Die automatische Bereinigung muss unbedingt aus, sonst muss ich immer wieder alles neu machen, was nicht Sinn der Sache wäre.

Heute habe ich erstmal knapp 5h gebraucht, um nextcloud mit mariadb zum laufen zu bekommen. Ich weiß zwar immer noch nicht, warum ich einen User in mariadb anlegen muss, wenn ich nur Fehlermeldungen bekomme, wenn ich den wähle, aber mit dem root & root-pw der mariadb klappt es. Merkwürdiges Verhalten, aber ich dachte mir schon, dass ich möglicherweise länge brauche pro Docker.

Mich verwirrt auch noch ein wenig, dass man nicht in einem Docker (shell) alles installieren kann und die Befehle dafür genauso im dockerfile angeben kann. In der Shell funktioniert es und im dockerfile bekommt man Fehlermeldungen (beispielsweise bei apt-key).
Ich hatte bis dato noch den Glauben, dass ich die handvoll Befehle dann auch einfach ins Dockerfile packen kann, wenn es in der Shell funktioniert. Leider wohl nicht.

Morgen hole ich mir noch eine interne HDD. Dann kommen da die Daten drauf. Ich weiß nur noch nicht, wie ich die am besten im Netzwerk freigebe und User+Rechte vergebe. Da wäre eine Synology im Vorteil gewesen
Man könnte ja nun OMV installieren, allerdings soll so wenig wie möglich auf das System. Mit Docker wäre schon netter.

 

[haydibe]

Mit compose.yml habe ih bisher nicht gearbeitet, hatte mir aber bereits überlegt, ob es nicht schlauer ist, wenn das im Docker erledigt wird, denn warum muss das Hostsystem unnötigerweise Zugriff haben?
Die Remoteshares wären ausschließlich nach Container-start gemountet, da der NUC durchläuft, ich den Plex-Docker nicht stoppen würde, die Datenserver aber ja aus sind, wenn nicht gebraucht. Also hätte das ja gar keinen Sinn.

Im wahren Leben mounten man Ressourcen in den Host und reicht diese, sofern benötigt, in einen oder mehr Container rein. Wenn Du die Daten auf einen NFS-Server speichern würdest, dann kannst Du die bei der Einbindung über eine compose.yml das mounten auf dem Host sparen - das macht dann Docker alles für dich.

Heute habe ich erstmal knapp 5h gebraucht, um nextcloud mit mariadb zum laufen zu bekommen. Ich weiß zwar immer noch nicht, warum ich einen User in mariadb anlegen muss, wenn ich nur Fehlermeldungen bekomme, wenn ich den wähle, aber mit dem root & root-pw der mariadb klappt es. Merkwürdiges Verhalten, aber ich dachte mir schon, dass ich möglicherweise länge brauche pro Docker.

Ich wette mit dir, wenn du nach einer docker-compose.yml gesucht hättest, wäre dort eine sinnvolle Startkonfiguration, die Du hättest in Minuten anpassen können. Im wahren Leben startet keiner Multi-Container Anwendungen über die Kommandozeile, sondern mittels docker-compose.yml als "Docker Compose"-Stack oder als Swarm-Stack.

Update: https://docs.docker.com/samples/library/nextcloud/#base-version---apache
Damit wäre das setup deutlich schneller gegangen + Versionsupdates von Image = einfach nur das Image Tag aktualliseren und wieder `docker-compose up -d` abfeuern.

Mich verwirrt auch noch ein wenig, dass man nicht in einem Docker (shell) alles installieren kann und die Befehle dafür genauso im dockerfile angeben kann. In der Shell funktioniert es und im dockerfile bekommt man Fehlermeldungen (beispielsweise bei apt-key).
Ich hatte bis dato noch den Glauben, dass ich die handvoll Befehle dann auch einfach ins Dockerfile packen kann, wenn es in der Shell funktioniert. Leider wohl nicht.

In RUN deklarationen kommt nichts anderes rein als verkette Shell-Befehle. Warum sollte das Verhalten anders sein?! Zeig mal Dein Dockerfile.

Morgen hole ich mir noch eine interne HDD. Dann kommen da die Daten drauf. Ich weiß nur noch nicht, wie ich die am besten im Netzwerk freigebe und User+Rechte vergebe. Da wäre eine Synology im Vorteil gewesen
Man könnte ja nun OMV installieren, allerdings soll so wenig wie möglich auf das System. Mit Docker wäre schon netter.

Ehrlich gesagt kommt es drauf an wofür Du die Freigaben haben willst. Es gibt viele Spielarten. Ich würde z.B. einen NFS-Server auf der NUC installieren und die Freigabe in ein Unterverezichnis eines Syno-Shares mounten. Mein Windows Notebook kann dann über die Freigabe der Syno auf die Daten zugreifen.

 

[Marino]

Die compose.yml muss ich mir auf jeden Fall einmal anschauen. Die Startconfig war nicht das Problem. Eher die Tatsache, dass ich vorher kaum Dockererfahrungen hatte. Die MariaDB und Nextcloud hatte ich einmal auf unraid laufen. Da klappte es. Ich habe mir einen Benutzer und eine Datenbank erstellt und diese gewählt. Hier geht das ums biegen und brechen nicht. Ich kann nicht den user wählen, sondern nur den root-user der mariadb mit dem root-passwort. Bei unraid habe ich sicher den angelegten user gewählt. Ich weiß ja sogar noch, welches Tutorial ich dazu hatte. Nachdem das geschafft war, ging es am Mac, aber iOS wollte nicht. Kleinigkeiten immer, die einen aufhalten.

Dockerfile kann ich morgen mal zeigen. Ich habe das gerade in Bearbeitung und nach und nach getestet. Ist ein wenig wirr gerade und würde so nicht laufen. Ich bekam Fehlermeldungen bei den einzelnen Befehlen, die im Shell funktionierten. Aber das baue ich morgen nochmal zusammen, damit man sehen kann, warum das nicht ging. Ich hatte damit unter docker am Mac getestet. Als der NUC da war, wollte ich Erfolgserlebnisse und habe das hinten angestellt


Freigaben:
Viele Freigaben sollen es nicht sein. Audiodaten sollen freigegeben werden für einen Player (Moodeaudio auf Raspberry Pi und LMS) und Dokumente-Ordner sollen freigegeben werden. Audiodaten nur mit Leserechten und die Dokumente natürlich auch zum schreiben So, dass immer das wichtige zugreifbar ist, ohne einen der Datenserver zu starten. So in etwa soll das aussehen. Nichts wildes, 3-5 user mit Lese- bzw. Lese und Schreibberechtigung. Keine Quota o.ä. Die Synology mache ich aus, wenn der NUC läuft. Es gibt dann nur noch den NUC und die beiden Datenserver.
Hast Du zufällig Informationen bzgl. mounten in ein share eines anderen Gerätes?

 

[Marino]

Hi,

entschuldige bitte, ich kam nicht zum antworten bisher. Seit Wochen krank und in Elternzeit. Ein frohes Neues Jahr wünsche ich.

Also, ich habe mich nun in die docker-compose.yml eingearbeitet und alles umgestellt. Schneller ging es nun nicht, da ich mich dem Thema ja erst einmal widmen musste, aber nun geht es eigentlich, auch mit VLAN (Tagged) hat es funktioniert. Mariadb mit Nextcloud läuft nun, auch wenn ich das freigegebene Volume löschen muss, wenn ich den Container neu erstelle, was ja eigentlich nicht so gedacht ist, aber mir geht es ja hauptsächlich um die Erreichbarkeit meiner gespeicherten Daten zwecks und das klappt.

Samba-Freigabe habe ich nun hinbekommen und es laufen knapp 8 Container.

Nun habe ich mich dem Problem-Docker gewidmet, den ich ja schon angesprochen hatte und wo ich die Ausgabe posten wollte. Ich habe allerdings statt java in debian zu installieren, einfach das Image "java:8" genommen. Dann umschiffe ich die Fehlermeldungen teilweise
Die docker-compose.yml hat ja einen großen Vorteil: Mit "docker-compose down" löscht er gleich alles wieder. Praktisch, wenn es nicht geklappt hat. Mache ich das ausschließlich mit dem Dockerfile, muss ich alles manuell löschen. Und genau da ist der Knackpunkt. Die compose mag meinen Entrypoint nicht.

Was muss ich machen?
Ein Java-Programm starten. Dazu gibt es bereits eine sh-Datei, welche in einem Unterordner in /opt/ ist (#!/bin/sh).

Dockerfile:

COPY HeliosKwlRemote /opt/test (darin ist eine run.sh)
RUN chmod -x /opt/test/run.sh

(Ich habe auch "chmod -R 764" und "chown -hR root" probiert, ging auch nicht).

Fehler:
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: "/opt/HeliosKwlRemote/run.sh": permission denied": unknown.

Abhilfe:
packe ich die run.sh ins root, wird sie gestartet. Aber darin wird ein java-Programm ausgeführt, was keine Dateien findet. Es müssten also alle Dateien ins root. Irgendwie doof.


Lösungsansatz:
Nur eine sh ins root, welche die andere sh-Datei in /opt/test/run.sh ausführt und folgendes macht:
entrypoint.sh (im root):

#!/bin/sh
cd /opt/HeliosKwlRemote
sh run.sh

Damit umschiffe ich das Problem aber nur. Schöner wäre, wenn man die sh Datei einfach ortsunabhängig ausführen kann, denn sie muss an dem Ort bleiben, wo das Programm ist.


Starte ich nun ohne entrypoint und gebe im shell direkt als ersten Befehl ein: "sh entrypoint.sh" (diese wurde natürlich auch mit "chmod -x" ausführbar gemacht), startet die Java app. Die entrypoint.sh startet die /opt/test/run.sh und diese die app. Wunderbar.

Also "ENTRYPOINT ["docker-entrypoint.sh"]" ins dockerfile und build und run... läuft. Die app wird sofort gestartet.

Nun soll die docker-compose.yml nur noch das dockerfile ausführen: (andere Versionen funktionieren ebenso wenig)

version: '3.7'
services:
  test:
    build: .
    image: test_image
    container_name: java_test
    restart: unless-stopped
    #ports:
    volumes:
      #- /etc/localtime:/etc/localtime:ro
      #- /etc/timezone:/etc/timezone:ro
      - /opt/dockerfiles/test:/opt/test:rw
    #entrypoint: ./entrypoint.sh ist ja bereits angegeben im dockerfile

Das führt zum ewigen restart des containers und er funktioniert nicht.

Zuvor bekam ich auch die Meldung:

 sh: 0: Can't open run.sh

Komisch, denn die docker-entrypoint.sh scheint ja ausgeführt zu werden (beide sh sind #!/bin/sh).


Ich verstehe nicht, warum es manuell funktioniert, mit dockerfile auch, aber die compose das nicht mag.
Echt nervig so etwas.

 

[haydibe]

PEBKEC

Dockerfile:

COPY HeliosKwlRemote /opt/test (darin ist eine run.sh)
RUN chmod -x /opt/test/run.sh

Dir ist klar, dass Du das Vereichnis HeliosKwlRemote nach /opt/test kopierst, oder?
Damit wäre die Zeile danach `chmod +x /opt/test/HeliosKwlRemote/run.sh`

Alternativ änderst du die COPY-Zeile: COPY HeliosKwlRemote/run.sh /opt/test/run.sh

Je nachdem, ob Du vor dem Start der Anwendung noch Manipulationen an Konfigurationsdateien (propterties? xml?) vornehmen musst, würde ich ein Entrypoint-Skript verwenden ODER direkt den Kommandozeilen-Aufruf zum Start der Java-Anwendung als Entrypoint-Skript verwenden. Wenn Du dabei die Notation in eckigen Klammern beibehälst, dann startet die Anwendung als PID1 und der Container kann dann ohne weitere Bastelei sauber beendet werden.

Dein Dockerfile tut exakt das was Du angibst. Das Problem ist nur, dass Du glaubst das Ergebnis deiner angegebenen Befehle wäre anders, als sie es tatsächlich sind.

 

[Marino]

Ja, ist mir klar, denn neben der dockerfile und docker-compose.yml ist eben Ordner.

Oh, ich sehe gerade, was Du meinst. Ist richtig so. Ich hatte nur HeliosKwlRemote gegen "test" getauscht, um das hier einfach darzustellen. Dabei habe ich mich hier einmal vertippt und Dich verunsichert

Machen wir es richtig:
Dockerfile:

COPY HeliosKwlRemote /opt/HeliosKwlRemote
COPY HeliosKwlRemote/config.properties /etc/helioskwlremote/config.properties
COPY /init/docker-entrypoint.sh /

RUN chmod -R 764 /opt/HeliosKwlRemote/ && \
    chmod -x /opt/HeliosKwlRemote/run.sh && \
    chmod -x docker-entrypoint.sh

RUN apt-get update && \
    # apt-get upgrade -y && \
    # Upgrade dauert recht lange, da knapp 100 Pakete upgedatet werden. Also erst einmal ohne
    apt-get install -y ser2net && \
    apt-get clean

docker-compose.yml

version: '3.7'
services:
  kwl:
    build: .
    image: kwl
    container_name: kwl
    restart: unless-stopped
    #ports:
    volumes:
      #- /etc/localtime:/etc/localtime:ro
      #- /etc/timezone:/etc/timezone:ro
      - /opt/dockerfiles/KWL/opt/HeliosKwlRemote:/opt/HeliosKwlRemote:rw
      - /opt/dockerfiles/KWL/etc:/etc/helioskwlremote:rw
    #entrypoint: ./docker-entrypoint.sh ist ja bereits angegeben im dockerfile

Der Ordner HeliosKwlRemote wird also nach /opt/ kopiert und eine config dann daraus noch woanders hin (testweise). Anschließend die Rechte geändert und die "docker-entrypoint.sh" gestartet, welche die /opt/HeliosKwlRemote/run.sh" ausführt.

docker-entrypoint.sh

#!/bin/sh

cd /opt/HeliosKwlRemote
sh run.sh

run.sh

#!/bin/sh
JAVA=`which java`
echo "Using Java: $JAVA"
$JAVA -Djava.util.logging.config.file=log.properties -jar HeliosKwlRemote-1.0.0-SNAPSHOT-jar-with-dependencies.jar

Die "config.properties" muss einmalig angepsasst werden. Wenn die fertig im Ordner liegt, reicht das kopieren aus.

Den Code direkt als CMD direkt ausführen, habe ich bisher nicht geschafft, sonst hätte ich das gemacht. Ich muss, soweit ich das verstanden habe, aber im "/opt/HeliosKwlRemote"-Verzeichnis sein, da er sonst beim CMD im root nach dem Programm sucht es es dort nicht findet.

Was mir auch unklar ist, warum das dockerfile beim build und anschließendem run die docker-entrypoint.sh ausführt und damit dann die run.sh ausführt und das Programm startet, aber die einfache Anweisung "build" nicht in dfer compose reicht und eine Fehlermeldung ausgibt. Dabei habe ich ja nichts weiter geändert. Die compose macht den build und run und nichts weiter.

 

[haydibe]

Es würde mich wundern, wenn das Dockerfile so funktioniert.

1. chmod -{Attribut} entfernt ein Attribut! Du entfernst im Nachgang das Execution-Flag von deiner Bash-Datei. Dadurch kannst Du sie nur noch via `sh docker-entrypoint.sh`oder `bash docker-entrypoint.sh` starten.

2. solange Du kein WORKDIR angibst, ist es immer /. Sprich: Dein letzter Chmod KANN so nicht funktionieren.

3. Wenn Du den RUN-Block mit den apt-Operationen an erste Stelle stellen würdest, würde es nur einmal gebaut werden und danach via Image-Cache wiederverwendet werden.

4. Warum startest Du nicht einen Container aus deinem Image, in dem Du via Kommandozeile das Entrypoint-Skript mit /bin/bash oder /bin/sh ersetzt? Dann kannst Du Dich im Container umsehen und schauen welchen Zustand ein aus Deinem Image erzeugten Container hat. Wenn Dein Container startet und oben bleibt, dann kannts Du auch mit docker exec -ti {container name oder id} /bin/bash eine Shell im Container öffnen.

5. Die Verzeichnisse sind absolut egal, solange Du exakt weist wo was im Image und damit später im Container landet.

6. Schau Dir portainer/portainer an. Es ist eine extrem leichtgewichtige Management-UI für Docker und Docker-Swarm. Vor allem beim anschauen von Logs und öffenen von Terminals ist es deutlich angenehmen als die Kommandozeile.

Bei meiner letzten Antwort hatte ich zwar geschrieben, dass das gesamte Verzeichnis inkl. darin befindlichen Dateien kopiert wird, aber es wird wohl tatsächlich nur der Inhalt kopiert, nicht das Verzeichnis selbst. Wichig ist, wenn das Ziel kein / am Ende hat wird das Ziel als Datei angesehen!
Siehe: https://docs.docker.com/engine/reference/builder/#copy

 

[Marino]

Hi, danke schon einmal für Deine Antworten. Ich habe nun noch einmal 2-3 Stündchen spielen können, leider ohne richtigen Erfolg. Ich bin zwar weiter, als zuvor, aber ich kann die docker-compose.yml nicht nutzen, obwohl das dockerfile alleine funktioniert.

Zu 1:
Du hast Recht, das mit dem chmod war wirklich falsch. Ich hatte irgendwo noch im Hinterkopf mit -x, um sie ausführbar zu machen und es steht auch auf einigen Seiten. Nachdem ich mir das genauer angelesen habe, kann das so nicht funktionieren.

Zu 2:
Workdir habe ich angegeben, damit funktioniert der Aufruf der /opt/HeliosKwlRemote/run.sh im dockerfile, aber immer noch nicht in der docker-compose.yml

Zu 3:
Guter Tipp, danke. Ist nach oben gewandert.

Zu 4:
Du meinst, einfach die compose-Datei weg lassen? Ich fand die echt praktisch, da ich mir nicht die ewig langen run-Befehle merken muss zum starten, vor allem wenn noch das USB-Device durchgereicht wird. Zudem kann ich in der compose-Datei einen restart erwirken, wenn der Container nicht mehr läuft. Das fand ich sehr nützlich.
Ich habe einmal ohne den Entrypoint den Container mit der compose-Datei erstellt. Das klappt. Dann bin ich mit "docker-compose exec kwl bash" rein und war im workdir (opt/HeliosKwlRemote). Soweit richtig, aber der ist leer. Nichts drin. Erstelle ich nur mit der dockerfile den Container und gehe mit "docker exec -it IMAGE_ID bash" rein, bin ich auch im opt/HeliosKwlRemote, aber hier sind Dateien drin. So etwas verstehe ich nicht. In meinen Augen nutze ich nur die dockerfile-Datei und mache einen build und dieser wird gestartet. Ich habe auch immer mal geschaut und alle images und container gelöscht, um sicher zu gehen, dass er neu erstellt. Hilft nichts.

Zu 6:
Da mache ich mich nun einmal dran.




Hier ein Beispiel, wie es mit docker-compose.yml nicht klappt, das dockerfile alleine mit build und run aber schon:

Ich scheine das nicht zu verstehen, warum die compose nicht möchte. Im dockerfile läuft es nun ausschließlich mit der run.sh, ohne docker-entrypoint.sh, aber die docker-compose.yml wirft einen Fehler aus.

dockerfile:

FROM java:8

RUN apt-get update && \
    apt-get install -y ser2net && \
    apt-get clean

WORKDIR /root

COPY HeliosKwlRemote /opt/HeliosKwlRemote
COPY HeliosKwlRemote/config.properties /etc/helioskwlremote/config.properties

WORKDIR /opt/HeliosKwlRemote/

#RUN chown -hR root /opt/HeliosKwlRemote
#RUN chmod -R 764 ./ && \
RUN    chmod 764 run.sh
    #chmod 764 docker-entrypoint.sh

ENTRYPOINT ["./run.sh"]

funktioniert mit:

docker build -t kwl .
docker run -it kwl

Startet direkt und zeigt mir automatisch im bash:

Using Java: /usr/bin/java
No config file specified with '-f <configfile>'. Searching for config file...
Autoselected config file '/etc/helioskwlremote/config.properties'
2019-01-05 20:34:57.172 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Connecting to Helios KWL on 192.168.200.4:4000
2019-01-05 20:34:57.195 INFO [main] de.root1.helios.Helios.connect: Connecting...

Die Verbindung kann natürlich ohne Durchreichen des USB-Adapter nicht klappen und der hängt noch am Raspberry Pi. Das muss ja hier erst einmal laufen.


Mit der docker-compose.yml:
docker-compose up --build

version: '2'
services:
  kwl:
    build: .
    image: kwl
    container_name: kwl
    restart: unless-stopped
    #ports:
    volumes:
      - /opt/dockerfiles/KWL/opt/HeliosKwlRemote:/opt/HeliosKwlRemote:rw
      - /opt/dockerfiles/KWL/etc:/etc/helioskwlremote:rw

, egal ob mit
docker-compose up --build
docker-compose up
ODER
docker-compose up --build
[/CODE]

gibt:

Successfully built aca0bff0ab10
Successfully tagged kwl:latest
Creating kwl ... error

ERROR: for kwl  Cannot start service kwl: b'OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \\"./run.sh\\": stat ./run.sh: no such file or directory": unknown'

ERROR: for kwl  Cannot start service kwl: b'OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \\"./run.sh\\": stat ./run.sh: no such file or directory": unknown'
ERROR: Encountered errors while bringing up the project.

Dabei führe ich doch eigentlich nur das dockerfile aus (build + run).


Versuch 2: Entrypoint in der compose angeben und im dockerfile auskommentieren. Also im compose:

    working_dir: /opt/HeliosKwlRemote
    entrypoint: ./run.sh

Ergebnis: Gleicher Fehler

 

[haydibe]

Mit Punkt 4 war gemeint, dass du zu Versuchszwecken das Entrypoint-Skript ersetzt um dich im Container umschauen zu könnst. Die Empfehlung geht prinzipiel IMMER in Richtung compose.yml, da deutlich anwendungsfreundlicher als epische Kommandozeilen-Aufrufe. Alles was Du über die Docker-Cli eingeben kannst, kann man auch über die compose.yml machen! Vorallem das Update eines Containers ist dann nur noch das Ändern des Tags am Image mit anschließenden `docker-compose up -d'. Mach das mal über die UI oder nur über die Docker-Cli... deutlich aufwändiger.

Der Grund warum via docker-compose keine Dateien zu sehen sind und mit der Docker-CLI schon ist ganz einfach: im compose.yml mountest Du ein Verzeichnis ÜBER das Verzeichnis in dem Deine Daten liegen. Die liegen zwar immer noch dort, werden aber von dem darüber gemounteten Verezeichnis überlagert. Das KANN so nicht gehen!
Entweder backst Du dir Konfiguration in das Image (das tust Du bereits) ODER Du mountest ganze Verzeichnisse mit der Konfiguration rein (das tust du ebenfalls!). Das ist wie mit deinem Samba-Mount: unmounte mal deinen Share und kopiere eine Datei rein. Mounte dann dein Share. Die vorher reinkopiert Datei ist nicht mehr zu sehen. Unmount den den Share wieder und die Datei ist wieder zu sehen. Ein Volume mountet und ersetzt den Inhalt des Verzeichnisses genauso

Normalerweise kopiert man solche Daten in ein Zwischenverzeichnis, prüft ob bestimmte Dateien im Zielverzeichnis vorhanden sind. Falls diese nicht da sind, kopiert man die "Default"-Konfiguration aus dem Zwischenverzeichnis in das Zielverzeichnis. So stellt man sicher, das a) Default-Konfigurationen in Volumes erzeugt werden und b) Konfiguration aus Volumes nicht durch die Default-Konfiguration ersetzt wird. Nichts ist schlimmer als ein Image das Konfigurationsdateien in Volumes erwartet und diese nicht selbst beim ersten Start erzeugt bzw. dorthin kopiert.

Ersetzt mal dein Entrypoint-Skript durch [ 'pwd' ]. Ich bin mir nicht sicher, ob man hier absolute Pfade angeben muss oder diese relativ ab der Workdir sein müssen. Die Ausgabe von pwd wird dir zeigen ob Du in / oder in was auch immer der Wert von $WORKDIR bist.

Kleiner Tipp: Docker Grundlagenwissen schadet nicht -> https://container.training/intro-selfpaced.yml.html

 

[Marino]

So hundertprozentig habe ich noch nicht verstanden, wo die compose mountet. Versucht diese ein Verzeichnis /opt/HeliosKwlRemote/opt/HeliosKwlRemote zu mounten?

Ich habe also aus der Compose die Volume-mounts auskommentiert. Scheint zu funktionieren

WARNING: Image for service kwl was built because it did not already exist. To rebuild this image you must use `docker-compose build` or `docker-compose up --build`.
Creating kwl ... done
Attaching to kwl
kwl    | Using Java: /usr/bin/java
kwl    | No config file specified with '-f <configfile>'. Searching for config file...
kwl    | Autoselected config file '/etc/helioskwlremote/config.properties'
kwl    | 2019-01-05 21:38:50.736 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Connecting to Helios KWL on 192.168.200.4:4000
kwl    | 2019-01-05 21:38:50.762 INFO [main] de.root1.helios.Helios.connect: Connecting...

Ich hatte das bisher so verstanden, dass die compose die doppelten Befehle, welche auch in dem dockerfile vorkommen, überschreibt. So hatte ich das auch beim entrypoint gelesen.

Ich benutze doch gar keinen -v Befehl im dockerfile. Daher verstehe ich noch nicht richtig, warum das nun so funktioniert, denn eigentlich möchte ich es ja in der compose haben, habe aber nicht verstanden, was da doppelt ist und was ich im dockerfile ändern müsste, damit ich das Volume in der Compose nutzen kann.
Ich dachte bisher, ich kopiere lediglich Daten (dockerfile), die ich dann nutze für das Programm und damit ich darauf zugreifen kann, habe ich sie in der compose einem Verzeichnis zugewiesen, falls ich daran etwas ändern muss.
Oder ist das Verändern des WORKDIRS der Punkt? Dann müsste ich das rausnehmen, alles absolut adressieren und erst in der compose den workdir und den entrypoint setzen. Das zerstört ein wenig mein Bild von dockerfiles und compose-Dateien, wenn man fertige dockerfiles nur schnell durch eine compose erweitert, zum ausführen und sorglos ein paar Pfade freigibt?!?

EDIT:
Ich werde immer abgemeldet und wenn ich den Text kopiere oder zum Absenden mich erneut anmelden muss, haut er mir die Umlaute um die Ohren, sorry

EDIT:
Grundlagen: Ich lese die ganze Zeit, alles was ich finden kann, soweit ich Zeit habe. Und ich habe auch das Buch "Get started with Docker in your projects" gelesen und einiges gelernt. Einige Punkte werden aber nicht angesprochen oder man merkt es erst, wenn man das Problem hat. Deinen Link schaue ich mir mal als nächstes an. Portainer läuft schon und darin "blättere" ich bereits

 

[haydibe]

    volumes:
      - /opt/dockerfiles/KWL/opt/HeliosKwlRemote:/opt/HeliosKwlRemote:rw

Das ist die compose-Syntax für -v!

Verzeichnises können nicht AUS dem Container auf dem Host exportiert werden. Es können nur Host-Verzeichnise (oder Named Volumes) ÜBER die des Container gemountet werden. Der Inhalt aus dem Container-Verzeichnis ist dann nicht mehr sichtbar.

Die Idee ist das ein Image ein Basisverhalten hat und man sie über Compose oder run Parameter übersteuert. Das ist so schon richtig. Dir fehlt nur Grundlagenwissen zu Docker um das Ganze so zu benutzen wie es gedacht ist. Du hangelst Dich bisher auch ziemlich zuverlässig von fehlerhafter Benutzung zur nächsten...

 

[Marino]

Das liegt daran, dass ich darüber bisher nie etwas gelesen habe und ich nutze dazu schon jede freie Minute, um ein Buch zu lesen, zu testen, Tutorials zu schauen, mit anderen Images zu vergleichen... etc. DAS Werk, was alles genau mit allen diesen Dingen behandelt, habe ich bisher nicht gefunden. Es werden immer nur ca. 80% beschrieben und ich komme dann in die restlichen 20%

Dafür, dass ich letzte Woche noch nichts mit Dockern zu tun hatte, finde ich das schon recht gut
Immerhin mache ich das ja nicht beruflich.

Ich hatte es immer anders herum verstanden, dass das Verzeichnis aus dem Container auf den Host gemountet wird. Bekommt man es denn so herum überhaupt hin, anfangs Daten in den Container zu kopieren (dockerfile), um diese dann an den Host zu übergeben? Wenn ich den Ordner leer habe, lege ich ihn ja über den des Containers und die app kann nicht gestartet werden, da sie quasi nicht da ist. Kopiere ich die selben Daten auch auf den Host und mounte das, könnte es evtl. funktionieren, aber dann ist das dockerfile ein wenig überflüssig an der Stelle und ich kann keine Rechte ändern (vielleicht doch, ich weiß es nur noch nicht).
Das einzig sinnvolle wäre dann in meinen Augen das mounten vom Host über das des Containers, die Daten vorher dort ablegen, (& hoffen, dass ich keine Rechte ändern muss oder gucken ob das geht im compose) und den Entrypoint in die compose zu legen. Dann kann ich allerdings nicht einfach einen Ordner mit allen Dateien haben (Program, compose, dockerfile) und einfach starten, sondern muss zuvor Verzeichnisse auf dem Host anlegen und Daten kopieren.

Ich könnte jetzt darauf verzichten, an die Daten zu kommen, da ich sie beim Erstellen einmal ändere. Aber vielleicht muss man es ja doch einmal und der nächste Docker, bei dem ich das auch brauche, kommt bestimmt

 

[haydibe]

Hast Du denn das Gefühl das Du 80% schon verstanden hast? Selbst auf einer Docker Basis 3-Tage Schulung bekommst Du nicht die 100% beigebracht.
Es macht nur deutlich mehr spass mit den Leute zu Diskutieren, wenn sie so eine 3-Tage Schulung schon hatten, weil sie dann die Basic schon verstanden haben und eher die richtigen Fragen stellen.

Ich hab Docker privat schon zwei Jahre benutzt, bevor ich es auf der Arbeit etablieren konnte.

Ein Container kann auf NICHTS vom Host zugreifen. Ein Host gibt beim Anlegen des Containers vor was dieser vom Host sehen und benutzen darf (das meiste davon passiert implizit).
Das Dockerfile enthält prinzipiel immer die Installation und Basis-Konfiguration, davon wird NICHTS an den Host übergeben - es wäre auch ganz schön unsicher wenn der Container eigenmächtig irgendetwas an den Host übergeben könnte.

Im professioniellen Einsatz verwendet man die Volume-Mounts gar nicht mehr... da verwendet man nur noch Named Volumes, die dann von jedem Docker-Node aus erreichbar sein müssen, da ein Container dort auf einem beliebien Node wieder hochkommen kann. Für Konfigurationsdateien und bspw. Zertifikate gibt es da entsprechende Verteilungs-Mechanismen im Cluster. Für Bewegdaten muss man sich da selbst drum kümmern.

Ein naktes Image zu erstellen und dann einen Container zur Laufzeit von aussen zu bestücken ist sinnfrei. Ein gutes Docker-Image sollte erlauben auch ohne Parameter einen Container mit Default-Verhalten zu starten. Ein Container definiert sich darüber, dass er die Kern-Anwendung und all seine Abhängigkeiten und Konfigurationen kapselt (=contained).

Schau dir mal den Foliensatz an, zu dem ich den Link gepastet habe. Das ist eigentlich recht vollständig und sinnvoller als eine 3-Tages Schulung. Es ist leichter zu verstehen, wie Docker funktioniert und es entsprechend zu verwenden, als seine Vorstellungen mit Docker erzwingen zu wollen und sich ewig von einem zum nächsten Problem zu hangeln.

 

[Marino]

Nein, 80% habe ich natürlich noch nicht verstanden, aber immer wenn man etwas liest, wird das jeweilige Thema nur zu max 80% erläutert. Dann gibt es teils verschiedene Bezeichnungen, jeder macht es ein wenig anders und das verwirrt dann auch noch. Den Foliensatz habe ich zu knapp 1/3 bis gestern spät noch durchgearbeitet und mir Notizen gemacht. Zu Volumes bin ich aber noch nicht gekommen und heute werde ich dazu auch nicht kommt..

Man wird sich aber auch eingestehen, das man mehr verstehen wird bei täglicher Anwendung, als jemand der privat sich einarbeitet, um ein paar Container ans laufen zu bringen. Dafür mache ich in meinen Augen schon viel. Ich könnte ja auch fertige Images nehmen, okay dann halt nicht für diesen Einsatzzweck. Denn einen fertigen Container, der meine Lüftungsanlage steuert, gibt es nicht. Ich bin ja schon froh, dass mal jemand ein Programm dazu geschrieben hat, um das auf den KNX-Bus zu bekommen. Man kann sich halt leider nicht in jedem Thema perfekt auskennen, was man privat nutzen möchte, sondern möchte es teils nur zum laufen bekommen. Da gehe ich bei dockern gerade einen etwas anderen Weg, aber wenn ich bei jedem Thema, wo ich etwas machen musste (Asterisk für Türkommunikation, Netzwerk mit Tagged VLAN und routing dazwischen, KNX-Programmierung, KNX Anbindung meiner Lüftung... etc. + Sachen zum Hausbau, innenausbau und garten/Parkplatz), dann wäre ich jetzt noch nicht bei dockern und hätte keine Zeit für meine Tochter
Bisher reichten oft ein paar Beispiele oder Tutorials zum richtigen Thema.

Vielleicht sollte ich das überdenken und keinen Zugriff gewähren. Denn eigentlich muss ich nichts ändern an der config. Und falls doch, "docker-compose down", config ändern und wieder "config-compose up -d". Aber vielleicht kommt das im Foliensatz noch.

Das starten ohne Parameter verfolg die compose ja schon einmal recht gut, daher möchte ich die auch verwenden. Denn woher soll ich bei Problemen ein Jahr später noch wissen, welche Parameter gesetzt wurden? Die compose ausführen ist da schon einfach, wenn der Rest automatisch erfolgen kann.

Ich hoffe, im Foliensatz kommt auch noch NFS mount im Container ,denn Plex steht neben diesem Container und dem Container, der die Logiksteuerung meines KNX-Bus übernimmt noch auf der Liste und ich habe bisher nur ein Volume erstellt und beschlossen, dass dieser Container hier wichtiger ist, denn der war mit ein Grund für den NUC. Danach muss nur noch ein Container gebaut werden, der meine 1wire Anbindung übernimmt und die Kommunikation mit KNX erlaubt