Docker-Container können nicht auf lokale MariaDB zugreifen (Timeout)

[EDvonSchleck]

Kannst du noch einmal einen User wie hier beschrieben anlegen?

 

[MattCB]

Du meinst, den User anlegen und gleich eine gleichnamige Datenbank? So hatte ich es getan.

 

[EDvonSchleck]

Ja, das meine ich.
Ich kann es gerne noch einmal hier nachstellen, das wird aber wie beim letzten Mal auch funktionieren.

 

[MattCB]

Nee, lass mal gut sein. Trotzdem Danke für das Angebot.

Irgendwas bockt auf meiner Synology. Wie gesagt: greife ich mit den Docker-Containern aus der VM auf die MariaDB auf der Synology zu, geht alles. Mittlerweile sogar ein testweise installierter Nextcloud-Container, der die MariaDB nutzt.

Ich könnte ja alle meine Container auf den Proxmox-server umziehen, aber ich möchte halt gerne alles auf der Synology machen. Die Nextcloud auf der Synology läuft ja (Version von linuxserver.io), aber halt nur mit einer SQlite-Datenbank. Und auf der Synology kann man die Docker-Ordner so easy sichern und Snapshots machen.

 

[EDvonSchleck]

Wenn das eine geht, denn auch das andere. Auch bei der Nextcloud sollte Mariadb funktionieren. Hätte es ansonsten noch einmal durchgetestet. Sieht ja fast aus, als ob es an der Firewall hängt.

 

[MattCB]

Die Firewall auf der Synology habe ich ausgeschaltet. Neustart der Synology hat auch nix gebracht, die lief vorher schon 14 Tage durch.

Wenn es an der Firewall liegen würde, dann würde es von der VM aber auch nicht funktionieren, nehme ich mal an. Die VM läuft aber nicht auf der Synology, sondern auf einem kleinen Intel NUC, mit dem ich zur Zeit ein bisschen mit Proxmox experimentiere.

Mir reicht es erstmal für heute. Werde wohl die Nacht von Maria(DB) träumen.

 

[EDvonSchleck]

Mir kommt es nur komisch vor, dass nur Docker betroffen sein soll. Durch die Bridge liegen die IPs in einem anderen Bereich als das Heimnetzwerk. Du kannst gerne probieren, den Container (ohne Mappings) im Hostnetzwerk (Docker) einzurichten.

 

[haydibe]

Timeout = Container kommt nicht bis zur Datenbank

Es kann nicht so viele Gründe geben die das Verursachen:
- Firewall doch nicht deaktiviert? (laut Posts: war/ist sie aus)
- MariaDB verwendet kein TCP und/oder anderen Port (laut Posts ist es aktiviert und der Port stimmt)
- Statt NAS-IP wurde der Hostname verwendet und evtl. kann der Container diesen nicht auflösen? (eher unwahrscheinlich)
- Container verwendet MACVLAN Client-Interface und versucht das NAS über die Ip des Parent-Interfaces anzusprechen (laut Posts bisher nicht der Fall)

Imho, ergibt es erst Sinn User und Grants zu überprüfen, wenn die grundsätzliche Verbindung steht.
Erst wenn das gegeben ist, könnte es noch sein, dass die IP, von der aus der User sich einloggen kann falsch sein (bei 'user'@'%' nicht möglich), das Passwort nicht stimmt, oder der Benutzer nicht ausreichende Berechtigung (Grant auf Tabele?) vorliegen.

 

[Mahoessen]

Ports:
MariaDB 5 : Port 3306
MariaDB 10: Port 3307

 

[MattCB]

Danke, dass ihr euch Gedanken macht.

Mir fiel es gestern kurz vor dem Schlafen noch ein, was ich versuchen könnte. Ich hatte die Firewall-Regeln so eingestellt, dass Zugriffe auf alle Ports nur aus dem internen Netzwerk (192.168.2.x) zugelassen sind. Zugriffe aus Deutschland nur für bestimmte Ports. Zugriffe von außerhalb DE sind komplett gesperrt.

Aber wie gesagt: die Firewall ist deaktiviert. Ich habe die Regeln trotzdem testweise noch ergänzt, so dass auch Zugriffe aus dem Netz 172.17.x.x zugelassen sind (diesen IP-Bereich hat das Bridge-Netzwerk von Docker bei mir). Keine Änderung.

