Account for latency in container removal
Under certain conditions when watchtower is monitoring a Docker Swarm cluster there would be cases where an updated container could not be started because the old hadn't yet been removed (name conflicts, mapped port conflicts, etc). We suspect that this has something to do with the async nature of swarm and even though we've asked the swarm master to remove a container it may not be completely removed from the associated node. The fix is to do some polling after the remove container call to ensure that the container is truly gone before proceeding.pull/1/head
parent
e06c46552a
commit
e21c21ec3b
Loading…
Reference in New Issue