selfoss in Docker auf dem Raspberry Pi 4 (TTRSS und FreshRSS laufen schon)

    Liebe Forengemeinde,

    ich hoffe, jemand von den Dockerexperten kann mir helfen. Ich bin Dockerneuling. Mit folgenden beiden Anleitungen habe ich es geschaft Tiny Tiny TSS und Fresh RSS auf meinem Raspberry Pi 4 in Docker laufen zu lassen. Wichtig ist ja auf dem Raspberry, dass man die arm-Version nimmt:

    https://github.com/FreshRSS/FreshRSS/tree/edge/Docker

    https://github.com/nVentiveUX/docker-ttrss

    Jetzt möchte ich abschließend noch selfoss (https://selfoss.aditu.de/) in Docker laufen lassen, bekomme es aber nicht hin.

    Habe nur hier die entsprechende arm-Version gefunden: https://hub.docker.com/r/rsprta/selfoss

    Mit dem dortigen Befehl läuft der Container zwar, aber ist nicht erreichbar, weil da irgendetwas nicht stimmt:

    docker run --detach --volume /mnt/docker/selfoss:/selfoss/data rsprta/selfoss

    Zum Vergleich mal die Ausgabe von docker ps, wo man sieht, dass bei selfoss nicht das Korrekte steht:

    Ich verstehe noch nicht so ganz, was an dem Docker jetzt nicht stimmen soll.

    Er läuft, es ist ein Port verfügbar. Wo ist das Problem?

    Was passiert, wenn du docker exec -it eager_bassi /bin/bash eingibst? Dann solltest du normalerweise eine Shell bekommen und kannst dann auch Befehle innerhalb des Dockers ausführen.

    Wenn du jetzt meinst, dass ganz rechts ein unerwarteter Name steht, dann hast du nur einfach vergessen einen Namen mit anzugeben ;)

    docker run --detach --name "selfoss" --volume /mnt/docker/selfoss:/selfoss/data rsprta/selfoss

    Wenn du andere Ports freigeben möchtest, dann fehlt dir der -p-Switch. Diese hast du ja selbst oben schon angegeben wo du die ttrss gestartet hast.

    Was also genau meinst du mit "das da bei sefloss nicht das richtige steht? Es steht zu 100% das richtige da. ;)

    Verglich mal die Kommandos mit denen du die TTRSS Docker gestartet hast, was dort angegeben ist und wie es dort angegeben wurde. Damit und mit meinem Posting hier solltest du dahin kommen wo do hin möchtest.

    Das Problem ist, dass ich das Webinterface nicht aufrufen kann. Im Gegensatz zum TTRSS Docker gibt es ja auch einen Unterschied bei den Ports:

    TTRSS:
    0.0.0.0:8000->80/tcp, :::8000->80/tcp

    FreshRSS läuft übrigens im gleichen Schema:
    0.0.0.0:8080->80/tcp, :::8080->80/tcp

    selfoss:
    8888/tcp

    Das meinte ich mit "nicht das richtige".

    Sorry, falls das jetzt falsch rüberkommt, aber ich habe gerade erst mit Docker angefangen und frage mich nun, warum ich selfoss nicht unter dem Port :8888 mit der IP des Raspberry Pi aufrufen kann, also 192.168.1.72:8888 in meinem Fall. Wahrscheinlich müsste es wie bei TTRSS und Fresh RSS so aussehen: 0.0.0.0:8888->80/tcp, :::8888->80/tcp. Das 0.0.0.0 davor fehlt mir ja z.B., aber wie bekomme ich das hin?

    Wenn ich den Befehl docker exec -it eager_bassi /bin/bash aufrufe, kommt das hier

    Zitat

    OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "/bin/bash": stat /bin/bash: no such file or directory: unknown

    Edit: Habe jetzt diese Befehlskette probiert, aber das Webinterface geht immer noch nicht. Wahrscheinlich muss das 8888/tcp am Anfang noch verschwinden so wie bei TTRSS. Aber wie geht das?:

    Zitat

    docker network create selfoss_net

    docker run -d --restart unless-stopped --log-opt max-size=10m \
    --name selfoss \
    --volume /mnt/docker/selfoss:/selfoss/data \
    -p 8888:80 \
    --network selfoss_net \
    rsprta/selfoss:latest

    Sieht jetzt so aus.

    Wenn der Docker ein Webinterface hat, dann läuft das per Default auf Port 8888. Du hast es jetzt nach Port 80 exposed. Wenn da also ein WebIF lädt solltest du es mit 127.0.0.1:80 aufrufen können.

    Das das mit dem "exec" nicht klappt kann daran liegen, dass der Docker "bash" nicht kennt. Tausche "/bin/bash" zu "/bin/sh" und es sollte klappen.

    Ich fahre mit den gleich Mal selbst hoch. Mal schauen, ob ich es hinbekomme. Ist dann aber nicht auf Arm sondern x86

    So..ich habe dann mal selbst ein wenig probiert.

    Ich habe den Befehl wie folgt ausgeführt:

    docker run -d -p 8000:8888 --volume /mnt/docker/selfoss:/selfoss/data rsprta/selfoss

    Damit kann ich das WebIF via 127.0.0.1:8000 erreichen

    Du hast es in dem Fall anders herum gemacht und das klappt natürlich nicht. Du hast extern Port 8888 verfügbar gemacht und den intern auf Port 80 geleitet, wo aber gar nichts läuft ;) . Das hast du durch: -p 8888:80 gemacht (siehe Erklärung unten).

    Ändere die Reihenfolge der Ports und dann solltest du glücklich werden.

    Zum Testen kannst du es auch erstmal ohne Volume hoch fahren:

    docker run -d --name selfoss -p 8000:8888 rsprta/selfoss

    und dann im Browser: 127.0.0.1:8000

    Wenn das klappt, stopst du den Container wieder docker stop selfoss und entfernst ihn anschließend: docker rm selfoss und fährst dir dann einen mit dem entsprechenden Volume hoch.

    docker run -d --name selfoss -p 8000:8888 -v <lokaler_ordner_auf_deinem_RPI>:<ordner_im_container> rsprta/selfoss

    Zur Erklärung und vielleicht noch ein paar "Best Practices"

    Dienste in Containern (und erst recht, wenn es Web-Dienste sind) laufen auf einem Port. Solche Ports müssen "exposed" werden, damit sie "von außen" erreichbar sein sollen. Das macht das -p 800:8888. Das "publiziert" den internen Port "8888" extern auf "8000". Änderst du es so ab -publish 12345:8888 dann erreichst du das Interface via 127.0.0.1:12345. Das Pattern ist also externer_port:interner_port. Wobei "extern" der Port ist, den du bei dir im Browser aufrufen möchtest.

    Verwende niemals "latest" als Tag. Du weißt nie, was du bekommst, wenn du den Container neu startest. "Latest" kann in 3 Monaten eine ganz andere Version mit anderen Konfigurationen sein und dann fängst du wieder von vorn an. Verwende immer eine Versionsnummer wo du dir sicher sein kannst, dass die Version, die du verwendet hast auch beim nächsten starten des Containers immer noch die gleiche ist und funktioniert.

    Einmal editiert, zuletzt von DaVu (11. Dezember 2021 um 15:21)

    Kleiner Nachtrag...wenn du Anfängst mehrere Container auf dem gleichen Gerät laufen zu lassen, dann musst du schauen, dass du nicht gleiche Ports verwendest.

    Als Grundlage dient immer noch: -p <lokaler_port>:<container_port>

    Wenn du jetzt Docker "A" so gestartet hast: -p 80:80, dann ist lokal bei dir der Port "80" belegt. Wenn du dann den selfoss-Container starten möchtest, kannst du den nicht mehr auf Port "80" exposen, da der schon belegt ist (von Docker "A"). Du solltest den selfoss-Container dann so starten: -p 8080:8888.

    Dabei musst du natürlich grundsätzlich darauf achten, dass du keine Ports lokal versuchst zu belegen, die durch andere Dienste des Betriebssystems belegt sind. Die meisten Dienste innerhalb eines Containers laufen auf einem 4-stelligen Port (selfoss läuft auf 8888). Andere laufen vielleicht auf "80". Ich habe mir angewöhnt Ports oberhalb von 30000 zu belegen und dann auch zu schauen, dass sich Zahlen gleichen. Nehmen wir an, sefloss läuft auf Port "8888", dann würde ich selfoss so starten: -p 38888:8888. Irgendwann kennt man die Dienste und die Ports und kann dann gleich Dinge zuordnen und man kommt nicht durcheinander. Das ist aber nur meine Vorgehensweise. Du kannst dir da eigene Eselbrücken bauen ;)

    Ein Betriebssystem belet meistens Ports bis 2048 von selbst. Wenn du lokal einen Apache installieren würdest, würde der sofort auf Port 80 laufen und du könntest keinen Containerport mehr darauf mappen. SSH läuft auf Port 22, FTP auf 21, HTTPS auf 443....

    https://de.wikipedia.org/wiki/Liste_der…disierten_Ports

    Wichtig ist halt, das du nichts belegst, was schon belegt ist. Ansonsten gibt es unschöne Nebeneffekte ;)

    Wenn du noch Fragen hast, dann immer raus damit. Docker kann manchmal ein wenig tricky sein und es dauert vielleicht nen Moment, bis es "klick" macht.

    Wenn du diese Container auch alle zusammen brauchst, dann könntest du mal drüber nachdenken, das alles in ein sogenannten "docker-compose" zu bauen. Dann müsstest du nur einen Befehl ausführen und dieser baut dir dann nach der Reihe die Container, die du alle für einen Service brauchst.

    Vielleicht interessiert es dich ja :

    https://docs.docker.com/compose/

    Ganz herzlichen Dank @DaVu, es hat funktioniert. Jetzt blicke ich auch in der Syntax besser durch. Das war eine sehr hilfreiche Erklärung.

    Eine Frage wäre noch gewesen, ob die Container automatisch nach einem Reboot des Pi wieder starten, aber das habe ich getestet und es klappt.

    Eine Frage noch: Bei jedem Container muss man auf die entsprechende Architektur achten, wie ich gelernt habe. Das bedeutet: Bietet der Container keine arm-Version an, kann ich ihn nicht auf dem Raspberry Pi 4 installieren. Ist es eigentlich zwingend, wenn mehrere Architekturen zur Verfügung stehen, die spezifisch anzugeben oder erkennt das System es selbst, welche Architektur es braucht?

    Mein Ziel ist momentan, alle selbstgehosteten RSS-Reader auszuprobieren. Wollte dazu nicht alles "nativ" auf dem Pi installieren. Selfoss gefällt mir allerdings nicht, weil man da fast nichts im Webinterface konfigurieren kann, sondern alles in Dateien schreiben/ändern muss. Werde daher jetzt ausgiebig FreshRSS und TTRSS testen. Daneben gibt es ja noch Miniflux, aber das gefällt mir vom Design her nicht, denn ich möchte links alle Quellen der Feeds untereinander haben und zwischen den Quellen wechseln. Bei Miniflux gibt es ja nur einen gesamten "Stream", der alle Quellen zusammenfasst und die einzelnen Quellen sind in einem separaten Reiter.

    Zu docker-compose: Also ich benutze momentan nur FreshRSS und TTRSS als Container. Ansonsten sind auf dem Pi noch Telerising und TV Headend, was man ja beides auch als Container laufen lassen könnte, nehme ich an. Hätte ich dadurch irgendwelche Vorteile, wenn ich diese beiden auch noch als Container laufen lassen würde? Performance-Vorteile oder so etwas? Sehe bislang keine Probleme an meinem derzeitigen Setup.

    Bisher läuft das problemlos. Dazu noch easyEPG. Alles unter Raspian Buster. Bin erst kürzlich in die Raspberry- bzw. Linux-Welt eingestiegen und noch kürzlicher in Docker, weshalb das alles Neuland für mich war. Vorher hatte ich mich nur mit Kodi auf der Shield beschäftigt.

    Mein nächstes Ziel ist es, den Container rssbridge/rss-bridge laufen zu lassen und so in FreshRSS und TTRSS selbstgehostete RSS-Feeds von Facebook, Instagram und Twitter zu inkludieren. Werde ich mich bald mal ausprobieren.

    Bzgl Architektur....hast du denn eine bestimmte Architektur bei der Installation des Docker angegeben? ;)

    Ich musste auf meinem Linux Rechner mit Fedora nichts angeben. Es wird automatisch erkannt.

    Docker-compose habe ich nur ins Rennen geworfen, da ich dachte, dass die Container, die aktuell verwendest voneinander abhängig sind. Wenn sie das nicht sind und die Container auch einzeln das machen, was du möchtest und du somit nur das suchst, was dir gefällt, dann macht docker-compose keinen Sinn.
    Und ja....zum Testen und spielen von Oberflächen und Diensten...dafür ist Docker gedacht. Docker kann auch so richtig produktiv laufen. Also so im großen Stil. Google selber läuft auf Kubernetes (grob gesagt "Orchestrierung für Docker"). Ich mache das mittlerweile Hauptberuflich und beschäftige mich als DevOp mit dem Betrieb und Deployment von IaC (Infrastructure as Code) und Kubernetes (k8s) in der Azure. Und ich kann dir sagen....Containerisierung klappt auch Produktiv abartig gut.

    Bzgl TVH und Docker....ich habe einen Docker für TVH auf meinem UnRaid laufen. Das schöne ist, dass ich auf UnRaid keine zusätzlichen Abhängigkeiten installieren muss um TVH laufen zu lassen. Das NAS kann also NAS bleiben und der Docker ist seine eigene Umgebung. Wenn die kaputt geht, geht nur die Kaputt und mein NAS bleibt stabil. Von der Performance bin ich zufrieden. Der Pi wird irgendwann an seine Grenzen stoßen. Wenn es bei dir gut nativ läuft, dann würde ich erstmal nichts ändern. Don't fix it if it's not broken ;) .
    Wenn du natürlich spielen und üben möchtest, dann nur zu. Ich habe zum Beispiel das Problem, dass mir der Container weg schmiert, wenn ich Aufnahmen starten möchte. Das könnte nativ besser laufen. Ist mir aber nicht so wichtig. Ich mache keine Aufnahmen. Daher bin ich zufrieden so wie es ist.

    Nein, ich habe keine bestimmte Architektur angegeben. Hat bei mir ja auch alles automatisch erkannt.

    Eine Frage habe ich noch zum Thema Updates: Nach meiner Recherche stoppt man den Container, löscht ihn und führt den Befehl einfach neu aus. Dann wird eine neue Version heruntergeladen, falls eine verfügbar ist. So wie ich das gelesen habe, muss man das aber für jeden Container einzeln machen.

    Mit Docker-compose kann man wohl mit folgendem Skript alle Container auf einmal updaten, was dann ja ein Vorteil wäre. Oder geht das auch ohne Docker-compose?

    Zitat

    #!/bin/bash
    docker-compose pull
    docker-compose up -d --remove-orphans
    yes | docker image prune

    Und beim Updaten werden ja nicht die Einstellungen gelöscht, d.h. bei den Feedreadern bleiben meine abonnierte Feeds beispielsweise erhalten, es wird nur die Version von TTRSS und FreshRSS aktualisiert und ggf. neue Features implementiert?
    Gelgentlich würde ich gerne meine Images manuell per Hand nämlich aktualisieren. Wie ist das die beste Lösung und was sind die Befehle? Docker Compose oder das Normale? Könnte man auch nur einzelne Images aktualisieren, wenn alle zusammen in Docker-compose laufen oder generell nur alle aktualisieren, weil sozusagen alle miteinander verbunden sind?

    Das sind viele Fragen ;)

    Updates:

    Dazu müssen wir erstmal schauen, wie wir den eigentlichen Container erstellt haben und wie Versionisierung in Docker überhaupt abläuft.

    Nehmen wir mal, wie für fast alle Tutorials, den NGINX-Docker:

    https://hub.docker.com/_/nginx/

    Auf dieser Seite hat man einen Reiter "Tags":
    https://hub.docker.com/_/nginx/?tab=tags

    Dort sind die entsprechenden Versionen des verfügbaren Dockers angegeben. Der aktuelle (abgesehen von "latest") ist der 1.21.4.

    Wenn ich also den NGINX Docker wie folgt starte:
    docker run --name nginx_davu -p 8080:80 -d nginx
    dann kommt als erste Zeile in der Ausgabe folgendes:
    Unable to find image 'nginx:latest' locally
    Er versucht also "latest" zu finden, das hat er nicht und daher zieht er sich das. Gebe ich also nichts an, dann nimmt er "latest". Das sieht man auch an der Image-Liste:

    Code
    docker image ls
REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
nginx        latest    f652ca386ed1   10 days ago   141MB

    Der laufende Container wird dann so angezeigt:
    3a9441d65501 nginx "/docker-entrypoint.…" 5 minutes ago Up 5 minutes 0.0.0.0:8080->80/tcp, :::8080->80/tcp nginx_davu


    Was mache ich aber, wenn ich eine bestimmte Version haben möchte? Z. B. 1.20. Wir schauen erstmal wieder auf der "Tag"-Seite wie der Tag benannt ist (manche werden auch so bezeichnet: "v.1.20" daher ist es wichtig genau den richtigen Tag zu verwenden:

    docker run --name nginx_davu -p 8080:80 -d nginx:1.20
    Die erste Zeile der Ausgabe zeigt dann:
    "Unable to find image 'nginx:1.20' locally"
    Er zieht also das Image 1.20.

    Das sieht man wieder an der Image Liste

    Code
    docker image ls
REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
nginx        1.20      c90c369e7833   10 days ago   141MB
nginx        latest    f652ca386ed1   10 days ago   141MB


    Der laufende Container sieht dann so aus:
    11b506f205e7 nginx:1.20 "/docker-entrypoint.…" 4 seconds ago Up 3 seconds 0.0.0.0:8080->80/tcp, :::8080->80/tcp nginx_davu

    Jetzt, wo wir wissen, wie man Container in einer bestimmten Version starten kann und wie man die Version auswählt, machen wir uns mal über Updates Gedanken ;) . Wenn du den gleichen Befehl mit dem Image 1.20 wieder ausführst, bekommst du kein Update. Du bekommst genau die Version wieder, die du vorher schon geladen hast. Es sei denn, es gibt eine neuere Version des Images mit dem entsprechenden Tag. Dann wird das geladen. Das ist aber eher selten. Vielmehr wirst du einen anderen Tag angeben müssen um eine neuere Version des Dienstes zu bekommen.
    Jetzt mag man sich fragen "Warum sollte ich überhaupt einen Tag angeben? Es macht doch das Updaten viel leichter, wenn ich 'latest' verwende und dann gar nichts angeben muss". Dazu habe ich oben schon eine Erklärung abgegeben. Wenn du heute "latest" ziehst, kann es sein, dass du z. B. einen Dienst in der VErsion "1" bekommst. In einem Jahr, wenn du es neu aufsetzt und wieder "latest" ziehst, liegt vielleicht schon die Version "3" vor. Diese benötigt eine komplett andere Konfiguration (da 2 Major-Updates dazwischen liegen) und dein Dienst wird nicht starten und du verstehst gar nicht warum ;).
    "Latest" zu verwenden die die gänzlich schlechteste Option um Docker Images zu starten. Es sei denn, zum Testen. Möchtest du einen Service produktiv nutzen, gibst du einen Tag an. Das solltest du dir gleich angewöhnen. Gibt es keinen Tag, dann tagst du das Image selbst und pusht es in deine eigene Docker Registry. Dann kannst du sicher sein, dass du immer die Version bekommst, die du auch erwartest.

    So viel zu Updates ;)


    Zitat von TTTMann

    Und beim Updaten werden ja nicht die Einstellungen gelöscht, d.h. bei den Feedreadern bleiben meine abonnierte Feeds beispielsweise erhalten, es wird nur die Version von TTRSS und FreshRSS aktualisiert und ggf. neue Features implementiert?

    Docker haben per default keinen "State". Der NGINX Container oben wurde "Stateless" gestartet. Das heißt, dass die Infos, die innerhalb eines Dockers liegen (und das beinhaltet auch die Konfiguration oder das Bereitstellen von Daten) kein fester Bestandteil sind. Wirfst du den Docker weg und löscht ihn, dann sind auch die Daten weg. Möchtest du das ändern, dann verwendest du "Volumes". Das sind Speicher, die außerhalb des Dockers auf deinem Rechner liegen. Meistens ein bestimmter Ordner auf deinem Rechner, der dann im Docker auf einen anderen bestimmten Ordner gemappt wird. Nur so kannst du sicher sein, dass deine Daten und deine Konfiguration ausgelagert und beim nächsten Mal auch wieder mit eingebunden werden, wenn du einen neueren Docker startest. Vorausgesetzt der neuere Docker kommt mit der Konfiguration des alten Dockers klar ;)

    Wenn du einen Docker aber nur "stopst" und dann wieder startest, dann sind die Daten noch da. Gestoppte Container listest du dir mit docker ps -a auf. Starten kannst du sie wieder mit docker start <containername>.


    Zitat von TTTMann

    Gelgentlich würde ich gerne meine Images manuell per Hand nämlich aktualisieren. Wie ist das die beste Lösung und was sind die Befehle? Docker Compose oder das Normale? Könnte man auch nur einzelne Images aktualisieren, wenn alle zusammen in Docker-compose laufen oder generell nur alle aktualisieren, weil sozusagen alle miteinander verbunden sind?

    Ich glaube diese Frage ist dann jetzt obsolet, oder? ;)
    Images werden nicht geupdated. Es werden neuere Images gezogen und die alten liegen dann immer noch auf deinem Rechner. Alte, nicht mehr benötigte Images löscht man mit:
    docker image rm <image-ID>
    Man kann Images nur dann löschen, wenn sie nicht mehr mit einem laufenden oder gestoppten Container in Verbindung stehen. Also erstmal mit docker ps -a checken welche Container in welchem Status bei dir vorliegen. Festlegen welche Container man nicht mehr braucht und diese dann entfernen: docker rm <containername> (<- geht nur bei gestoppten Containern) und dann das passende Image löschen.

    Ich mach das mal mit den NGINX Containern:

    Code
    docker ps -a
