Description
docker service create explicitly takes in --network option to let user select a globally scoped network for which swarmkit can allocate and manage resources.
But --network is optional and if the user doesn't specify one then swarmkit doesn't setup any network or allocate network resources ( one exception is -p where swarmkit uses the default ingress network ).. In such a scenario docker daemon uses the node-local default network, docker0 bridge in Linux or nat in Windows, etc...
This proves that swarmkit and services are robust enough to work in node-local network setup. Infact, there is absolutely no special case to support this scenario and that means the same logic must work for other node-local networks such as --host, --none or other user-defined bridge network or macvlan or ipvlan drivers. (there has been a few requests to enable this as well)
But, we don't have the UX/API to enable this functionality & this is a proposal to enable that support.
node-local networks (aka local-scoped networks) needs resource allocation and management done locally by the engine in the same traditional ways. Hence swarm manager cannot be involved in such a node specific resource allocation. Hence it is not appropriate to overload the --network keyword in docker service create to convey the same functionality. Infact, (as per @mrjana) this feature can be considered more of a network constraint applied by the swarm manager and schedule the task only on the nodes on which the corresponding node-local network is present.
In order to achieve this, we can consider either of the following UX -
- overload the
--networkAPI indocker service createthat will take innode-localnetworks as well and make a decision to use aglobal-scopednetwork if present or apply thenetwork constraintto filter schedule the tasks only to those nodes where thenode-localnetwork is present. - introduce a new
--net-constraintflag (apologies on poor choice for the flag name), and that is explicitly meant for such a constraint mechanism and scheduling the task on appropriate nodes.
In either case, the only role of swarmkit is to schedule the task on a particular node and the rest of the functionality is handled at the engine level just as it is done today for the default case.