Use environment variables for network setup
The current setup uses manually assigned IPs, which need to be set up on docker-compose. This is limiting the ability to deploy mailman on environments where those IPs are already assigned or reserved by a software-defined network.
Changes would be needed at least on docker-compose.yaml, as well as on config files (e.g. settings.py), if we want to be able to setup mailman on networks with dynamic address assignment.
I was assuming that most of the people would override the default settings in the settings.py using a settings_local.py that can be placed at /opt/mailman/web/ on the host and will be imported by the settings.py.
Also, apart from ALLOWED_HOSTS which has the assigned IP of the container (172.19.199.3), all other settings are configurable by environment variables. I see that mailman-core's address uses the hostname which can be assumed to be True when using the compose file but can be overridden by using the method mentioned above.
About changes in the compose file that is True, but I don't think there is any way for me to accommodate all the requirements in a single compose file, I think for special requirements, it is possible to edit the compose file or maybe just add another one to override some of the settings instead of creating a new one.
If there is any other setting that you feel are hard coded in the configuration and cannot be changed without tinkering with the image itself, please let me know?
Is there any reason that Docker's hostname-based networking isn't used?
@ishitatsuyuki Hostname based networking works best for communication between the containers. But I have no idea how to do make the host aware about the hostnames.
MTA and Webserver need to be able to connect to the containers for which I have settled on using this method.
Answer: Docker Compose expose section.
Expose doesn't bind anything to the host, it is only a directive for the linked containers about the open ports AFAIK.
If you actually meant port binding to a host port and the accessing the services, I don't like that method particularly because it doesn't play well with iptables and bypasses firewall.
Oops, not expose, I meant port.
What do you mean by "bypass firewall"? I think it simply binds to localhost.
The way it binds to localhost is by manipulating iptable rules because of which, if lets say ,you have port 8080 blocked in your firewall and if you bind 8080 from your container to the host, it gets exposed to outside.
@maxking Shouldn't this issue be closed? As I understand it it was fixed with release 0.4.0.
This issue has not been updated for more than 1year