英文:
Distributed Systems NSQ topology pattern on Docker containers
问题
在最后一个例子中描述的“NSQ实时分布式消息平台”，是否可以使用Docker进行复制？是否有人有Dockerfile或镜像的示例？
英文:
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?
答案1
得分: 2
我在等待一些后台任务完成时，我会试着解答这个问题。
@Luca G. Soave提到的分布式消息平台可以在这里看到：
我认为这个问题的根本问题是对Docker容器的误解。
在我们的讨论中，假设Docker容器只是虚拟机的另一个名称。关于“是否可以使用虚拟机构建分布式系统”的问题并不完全适用，因为这实际上只是一种配置、抽象和协调的问题。
上面的图表可以使用每个接触点/责任（节点）在Docker容器或虚拟机中自包含地重新创建。例如：
- 每个API/nsqd节点都在自己的容器中
- 每个nsq_to_file节点都在自己的容器中
- 每个nsqlookupd节点都在自己的容器中
根据您设置Docker镜像的方式，您可以以多种方式实现此分布式（多主机）版本。一些想法包括：
-
将容器内部端口映射到相同的主机端口，并将节点配置为将自己广播为主机IP，这样当其他节点连接到它们时，它们将直接连接到容器所映射到的主机端口的外部IP。
-
使用类似于consul的服务发现包来替换nsqlookupd，以添加附加元数据。如果您运行许多容器，每个容器都在内部绑定到相同的端口（例如端口9090），但允许主机上的
docker进程管理随机的外部端口映射，这将非常有用。
关于Docker，最近有一些关于在主机之间广播信息以与相关容器通信的新进展；这将是一种向您的api/nsqd容器提供有关nsqlookupd容器信息的方法。
我在小规模部署中使用MaestroNG取得了成功，但对于大规模的Docker部署来说，它绝对不是一个很好的解决方案。
英文:
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:
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
dockerprocess 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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论