Nextcloud All in One – mit Docker Compose und Traefik installieren

Hallo,
vielen Dank für die TOP-Anleitung – Hatte vorher ein Nextcloud-AIO-Version ohne traefik am Laufen und konnte sogar ein Borg-Backup zurücksichern und es hat immer noch funktioniert! Also ich habe jetzt auch keine Sorgen mehr, dass ich das nicht wieder sauber aufgesetzt bekomme, wenn mir das richtig abraucht!

Irritieren tut mich aber der Zugriff: http://i.p.ad.dr:11000. Das ist ja ein http Zugriff der dann über eine offizielle IP zugreift ?? Ist das TLS?

Meine Clients sind aber alle auf https:// eingestellt und das geht auch.

Also welche Ports werden jetzt nach aussen durchgeschleift?

nextcloud-aio-mastercontainer 8080
nextcloud-aio-apache 11000

Also jetzt mal getestet:

https://i.p.ad.dr:8080 -> kommt beim AIO-Mastercontainer raus (Alles gut!)
http://i.p.ad.dr:11000 -> wird redirected auf https://name.domain.de/login (Eben der traefik-hostname des nextcloud-aio-apache containers.)
Soweit so gut funktoniert es ja –
Folgende Fragen:
1.:
Der Service-Eintrag http://i.p.ad.dr ind nextcloud@file ist aber irritierend, weil es so aussieht, als würde der Traefik über http und die offizielle IP-Adresse auf den Apache von Nextcloud zugreifen. (TLS? – Wenn ja, wer sagt, dass TLS Pflicht ist.)

( Ich meine den Eintrag in der dynamic_conf:
 services:
     nextcloud:
         loadBalancer:
             servers:
                 – url: “http://5.7.2.1:11000” )

So und jetzt kommt es:

2.: “traefik.http.services.nextcloud.loadbalancer.server.port=443” (im Mastercontainer)

3.: Vom allgemeinen redirect von web auf websecure sprechen wir ja nicht, und warum da der Service-Zugriff auf http://5.7.2.1:11000 nicht gestört wird. (Warscheinlich TLS)

Das sind doch lauter widersprüchliche Konfigurationen. Ich habe den Eindruck Du hast da ganz schön lange dran gesessen, bis das lief, weil nextcloud viel eigenes macht, was erstmal undurchsichtig ist.(Und – es gibt noch viel zu lernen)

Schauen wir uns nochmal einen access.log – Eintrag im Traefik an:
1.8.131.223 – – [05/Dec/2023:13:58:52 +0000] “GET /remote.php/dav/avatars/xxx/128.png HTTP/1.1” 200 2523 “-” “-” 2780 “nextcloud@docker ” “http://95.216.9.232:11000” 79ms           

Der Router nextcloud@docker kommt von aussen rein und leitet auf den Service nextcloud@file weiter (also i.p.ad.dr:11000). Da hängt der nextcloud-aio-apache dran.

Der beantwortet entweder selber oder leitet an andere Container weiter. (Er muss also auch als reverse-proxy agieren.)

Also – lange Rede kurzer Sinn: Da docker ja einen Name-Service zur Verfügung stellt, müsste eigentlich auch in der dynamic_conf.yml folgender Eintrag funktionieren:

 services:
     nextcloud:
         loadBalancer:
             servers:
                 – url: “http://nextcloud-aio-apache:11000” )

So – einen Test durchgeführt:
docker exec -it traefik /bin/sh
ping nextcloud-aio-apache
(Geht nicht, weil der traefik nur im Netzwerk proxy und crowdsec ist, aber nicht im Netzwerk nextcloud-aio ist.)
OK – den nextcloud-aio-apache zum Testen zusätzlich mit Hilfe von Portainer in das Netzwerk proxy gehängt.
So – einen Test durchgeführt:
docker exec -it traefik /bin/sh
ping nextcloud-aio-apache (Geht!)

Jetzt könnte ich vermeiden, den Port 11000 ganz nach draussen zu hängen, sondern er müsste nur auf dem Container auf 0.0.0.0:11000 hängen und wäre dann von Traefik und dem Mastercontainer über den Namen nextcloud-aio-apache erreichbar.

Da der nextcloud-aio-apache container ja vom Mastercontainer konfiguriert wird und ich da nicht richtig Zugriff auf die Konfiguration habe, würde ich das Netzwerk nextcloud-aio in der Traefik-Konfiguration definieren und beim Mastercontainer als external.
Also so (docker-compose.yml – ACHTUNG – Ich habe die Netzwerke bei mir kleiner gemacht – /24 und der Traefik hat überall die 253.)
   networks:
     crowdsec:
       ipv4_address: 172.31.254.253
     proxy:
       ipv4_address: 172.31.253.253
nextcloud-aio:
ipv4_address: 172.31.252.253

So jetzt beim Master-Container das Netzwerk als external definieren:

   networks:
     – proxy
– nextcloud-aio
networks:
 proxy:
   external: true
nextcloud-aio:
   external: true

Jetzt kommt die Preisfrage:
Wo kommt eigentlich die Netzwerk-Konfiguration der anderen Container her?
Wenn die docker automatisch erzeugt, heisst die doch immer nextcloud-aio_default oder so.

Das habe ich jetzt auch gefunden:in der Containers.json ist das Netzwerk nextcloud-aio definiert. Da ich die nicht in den Volumes gefunden habe, sollte das statisch von Master-Container ausgebracht werden und könnte dann auch funktionieren, wenn der das Netzwerk von traefik erzeugt wird.
Das muss ich nochmal in einer Neuinstallation testen.

Möglicherweise geht es aber auch viel viel leichter:

Ich habe in der Konfiguration vom Master-Container eine Einstellung gefunden, die APACHE_IP_BINDINGS heisst und standardmäßig auf 0.0.0.0 steht. In der Doku wird manchmal von localhost (also 127.0.0.1) gesprochen.
Das wäre jetzt nicht so ganz die Docker-Konvention, aber würde auch einen gefühlt deutlichen Sicherheitsgewinn bieten und wäre etwas leichter, als das Gewürge oben.

Also – wieder viel gelernt.

Danke für die super super Vorarbeit. Das hätte ich definitiv nicht alleine hinbekommen.

Sagt doch mal was dazu, welche Konfigurationsweise Ihr für sicherer und auch konstanter haltet (gegenüber von Updates von Nextcloud-AIO).