I have two web services, one of which creates resources on disk for the other one to read and process. The resources are subject to irregular change, so I'd like to inform the consumer service when a resource is updated instead of polling and saving the file timestamps or restarting services.

Problem is, I intend to replicate the consumers. With Docker one can compose a set of services and replicate specific services for redundancy or performance. However, those replicas are behind a common address to the outside world and a load balancer decides where to pass a particular request. For my use, each replica would need to be informed as soon as a resource is updated so it can in turn stay up to date. Initial loading and processing is costly so constant reloading is a bad choice.

Is there a way, in Docker, to broadcast or copy a request to all containers of one type? Or simply to every running container?

It really would be a non-issue if it weren't for the masking load balancer... Apparently one can specify a network endpoint_mode as dsnrr to get access to a list of container addresses, but using it would to my knowledge involve actually rewriting the balancer, which is less than ideal for this limited case.

  • What mechanism are you using as the load balancer? Docker Swarm? An external load balancer? – Mike Partridge Feb 22 at 14:24
  • @MikePartridge Defaulting to Swarm, yes, but it's not set in stone. – Felix Feb 22 at 14:30

The simplest solution is to simply have a message queue. Each instance would register as a listener on the queue, and you can send a message to all listeners. With this solution you would have multiple queues or have the instance filter appropriately.

Another solution includes using a discovery service like Eureka which can be queried for the instances. NOTE: Eureka is only one of many similar products. If your environment isn't Java native, then you might want to find a discovery service that is more appropriate for your application. In this scenario, each instance of a service registers itself with the discovery service. And each client can query for the available instances. That allows each microservice to call each other directly, or perform local load balancing.

If you want to keep it in the docker ecosystem, then you might look at "Docker Discover". I don't have any personal experience with this one, but it might help with some of your problems.

  • Thanks, but the problem with a message queue, at least as far as I understand it, is that I can't send the messages anywhere. All the replicas are behind a common address with no way to tell which one the request was sent to. But I'll take a look at the discovery things. – Felix Feb 22 at 14:40
  • @Felix - in the message queue solution, the instance that made the change would publish a message about the change to a queue, all services that care about it would be subscribed to the queue, and they could then reload the resource when the message appears. – Mike Partridge Feb 22 at 16:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.