Beiträge von ariaci

Moin,

mein Setup geht etwas weiter, als von UpSpin beschrieben ... die Richtung ist jedoch dieselbe.

Ich habe einen eigenes Docker-Image, basierend auf webdevops/php-apache und verlinke die Zertifikate direkt mit dem dazu passenden Container. Im eigenen Docker-Image wurden einige Konfigurationen angepasst, so dass ich mehrere virtuelle Hosts (sogenannte vHosts) über einzelne Konfigurationen erstellen kann. Auch werden beim Erzeugen des Images automatisch die in webdevops/php-apache fehlenden Module proxy, proxy_http, proxy_ajp, rewrite, deflate, headers, proxy_connect und proxy_html dem eigenen Apache2-Image hinzugefügt.

NextCloud läuft nun direkt im Docker-Container, welcher unter Verwendung meines eigenen Images erstellt wurde. Da die Zertifikate nun im Container verlinkt werden, benötige ich für NextCloud keinen ReverseProxy. Diesen benötige ich aber für andere Dienste, wie Urbackup, welches aufgrund des verwendeten BTRFS in einer eigenen VM laufen muss und nativ ohne Anpassungen nur HTTP zur Verfügung stellt. Daher stammt auch die vorher gepostete Konfiguration.

Theoretisch sollte die gepostete Konfiguration, sobald die Zertifikate in "/opt/docker/etc/httpd/vhost.ssl.conf" richtig konfiguriert sind auch direkt passen. Eine Notwendigkeit besteht allerdings nicht, sobald die Zertifikate im php-apache-Container liegen und NextCloud im selben Container läuft. Dann kann dieser die Zertifikate direkt und ohne ReverseProxy verwenden. Hier hängt es etwas davon ab, wie meine Infrastruktur funktionieren soll/tatsächlich funktioniert.

Da allerdings über die Gui von Qnap keine einzelnen Dateien verlinkt werden können, sondern nur Verzeichnisse, ist mein Ansatz etwas komplizierter zu bewerkstelligen. Dadurch wird mindestens ein eigenes docker-compose.yml zur Erstellung des Containers benötigt. Für solche Dinge verwende ich durchweg Scripte und die Konsole der Qnap.

Ich hoffe, ich konnte die Verwirrung etwas entwirren.

Ciao

ariaci

Apropos:

Ich halte es nicht für unbedingt gut, einen simplen ReverseProxy allein in einer VM zu betreiben. Der Overhead einer VM ist im Vergleich zu einem Docker-Container immens hoch. In meinem Fall benötigt der eigene php-apache-Container gerademal 484 MB Platz auf der Platte. RAM und CPU werden mit 0% nicht einmal messbar. Dies liegt daran, dass Docker im Kernel des Hosts in einem sogenannten eigenen Namespace läuft. Dadurch wird für syscalls deutlich weniger Performance benötigt, als bei einer VM, die quasi erst einmal alles für den Host "übersetzen" muss. Auch sind Updates in einer VM deutlich komplexer zu bewerkstelligen und Fehlerfälle schwieriger zu beheben, da das gesamte OS mit betroffen ist/sein könnte. Backups einer VM sind auch schwieriger zu handhaben. Unter Docker verlinke ich lediglich die passenden Ordner des Hosts und schon kann der Host Backups anfertigen. Eine VM sollte durchgängig unabhängig vom Host laufen.

Hallo,

ich versuche mal einen Schnelldurchlauf, zur Konfiguration eines Apache-Webservers, der einen spezifischen Host zur einem anderen Server als Proxy durchleitet ...

Folgenden Inhalt hat meine Konfiguration des php-apache-Containers:

#######################################
# Vhost
#######################################

