Docker Container plötzlich mit 192.168.0.0.0/16 statt 172.17.0.0.0/16: verlorene Dienste
Meine Docker -Anwendungen konnten plötzlich keine E-Mails über den Host Postfix MTA senden. Ich habe dies behoben, indem ich einen Docker Standard-Adresspool angegeben habe, aber es ist besser, dies vor der Bereitstellung zu tun.
Ich habe einen ISPConfig Server mit Docker Anwendungen. Sie verwenden den Host Postfix Mail Transfer Agent (MTA), um E-Mails an die Außenwelt zuzustellen. Vor der Nutzung der Sende-Mail-Funktion habe ich geprüft, ob Postfix erreichbar ist. Das funktioniert einwandfrei. Aber plötzlich wurde keine Post verschickt. Die Protokolldatei enthielt Fehlermeldungen wie:
2019-11-26 17:31:56,758 ERROR MailMessage - send_mail: self.error_message = sending message, e = {'joe@example.com': (554, b'5.7.1 <joe@example.com>: Relay access denied')}
2019-11-26 17:31:56,759 ERROR MailSend - send during send, errors = send - sending message, e = {'joe@example.com': (554, b'5.7.1 <joe@example.com>: Relay access denied')}
2019-11-26 17:31:56,759 ERROR AddonContactForm - send_contact_form: mail_sender.get_errors() = send - sending message, e = {'joe@example.com': (554, b'5.7.1 <joe@example.com>: Relay access denied')}
Relaiszugriff verweigert? Warum? Dann erinnerte ich mich daran, dass Postfix eine mynetworks Einstellung in der Datei hat:
mynetworks = 127.0.0.0/8 [::1]/128 172.16.0.0/12
Dies führte mich zu den IP-Adressen, die Docker den Containern zugewiesen hat:
systemctl status docker
mit Ergebnis:
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2019-10-16 21:26:07 CEST; 1 months 11 days ago
Docs: https://docs.docker.com
Main PID: 765 (dockerd)
Tasks: 28
Memory: 53.7M
CPU: 39min 54.387s
CGroup: /system.slice/docker.service
├─ 765 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
├─ 9784 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8001 -container-ip 192.168.32.2 -container-port 8001
└─18316 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8000 -container-ip 192.168.176.2 -container-port 8000
Die Docker -Container verwendeten plötzlich das 192-Subnetz anstelle des 172-Subnetzes. Ich verstehe (immer noch) nicht, warum das passiert ist, aber es musste gelöst werden. Nach einiger Suche habe ich die Lösung für das Problem gefunden. Vom untenstehenden Link:
..... haben wir folgende Netzwerkreichweite für Brückennetze.
"172.17.0.0/16", "172.18.0.0/16", "172.19.0.0/16", "172.20.0.0/14", "172.24.0.0/14" "172.28.0.0/14", "192.168.0.0/16"
Wenn wir ein Netzwerk erstellen, prüfen wir, ob das Netzwerk überlappend ist, nur innerhalb von im Docker erstellten Netzwerken. Wir haben die Unterstützung des Standard-Adresspools für das Bridge-Netzwerk hinzugefügt. Sie können es über die Datei daemon.jason oder Input-Param konfigurieren, während Sie Docker Daemon starten. Auf diese Weise können Sie ein Subnetz auswählen, das dockerD erstellen soll ( Standardgateway oder Netzwerk).
Ich habe die Standard-Adresspools für meine Docker -Netzwerke beim Erstellen der Datei angegeben (sie war nicht vorhanden):
/etc/docker/daemon.json
mit dem Inhalt:
{
"default-address-pools":
[
{"base":"172.17.0.0/16","size":24}
]
}
Dann habe ich Docker neu gestartet:
systemctl restart docker
Die Container hatten noch 192 Subnetz-IP-Adressen. Dann habe ich es für die Docker Anwendungen getan:
docker-compose .... down
docker-compose .... up -d
Jetzt hatten sie wieder 172 Subnetz-IP-Adressen und die Mail kam wieder raus! Um sicher zu gehen, habe ich auch den Server neu gestartet und war froh zu sehen, dass alles in Ordnung war.
Einige Befehle zum Testen
Mit dieser Methode, siehe auch Link unten, können Sie überprüfen, ob das richtige Netzwerk erstellt wurde:
docker network create foo
docker network inspect foo | grep Subnet
Einige andere Befehle, die ich im Prozess verwendet habe:
route -n
docker inspect <container>
docker network ls
docker network inspect <network>
Zusammenfassung
Ich weiß immer noch nicht, was dieses Problem verursacht hat, aber glücklicherweise können Sie ein Subnetz für das Standardnetzwerk angeben. Dies sollte bei der Verwendung von Docker unbedingt stärker betont werden! Sie können auch Standard-Subnetze in docker-compose angeben, aber ich habe dies nicht getestet. Jedenfalls gelöst.
Links / Impressum
Allow user to specify default address pools for docker networks #29376
https://github.com/moby/moby/pull/29376
Configuring Docker to not use the 172.17.0.0 range
https://serverfault.com/questions/916941/configuring-docker-to-not-use-the-172-17-0-0-range
Docker (compose?) suddenly creates bridge using 192.168.16.0/20 range #37823
https://github.com/moby/moby/issues/37823
How does compose chooses subnet for default network? #4336
https://github.com/docker/compose/issues/4336
networks
https://docs.docker.com/compose/compose-file/#networks
Mehr erfahren
Docker
Neueste
- Ausblenden der Primärschlüssel der Datenbank UUID Ihrer Webanwendung
- Don't Repeat Yourself (DRY) mit Jinja2
- SQLAlchemy, PostgreSQL, maximale Anzahl von Zeilen pro user
- Anzeige der Werte in den dynamischen Filtern SQLAlchemy
- Sichere Datenübertragung mit Public Key Verschlüsselung und pyNaCl
- rqlite: eine hochverfügbare und distverteilte SQLite -Alternative
Meistgesehen
- Verwendung von Pythons pyOpenSSL zur Überprüfung von SSL-Zertifikaten, die von einem Host heruntergeladen wurden
- Verwendung von UUIDs anstelle von Integer Autoincrement Primary Keys mit SQLAlchemy und MariaDb
- PyInstaller und Cython verwenden, um eine ausführbare Python-Datei zu erstellen
- Verbindung zu einem Dienst auf einem Docker -Host von einem Docker -Container aus
- SQLAlchemy: Verwendung von Cascade Deletes zum Löschen verwandter Objekte
- Flask RESTful API Validierung von Anfrageparametern mit Marshmallow-Schemas