Nextcloud Docker Image erstellen

Warum bauen wir ein eigenes Image für Nextcloud?

Nextcloud ist eine Cloud-Server Anwendung, mit der wir Dateien zwischen unseren Systemen synchronisieren können. Natürlich dürfen wir auch Freigaben anlegen und Links verschicken, damit unsere Freunde oder Kollegen Zugriff auf hochgeladene Dateien bekommen.

Nextcloud ist eine sehr pfiffige Alternative zu beispielsweise Dropbox, Google Drive und ähnlichen Diensten. Weil wir die Daten auf unserem eigenen Server hosten haben wir etwas mehr Privatsphäre. Wir sind der Herr unserer Daten!

Für Nextcloud erstellen wir ein eigenes Image, dass wir dann im nächsten Kapitel in einem Container starten. Packen wir’s an :)

Warum basteln wir an den Docker Images rum?!

Bei Traefik, MariaDB und phpMyAdmin haben wir einfach die offiziellen Images von Docker herunterladen lassen und alles läuft. So sollte es eigentlich sein.

Für Matomo, WordPress und Nextcloud hingegen bauen wir unsere eigenen Images, obwohl es hier ja auch für jeden Dienst ein fertiges, offizielles Docker Image gibt. Also warum tun wir uns diesen Stress an und fummeln hier manuell in der Config herum?

Kombiniert lauten die Antworten auf diese Frage „E-Mail“ und „Grenzwerte“:

Datenbank Container – MariaDB

Mittlerweile benötigt fast jede WEB-Anwenung eine Datenbank im Hintergrund. Ob Blog, Web-Tracker, Cloudspeicher, CRM-Programme und so weiter… Keine dieser Anwendungen würde ohne Datenbank laufen.

Früher war die Waffe der Wahl unter Linux ganz klar MySQL. Seit das Projekt aber an Oracle verkauft wurde, gab es immer mehr Spannungen bei den Entwicklern und der Community. Dies gipfelte dann in der Abspaltung des Projekts in die MariaDB, welche eine vollständig kompatible Plattform und mittlerweile sogar pfiffige Lösungen auf Basis von MySQL bietet.

Ich selbst setze die MariaDB schon seit gut fünf Jahren ein und wurde bisher noch nie enttäuscht. Darum setze ich auch bei unserem Docker-Setup auf MariaDB.

Traefik Docker Container als Reverse-Proxy und Let’s Encrypt Provider

Docker ist gut und schön, hat aber einen gravierenden Nachteil: Wir haben ja für jeden Dienst einen eigenen Container. Und diese Container werden über Ports nach „außen“ angebunden. Port 80 und 443 bedient zum Beispiel den Zugang zum Web. Belegt ein Container diese Ports mit seinem eingebauten Webserver, ist Schicht im Schacht. Kein weiterer Container kann dann auf Port 80 kommunizieren, da sich diese ansonsten ins Gehege kämen. Natürlich können wir auf andere Ports umsteigen, aber dann müssen wir die entsprechend mit im Browser übergeben: (http://www.xp-server.de:44480) zum Beispiel.

Das schaut nicht nur furchtbar aus, es gibt auch Stress mit Google. „https“ funktioniert auch nicht richtig, weil das auf Port 443 festgenagelt ist. Und niemand merkt sich zu Domains auch noch Portnummern. Also muss eine andere Lösung her…

Die wurde gefunden in Form eines Systems, das man „Reverse Proxy“ getauft hat.

Verwendung
von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen zu Cookies erhalten Sie in unserer Datenschutzerklärung.

Scroll to Top