<VirtualHost *:80>
  ServerName hostname.domain.tld
  ServerAlias hostname

  UseCanonicalName Off

  <IfVersion < 2.4>
    Include /opt/docker/etc/httpd/vhost.common.d/*.conf
  </IfVersion>
  <IfVersion >= 2.4>
    IncludeOptional /opt/docker/etc/httpd/vhost.common.d/*.conf
  </IfVersion>

  Redirect permanent "/" "https://hostname.domain.tld/"
</VirtualHost>

<VirtualHost *:443>
  ServerName hostname.domain.tld>
  ServerAlias hostname

  UseCanonicalName Off

  <IfVersion < 2.4>
    Include /opt/docker/etc/httpd/vhost.common.d/*.conf
  </IfVersion>
  <IfVersion >= 2.4>
    IncludeOptional /opt/docker/etc/httpd/vhost.common.d/*.conf
  </IfVersion>

  Include /opt/docker/etc/httpd/vhost.ssl.conf
  
  ProxyPreserveHost On
  ProxyPass / http://destinationhostname.destinationdomain.tld:destinationport/
  ProxyPassReverse / http://destinationhostname.destinationdomain.tld:destinationport/
</VirtualHost>

Der erste VirtualHost-Part hört auf Port 80 aller eingehenden Verbindungen und konfiguriert die Weiterleitung von HTTP auf HTTPS. Damit wird quasi eine direkte HTTP-Verbindung unmöglich. Der zweite VIrtualHost-Part beschreibt dann die gekapselte HTTPS-Verbindung. Sämtliche über den Port 443 eingehenden Verbindungen werden nach "ProxyPass" geleitet. Antworten des dort konfigurierten Proxy-Ziels werden über "ProxyPassReverse" aufgelöst. In der hier sichtbaren Konfiguration werden alle unter Root liegenden Dateien direkt 1:1 in beide Richtungen weitergeleitet. Damit wird sichergestellt, dass die Verzeichnisstrukturen des Proxies mit dem Nicht-HTTPS-Ziel übereinstimmen.

Vielleicht klärt dies einiges zum Thema Apache-Proxy auf.

Ciao

ariaci

Moin,

da bei mir die Lösung von nogrup leider keinen Erfolg brachte, da die Anmeldung über den Button funktioniert, jedoch der Dialog nicht mit OK geschlossen werden kann (angeblich stimmt das Client-seitige-Verschlüsselungskennwort nicht überein), habe ich habe den Bug vor etwa drei Wochen endlich mal bei Qnap gemeldet. Dort wurde nach mehreren Versuchen vor ca. einer Woche das Problem an die entsprechende Entwicklergruppe weitergereicht.

Eine Lösung ist aktuell noch nicht in Sicht ... leider!

Ich melde mich, wenn es neue Informationen dazu gibt.

Ciao

ariaci

Moin,

ich habe seit exakt dem Update von Cloud Backup Sync/Hybrid Backup Sync das Problem. Am Donnerstag Abend eingespielt und der nächste Job lief nicht mehr durch. Authentifizierungsfehler bei Google Drive. Danach habe ich alle Jobs neu eingerichtet und es hat dann erstmal 2 Tage gedauert, um die Backups zu comparen. Gestern war er dann durch und wieder dasselbe Problem.

Eine Authentifizierung bzw. Neuanmeldung bei Google Drive fuinktioniert nicht, da angeblich das Verschlüsselungspasswort nicht identisch ist ...

Weiß jemand Rat?

Danke

ariaci

Hallo Luzifer,

Das klingt ja schon mal ganz gut

Allerdings gibt es bei Anpassungen über den von dir geschilderten Weg einige Probleme mit Updates. Sobald du auf das aktuellste "webdevops/php-apache"-Image nutzt, sind deine durchgeführten Änderungen verloren und eine weiteres mal durchzuführen. Ich habe gerade noch einmal geschaut, wie ich dieses "Problem" löse.

Ich habe das so gelöst, indem ich mir ein eigenes Docker-Image auf Basis von "webdevops/php-apache" erzeuge und aus diesem dann meinen Webserver bilde. Beim Erzeugen meines eigenen Images kann ich dann beliebige Änderungen am Basis-Image durchführen. Ich ersetze hierbei einige mitgelieferte Konfigurationsdateien mit meinen eigenen. Damit lässt sich ein Update wunderbar durchführen und meine Änderungen gehen nicht verloren.

Ciao
ariaci

Hallo Luzifer999,

sorry, dass ich erst jetzt zum Antworten komme - die Arbeit halt - aber das kennst du ja sicher selbst

Um Hilfe zur weiteren Konfiguration des Container zu erhalten, kannst du auf diese Seite schauen: http://dockerfile.readthedocs.…ckerfiles/php-apache.html
Dort sind sämtliche Konfigurationsmöglichkeiten, ob über Umgebungsvariablen oder die Configs selbst, dokumentiert.

In deinem Fall sollte das Binden des Ordners "/opt/docker/etc/httpd/conf.d" des Containers zu einem lokalen Ordner deiner Wahl ausreichend sein. Nach einem Start des Containers dürfte dann dein lokaler Ordner mit den aktuellen Konfigurationsdateien des Apache gefüllt sein. Eine Änderung der Konfiguration wirkt sich entsprechend nach einem Neustart des Containers (oder des Apaches direkt im laufenden Container) aus.

Ich hoffe das hilft dir etwas weiter ...

Ciao
ariaci

Hallo,

versucht mal bitte per SSH den Besitzer/die Besitzergruppe für den Ordner und sämtliche darunter liegenden Dateien auf 1000:1000 zu setzen.

Das funktioniert über SSH (zum Beispiel per Putty) über folgenden Befehl:

chown -R 1000:1000 /share/Public/nextcloud

Anstatt “/share/Public/nextcloud“ müsst ihr natürlich euren verwendeten NextCloud-Ordner verwenden, in den ihr den nextcloud-Source entpackt habt.

Ich hoffe das hilft etwas ...

Ciao
ariaci

PS: Ich habe alle im Tutorial beschriebenen Schritte als Administrator ausgeführt. Evtl. besteht hier noch ein Unterschied?

Moin,

sorry, da habe ich dich gestern falsch verstanden. Ich war der Meinung, dass du dein "DockerFiles"-Verzeichnis nach "/app" gemountet hast.
Dies ist ja nun zum Glück geklärt ...

Probiere bitte mal, dem allen unter /share/nextcloud liegenden Dateien/Verzeichnissen den Besitzer 1000 mit der Gruppe 1000 zu geben.
Sollte dann folgender Befehl sein:
chown -R 1000:1000 /share/DockerFiles/nextcloud/

Ich glaube das Problem ist, dass der Nutzer und die Gruppe "application" im Docker-Container diese Nutzer-/Gruppen-ID verwenden. Einige Dienste verwenden u.U. noch unter diese ID und können somit nicht auf /app zugreifen.

Ciao
ariaci

Hallo silencshadow,

versuch bitte mal anstatt

chown -R httpdusr:everyone /share/DockerFiles/
chown -R httpdusr:everyone /share/DockerFiles/nextcloud

die Verwendung der Nutzer-IDs. Ich hatte damit vor langer Zeit auch mal Probleme und dächte, ich hätte das mit den Befehlen

chown -R 1000:1000 /share/DockerFiles/
chown -R 1000:1000 /share/DockerFiles/nextcloud

klären können. Aus diesem Grund habe ich mir dann ein eigenes Image, basierend auf webdevops/php-apache, gebaut.

Ciao
ariaci

Hallo nadstefan,

ich versuche mal deine Frage zu beantworten.

Ich sehe den größten Vorteil bei Docker darin, dass das vorhandene System absolut unangetastet bleibt. Bis auf die nach außen geführten Volumes, werden keine Änderungen am Host-System vorgenommen. Dadurch können Updates usw. ohne Weiteres durchgeführt werden. Sollte es zu Problemen kommen, so kann dieser Container auf einen funktionierenden Stand zurückgesetzt werden. Die Flexibilität liegt darin, dass eben sämtliche benötigten Komponenten bereits komplett "verpackt" geliefert werden und damit auch keine System-Bibliotheken zerstören, da jeder Container in einem abgetrennten Kernel-Namespace des Hosts läuft. Im Fall des verwendeten "webdevops/php-apache" hat dies den Vorteil, dass PHP7 verwendet werden kann, obwohl der Host-eigene Apache der Qnap nur PHP5 anbietet. Beide Installationen beeinflussen sich nicht.

Zu deinen vier Positiv-Punkten:

• https-Unterstützung
  Auch diese kann über das vorliegende Basis-Image konfiguriert werden. Allerdings habe ich diesen Schritt aufgrund der sonst hinzukommenden Komplexität erst einmal bewusst ausgelassen. Die Nutzung eines Reverse-Proxies ist allerdings sehr sinnvoll, um die verwendeten Zertifikate zentral an einer Stelle "hosten" zu können.
• Docker wird nicht bei jeden Klick auf die Einstellungen neu gestartet
  Da die ContainerStation als Backend im Hintergrund ebenfalls vollständig das native Docker verwendet, ist auch hier eine Unterdrückung des Neustarts möglich. Dazu muss das Häkchen "Container zur Übernahme der Einstellungen bitte neu starten" deaktiviert werden:
  Container-Neustart-Einstellungen.png
• schnell eingerichtet
  Im Prinzip hast du hier vollkommen Recht. Eine Einrichtung über die bash geht deutlich schneller von der Hand, wenn man firm in der Benutzung der Gui ist. Ich selbst habe für diese wiederkehrenden Aufgaben Skripte geschrieben, welche lediglich gestartet werden müssen. docker-compose übernimmt hier das Updaten und die passende Konfiguration der Dienste.
• Verzeichnis Wahl
  Jup - man hat auf der Konsole auch die Möglichkeit, Verzeichnisse zu nutzen, welche nicht in der Oberfläche angeboten werden. Würde ich ebenfalls als Vorteil sehen

Zu deinem Negativ-Punkt:

• Gefühlt langsamer
  Ich glaube nicht, dass eines der beiden Systeme tatsächlich langsamer oder schneller ist. Die ContainerStation verwendet ja im Hintergrund auch nur docker. Ich kann mir maximal vorstellen, dass auf der bash manuell ein paar Befehle mehr, wie z.B. das Pullen der aktuellsten Version, ausgeführt werden, die an der Oberfläche so entfallen. Im laufenden Betrieb sollte sich die Performance gar nicht unterscheiden.

Zum Update:

Da gibt es verschiedene Varianten. Ich habe Skripte geschrieben, die sich das aktuellste Image des benötigten Basis-Image pullen und nachher automatisch per docker-compose auf Basis dieser neuen Images einen neuen Container erstellen. Das Ganze könnte auch manuell durchgeführt werden, erfordert jedoch, dass bei jedem Update sämtliche Einstellungen (wenn das Update über die ContainerStation durchgeführt werden soll) neu konfiguriert werden müssen. Dabei müssen die lokal liegenden Volumes wieder korrekt mit dem Image verbunden werden.

Ich hoffe, meine Antworten waren nicht allzu verwirrend

Ciao
ariaci

Hallo,

ich habe gerade die Anleitung zu NextCloud fertiggestellt. Wer mag, kann diese mal ausprobieren und inspizieren

Zu finden ist diese hier:
[Howto] Nextcloud mittels Docker-Container

4) NextCloud-Instanz konfigurieren

• Browser starten und Über Namen des "http://<Namen oder IP des NAS>:<Port>" NextCloud aufrufen
  04 nextcloud in Aktion Ersteinrichtung - Schritt 1.png
  Hier erfolgt das Basis-Setup von NextCloud. Gebt hier den Nutzernamen und ein Passwort für euren Administrator zu NextCloud ein. Weiterhin konfiguriert ihr hier eure zu nutzende Datenbank. Im Standardfall verwendet NextCloud SQlite. Dies ist jedoch nicht empfehlenswert. Zur Konfiguration auf das Feld "Speicher und Datenbank" klicken und auf "MySQL/MariaDB" wechseln. Nun könnt ihr euren vorab in Schritt 1 erstellten Nutzer, das dazugehörige Passwort und die zu verwendende Datenbank (sollte mit dem Namen des Nutzers übereinstimmen) konfigurieren. Als Adresse des Datenbank-Servers tragt ihr den im Schritt 3.1 verwendeten Alias-Namen ein.
  Nach Klick auf "Installation abschließen" benötigt NextCloud etwas Zeit, um die MariaDB-Datenbank mit Daten und den zugehörigen Tabellen zu füllen. Genehmigt euch hier am besten einen weiteren und lasst eure Qnap "rödeln".
• Nach Abschluss der Einrichtung
  04 nextcloud in Aktion Ersteinrichtung - Schritt 2.png
  Nach Abschluss müsst ihr nur noch den "Willkommen"-Bildschirm per Klick auf das "X" rechts oben schließen.
• Laufende und komplette eingerichtete Instanz von NextCloud
  04 nextcloud in Aktion Ersteinrichtung - Schritt 3.png
  Seht ihr diesen Bildschirm, so ist alles korrekt verlaufen und ihr habt eine laufende NextCloud-Instanz.

  
  

  
  

  HERZLICHEN GLÜCKWUNSCH!

Das war's dann erstmal von mir. Ich hoffe, ihr könnt/konntet mit dem kleinen etwas anfangen.
Und nun viel Spaß beim Nachmachen ...

3) Docker-Container für NextCloud erstellen

• Auswahl des Images "webdevops/php-apache", Klick auf "Erstellen" und Einstellung des Container-Namens
  03 php-apache-Container erstellen - Schritt 1.png
  Im ersten Schritt ist der Container-Name (Feld 1) zu vergeben. Dieser muss lokal eindeutig sein. Im Normalfall ist hier nichts anzupassen. Die restlichen allgemeinen Eigenschaften können ebenfalls beim Standard verbleiben. Nachdem alles für euch passend konfiguriert ist, genügt ein Klick auf "Erweiterte Einstellungen". Solltet ihr Probleme beim Erstellen des Containers haben und z.B. der Eingangspunkt bzw. Befehl leer sein, so schaut bitte die Allgemeinen Hinweise (Punkt 0) im "MariaDB + phpMyAdmin im Docker-Container erstellen"-Tutorial durch und befolgt die dort stehenden Punkte.
• MariaDB und NextCloud miteinander vebinden, damit eine gesicherte Kommunikation zwischen diesen Containern erfolgen kann
  03 php-apache-Container erstellen - Schritt 2.png
  Nachdem in die erweiterten Einstellungen gewechselt wurde, befindet man sich auf der Seite "Link". Über diese Seite können Docker-Container miteinander verbunden werden. Um eine Verbindung herzustellen reicht ein Klick auf "Hinzufügen" und die richtige Konfiguration der entsprechenden Werte. In der Combobox in der Spalte "Link" ist in unserem Falle der Name des Docker-Container von MariaDB auszuwählen. In meinem Fall lautet dieser "mariadb-1". Als Alias verwenden wir die Bezeichnung "db". Die Bezeichnung kann jedoch von auch frei gewählt werden. Wichtig ist, dass ihr euch den hier vergebenen Alias-Namen merkt, da später unter diesem Hostnamen MariaDB dem NextCloud-Container zur Verfügung steht. Ist dies getan, so konfigurieren wir nun die benötigten Umgebungsvariablen über einen Klick auf "Umgebung".
• Benötigte Umgebungsvariablen für den Apache-Container festlegen
  03 php-apache-Container erstellen - Schritt 3.png
  Um die Umgebungsvariablen des Docker-Containers festzulegen, müsst ihr in den erweiterten Einstellungen auf die Seite "Umgebung" wechseln. Danach seht ihr eine Liste der Variablen und deren Werte. Die dort sichtbaren Variablen werden unter dem entsprechenden Namen und mit dem festgelegten Wert an den Container übergeben. Diese stehen dann dem Container für seine Zwecke zur Verfügung. Es werden nicht immer alle konfigurierbaren Umgebungsvariablen nach außen geführt. Wichtig ist für das verwendete Apache2-Image, das die Umgebungsvariablen "APPLICATION_GID" und "APPLICATION_UID" korrekt konfiguriert sind. Mittels "APPLICATION_GID" wird die zu verwendende Benutzergruppe konfiguriert, unter der der Apache2-Dienst im Container laufen soll. Dieser sollte unter der Administrator-Gruppe der Qnap laufen, welche die ID 0 haben müsste. Mit "APPLICATION_UID" ist der zu nutzende User konfigurierbar. Dieser sollte als lokaler httpdusr des Host-Systems (eurer Qnap) laufen. Die ID des Users dürfte im Standardfall bei Qnap 99 lauten. Falls ihr euch nicht sicher seid, ob diese Werte passen, so könnt ihr diese mittels SSH, z.B. Putty und den Befehlen id -u httpdusr für die Nutzer-ID bzw. id -g httpdusr für die Gruppen-ID ermitteln.
  Sind diese beiden Werte konfiguriert, so geht es zur Konfiguration des Netzwerks per Klick auf "Netzwerk" weiter.
• Konfiguration der Ports, um auf den Apache2-Webserver für die NextCloud-Instanz über den Host zugreifen zu können
  03 php-apache-Container erstellen - Schritt 4.png
  Dieser Schritt wird nicht unbedingt benötigt, ist jedoch dann wichtig, wenn ich die NextCloud-Instanz direkt über die Adresse des NAS erreichen möchte. Im Normalfall wählt Docker beim Start des Containers einen zufälligen Port für jeden Port, der durch den Container nach außen gegeben werden soll. In unserem Fall verwendet der Apache2-Container die Standardports 80 für eine unsichere Verbindung (Standardport für Standard HTTP-Anwendungen) und 443 für eine sichere Verbindung zum Webserver. Um über den Host auf den Webserver des Containers zugreifen zu können, kann jedoch nicht in jedem Fall direkt der Port 80 oder 443 verwendet werden, da Docker ja nicht weiß, ob diese Ports bereits durch den Host belegt sind. Daher wird wird bei Nichtkonfiguration zufällige, freie Ports verwendet. Diese können hier auf feste Ports gelegt werden. In meinem Beispiel der Port 10080 für eine unsichere Verbindung und 10443 für eine sichere. Ist mein NAS über den Namen "testnas" erreichbar, so ist die Apache2-Instanz des Containers für HTTP über testnas:10080 und für HTTPS über testnas:10443 erreichbar. Der letzte Port 9000 wird auf dem Host nicht unbedingt benötigt und kann daher frei bleiben bzw. zufällig beim Start vergeben werden.
  Nachdem hier alles entsprechend konfiguriert wurde, kann auf die Konfiguration des Apache2-Contents per Klick auf "Freigabe..." gewechselt werden.
• Apache2-Inhalt außerhalb des Containers festlegen
  03 php-apache-Container erstellen - Schritt 5.png
  Wird dieser Schritt übersprungen, so wird innerhalb des Containers ein extra Datenbereich angelegt, so stellt unsere Apache2-Instanz keinerlei Inhalt zur Verfügung. Um NextCloud dem Apache2-Server zur Verfügung zu stellen, muss hier eine Verbindung zwischen dem Host-Dateisystem und unserem Container angelegt werden. Laut Dokumentation des "webdevops/php-apache"-Images steht dafür im Container der Ordner "/app" zur Verfügung. Sämtlicher dort liegender Inhalt wird durch Apache2 gehostet. Da ich in meinem Fall in Schritt 2 den Download nach "/Public" entpackt habe, verwende ich in meinem Beispiel den lokalen Ordner "/Public/nextcloud" und binde den kompletten Inhalt unter "/app" im Container ein. Im Hintergrund verwendet Docker eine Art Mount-Point. Das heißt, eine lokale Änderung wirkt sich direkt im Container und andersherum aus.
  Nachdem auch dies korrekt konfiguriert wurde, genügt ein Klick auf "Erstellen", um unseren Webserver mit Apache2 und NextCloud zu erstellen.
• Erstellen des Containers
  Die Erstellung sollte relativ flott von unserer Qnap erledigt sein. Prüfen könnt ihr dies, indem ihr euch die Konsolenausgabe (unterer Teil in der Container Station - einfach den entsprechenden Docker-Container mit dem richtigen Namen anklicken) anschaut. Nachdem der Container hoffentlich korrekt läuft, kann per Browser und unserem konfigurierten Port für eine unsichere Verbindung direkt zu NextCloud gewechselt werden.

  
  

  
  

  HERZLICHEN GLÜCKWUNSCH - DIE ERSTE HÜRDE IST ÜBERWUNDEN

2) Download und Entpacken von NextCloud zur späteren Nutzung unter Apache2

• Download von NextCloud mittels der DownloadStation der Qnap
  02 Vorbereitung Download Nextcloud - Schritt 1.png  02 Vorbereitung Download Nextcloud - Schritt 2.png
  Der passende Link zur aktuellen Version von NextCloud kann über die Website von NextCloud erfolgen. Zum Zeitpunkt dieses Tutorials war die Version 12.0.5 aktuell und unter dem Link im Screenshot erreichbar.
  02 Vorbereitung Download Nextcloud - Schritt 3.png
  Die Zieldatei kann in einem beliebigen Ordner gedownloaded werden. In meinem Fall landen diese im Download-Ordner der Qnap. Nach Klick auf "Übernehmen" beginnt der Download selbstständig.
  02 Vorbereitung Download Nextcloud - Schritt 4.png  02 Vorbereitung Download Nextcloud - Schritt 5.png
  Nach Beendigung des Downloads müssen die Dateien des Downloads noch entpackt werden. Dazu Klicken wir in der DownloadStation in der Dateiliste mit der rechten Maustaste auf den NextCloud-Download und wählen "Enthaltenden Ordner öffnen".
• Entpacken des Archives
  02 Vorbereitung Download Nextcloud - Schritt 6.png
  Nun landen wir in der FileStation unserer Qnap und können per rechter Maustaste auf den Download mögliche Aktionen auswählen.
  02 Vorbereitung Download Nextcloud - Schritt 7.png
  In unserem Fall wählen wir die Aktion "Extrahieren > Dateien extrahieren ...". Es erscheint nach Klick folgender Dialog.
  02 Vorbereitung Download Nextcloud - Schritt 8.png
  In diesem Dialog wählen wir den Zielordner. In meinem Fall landen sämtliche Dateien inkl. der gesamten Ordnerstruktur im Ordner "Public" der Qnap. Meine Empfehlung wäre hier jedoch ein eigener Ordner, da auf Public im Standardfall quasi jeder Nutzer Zugriff darauf bekommt. Nach Klick auf "Alle extrahieren" hat eure Qnap erst einmal einige Minuten zu tun.
  02 Vorbereitung Download Nextcloud - Schritt 9.png
  Solange das rot markierte Symbol sichtbar ist, entpackt eure Qnap sämtliche Dateien und arbeitet noch. Erst nachdem dieses Symbol in der Toolbar verschwunden ist, ist das Entpacken vollständig beendet. Vor Abschluss dieses Schrittes sollte NICHT mit Schritt 3) des Tutorials fortgefahren werden. Am besten lehnt ihr euch zurück, genießt einen und lasst die Qnap werkeln.

1) Anlegen des NextCloud-eigenen MariaDB-Nutzers mit der dazugehörigen, leeren Datenbank

• Einloggen mittels phpMyAdmin auf der passenden MariaDB-Instanz
  01 Vorbereitung MariaDB Database - Schritt 1.png
• Die Benutzerverwaltung öffnen
  01 Vorbereitung MariaDB Database - Schritt 2.png
• Den neuen Benutzer für unser späteres NextCloud anlegen
  01 Vorbereitung MariaDB Database - Schritt 3.png  01 Vorbereitung MariaDB Database - Schritt 4.png
  Der Benutzername und das Passwort sind frei wählbar. Punkt vier hingegen ist obligatorisch, da andernfalls lediglich der Nutzer ohne die passende Datenbank angelegt wird. Die vom restlichen System getrennte Datenbank ist jedoch aus Sicherheitsgründen sinnvoll, um einem Hacker nicht vollständigen Zugriff auf unsere MariaDB zu gewähren.
  01 Vorbereitung MariaDB Database - Schritt 5.png  01 Vorbereitung MariaDB Database - Schritt 6.png
  Wurde der Nutzer korrekt angelegt, so ist die dazugehörige Datenbank selbigen Namens im linken Bereich von phpMyAdmin zu sehen. Weiterhin ist im oberen Bereich auf der rechten Seite die passende Erfolgsmeldung sichtbar.

[NAS Typ:] TS-251+
[Firmware:] 4.3.4.0435
[Getestet:] ja
[Sonstige Modifikationen:] keine

Um den vielen Fragen nach einem Tutorial zur Nutzung von NextCloud nachzukommen, habe ich ein weiteres kleines Schritt-für-Schritt-Tutorial erstellt. Da dieses Tutorial als Voraussetzung MariaDB und phpMyAdmin benötigt, sollte vorher mein erstes Tutorial zum Thema "MariaDB + phpMyAdmin im Docker Container" durchgeführt werden. Beide Docker-Container müssen gestartet sein und sollten korrekt laufen. Andernfalls müssen die entsprechenden Felder selbstständig korrigiert bzw. korrekt gefüllt werden. Nach erfolgreicher Durchführung dieses Tutorials steht ein Apache2-Server in einem Docker-Container mit einem lauffähigen NextCloud über das unsichere HTTP-Protokoll zur Verfügung. Ich empfehle es ausdrücklich nicht, diesen NextCloud-Server direkt über das Internet nach außen zugänglich zu machen. Vor Nutzung dieser NextCloud-Instanz über das Internet sollte ein Reverse-Proxy mit einem passenden Zertifikat eingerichtet werden. Innerhalb des eigenen, privaten Netzes sollte die Nutzung in meinen Augen unbedenklich sein.

Da das offizielle NextCloud-Image Probleme unter Nutzung eines Qnap-NAS aufweist (Container beendet sich nach Wechsel auf den laufenden Container über die Qnap-GUI selbstständig, da Apache2 das Linux-Signal SIGWNDCH für sich verwendet), nutze ich für dieses Tutorial das Image "webdevops/php-apache", welches auf dem Docker-Hub zur Verfügung steht. Mit diesem habe ich bereits sehr positive Erfahrungen sammeln können

Dieses Tutorial besteht im wesentlichen aus den folgenden vier Punkten:

• Anlegen des NextCloud-eigenen MariaDB-Nutzers mit der dazugehörigen, leeren Datenbank
• Download und Entpacken von NextCloud zur Nutzung unter Apache2
• Docker-Container für NextCloud erstellen
• NextCloud-Instanz konfigurieren

Ich habe das gesamte Tutorial auf mehrere Antworten verteilt, da ich sonst Probleme mit dem bestehenden 10.000-Zeichen-Limit des Forums hatte und leider noch nix vom Blog wusste - Vieln Dank noch einmal an Christian für den Hinweis dazu - das nächste mal werde ich dort schreiben ...

Aber nun genug geredet - "Let's fetz" und viel Spaß

Guten Morgen,

sorry - bei mir geht es etwas schleppend mit dem Tutorial zu Nextcloud voran. Das offizielle Image bindet den Apache2 ein und der hat ein Problem damit, wenn dieser direkt auf der Konsole interaktiv ausgeführt wird. Dann beendet sich Apache2 nämlich automatisch, da die Entwickler von Apache das Linux-Signal SIGWNDCH (was gesendet wird, wenn sich z.B. per SSH auf eine laufende Sitzung verbunden wird und sich das Fenster in der Größe auf dem Client ändert) "missbrauchen". Da sich die Qnap generell per Terminal in den Docker-Container hängt, wird dieser dadurch permanent beendet ...

Hier muss ich mir noch eine Lösung einfallen lassen.

Das eine Speicherung per docker commit möglich ist, mag sein. Es handelt sich jedoch dabei nicht um den empfohlenen Weg. Eine Benutzung des Befehls löst zwar augenscheinlich mein aktuelles Problem, kann jedoch in Zukunft zu weiteren Problemen führen. Weiterhin benötige ich zur Erstellung eines eigenen Images auf Basis eines anderen nicht das Original-Dockerfile. Meine selbst erzeugten Images basieren alle auf Images, die zwar auf gitlab das Dockerfile anbieten, jedoch habe ich diese noch nie benötigt.

Dies zeigt auch schon ein Blick in die Dokumentation des Dockerfile (https://docs.docker.com/engine…uilder/#parser-directives). Die FROM-Direktive benötigt laut Dokumentation ein Name eines bestehenden Images. Beim Bauen eines eigenen Images über docker build kann man dies auch sehr gut sehen. Es werden alle benötigten Layer einzeln gedownloaded. Am Ende werden diese per Overlay-Technik zu einem virtuellen Dateisystem gebunden.

Somit wird lediglich ein eigenes Dockerfile benötigt, was über die FROM-Direktive ein lokal vorhandenes Image als Basis verwendet und über weitere RUN-Direktiven dieses erweitert. Dieses Konzept habe ich selbst schon unter Linux- und Windows-Docker probiert.

Guten Morgen

Selbst in so einem Fall ist ein manuelles apt-get im Docker-Container nicht sinnvoll, da nach Updates, evtl. Restarts usw. immer wieder sämtliche Updates hinüber sind. Normalerweise basieren viele Images auf dem latest-Stand der betroffenen Betriebssysteme. Sollte ich mal einen erwischen, der doch nicht auf dem aktuellsten Stand ist, dann wäre der eher sinnvollere Weg, ein eigenes lokales Image auf Basis des "alten" Images zu erzeugen und beim Erzeugen über das Dockerfile und Docker die passenden Updates einzuspielen.

Docker ist nicht ohne Grund in eine Anwendungs- und Datenschicht geteilt. Die Anwendungsschicht ist zwar im Laufenden Zustand änderbar, aber die Änderungen sind nicht persistent. Persistente Änderungen können nur auf Verzeichnisse durchgeführt werden, die als ein volume mit dem Host "verbunden" sind. Dort liegen dann sämtliche Änderungen und diese "überleben" auch Neustarts oder Updates.

Ciao
ariaci

Moin,

HTTPS funktioniert mit dem offiziellen NextCloud-Image nicht ohne weiteres "out of the box". Der dahinterliegende Webserver ist nur für HTTP konfiguriert. Um HTTPS trotzdem zu ermöglichen muss der lokale Apache der Qnap als Reverse-Proxy zum Docker-Container konfiguriert werden. Leider kann ich dir da nicht helfen, da ich das selbst noch nie umgesetzt habe und nur weiß, dass es theoretisch funktionieren müsste. Auf dem Docker-Hub findest du unter NextCloud die passende Hilfestellung. Dort gibt es eine extra Sektion für HTTPS. Ich hoffe, das hilft dir etwas weiter.

Ein anderer Weg wäre, dir ein lokales, eigenes Image auf Basis des offiziellen Images zu bauen und dann dieses als Grundlage für deinen Container zu verwenden. Diesen Weg fahre ich bei all meinen verwendeten Containern. Damit habe ich etwas mehr Möglichkeiten ein Image an meine Anforderungen anzupassen. Es handelt sich dabei allerdings um den komplizierteren Weg.

Ciao
ariaci