Closed mlollo closed 3 years ago
I think I've got something working on branch ufw-threads.
I'm not sure this is the right approach, from what I am understanding subprocesses are running at the same time ufw commands and ufw can't handle requests at the same time. Some time rules were updated and some time not. With threading and a lock rules are updated correctly.
For readability I could put the lock at the beginning and the end of the handler handle_ufw_rules
. This will make ufw rules to appear in order when running ufw status
command.
That's a great observation ! and makes sense.
ufw-threads branch is up to date with ufw-comment idea. It was tested on debian 10.8 docker 20.10.5. One can argue that ufw-docker-automated is quite slow to keep up if docker containers restart at a fast pace. This delay depends on the number of ufw rules and spawned containers. But there is a stability in the long run (could be in minutes if you spawn 50/100 containers). This could be tested at a large scale when spawning hundreds of containers.
This issue is a consequence of using docker API to retrieve container information. When a container dies, the container doesn't exists anymore. The docker API call fails and returns nothing. Hence ufw rules are not cleaned properly. This issue is fixed in PR #14
I abandoned ufw-threads branch because there is no point of using threading if it can't update ufw rules simultanously (I had to use locks). ufw-update-onrestart branch is the most recent version that I use currently.
docker-compose
I think the script can handle one event at a time, when it needs to continue to listen to other events. Maybe with subprocess the script could open a dedicated child process for cleaning rules for a container and continue to listen on the main process ?