Seafile-Docker hinter eigenem reverse proxy betreiben

#1

Guten Tag,

derzeit suche ich eine Alternative zu Dropbox & Co., welche selbst gehostet werden soll. Hierbei ist wichtig, dass die Lösung als Docker-Container auf einem lokalen Server genutzt und hinter einem bestehenden nginx reverse proxy betrieben werden kann. Dieser nginx übernimmt SSL Offloading etc.

Nun ist es so, dass die Docker-Container von Seafile einen eigenen nginx mitbringen und ich davon absehen möchte eigene Container zu bauen. Ich konnte jedoch keine Informationen dazu finden, ob der Betrieb eines eigenen nginx vor dem “offiziellen seafile nginx” zu Problemen führen kann.

Ein Gedanke von mir war z.B. den Docker-Container so zu starten, dass nicht die Ports 80 und 443 nach außen gereicht werden, sondern direkt die Ports 8000 usw., welche dann vom bestehenden nginx angesprochen werden.

Dadurch habe ich im Container zwar ein nginx laufen, welcher jedoch nicht genutzt wird, da ihn keine Anfragen erreichen.

Leider musste ich die Erfahrung machen, dass nicht bei jeder Software solche trivialen Dinge problemlos klappen und ich wollte einmal nachfragen, ob hierzu Erfahrungen bestehen oder gar Tipps?

Sollte sich dies nicht sauber realisieren lassen, wäre meine alternative wohl nextcloud, wobei die Software die Anforderungen nicht ganz so sauber erfüllt wie Seafile.

#2

Ich habe für ein kleines Haus-Setup erfolgreich vor dem offiziellen Docker-Container laufen, und zwar mittels docker-compose und traefik, letzterer übernimmt dann die SSL-Anfragen und leitet sie per HTTP an den Docker-NGINX weiter. Soweit ich verstehe, ist das auch gut so, da der NGINX im Container ein einen Demultiplex des Filesync-Protokolls macht, welcher intern auf einem anderen Port im Container läuft. Wenn man also das SSL-Zeug abschaltet, nutzt man zwar immer noch einen zweiten Reverse-Proxy, allerdings nur noch für diese Aufgabe.

Meine erste Idee war auch, den internen Proxy ganz abzuschalten, das erhöht aber den Konfigurationsaufwand, da man das Multiplexing in den primären Proxy auslagern muss. Momentan ist mir der Overhead aber egal…

#3

Hi,
könntest Du bitte den compose mal posten oder verlinken?
Bin nämlich auch gerade am selbem Problem.

1 Like
#4

Ich hab das ganze ähnlich wie fungs laufen, nur unter Kubernetes mit traefik als Ingress. Da es nur ein kleines Setup mit <10 Usern ist stört mich der interne nginx auch nicht sonderlich. Ich weiß nicht ob das jemandem hilft, aber hier ist die spec vom Seafile Container:

spec:
  containers:
  - name: seafile
    image: seafileltd/seafile-mc:7.0.5

    ports:
    - name: http
      containerPort: 80

    env:
    - name: DB_HOST
      value: "127.0.0.1"
    - name: DB_ROOT_PASSWD
      value: <Datenbank Passwort>
    - name: TIME_ZONE
      value: Europe/Berlin
    - name: SEAFILE_SERVER_LETSENCRYPT
      value: "false"
    - name: SEAFILE_SERVER_HOSTNAME
      value: cloud.example.com

    volumeMounts:
    - name: data
      mountPath: /shared

    resources:
      requests:
        cpu: 200m
        memory: 1Gi
      limits:
        cpu: 1
        memory: 2Gi

Im Falle von Docker könnte man also einfach ein

docker run -p 8080:80 -d -e "SEAFILE_SERVER_LETSENCRYPT=false" \
-e "SEAFILE_SERVER_HOSTNAME=cloud.example.com" seafileltd/seafile-mc:7.0.5

ausführen und davor einen Reverse Proxy klemmen.

#5

+1

Danke schonmal! :slight_smile:

#6

Ich melde mich auch einmal zu Wort:

In zwischen habe ich das Problem selbst gelöst indem ich MySQL und Seafile unter einem Debian 10 selbst installiert habe und den vorhandenen nginx nutze um die Verbindung zu Seafile herzustellen. Jedoch kam ich letztendlich nicht um einen nginx unter Debian 10 herum, da die Media-Files leider innerhalb von Seafile liegen und der Reverse Proxy so natürlich nicht darauf zugreifen konnte. Diese Dateien von extern beim Reverse Proxy zu mounten war mir nicht so eine schöne Vorstellung.

Letztendlich bin ich jedoch mit der Lösung zufrieden und bereue es nicht mich gegen die Docker-Lösung entschieden zu haben, auch wenn ich mehr Zeit investieren musste. Ich habe mich in dem Zuge dann hingesetzt und die Installation und Konfiguration per Ansible realisiert, weswegen ich die VM jederzeit im Katastrophen-Fall wiederherstellen kann.

In der Automatisierung konnte ich dann auch direkt fail2ban, clamav, logrotate, Vorschau-Funktion, Auslagerung per NFS, Backup etc. berücksichtigen, so dass alles dokumentiert vorliegt. Hat mich ca. 3 Tage gekostet aber nun weiß ich wenigstens wie der Hase läuft und wo die Dokumentation von Seafile nicht ganz so gut ist. Hilft dabei Seafile besser einzuschätzen.

Dazu war mir letztendlich der Gedanke nicht mehr sooo geheuer einen Docker-Container, wo ich nicht das Dockerfile zu einsehen kann, bei mir zu starten. Zumindest habe ich es nicht gefunden, vielleicht habe ich es übersehen. Aber solang ich das Dockerfile dazu nicht sehe, traue ich dem Container keine 5 Meter weit. Letztendlich könnte dort alles drin stecken :wink:

#7

Die derzeit angebotene Docker Version ist aus meiner Sicht auch alles andere als zufriedenstellend.

Dieses ist übrigens unter https://github.com/haiwen/seafile-docker verfügbar.

#8

Okay, das Dockerfile habe ich in dem Unterverzeichnis nicht gefunden. Das Repo hatte ich gesehen, jedoch in dem Verzeichnis “image” nicht die Dateien vermutet. Mein Fehler tatsächlich.