A lightweight configuration service that supports managing app configurations across multiple environments. Inspired by tools like etcd, consul kv and spring cloud config, Configmonkey was built with distributed environments in mind, and it's goal is to provide an easy way to externalize and manage microservice configurations from a single place, without interfering with the application's ci/cd lifecycle.
Table of Contents
Clone this repo and start the dependencies with docker-compose:
docker-compose upAlternatively, if you prefer to start the dependencies in a different way (postgres database), adjust the configuration in .cargo/config.toml with the appropriate connection strings.
Then start the app using cargo:
cargo runIf everything started correctly, the application will then be available at http://127.0.0.1:8000.
Warning
Configmonkey is still under development and is not stable for production use.
We plan to release instructions on how to properly host configmonkey at later stages, but in the meantime, a simple way to do it is to use the hosting/docker-compose.yml file provided in this repository. Alternatively, head to Docker Hub, which also contains the same docker compose example.
cargo buildNote that the build process doesn't include running the tests. Use this command if you just want to make sure the code compiles properly and are not interested in running the app and the dependencies
With the dependencies already started, run the tests using cargo. The test suite creates several databases and requires the environment variable DATABASE_URL to point to any postgres database. Check .cargo/config.toml if you want to use a different database for tests.
cargo testConfigmonkey is a recent project and welcomes new contributors. Since this is still at an early stage of maturity, there are plenty of ways to contribute
We'd love to hear about your experience with configmonkey and get feedback on how it could be improved. At this stage, we're interested in all kinds of issues:
- General feedback on the overall experience (please use it !)
- Bug reporting
- Feature requests or suggestions
Code contributions are certainly welcome. If this will be a large PR/contribution, please make sure to open an issue first so that we can disscuss it. Eitherway, we'll pay attention to all kinds of PRs:
- Fixing an open issue
- Fixing a bug
- Implementing a new feature (Let's discuss first)
- Updating documentation
- Implementing tests
Currently the only interface to configmonkey is via the REST API, which means that users will need to build the integrations on their side. While we have plans to add several clients in the future, any kinf of contribution here is welcome:
- CLI tool
- Node SDK
- Rust SDK
- Golang SDK
- Java SDK
- ...
If you decide to build one of these, make sure you let us know, so that we can reference it in the docs!
At the moment, configmonkey is a pet project and therefore we don't have any kind of deadlines nor a roadmap. Contributors are welcome to open discussions (use the issues for that) and help shape the future of this tool. There are however, some items we're thinking about focusing next:
Right now, there is no support for editing or retrieving single and nested config properties, restricting the /v1/configs to editing full configuration maps. We want to extend this endpoint to make it as simple and flexible as possible
The only way to run configmonkey now is unauthenticated, which may be enough for most systems, but we want to have the option of extra security by adding JWT validation as a configurable option
Initially thought of, tenant support is hidden under the default tenant in the database. We can leverage the authentication feature to segregate applications, environments and configs across multiple tenants
The current format exported by the API is JSON, which will cover most use cases, but we can make use of the Accept header to export the configurations on other popular formats like .env, toml, yml etc