CONTAINER ID   IMAGE        COMMAND                  CREATED          STATUS                     PORTS                                   NAMES
59f14db12e1a   nginx        "/docker-entrypoint.…"   11 seconds ago   Up 9 seconds               0.0.0.0:8081->80/tcp, :::8081->80/tcp   nginx_davu2
11b506f205e7   nginx:1.20   "/docker-entrypoint.…"   20 minutes ago   Exited (0) 4 seconds ago                                           nginx_davu


    Ich habe mal 2 Container hoch gefahren. Einen mit "latest" und einen mit "1.20". Den mit 1.20 habe ich gestoppt, was man an dem "exited" sehen kann. So kannst du sehen, welche Container laufen und welche nicht. Jetzt habe ich natürlich auch beide Images noch hier liegen:

    Code
    docker image ls
REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
nginx        1.20      c90c369e7833   10 days ago   141MB
nginx        latest    f652ca386ed1   10 days ago   141MB


    Das Image 1.20 brauche ich nicht mehr, da zu alt. Bevor ich es aber entfernen kann, muss ich erst den gelöschten Container entfernen: docker rm nginx_davu

    Dann kann ich das Image entfernen: docker image rm c90c369e7833

    Das wars dann:


    Nimm dir mal die 3 Stunden und schau dir das Video hier an:

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.

    Ist wirklich gut und sollte für den Anfang reichen ;)

    Ich brauche noch einmal Hilfe, sorry.

    Ich bekomme Portainer nicht ans Laufen. Habe folgenden Befehl ausgeführt:

    Zitat

    sudo docker run -d -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:linux-arm


    Sieht dann bei mir so aus mit docker ps und der Port 9000 lässt sich nicht via Webinterface aufrufen:

    Zitat von TTTMann

    Sieht dann bei mir so aus mit docker ps und der Port 9000 lässt sich nicht via Webinterface aufrufen:

    Und wie versuchst du das Webinterface aufzurufen?

    Weiter solltest du dir mal Gedanken darüber machen, dass man Docker nicht mit sudo laufen lässt ;). Ich meine...es schadet auch nicht, aber notwendig ist es nicht. Und vor allen Dingen brauchst du das nicht, wenn du sowieso schon root auf dem RPi bist :D Mehr Rechte als "root" geht nicht ;)

    Ich habe das gerade mal ausprobiert:

    docker run -d -p 9000:9000 --name=portainer --restart=always -v /run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce

    Die einzigen Änderungen, die ich vornehmen musste waren:

    Bei mir ist die Datei docker.sock im Ordner "/run/" und ich nutze hier halt eine x86 Maschine. Daher habe ich das "linux-arm" entfernt und dann kann ich den Portainer mit:

    127.0.0.1:9000

    aufrufen.


    Rufst du den Portainer vom RPi aus auf? Wenn nicht, von welchem Gerät dann? Läuft auf dem RPi ne Firewall, die Zugriff von außen blockt? Was sagen die Logs: docker logs <container_name>

    Du könntest übrigens auch einfach "latest" nehmen:

    Du musst immer schauen, ob es auch für das Tag eine Arm-Version gibt und die gibt es auch für "latest" und wahrscheinlich auch für alle anderen Versionen

    Einmal editiert, zuletzt von DaVu (21. Dezember 2021 um 16:58)

    Komisch, jetzt geht es. Docker noch einmal deinstalliert, reboot und neuinstalliert. FreshRSS lief vorher schon.
    Keine Firewall, Aufruf via Notebook.

    Aber trotzdem Danke für die Infos. Bei FreshRSS funktioniert das mit dem Tag :latest nämlich nicht, da kommt ein Error. Man muss dort explizit :arm angeben.

    Würdest du denn Portainer empfehlen oder ist das unnötig?

    Ob der für dich nötig ist oder nicht, musst du selbst wissen. Er bietet ne hübsche GUI und auch ein paar Stats. Verkehrt ist es nicht, gebraucht habe ich den noch nie.

    Wir benutzen mit Kubernetes ähnliche Systeme. Da heißt es dann nachher "Lens". Da kannst du aber mit docker nichts mit anfangen.

    Spiel damit rum und entscheide einfach selbst ob du es brauchst oder nicht. Er wird halt auch Ressourcen verbrauchen ;)

    Noch ein Tip

    Je nachdem wie dein Browser eingestellt ist, kann es sein, dass er gecachte Inhalte hat und er sich so an Dinge erinnert. Sollte also vielleicht eine Seite nicht erreichbar sein, da du den Container nicht richtig gestartet hast, später aber den Container richtig startest und den Browser nicht schließt....dann könnte es sein, dass dich dein Browser verarscht. Ich würde, wenn du dir sicher bist, dass es so laufen sollte, immer mit einem "Privaten Fenster" testen.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden