About [0]/[1]: I guess you are right in this not working out of the box, but this could possibly be worked around with a custom entrypoint that behaves differently on which slot the task is running in.
> (Since when you restart a stack to add the new service, the old service will also get restarted. If I'm remembering what I found correctly.)
Are you sure the Docker Image digest did not change? Have you tried pinning an actual Docker Image digest?
> Then there's updating services/replicas. You cannot have Swarm kill a service/replica until after the replacement is actually up and running. Which means you'll need to create a new volume every time you need to upgrade, otherwise you'll end up with two instances of your app using the same data.
Is this true even with "oder: stop-first"?
> To complicate things, as far as I can tell, Swarm doesn't yet support CSI plugins. So you're pretty much stuck with local or nfs storage. If you're using local storage when deploying new replicas/services, you better hope the first replica/service starts up on same node it was on before...
True, but there are still some volume plugins that work around and local storage should work if you use labels to pin the replicas to nodes.
