After reading https://success.docker.com/article/ucp-2-0-service-discovery and other interesting related topics, one thing was still quite unclear: when exactly the VIP of a docker service change.
From what I know of Docker Swarm, a service (when created) gets assigned a virtual IP address representing the logical service unit. This IP address will then be used for routing within by Docker DNS and load balancer. In which scenarios would this VIP change? This is important because other services (such as NGINX or Varnish) will cache the resolved IP of configured upstream servers (which will resolve to the VIP) on startup.
When testing locally (Docker for Mac), I get the following results, but I cannot say if this can vary or not. My simple test consisted of pinging the service from within another service in the stack and inspecting the resolved IP. This was tested on a single host.
Removing the entire stack and re-creating it will give it a new VIP. This one was probably pretty obvious.
Removing the service from the Swarm stack (docker service rm X) and re-deploying the stack (effectively just updating all services and re-creating X) will give it a new VIP.
Scaling the service does not seem to give it a new VIP. I tried scaling 1 -> 3 -> 5 -> 0 -> 1 here, always retaining the VIP, though resolving to 127.0.0.1 while scaled to 0 (expected?).
Updating the service (by re-deploying the same stack) retains the same VIP.
Updating the service by docker service update X --force retains the same VIP.
Should I expect the VIP to stay allocated (fixed) while the service is deployed in the stack (scaled to 0 or otherwise)? Would this be something that differs between Docker for Mac and *NIX Docker?