Rescheduler-lite is a job/work scheduler that is easy to deploy, operate, and worker/environment agnostic
Rescheduler-lite is in development and thus all warnings apply; feel free to play around, raise PRs, get involved in discussion, but above all else don't rely on it for now(!) 🙂
- Single binary
- Low memory footprint
- Built-in observability
- Build-in backup and restore
- Build on top of standard components
- Leverage RabbitMQ, or Aws SNS for message passing
The main goal of rescheduler-lite is to simplify scheduled/recurring jobs for small and mid-size projects.
More often than not a basic feature needs to be implemented that requires things to happen in the future (sending reminder emails, webhooks, etc.) or to perform a recurring task (generating reports, collecting external information, etc..).
Where these things are usually really project specific the scheduling of these jobs is not. Still it can be a hassle to get job scheduling setup in a convenient and low maintenance fashion.
rescheduler-lite aims to take away this generic scheduling of jobs while not having any opinions around the way these jobs are implemented or executed. All of this while being easy to deploy and maintain for smaller teams.
Rescheduler-lite is a self-contained application that doesn't require dedicated services, outside of an RabbitMQ node or Aws SNS topic to run. The binary can be ran on any machine with a supported cpu architecture as long as it has read and write access to the database file.
For recommended hardware specifications refer to the Deployment section. The diagram below should give a basic understanding of how rescheduler-lite functions on a high level.
All interaction with rescheduler-lite is done through its API.
API docs can be accessed on /api/docs, when running the docker-compose http://localhost:8080/api/docs
Rescheduler-lite consists of a single binary that can be deployed virtually everywhere. The only constraint is the availability of some form of persistent storage.
Alongside rescheduler-lite it is needed to deploy a messaging technology. Currently RabbitMQand AWS SNS are supported. These messaging technologies are needed to pass messages from rescheduler-lite to consumers.
Describe binary deployment
Describe docker based deployment
Contributions are welcome 👍
For all discussions and questions there is a separate discussions board. For everything that is not a bug report please use this board.
When you are testing rescheduler-lite and run into something you think is an issue it would be appreciated if you take the time to describe the issue you run into with as much context as possible. You can drop this information in the issues section and apply the bug tag.
If you feel like there is missing or incorrect documentation feel free to create an issue with the corresponding documentation tag. Please take your time to describe what and why you are missing, of coarse you are free to come up with an initial write-up or proposal of how to document this part of the application.
In order to start hacking developing on rescheduler-lite the following is needed
After that you should be able to start developing on the project and run any development dependencies (RabbitMQ) in Docker
In order to start RabbitMQ you can use the docker-compose file in the repo.
From the root of the project run;
docker-compose up -d --buildRescheduler-lite is shipped with build in logs in JSON format and metrics in OpenMetrics format
By default logs will be directed to stdout and stderr from there you can forward/ingest they into your log collector.
Metrics are provided and OpenMetrics format and exposed on the /metrics path. The following types of metrics exposed
- Node/host metrics, prefixed with
node_ - Dotnet CLR metrics, prefixed with
dotnet_ - Http metrics, prefixed with
http_ - Application metrics, prefixed with
sched_