Firewall über DSM zurückgesetzt: keine Änderung
Firewall deaktiviert: keine Änderung

MariaDB deinstalliert und, neu installiert. Port auf 3306 und 3307 versucht. TCP/IP Verbindung zugelassen. Keine Änderung.

Als MySQL Adresse in Baikal habe ich natürlich die IP-Adresse des NAS angegeben. Sowohl mit Port (als ich 3307) versucht habe als auch ohne Port-Angabe (als ich es mit Port 3306 versucht habe).

Also offensichtlich mache ich alles richtig. Die Zugriffe über Docker-Container auf der VM funktioniert ja (sowohl Baikal als auch Nextcloud), also steht die TCP/IP-Verbindung zu MariaDB.

Ich vermute, dass irgendwie die Firewall in der Synology verstrubelt ist. Kann man die irgendwie komplett zurücksetzen?

Baikal auf dem Hostnetz laufen lassen geht glaube ich nicht, da man für Baikal keinen anderen Port vorgeben kann. Und da Baikal Port 80 nutzt, wird das nicht funktionieren. Deshalb ja das Bridge-Netzwerk, da man da einen anderen Port mappen kann.

Mir gehen echt die Ideen aus. Bin kurz davor, ein Ticket bei Synology aufzumachen. Oder mal Docker deinstallieren und neu installieren. Da ich die wichtigsten Container per Aufgabenplanung installiere und die Daten persistent sind, sollten sie ja erhalten bleiben und die Container danach wieder sauber starten.

 

[Ulfhednir]

Vielleicht noch in die my.cnf schauen.
https://www.digitalocean.com/community/tutorials/how-to-allow-remote-access-to-mysql
https://kb.synology.com/de-de/DSM/tutorial/Can_MariaDB_settings_be_customized_on_Synology_NAS

 

[MattCB]

Die Datei gibt my.cnf es bei mir nicht. Da gibt es nur die my_port.cnf (da steht der Port 3306 drin) und die synology.cnf (da steht nur drin: skip_networking=0, also vermutlich, dass man per TCP/IP drauf zugreifen darf).

Aber ich verstehe halt nicht, warum es von einem anderen Clienten im Netzwerk absolut problemlos funktioniert. Bin kurz davor, das ganze Docker-Gedöns doch wieder auf dem Proxmox-Server laufen zu lassen und das NAS nur als Datenbank-Server zu missbrauchen. Für irgendwas muss ja der Intel NUC gut sein. ;-)

EDIT: Mal eine Frage zur Export-Funktion von Docker: ich habe vor dem Deinstallieren von Docker alle vorhandenen Container inklusive Daten exportiert. Somit sollten ja neben den Einstellungen auch die Ordner samt Daten gesichert werden. Die Dateien waren auch dementsprechend groß.

Nach dem Deinstallieren von Docker war natürlich auch der Docker-Ordner weg. Also Docker wieder installiert. Nun der erste Haken: man musste zwingend erstmal irgendeinen Container anlegen, da man sonst gar nicht in das Menü zum Importieren kommt. Und nach dem Importieren konnten die Container nicht gestartet werden, da die Ordner eben NICHT automatisch erzeugt wurden. Wozu sichert die Export-Funktion dann die Ordner, wenn dann beim Importieren die Ordner nicht automatisch erzeigt werden? Schulnote 6, liebes Synology-Team.

Gut, dass ich vor dem Deinstallieren noch mal ein Hyperbackup des Docker-Ordners angelegt habe. Somit waren alle Daten innerhalb von einer Minute wieder da und die Container innerhalb von 2 Minuten wieder hergestellt. Und jetzt teste ich das ganze nochmal.

EDIT2: Geht leider immer noch nicht. Die auf der Synology laufenden Container können nicht auf die lokal laufende MariaDB zugreifen. Ich mache in Ticket bei Synology auf...

 

[EDvonSchleck]

EDIT: Mal eine Frage zur Export-Funktion von Docker: ich habe vor dem Deinstallieren von Docker alle vorhandenen Container inklusive Daten exportiert. Somit sollten ja neben den Einstellungen auch die Ordner samt Daten gesichert werden. Die Dateien waren auch dementsprechend groß.

