Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove RabbitMQ and scheduler #238
RabbitMQ is powerful but hard to operate, particularly when managing clusters of multiple nodes that break from time to time. We don't benefit from the pub/sub features of AMQP as most interactions are 1 to 1: scheduler to agent, agent to scheduler. Only event workers use round robin distributions, but those can easily be rewritten to poll the DB.
With HTTP/2 now standard in Golang, we should simply the backend architecture and get rid of RabbitMQ entirely in favor of a full Rest API interaction. Agents should authenticate to the API using tokens, maintain a connection open, and receive actions via server push.
This is a tough one. The amount of code we're touching is very large.
Over the past year or so I've produced about 6 variants of Mig that in attempt to remove the dependancy on RabbitMQ in various ways. End goal I'd like to see on-demand data streams rather than persistant TCP connections to a central point. Some kind of automatic protocol selection with plugable transports (eg: allow staff laptops to traverse strict customer networks) but nothing worth sharing yet.
After much experimentation, it seems Serf and its gossip protocol implemented in Mig coupled with optional central long term storage would be the best approch for my use cases however I've not even considered HTTP/2 so will have a read up on that.
We'd like to go with a full HTTP/2 implementation and a simplified architecture. The end goal is to get rid of both RabbitMQ and the scheduler, and centralize all features on the API (then renamed mig-server).
The API will need 5 new endpoints:
We'll also need to move the periodic tasks from the scheduler to the api, but that's just adding a new goroutine that will run on a single host (lock in db?).