Please explain global scope

could anyone explain the global scope in more detail as in not explained in details in the docs or here in the forum.

thank you very much, it would highly be appreciated

What exactly are you looking for?

A replicated service will have the number of desired replicas, though without any guaranty that those instances are spread accross all available nodes matching the placement contraints. A good example is anything that has some sort of replicated/quorum based state, where a fixed number of instances needs to be run.

A global service on the other hand will have a single instance per node that matches the placement contraint. A good usecase for this is a node based agent (like the portainer agent) or a reverse proxy (like traefik) especialay if the instances bind the host ports instead of using the ingress mesh. Be aware that a global service will be deployed on new nodes matching the placement constraint as soon as they join your swarm.

Of course both could be used with stateless services as well.

1 Like

that is too much input at once
As far as I understand it is only related to Swarms, isn’t it?

what do you mean here?
Clone services to have them run as backup service in case the main one fails or using the same DB in different docker hosts, which in turn make a swarm?

sorry I’m lost here

what about global networks, compared to local or swarm?

why should it do so?

Yes, this a Swarm only feature

Replicas are identicaly configured instances of your service. Scalling out and/or high availability could be motivations to run replicated services. There is no guaranty that the instances will be executed on different host. Though, you get a guaranty on how many replicas will be running. If they share the same database you will need to make sure that the application is able to handle non-sticky sessions.

Then your use case high likely doesn’t require it :slight_smile:

What is a global network? Only Overlay Networks are capabale to spann a network across swarm nodes.

Again, it depends on your use case. While ingress ports are bound to all nodes, host-ports are only bound on machines running the service. Access to host ports is noticable faster. If you want to dedicate nodes to specific environments and run the same services just for different stages, you you pretty much run the same setup, just with defferent placement constraints, without having to deal with port collisions.

It pretty much boils down to your use case.

1 Like


    inet scope global eth0

in Empowering App Development for Developers | Docker

 scope ( `swarm|global|local` )

in docker network ls | Docker Documentation

I actualy never cared how docker manages the ip addresses on its virtual devices on the host… never had to…

Whenever I need an overlay network, decoupled from the lifecylce of a Stack deployment, I create them manually with the option “–driver=overlay”. Most networks are declared inside my docker-compose.yml files and are bound to the lifecylce of the Swarm Stack: created during deployment of the stack, removed during removal of the stack.

I am still unclear about what a “global scoped docker network” would look like. The docs are not realy helpfull :slight_smile: Never had to use them in the last past 2,5 years that I am using Docker Swarm.

Could someone please provide a legit use case for global scoped swarm networks?

thanks for the feedback, at least I can say now, it is properly related Docker Swarm.
Would be great if anyone could enlighten us :smiley:

I did some test and results are unexpected. Seems like either the global scope is a doku bug OR the implementation has a bug. Though, as there is no explanation, I would suspect it to be a doku bug.

global scoped overlay:

root@swarm1:~# docker network create --scope global --driver overlay test
root@swarm1:~# docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
k9p46mbqrb15        test                overlay             swarm

global scoped, default driver:

root@swarm1:~# docker network create --scope global  test2
Error response from daemon: This node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again.

global scoped bridge:

root@swarm1:~# docker network create --scope global  --driver bridge test3
Error response from daemon: This node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again.

All three commands have been executed on a manager node…

Macvlan network are also not global…

root@swarm1:~# docker network create --scope global  --driver macvlan   -o parent=eth0   --subnet=   --gateway=   --ip-range=   test4
Error response from daemon: This node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again.

The same is true for ipvlan:

root@swarm1:~# docker network create --scope global  --driver ipvlan   -o parent=eth0   --subnet=   --gateway=   --ip-range=   test5
Error response from daemon: This node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again.

This one challenged me. I like that :slight_smile:

Here we go: the native drivers from Docker Swarm mode do not support the scope global. Only 3rd party network drivers (called remote drivers) that rely on the network state beeing stored in a k/v store provide the scope global, like e.g. calico or weave. But then again: I never had to use a remote driver with Docker Swarm mode…

This is a pretty well written deep dive into Docker networking:

1 Like

thanks for your great efforts, going to read the referenced link

where can that be reported?

I you follow the rest of my write up: it is more like a dokubug in the sense of “information is missing”.

I don’t know if the Docker folks read this otherwise it going to be hard to find that.
Let’s see what happens if I do