How do you usually manage database / service users through Nix(OS) modules? In particular I am wondering about RabbitMQ and MongoDB, but this is more of a theoretical question. I am used to Puppet where you can declaratively manage everything through third party modules. Now as I am starting to use NixOS more and more I am wondering what the correct approach here would be.
MySQL module seems to have the option that you can just seed the initial state. Later everything including additional users is data I guess (and you just restore from a backup.). So for test database instances that you would like to provision on demand with NixOps you’d have some nix configuration and initial sql dump stored?
What about RabbitMQ? Does it make more sense to just add that feature (akin to MySQL) to existing modules or would you recommend that I write the whole configuration management as a module. Is there anything out there already? Problem is that this is unfortunately not just a generation of some config file but dealing with mutable state that can get messy quite fast.
managing state with NixOS modules is a controversial topic. It’s would be much easier to assume that NixOS manages only transient and buildable stuff.
This is a bit different to Puppet/Salt. There you have some initializer and destructor, which are called on first migration, and on state removal. In NixOS a different approach is used – to rm -rf everything and recreate from scratch. (note, no real rm -rf is done – I’m just trying to make an effective speech)
State (which databases are about) isn’t very good for rm -rf and recreate, so NixOS usually doesn’t manage it. It is hard to rollback state, or switch to previous state, and what to do if state was applied only partially…
Now, that I stated that, there are modules which try to emulate “initialization”/“destruction” steps for DBs in NixOS. But I still advise you not to Nixify the state-changes. Stick with bash scripts, which you optionally deliver using NixOS.
Yeah, I am aware it’s a bit controversial. Problem (or feature) is that meta-data like users, permissions etc. are part of the same database where also other data resides. In that sense it would be nice if you could start RDMS with some option --all-metadata-from-file and then have a pure transformation from nix code to this config file format. Or some extreme immutable-infrastructure solution. Keep such data on transient partition and destroy the installation for each change, but mount some volume with persistent data to each new instance.
Well I am probably complicating too much, what are you actually using in production and how does it work for you?
For RabbitMQ you can import / export schema definitions to JSON apparently (Schema Definition Export and Import — RabbitMQ). But the problem is that as far as I understand this config is not complete state of the world (like if there is some user and he is missing in the json that won’t cause him to get deleted). So I could use that just for initial set-up (similar to MySQL case). But does it make sense to convert nix to this json format instead of just generating a shell script with a bunch of rabbitmqctl binary invocations?
I’ve just checked MongoDB module and it also has a similar initialScript option which I’ve missed previously.
I’ve tried to Nixify and make declarative users and databases in postgresql, but that wasn’t flexible enough I wanted (and also required training for others, who usually didn’t like that).
I also have never tried to model data installations as immutable infra.