A way to make service prefer communicating with another service if it's nearby(same host)

Open Source Projects Swarm
1

I have one global service. It’s a central logger that uses ZeroMQ.

Is there a way to set “affinity” for the log clients - other services, which are replicated over the same nodes, as the logger service is? They connect using TCP, and use DNS to resolve the logger service name on each call to log method.

The logger service stack looks like this:

version: "3.9"
services:
  log_svc:
    image: log_svc
    isolation: 'process'  
    environment:            
      - host_name={{.Node.Hostname}}      
    volumes:
      - C:\log_svc\Log:C:\Log              
    deploy:
      endpoint_mode: dnsrr
      mode: global
#      replicas: 1      
      restart_policy:
        condition: any
      placement:
        max_replicas_per_node: 1
        constraints:
#          - node.role==worker
          - node.labels.os == windows
    networks:
      - stack1_net
      - stack2_net

networks:
  stack1_net:
    external: true
  stack2_net:
    external: true

So, if a svc1 and logger_svc both exist on the same node, a way to make svc1 prefer communicating with logger_svc_node1 instead of logger_svc_node2?

2

The questions you asked so far have been an alternative take on how to use replicas, direct finding of bugs, or things that simply are not implemented in Swarm.

This topic falls into the last category, and looks like a good candidate for a feature request. This feature request should probably be filed in the swarmkit github repository.

3

Sorry, if I’m a bit noisy here, I’m experimenting with Swarm, and must decide on the future path soon.

In any case this problem I had seems to be related to mode: global deploy option, when replicas option is used the load balancing seems to even out, even after failure and reboot of one node.

4

All good :slight_smile: Yours posts show that you dig into the docs and try everything there is. Which is excellent when deciding whether to use a new technology. Though, If something is not mentioned in the compose specs (in case of swarm stacks the old compose version 3 reference), it’s a good sign that it doesn’t exist. Not everything that exists for plain docker containers is supported by swarm tasks.

It also makes sense to post and double check if things are just misconfigured or possible bugs. And I am pretty sure you found one.

Your finding is still odd, as it shouldn’t matter whether the service is deployed in global or replica mode. In both cases the dns entry for the dnsrr endpoint mode should return a multivalued dns response for the service name - it should be updated to reflect when a task is stopped or started. While dnsrr can suffer from client side dns resolution caching, vip will not. Though, vip on the other hand does not support long-lived connections.