Docker containers die plotseling 192.168.0.0.0/16 gebruiken in plaats van 172.17.0.0/16: diensten die verloren gaan.
Mijn Docker applicaties konden plotseling geen mail meer versturen via de host Postfix MTA. Ik heb dit opgelost door een Docker standaard adres pool op te geven, maar het is beter om dit te doen voor de implementatie.
Ik heb een ISPConfig server met Docker toepassingen. Zij gebruiken de host Postfix mail transfer agent (MTA) om post naar de buitenwereld te brengen. Voordat ik de functie send mail gebruik heb ik een controle of Postfix toegankelijk is. Dit werkt prima. Maar plotseling werd er geen post meer verstuurd. Het logbestand bevatte foutmeldingen zoals:
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')}
Relais toegang geweigerd? Waarom? Toen herinnerde ik me dat Postfix een mynetworks instelling heeft in het bestand:
mynetworks = 127.0.0.0/8 [::1]/128 172.16.0.0/12
Dit leidde me naar de IP-adressen die door Docker aan de containers zijn toegewezen:
systemctl status docker
met resultaat:
● 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
De Docker containers gebruikten plotseling het 192 subnet in plaats van het 172 subnet. Ik begrijp (nog steeds) niet waarom dit is gebeurd, maar het moest worden opgelost. Na wat zoeken heb ik de oplossing voor het probleem gevonden. Van onderstaande link:
.... door het ontwerp hebben we een netwerk bereik voor brugnetwerken.
"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"
Wanneer we een netwerk creëren, controleren we alleen of er sprake is van een overlappend netwerk binnen een door de docker aangemaakt netwerk. We hebben standaard adrespool ondersteuning voor bridge netwerk toegevoegd. U kunt het configureren via daemon.jason bestand of input param tijdens het starten van Docker Daemon. Op die manier kunt u subnet kiezen dat u wilt dat dockerD aanmaakt (standaard gateway of netwerk).
Ik heb de standaard adrespools voor mijn Docker netwerken gespecificeerd door het bestand aan te maken (het was er niet):
/etc/docker/daemon.json
met de inhoud:
{
"default-address-pools":
[
{"base":"172.17.0.0/16","size":24}
]
}
Daarna heb ik Docker opnieuw opgestart:
systemctl restart docker
De containers hadden nog 192 subnet IP adressen. Daarna deed ik dat voor de Docker toepassingen:
docker-compose .... down
docker-compose .... up -d
Nu hadden ze weer 172 subnet IP adressen en de mail kwam er weer uit! Om er zeker van te zijn, heb ik ook de server opnieuw opgestart en ik was blij om te zien dat alles in orde was.
Enkele commando's om te testen
U kunt deze methode gebruiken, zie ook onderstaande link, om te controleren of het juiste netwerk is aangemaakt:
docker network create foo
docker network inspect foo | grep Subnet
Enkele andere commando's die ik daarbij heb gebruikt:
route -n
docker inspect <container>
docker network ls
docker network inspect <network>
Samenvatting
Ik weet nog steeds niet wat de oorzaak van dit probleem is, maar gelukkig kun je een subnet opgeven voor het standaard netwerk. Dit moet echt meer benadrukt worden wanneer je Docker gaat gebruiken! U kunt ook standaard subnetten opgeven in docker-compose maar ik heb dit niet getest. Hoe dan ook opgelost.
Links / credits
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
Lees meer
Docker
Recent
- Database UUID primaire sleutels van je webapplicatie verbergen
- Don't Repeat Yourself (DRY) met Jinja2
- SQLAlchemy, PostgreSQL, maximum aantal rijen per user
- Toon de waarden in SQLAlchemy dynamische filters
- Veilige gegevensoverdracht met Public Key versleuteling en pyNaCl
- rqlite: een alternatief voor SQLite met hoge beschikbaarheid en distributed
Meest bekeken
- Met behulp van Python's pyOpenSSL om SSL-certificaten die van een host zijn gedownload te controleren
- Gebruik van UUIDs in plaats van Integer Autoincrement Primary Keys met SQLAlchemy en MariaDb
- PyInstaller en Cython gebruiken om een Python executable te maken
- Maak verbinding met een dienst op een Docker host vanaf een Docker container
- SQLAlchemy: Gebruik van Cascade Deletes om verwante objecten te verwijderen
- Flask RESTful API verzoekparametervalidatie met Marshmallow-schema's