Add --mode=singleton for docker service create

[ktwalrus]

I need to run single task services on a swarm overlay network. In previous versions, the docker run command could be used, but the new swarm mode doesn't allow classic containers on a swarm overlay network.

I can define a service with --mode=replicated --replicas=1 --endpoint-mode=dnsrr which almost works except that the service can be scaled later by some admin in production. My single task services would break if they were scaled to more than 1 replica.

So, I request you consider implementing --mode=singleton to fix the number of replicas to 1 and use the task's IP as the service IP. Attempt to scale such a service would fail with an error as only --mode=replicated services can be scaled by an admin.

[icecrime]

In previous versions, the docker run command could be used, but the new swarm mode doesn't allow classic containers on a swarm overlay network.

This is being solved in #25962: can you please confirm that this PR could work for you?

[ktwalrus]

I think that PR would mostly work, but I only quickly skimmed all the commentary and don't exactly understand its implications.

I like the idea of --mode=singleton since I could update the service to a new image (newer version) and docker could probably do a proper replacement where the new task would come up and start receiving new connections while the old task is still available to finish its connections (so no requests to the service are lost). This is possible because the service IP would become the new task's IP for new DNS requests while clients that have the old task's IP could still have the connections started using the old task's IP serviced by the old task. Docker services could kill the old task after all requests were serviced.

Still, I think it would be better to simply add a new mode to docker service create for my use cases.

[friism]

I want to second the usefulness of this proposal, especially if there were a way to specify it in bundle files.

Imagine an app that includes a database service writing data to a volume that's using a (network backed) volume driver. In that case, you'd want at most one replica of that service running to avoid multiple replicas attempting writes. The proposed mode would be useful for that.

[AkihiroSuda]

I think user can set up some distributed lock service (e.g. etcd) for avoiding multiple replicas attempting writes

[cpuguy83]

Preventing multiple writes to a volume should be handled by volume orchestration. This is something we don't do in 1.12 and intentionally we did not include a --volume flag on service create.

[lawley]

In our case we use a reverse proxy to route certain requests to our "singleton" service. This is not about preventing multiple writes, but a result of some interactions being effectively stateful. Adding machinery into our service (distributed lock) to prevent it being scaled seems like overkill.