Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[OliverIO]

@mcbirne sagte in Update vom Container gemacht und nun läuft nichts mehr:

es sollte keine eigene andere IP Adresse sein, da ich auf die Admin Konsole mit der gleichen IP komme, die ich auch für phpMyAdmin brauch.

wenn du mit docker arbeitest, dann sollten die einzelnen services auch in eigenen container sitzen. wenn man das nicht will und alles in einem vereint haben will, dann sollte man eine vm benutzen, da die vorteile von docker dann eh verloren sind.

leider hast du noch nichts erzählt, wie die konstellation genau ist. bei docker gibt es viele möglichkeiten

ich gehe mal davon aus, das du kein macvlan konfiguriert hast, mit dem du einzelnen container eine eigene ip adresse aus deinem lan vergeben kannst.
wahrscheinlich hast du die container im bridge modus laufen. dh die ports innerhalb des containers werden auf ports deiner synology gemappt.
daher musst du im iobroker by der db konfiguration auch die ip oder namen deiner synology eintragen + ggfs noch den port 3306 (falls durch mapping nicht geändert)

127.0.0.1 kann es definitiv nicht gewesen sein, ausser du hast die datenbank im iobroker installiert. aber wie gesagt, das würde ich nicht machen.

[Codierknecht]

@oliverio
Wer auf seiner Synology nicht noch etwas betreibt, das mit den Ports des ioBroker kollidiert, sollte den Container besser im Host-Mode betreiben.
Eher früher als später fehlt sonst mal wieder ein Port im Mapping.

[OliverIO]

@codierknecht

hm verstehe ich nicht so ganz.
durch den hostmode erhält der containre doch nicht automatisch eine eigene ip aus dem lan.
ich hab den unterschied immer so gesehen, das die container bei bridge netzwerktechnisch voneinander isoliert sind und bei host nicht.

port mapping konflikte kannst du aber bei beiden bekommen.
daher setze ich macvlan ein. da kann ich einem container eine eigene ip zuordnen. broadcasts funktioniert dann auch wunderbar im lan.

ich kenne allerdings nur die docker terminologie und weiß nicht ob synology unter host mode etwas anderes versteht
https://docs.docker.com/network/drivers/host/

nachtrag:
https://kb.synology.com/de-de/DSM/help/Docker/docker_network?version=6
ne kein unterschied

evtl hier meine sichtweise
meine hostmaschine hat die ip
192.168.1.10
bridge modus
erster container 172.17.0.1
erster container 172.17.0.2
host modus
erster container 172.17.0.1
erster container 172.17.0.1

innere ports werden durch portmapping auf der host-maschine verfügbar gemacht.

bei macvlan erhält der container eine echte eigene ip-adresse, da der macvlan-treiber eine weitere virtuelle netzwerkkarte mit eigener MAX-Adresse (was die voraussetzung für eine eigene IP ist) erzeugt

[mcBirne]

@oliverio
OK, das Teil läuft auch auf meinem Docker im bridge Modus.

Meinen IO Broker erreiche ich mit 192.168.178.84:8081
Daher habe ich jetzt bei server IP al die 192.168.178.84 eingetragen. Mit folgendem Ergebnis:

Wie kann ich es dem Host erlauben auf die Datenbank zuzugreifen?

[OliverIO]

@mcbirne

die container dürfen immer nach kontakt aufnehmen. kenne da keine beschränkung.
kannst du mal schauen was im log steht?
mich wundert es etwas, das da die container ip steht (weiß aber nicht ob es die vom iobroker oder von mysql ist)
funktioniert den dein myphpadmin mit dem zugriff?
wenn nicht, dann stimmt was nicht mit der datenbank

nachtrag: ist die ip des iobrokers

[Codierknecht]

@oliverio sagte in Update vom Container gemacht und nun läuft nichts mehr:

durch den hostmode erhält der containre doch nicht automatisch eine eigene ip aus dem lan.

Nein - das natürlich nicht.
Aber die meisten Probleme handeln sich die User im Bridge-Mode ein, weil sie dann vergessen die benötigten Ports zu mappen.

Macvlan ist für die allermeisten auch schon ein paar Stufen zu hoch.

In der Regel dürfte die Synology lediglich als Datengrab dienen.
Ein ioBroker-Container im Host-Mode dürfte da keine Portkonflikte verursachen.

[OliverIO]

@codierknecht sagte in Update vom Container gemacht und nun läuft nichts mehr:

Ein ioBroker-Container im Host-Mode dürfte da keine Portkonflikte verursachen

wenn du nur iobroker drauf laufen lassen hast?
ich hab hier ca 20 container laufen, aber nicht alle mit einer eigenen ip
ok keine syno aber ein nuc. unterschied ist ja nur, das da keine große festplatte dran ist.
da musste ich schon einige mit anderen ports mappen und dann über einen reverseproxy wieder für mich einfach machen

[mcBirne]

@oliverio der phpMyAdmin Zugang funktioniert

[mcBirne]

@codierknecht said in Update vom Container gemacht und nun läuft nichts mehr:

e meisten Probleme handeln sich die User im Bridge-Mode ein, weil sie dann vergessen die benötigten Ports zu mappen.
Macvlan ist für die allermeisten auch schon ein paar Stufen zu hoch.

OK, kann ich den Container nachträglich auf den Host Modus umstellen?

[Codierknecht]

@mcbirne sagte in Update vom Container gemacht und nun läuft nichts mehr:

OK, kann ich den Container nachträglich auf den Host Modus umstellen?

Nein. Das lässt sich - zumindest mit den Bordmitteln der Synology - nicht ändern.

[Codierknecht]

@oliverio
Die wenigsten User haben hier eine Synology am Start, die potent genug wäre um da mit vielen Containern Probleme zu produzieren.

Auf Deinem NUC sieht das natürlich ganz anders aus.
Aber Du weißt ja auch was Du da tust ;-)

[mcBirne]

@codierknecht
OK, dann werde ich einen neuen Container aufsetzen und nicht den Bridge Mode verwenden.
Das zurückspielen des Backup hat ja gut funktioniert.
Sollte ich bei der Erstellung des Containers noch andere Dinge beachten?

[OliverIO]

@mcbirne

ich denke es liegt nicht an bridge/host
evtl benötigt man im iobroker noch das package

mysql-client

bin mir aber nicht sicher
einfach in die environment variable package eintragen, dann wird das paket bei der containererstellung mit installiert
https://docs.buanet.de/de/iobroker-docker-image/docs/#umgebungsvariablen-env

[Codierknecht]

@oliverio
Hatte ich bei mir nicht aktiv.
Dafür aber den SQL-Adapter. Der hat fleißig in MariaDB geloggt.
Vielleicht installiert der ja hintenrum das Package?

[OliverIO]

@codierknecht
in der anleitung des sql-adapters steht das so drin.
allerdings nur zusammen mit dem sqlserver.
für remote stand da jetzt nix

aber wenn das drauf ist, dann könnte er mal über die console den client aufrufen und schauen ob da eine bessere fehlermeldung kommt

[mcBirne]

@oliverio nach dem neuen Aufsetzten des Containers ohne Bridge klappt der SQL Adapter wieder. Auch die anderen beiden Adapter sind wieder grün.

[Homoran]

@mcbirne sagte in Update vom Container gemacht und nun läuft nichts mehr:

@oliverio nach dem neuen Aufsetzten des Containers ohne Bridge klappt der SQL Adapter wieder. Auch die anderen beiden Adapter sind wieder grün.

so sind halt Container