7

Is it possible to replicate "NSQ realtime distributed messaging platform" described in the last example of "Topology Patterns" with Docker? Does anybody have a dockerfile or image example?

fabrizioM
  • 46,639
  • 15
  • 102
  • 119
Luca G. Soave
  • 12,271
  • 12
  • 58
  • 109
  • 1
    great question, I'm imagining this would make use of container linking, which I haven't dived into yet. – dskinner Dec 02 '13 at 13:01
  • There is an interesting follow-up about related topic on GitHub: https://github.com/bitly/nsq/issues/283#issuecomment-30048495 topology question is still ongoing but good foundations have been injected thanks to the work of Matt Reiferson (mreiferson: https://index.docker.io/u/mreiferson/) – Luca G. Soave Dec 07 '13 at 13:02
  • @LucaG.Soave I think it would be nice to add yourself an answer. Including a reference to the official Go package for NSQ: https://github.com/bitly/go-nsq – eAbi Mar 25 '14 at 14:11
  • @eAbi https://github.com/bitly/go-nsq is great, but nonetheless, is not an answer to my question. Moreover is nothing to do with Docker or containerization of that toplogy, in my understanding. Please bear with me if I'm wrong, a liitle more explaning/exampling could help here. – Luca G. Soave Mar 25 '14 at 18:14

1 Answers1

2

I'll take a crack at this while I'm waiting for a few background tasks to finish.

The distributed messaging platform that @Luca G. Soave mentioned can be seen here: source: www.nsq.io/deployment/topology_patterns.html

I believe this question has a fatal issue at its root: a misunderstanding of what Docker containers are.

For the purposes of our discussion, let's pretend that a Docker container is just a different name for a virtual machine. The question of "Can a distributed system be built with virtual machines?" doesn't quite fit since it's really just a matter of configuration, abstraction, and coordination.

The diagram above can be recreated with each point of contact/responsibility (node) being self-contained within a Docker container or a virtual machine. i.e.:

  • Each API/nsqd node is in its own container
  • Each nsq_to_file node is in its own container
  • Each nsqlookupd node is in its own container

Depending on how you set-up your Docker images, you may implement a distributed (multi-host) version of this in a number of ways. Some ideas are:

  • Mapping container internal ports to the same host port, and configuring your nodes to broadcast themselves as the host ip, so that when other nodes go to connect to them, they're latching onto the host's external ip at the port mapped to the container; thus connecting directly to the container.

  • Using a service discovery package like consul to replace the nsqlookupd in order to add additional metadata. This would be useful if you're running many containers that each internally bind to the same port (e.g. port 9090), but allow the docker process on the host to manage the random external port mappings.

As this relates to Docker, there have been some recent developments in broadcasting information across hosts to related containers; which would be one way to seed your api/nsqd containers with information about the nsqlookupd containers.

I've had success using MaestroNG for small deployments, but it definitely is not a great solution for large-scale docker deployments.

Momer
  • 3,158
  • 22
  • 23