Ich glaube, da verstehst du etwas falsch. Der Export besteht aus den Docker-Container-Einstellungen und ggf. dem Dockerimage. Nicht enthalten sind die ausgelagerten Dateien und Ordner. Ich sichere die Images nicht, sondern nur die Einstellungen. Das geht auch ganz einfach mit einem Skript (Aufgabensteuerung bzw. zeitgesteuert).

Nach dem Deinstallieren von Docker war natürlich auch der Docker-Ordner weg. Also Docker wieder installiert.

Dazu kann ich nicht viel sagen, will das aber auch nicht unbedingt ausprobieren. Normal sollte es so sein, dass der „Docker“-Ordner, sofern dort andere Ordner enthalten sind, nicht gelöscht werden. Bei der Webstation wird nach der Deinstallation auch der „Web“-Ordner nicht gelöscht. Sollte das, so sein, Synology bitte darauf hinweisen. Aber es besteht ja auch die Möglichkeit, die bereit gestellten Ordner außerhalb von /docker zu mounten. Dort dürfte nichts angefasst werden beim Löschen.

Nun der erste Haken: man musste zwingend erstmal irgendeinen Container anlegen, da man sonst gar nicht in das Menü zum Importieren kommt. Und nach dem Importieren konnten die Container nicht gestartet werden, da die Ordner eben NICHT automatisch erzeugt wurden.

Das ist auch nicht Sinn dahinter, die Ordner musst du beim Einrichten ja auch erst einmal erstellen. Diese dienen ja nicht für den Betrieb des Docker, sondern nur für die dauerhafte Speicherung der Files und Datenbanken. Verzeichnisse zu mounten ist kein Muss, nur sind die Daten bei Neuinstallation oder neu starten des Containers weg.

Wozu sichert die Export-Funktion dann die Ordner, wenn dann beim Importieren die Ordner nicht automatisch erzeigt werden? Schulnote 6, liebes Synology-Team.

Siehe oben, Docker richtig verstehen und notfalls Ordner außerhalb von /docker benutzen.

Gut, dass ich vor dem Deinstallieren noch mal ein Hyperbackup des Docker-Ordners angelegt habe. Somit waren alle Daten innerhalb von einer Minute wieder da und die Container innerhalb von 2 Minuten wieder hergestellt. Und jetzt teste ich das ganze nochmal.

Dafür ist es ja da und der richtige Weg für eine Neuinstallation oder Umzug.

EDIT2: Geht leider immer noch nicht. Die auf der Synology laufenden Container können nicht auf die lokal laufende MariaDB zugreifen. Ich mache in Ticket bei Synology auf...

Ich denke, das ist der richtige Weg, das sollte schnell gehen und am besten auf das Entfernen des Docker-Ordners hinweisen. Bestes Beispiel Webstation, dort wird es auch so umgesetzt!

 

[Ulfhednir]

Moment mal: Du möchtest aus einem Bridge-Network ausbrechen und einen direkten Zugriff auf das Host-System ermöglichen? Ich sage mal vorsichtig: Das dürfte nicht im Sinne der Definition der Bridge sein. @haydibe bitte korrigiere mich.

Ich würde sagen: Entweder du verwendest den HOST-Modus - wo du allerdings bereits sagtest, dass sich der Port im Image wohl nicht umbiegen lässt - oder du versuchst es mal mit MACVLAN. Das könnte dann noch eher zum Erfolg führen.

 

[EDvonSchleck]

Eine Bridge in Zusammenhang mit der installierten Datenbank (MariaDB) funktioniert ohne Probleme. Das habe ich nicht nur in den Beiträgen geschrieben, sondern auch dokumentiert. Ich denke auch das Irgendwas im Hintergrund blockiert, obwohl es über die GUI nicht ersichtlich ist.

MACVLAN ist ja noch schlimmer.

Ein schönes Feature wäre, wenn Synology bei der Dockerapp eine Netzwerkkarte zuweisen lassen kann wie bei der VM. Habe bei meiner DS 4 LAN die könnte man gut dafür einsetzten anstatt das aufwendig mit MACVLAN und deren Workaround zu betreiben.

 

[haydibe]

Moment mal: Du möchtest aus einem Bridge-Network ausbrechen und einen direkten Zugriff auf das Host-System ermöglichen? Ich sage mal vorsichtig: Das dürfte nicht im Sinne der Definition der Bridge sein. @haydibe bitte korrigiere mich.

