Wie erstelle ich einen Docker-Container?

[copypastedau]

Ich weiss, blöde Frage. Ich sitze seit 3 Tagen und klicke mich von einem Tutorial zum andern, aber irgendwie bin ich zu blöd.
Aufgabenstellung:
Ich habe meinen alten Linux 8 Datensammler/Server ausrangiert. Meine Buffalow-Linkstation ist ebenfalls in den Ruhestand geschickt worden.
Ersetzt wurden beide durch eine DS 923+.
Früher habe ich viele Automatismen im Haus und im KNX-Bus über Shell-Scripte und RRD-Graphen abgearbeitet.
Das habe ich jetzt grösstenteils über Node-Red realisiert.
Lediglich ein Script bekomme ich nicht ersetzt und würde es gerne weiter laufen lassen.
Es ist ein recht einfaches Script, das per TCP-Dump ein paar Daten abgreift, umrechnet und in eine Datei schreibt.
Ich habe mir jetzt via Docker mal ein Debian 8 auf die Synology gezogen und das Script soweit angepasst, das es im Terminal auch arbeitet.
Wie bekomme ich es hin, das das Script als Cronjob läuft? Ich habe zwar im Terminal cron nachinstalliert und via Crontab -e eingerichtet.
Aber es läuft nicht an.
Irgendwelche Lösungsansätze?

 

[EDvonSchleck]

Warum schreibst du nicht, um welche Software es sich genau handelt? Welche DS hast du genau? Wenn du eine Linux Distribution nutzen willst, warum nicht in der VM?

Automatisierungssoftware gibt es ein paar in Docker. Die werden aber direkt als Image/Container betrieben.

 

[copypastedau]

Welche DS? DS 923+, siehe oben.
Automatisierung erstmal node-red, siehe auch oben. (Visualisierung ggf später per Cometvisu)
Die Software ist einfaches shell-script, das den UDP-Stream aus einem Nibe-Gateway ausliesst und in eine csv-Datei schreibt.
Siehe -> hier
Warum nicht in VM? Wenn VM bei dir gleicht Docker: das ist meine Frage gewesen, ebenfalls siehe oben.

 

[Stationary]

Die Antwort auf die Eingangsfrage findet sich in allgemeiner Form hier: https://docs.docker.com/build/

 

[EDvonSchleck]

Automatisierung erstmal node-red, siehe auch oben. (Visualisierung ggf später per)

Das kannst du doch direkt in Docker laufen lassen > https://hub.docker.com/r/nodered/node-red-docker/ oder https://hub.docker.com/r/cometvisu/cometvisu

Warum nicht in VM? Wenn VM bei dir gleicht Docker: das ist meine Frage gewesen, ebenfalls siehe oben.

Verstehe deine Aussage nicht. Die Frage war: wenn du ein Linux laufen haben wills wo du Software installieren möchtest, wäre eine VM wohl besser geeignet. Sicher virtualisiert Docker auch, ist aber eher fix, was die nachträglichen Installationen betrifft.

 

[Tommi2day]

starte das Script aus dem Aufgabenplaner mit docker exec <container> <scriptname>, wenn der Container läuft.

 

[copypastedau]

Mal zu mir: ich habe mal 6 Monate in der AG Basic-Programierung auf einem Z1013 gelernt. Nur um mich mal zeitlich und örtlich einzuordnen.
Danach nur noch sporadisch nach irgendwelchen Tutorials zusammengestoppelt. Auch Englischkenntnisse sind nur rudimentär vorhanden.

@Stationary : Da werd ich leider nicht schlau draus.

@EDvonSchleck : Meine Frage war auch nicht nach Node-Red oder ein Linux in dem ich was nachinstallieren kann sondern die Funktionalität, ein Shellscript in einem Container als Cronjob laufen zu lassen. Bitte Eingangsfragestellung genau lesen.

@Tommi2day : Wenn ich im Aufgabenplaner ein Scrit: "docker exec debian1 /home/nibe.sh" laufen lassen, bekomme ich ein Rechteproblem angezeigt:
"Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/debian1/json": dial unix /var/run/docker.sock: connect: permission denied"

Es gibt wohl auch ein Container "nibepi-base" der letztendlich macht was ich brauche, aber ich verstehe nicht mit welchen Rahmenparametern ich ihn zu laufen bekomme.

Ich habe mich mal hier orientiert und auf einem Debian 10 einen Container aus folgenden Dockerfile gebaut:

FROM debian:8.11
RUN apt-get -y update
RUN apt-get -y --force-yes install tcpdump
RUN apt-get -y --force-yes install bc
RUN apt-get -y --force-yes install vim
RUN apt-get -y --force-yes install net-tools
RUN apt-get -y --force-yes install nano
RUN apt-get -y --force-yes install cron
RUN mkdir /home/variablen
ADD nibe.sh /home/nibe.sh
RUN chmod 755 /home/nibe.sh
CMD cron
RUN crontab -l | { cat; echo "* * * * * bash /home/nibe.sh"; } | crontab -

