Das eigene Subnetz in einem Docker-Container erkennen

Container-Umgebungen laufen in einem eigenen IP-Subnetz. Dieses kann zum Beispiel in docker-compose.yaml statisch definiert werden. Gerade in automatisierten Umgebungen kann dies zu Adresskonflikten führen. Daher empfiehlt sich eine dynamische Adressvergabe.

Was jedoch, wenn im Container laufende Applikationen das eigene Subnetz kennen müssen? Dieser Post stellt diesen Fall dar. In der Praxis sollten Mails aus einem NodeJS-Programm versendet werden. Zur besseren Kontrolle und zum asynchronen Versand kam ein lokaler Postfix-Daemon zum Einsatz. Dieser wurde als eigener Microservice realisiert.

Postfix ist in seiner Standard-Konfiguration so eingestellt, dass es Mails zu externen Domains entweder nur von Clients weiterleitet, die per SASL authentifiziert sind oder welche mit IP-Adressen senden, die in mynetworks eingetragen sind. Im Letzteren könnte man natürlich nun 0.0.0.0 eintragen, jedoch ist das auch in einem abgeschlossenen Docker-Netzwerk nicht die feine Art. Eine Authentifizierung über SASL würde weitere zwei Konfigurationsparameter für das CI/CD-System erfordern, weswegen sich hier die Angabe des eigenen Subnets anbietet.

Hierfür bietet Postfix praktischerweise direkt eine eigene Direktive:

mynetworks_style = subnet

Allerdings weißt schon die Dokumentation darauf hin, dass dies nur auf Systemen funktioniert, die über ip oder ifconfig konfiguriert sind. In der hier gewählten bullseye-slim-Containerumgebung war dies nicht der Fall.

Zahlreiche Posts im Internet verweisen richtigerweise auf eine Kombination des ip-Commands in Kombination mit grep und awk. Jedoch bekommt man in diesem Fall zwar korrekterweise die Subnetzmaske und die eigene IP, jedoch nicht im Netzwerkformat, so wie Postfix es erwartet. Abhilfe schafft in diesem Fall die Ausgabe des route-Commands, welcher das Subnetz + Maske so ausgibt, wie es in der Postfix-Konfiguration verwendet werden kann:

mynetworks = 127.0.0.1,$(/sbin/ip route | grep "link src" | awk '{print $1}')