Glueson - configure runtime-inputs at buildtime

Announcements
1

Hi Guys

I’m currently working on an experiment called glueson. The name is a combination of glue(code) and JSON, and should hint already what it is:

It is intended to “glue” together arbritrary processes, and configure what they pass to each other. Sounds like a bash script? Yep, it could be seen as a competitor.

The main use-case that I have in mind for glueson is for building scripts that need to deal with runtime-paramenters. Stuff that cannot be built into the script at build-time, like secrets for example.

So why not just use bash scripts? Glueson is specifically designed to be used with the nix module system! It makes a script very configurable.

As an example, let’s assume we have a module that gives us options to configure the environment variables of a dev shell:

{
  devShell.environment = {
    API_URL = "http://api.example.com/";
    SMTP_HOSTNAME = "smtp.example.com";
  };
}

The problem with this is that we cannot set secrets here. So the module needs to give us a way to do this, like for example:

{
  devShell.environment = {
    API_URL.static = "http://api.example.com/";
    API_KEY.command = "sops decrypt ./api_key.txt";
    SMTP_HOSTNAME.static = "smtp.example.com";
    SMTP_PASSWORD.command = "vault kv get -field=smtp_password secret/my-app";
  };
}

This of course works, but now it’s the modules job to deal with this correctly.

With glueson, the responsibility to deal with dynamic values could to some extent be moved out of the module. Here’s an example how it could look with glueson:

{
  devShell.environment = {
    API_URL = "http://api.example.com/";
    API_KEY = {
      _glueson = "execute";
      command = "sops decrypt ./api_key.txt";
   };
    SMTP_HOSTNAME = "smtp.example.com";
    SMTP_PASSWORD = {
      _glueson = "execute";
     command = "vault kv get -field=smtp_password secret/my-app";
    };
  };
}

In this example, the module would just define the type of the environment variable values to be glueson and then pass the whole environment object to glueson to be resolved at runtime.

This is pretty much an experiment for now, but I’m very curious if this is interesting to someone else and could potentially solve their problems as well. I’m developing this, because I’m currently trying to create a flake-parts module for my company that allows us to configure us all our projects in a similar whay, from building the app, generating & pushing docker images and also deploying them to kuberenetes. The flake-module will give awesome defaults, but still allow to configure anything, even kubernetes resources.

And that’s where I saw the need for this. Especially in the deployment configuration, there’s a lot of stuff that’s only available at runtime. I’ve tried wiring everything up with bash scripts at first, but that quickly resulted in quite some pain. So I’m trying to create a prototype that uses glueson instead and see how this goes.

8 Likes