I’d like to announce a new open-source project from Juspay called services-flake. It allows defining and running services in your project flakes, and works on both Linux and macOS . We internally use it in various projects at Juspay.
Features
services-flakes is based on flake-parts, which brings the NixOS module system to flakes and that heavily simplifies the DX while editing Nix.
Thus, you can share your services across projects (see the Nammayatri blog post below for an example)
It works on both Linux and macOS and runs services natively (configured in Nix) without using emulation
This is made possible by running the services via process-compose.
You can define multiple services of the same type
We have a native testing infrastructure that you can use to test your services both locally and in CI (pure Nix builds)
We are pretty happy at how it has shaped up so far. There’s room for improvement, and we’re open to any feedback you’ve got.
community.flake.parts is an initiative to unify the docs for various flake-modules created using flake-parts. The projects and their docs exists in the repo of their own, keeping it decentralised.
The README has a comparison, currently only against devenv.sh.
I think another contender would be numtide/devshell, which is more open to use as a component (unlike devenv), but doesn’t provide ready-to-use services. Arion does something similar for docker-compose instead of process-compose, but also not a library of services, and no flake-parts module yet.
Especially because we can define the services once and reuse everywhere else, it opens up possibilities like being able to import these configurations into other set of process groups. These other sets could be doing anything, like one of them could be running load-test on your application, another could be running integration-tests, etc.
I was trying to write my own service as a module, adhering to this format, to be used in the same flake, but I was having a hard time finding any documentation on how to do so…
I can see that you guys basically translate the YAML configuration into an attribute sets, but would be grateful for more detailed docs.
Also, I noticed the lib.multiService utility, but since I’m rather new to modules I’m struggling to find a way to make use of it for my own services… Again, would appreciate better docs on service writing rather than consuming!
I was originally trying to do my service using services-flake as template, but was getting issues (I think flake show was saying that the check set was not a derivation or something), so I searched some more and found the passetto service, and that did work but couldn’t get it to multiservice.
The added explanation of the difference made it clear why that was the case!
So yeah, the document was basically exactly the process I went thru but explained the right way!
Now I’m trying to configure my service to have some state outside the store, but I think that’s outside the scope of this module
If I may have a feature request, it would probably be some sort of “migration” function to docker/docker-compose/helm, perhaps I’ll work on that if I really want that feature and expose it as a module, since I’d like to use process-compose locally but deploy containers since that’s supported the most.
This is what I think the future for services would look like:
Option definitions will lie in nixpkgs along with config for systemd service, which it already does, but won’t be as tightly coupled after “Portable service layer” is implemented. services-flake can then re-use the options from nixpkgs, and output configs for multiple targets, like: lanuchd, process-compose or as you mentioned docker/docker-compose/helm. Thus, we will have uniformity in option definitions no matter what the underlying service management mechanism one uses.
