I'm on Alpine Linux 3.13.2, iptables-1.8.6-r0, and docker-20.10.3-r0.
I'm trying out Graylog 4 using their sample docker-compose .yml file. I got Graylog running as expected, then did docker-compose ... down, so I could start customizing the config. And that's when the problems started. But, even if I didn't change the config, the next docker-compose ... up -d, would result in the web UI's connection timing out. My eventual workaround was simply to change all the port-forwards every time I bounced the containers (E.g. 9000:9000 became 9001:9000, then 9002:9000, etc.).
Ultimately, after a LOT of research, I discovered that old the port-forwarding rules that Docker setup in the nat table on the DOCKER chain were not being deleted after a docker-compose ... down. (FYI: All the rules pertaining to previous instances remain.) So what I did was use iptables-save, edit the saved file to delete the old rules, then apply my edits with iptables-restore. After that, I could connect to the Graylog UI again, without needing to change the ports or bounce the containers.
So the meat of the question is: Is this expected Docker behavior or a bug? FYI: The most I see logged at "/var/log/docker.log" is a warning that my Linux instance doesn't have "ip6tables".
I presently expect that my new workaround will be to see how I can tell Docker to statically assign internal IP addresses for my containers.
Tangent
And hopefully this will also happen to "fix" the other problem I have at reboot where docker experiences one of those
iptables failed: ... Another app is currently holding the xtables lock. Perhaps you want to use the -w option?\n (exit status 4))
errors and fails to start up my graylog container. Because maybe all those rules it leaves behind are triggering a race condition somehow?
