Does docker swarm cluster support publisher / reader pattern

[kaishen2018]

I am new to this events project, want to understand whether docker swarm cluster support publisher / reader pattern. I am looking for way working like this:

1. there is a docker cluster, take swarm cluster as example.
2. I can setup a client listener, which is connect to the cluster, my client can be notified automatically no matter what changes in the cluster, like new node joined, new images pulled, new container start/ stop, etc.
   Does this event project support this?

[stevvooe]

@yangguoyk2015 This package is a generic event distribution package. So the answer is yes. Is there specific code to do exactly this within this package? No.

Please read the documentation to get a better idea of the use cases for this package.

[kaishen2018]

@stevvooe , thanks for your quick response. Per my understanding, so far, in Docker projects, only the Docker registry has implemented the auto notification strategy, that's where this go-events project come from.

We have a desire that maybe we can build a small image, which can work together with Docker Engine or swarm, with this new image, it can collect all the changes (new nodes joined/ new containers, etc) in the docker cluster, and convert these changes into a standard event, and broadcast these events to its subscribers, similar way as webhook, you can choose the interested events and set the target end-point URL. If we can make this, we can receive the latest notification and get the latest status in the cluster, instead we have to monitor the cluster status manually.

Let me know your comment. Thanks!

[stevvooe]

@yangguoyk2015 That sounds somewhat like the long term goal of this project. It would be great if you could give this package a try and let me know what you are missing. With the current docker engine, you would have to call the events API and then aggregate and distribute that. We may want to add to notifications to docker itself, but that is not planned. For your use case, I'd recommend running some sort of aggregation agent based on this package and work from there. If we find it may be better to implement that within docker, we can work from there.

Part of the next step here is porting over the plumbing for notifications.Endpoint. I'll probably try this week or next week, depending on my schedule. We also need the "inverse" of that, which accepts calls from remote HTTP service and dumps it into an event queue. We may also want to define sinks for commonly used queueing services, such as kafka, sqs and rabbitmq.

To provide you a little context, the docker-archive-public/docker.engine-api#89 (comment) proposes some changes to the engineapi.Events call that I'd like to compatible with this dispatch package. We still need to define a Source that can be compatible with the Sink definition.

[kaishen2018]

@stevvooe , thanks for your answer. I will try per your comment, will see how amazing Docker will be :).

[resouer]

@yangguoyk2015 I don't think your question is related to this repo. As far as I know, k8s is designed to be event driven, the only thing you need is watching etcd events for the change you are interested in (like container status changes etc).

[Adirio]

Should this Issue be closed?