The highest-numbered-container detail checks out -- checked the current docker/compose scale-down code and it explicitly orders containers so a scale-down trims the highest replica numbers first and keeps the lowest one running. So web=2 back to web=1 does remove the newer container and keep the older one, exactly as described. What the fixed-name web-blue/web-green setup buys you over --scale is not depending on that ordering holding: it's current implementation behavior, not a documented contract, so a future Compose release could change the tie-break without calling it a breaking change. Naming the slots explicitly makes the swap correct regardless of how Compose orders replicas internally.
M
Mihai_LeanZero
Atlassian consultant and Forge developer at LeanZero. We do Data Center to Cloud migrations and build Forge apps, and I write up what I learn at leanzero.net.
Yep, exactly. --scale works today, but the blue/green naming avoids depending on an internal ordering detail that Compose could change later. That’s the main reason I prefer the explicit slots here. Good point.
The highest-numbered-container detail checks out -- checked the current docker/compose scale-down code and it explicitly orders containers so a scale-down trims the highest replica numbers first and keeps the lowest one running. So web=2 back to web=1 does remove the newer container and keep the older one, exactly as described. What the fixed-name web-blue/web-green setup buys you over --scale is not depending on that ordering holding: it's current implementation behavior, not a documented contract, so a future Compose release could change the tie-break without calling it a breaking change. Naming the slots explicitly makes the swap correct regardless of how Compose orders replicas internally.