Ein Bridge-Netzwerk erlaubt den Container überall hinzukommen, wo der Host auch hinkommen kann.
Der Mehrwert ist die Isolation des Traffics innerhalb der Container-Netzwerke und der expliziten Freigabe bei Ingress-Traffic.

Im Grunde verhält es sich wie ein geNATetes Netzwerk, bei dem alle Clients in einem isolierten Netzwerk sind, ausgehender Traffic und seine Antworten funktionieren, aber für eingehenden Traffic Portforwarding gemacht werden muss. Nur mit dem Unterschied, dass man bei Docker auf die Schnelle neue Netzwerke erzeugen kann und die Portforwarding-Regel am Container klebt

 

[MattCB]

Kleiner Nachtrag:

Das ganze funktioniert übrigens auch nicht, wenn ich einen MariaDB-Server per Docker auf der Synology aufsetze. Das Paket MariaDB habe ich vorher sicherheitshalber deinstalliert, wobei man ja beides parallel laufen lassen könnte, wenn sie auf unterschiedlichen Ports laufen. Zugriffe von Containern, die direkt auf dem NAS laufen, laufen ins Timeout. Zugriffe von einem anderen Clienten im Netzwerk auf den MariaDB-Container funktionieren hingegen problemlos.

Ich werde das mal bei Gelegenheit sauber dokumentieren und Synology per Supportticket um die Ohren hauen. ;-)

 

[EDvonSchleck]

MariaDB Docker war im gleichen Netzwerk wie Baikal? Als Adresse hast du die IP, Docker-IP oder Dockernamen eingegeben?

 

[MattCB]

Der MariaDB Container auf dem NAS lief einmal als Bridge und dann nochmal zum Testen auf dem Host. Baikal lief in einem Bridge Netzwerk. Wenn sowohl MariaDB als auch Baikal als Bridge laufen, sollten sie ja beide im gleichen Netzwerk sein. Man könnte dann zwar die IP der MariaDB angeben (172.17.x.x.), aber die kann sich bei einem Neustart des Containers ja ändern. Als Adresse habe ich die IP des NAS sowie den Port 3306 angegeben. Bei Einrichtung im Bridge Netzwerk wurde Port 3306 auf Port 3306 im Container gemapped. Beim Betrieb im Hostnetzwerk brauche ich das ja nicht.

Wie gesagt: von einem Client im Netzwerk (Proxmox-Server, auf dem ich in einem LXC Container Docker zu laufen habe) ging der Zugriff auf den MariaDB-Container völlig problemlos.

Wenn ich Zeit und Muße habe, teste ich das ganze nochmal, indem ich den MariaDB Container in ein MacVLAN packe. Dann bekommt er seine eigene IP im Netzwerk und kann somit als eigenständiges "Gerät" angesprochen werden.

Eins kann ich noch versuchen: ein neues Bridge Netzwerk erstellen, dann sollte auch die DNS-Auflösung im Container funktionieren. Das geht beim Standard-Bridge-Netzwerk wohl nicht. Dann Baikal und MariaDB in dieses Netzwerk packen, dann könnte man die MariaDB ja theoretisch mit dem Containernamen statt der IP ansprechen.

 

[EDvonSchleck]

Eins kann ich noch versuchen: ein neues Bridge Netzwerk erstellen, dann sollte auch die DNS-Auflösung im Container funktionieren. Das geht beim Standard-Bridge-Netzwerk wohl nicht. Dann Baikal und MariaDB in dieses Netzwerk packen, dann könnte man die MariaDB ja theoretisch mit dem Containernamen statt der IP ansprechen.

Neue Netzwerke sind auch nur Bridge-Netzwerke. Auch unter Bridge funktioniert die Verbindung über den Namen. Komisch finde ich, dass anscheinend nur MariaDB geblockt werden, unabhängig von der Installationsmethode.

Was sagt der Synology Support dazu?

Ich benutze mein DS seit Einrichtung von DSM4.x. Upgedatet wurde bis auf die aktuelle Version 7.1.1. Update 2 ohne das System einmal zurückzusetzen. Ich habe viel ausprobiert in diesen 9 Jahren und keinerlei Probleme. Wenn du meinst, es könnte an Docker liegen – was ich aber nicht bestätigen kann. Könntest du einfach die Webstation-Version von Baikal installieren. Dazu brauchst du nur die Webstation, Apache und PHP (8) installieren und die Baikal.zip im Webordner entpacken. Das dauert keine 5 Minuten.