Networks

This guide allows you to tune SWARM networks thanks to your inventory.

Internal network

ensure networks are reserved

Netmask, defined inside Swarm networks and REGARDS network, must be reserved by your corporation to prevent the usage of these reserved masks.
Otherwise, a machine that has an IP inside one of these reserved masks would not be reachable from your REGARDS cluster.

Swarm networks

By default, demo inventories defines several communication networks used by Swarm nodes to communicate to each other.
Default values are :

# Inside inventories/<inventory name>/group_vars/docker_nodes/main.yml
docker_bip: 10.122.20.1/24
docker_ingress_network: 10.122.22.0/24
docker_ingress_network_gateway: 10.122.22.1
docker_gwbridge_network: 10.122.21.0/24

info

See more about these networks on the Docker documentation:

• Ingress network for routing mesh enables each node in the swarm to accept connections on published ports for any service running in the swarm
• The docker_gwbridge is a virtual bridge that connects the overlay networks (including the ingress network) to an individual Docker daemon's physical network
• Docker uses a software bridge which lets containers connected to the same bridge network communicate

Network overlaps

When network address ranges are misconfigured and overlap, docker logs this message (seen when running status.sh in cli folder or during Docker's daemon boot) : ERROR: Pool overlaps with other one on this address space

Solution: reconfigure yours networks to prevent them to overlap

REGARDS network

By default, demo inventories defines an internal microservice communication network with the following value :

# Inside inventories/<inventory name>/group_vars/regards_nodes/main.yml
group_docker_network_ip_network: "10.11.7."

This property allows to create an overlay network dedicated to our microservices with:

• a subnet in 0/24
• and its gateway.

External networks

This option is facultative.

To define external access to microservices, you must first declare the external networks to use as follows:

group_config_mservices:
  external_networks:
    - network: foo
      name: net_foo

Generated configuration

This configuration generates networks top-level element as defined in the compose specification.

Reminder

The creation of these external networks is not handled by regards playbook. You must create them beforehand by your own!

It is then possible to define specific connections to the following microservices: gateway, authentication, catalog or front.

For instance:

group_docker_mservices:
  catalog:
    configuration:
      external_networks:
        - network: foo
          aliases:
            - foo.catalog

Generated configuration

This configuration generates networks and optionnaly aliases as defined here.

Preferred networks

This option is facultative.

As a side effect when several networks are defined inside your SWARM network, you will have to specify the preferred networks in order to microservice to talk to each other without network issue.

So to force internal microservice communication to use internal network, you will have to setup the following properties:

For instance:

group_config_mservices:
  # Value depends on your internal network configuration
  preferred_networks: 10.11