Wenn ich es dann mit "docker export <NAME> | gzip > <NAME>.gz" exportiere, bekomme ich ein ca 100MB grossen gz-File, aber ich bekomme es nicht als Container in den Synology/Docker importiert.

Und nun komme ich erstmal nicht weiter.

 

[haydibe]

Keine Ahnung was Dein Skript tut und welche Abhängigkeiten es hat, aber ein eigenes Image ist einfach gebaut.

Ich würde immer das Alpine Base-Image verwenden, außer es gibt einen Grund es nicht zu verwenden.
Mit der RUN Instruktion wird tcpdump und bash installiert, die von Haus aus nicht im Alpine Image verfügbar sind. Wenn Du keine Bash-Features nutzt, lohnt es direkt nur "sh" zu verwenden und bash erst gar nicht im Image zu installieren.
Die COPY Instruktion kopiert eine Datei aus dem Pfad wo die Dockerfile-Datei liegt in das Image. Wichtig ist, es gehen nur relative Pfade ab dem Build-Kontext (meist wo das Dockerfile liegt). Das Skript sollte dann alles behandeln, was der Container bei jedem Start ausführen soll.
Mit der ENTRYPOINT Instruktion legt man fest, welcher Befehl bei Start des Containers ausgeführt wird.

Dockerfile:

FROM alpine:3.17
RUN apk add --no-cache tcpdump bash
COPY entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

Zum Bauen dann einfach: docker build -t ${image_name:tag} . (der Punkt steht für Build-Kontext == aktuelles Verzeichnis, ${image_name:tag} muss natürlich durch einen von dir selbst festgelegten Wert ersetzt werden).
Aus dem Image kann man dann mit docker run -ti --rm --net=host ${image_name:tag} einen Container starten, der dank --rm wieder gelöscht wird, sobald das Bash-Skript mit seiner Arbeit fertig ist. Das --net=host startet den Container im selben Netzwerk-Namepace wie den Host, so dass tcp-dump alles mitschneiden kann. Sicherlich willst Du mit -v auch noch einen Host-Pfad auf einen Container-Pfad mounten, um das Ergebnis auf den Host zu bekommen.

 

[copypastedau]

Verstehe deine Aussage nicht. Die Frage war: wenn du ein Linux laufen haben wills wo du Software installieren möchtest, wäre eine VM wohl besser geeignet. Sicher virtualisiert Docker auch, ist aber eher fix, was die nachträglichen Installationen betrifft.

Jetzt habe ich erst begriffen, was du eigendlich gemeint hast. Das die Synology auch VM kann, wusste ich nicht.
Also werd ich wohl eine VM mit einem Debian bauen und mein Script darin laufen lassen.
Wie ist eigendlich der Ressourcenverbrauch Docker (wenn ich es mal hinbekommen würde) vs VM ?

 

[geimist]

Für eine VM musst du den RAM zuweisen, d.h. er steht dir für das DSM nicht mehr zur Verfügung. Außerdem muss in einer VM das komplette Gast-OS virtualisiert werden. Wenn irgend möglich, würde ich für diesen Zweck den Weg über Docker bevorzugen. @haydibe hat es doch prima erklärt.

BTW: ich hab mir nicht jede Zeile deines Skripts angesehen, aber würde es möglicherweise nicht direkt im DSM laufen? Mindestens die Berechnung mit bc müsste man wohl ersetzen, da bc nicht nativ vorhanden ist. Gibt es aber auch zum Nachinstallieren über die SynoCli misc. Tools.

 

[Stationary]

Für eine VM in der 923+ sollte der RAM reichlich aufgerüstet werden.

 

[Benie]

Ich weiß zwar nicht wie gut Debian in der VM läuft, aber ich habe LinuxMint Cinnamon 22.1 "Vera" auf meiner 920+ in der VM laufen, ca. 10GB RAM dafür sollte man schon einplanen. Allerdings, läuft sie dann schon recht flüssig. Von der Linux Mint gibt es 3 Versionen, die Leichteste und Resourcen schonendste ist die xfce Version, hinzu installieren kann man immer wenn man etwas braucht.
Die "22.1 "Vera" ist ganz neu und kam erst diesen September als LTS Version heraus.

 

[copypastedau]

So, ich habe erstmal alle Dienste und Anwendungen vom Alten Datensammler auf die Synology übertragen.
Node-Red, Grafana, Influx, MQTT und Unifi als Docker, 2 Shell-Scripte für Altanwendungen in einer Debian 9 VM.
CPU-Last normal 2-3%, Rambelegung ca 65-70%. In der Bedienung keine Performanceprobleme, Ruckler oder ähnliches.
Danke erstmal für die Hinweis.

Ob ich die beiden Altscripte irgendwann nochmal versuche in einen Docker-Container zu packen, weiss ich noch nicht.
Vielleicht gönne ich mir mittelfristig auch etwas mehr RAM.