DSL for service infrastructure

{
  config,
  lib,
  ...
}:
let
  cfg = config.mjm.services;
in
{
  imports = [
    ./http.nix
    ./postgresql.nix
    ./secrets.nix
    ./s3.nix
    ./upstreams.nix
  ];

  options.mjm.services =
    let
      serviceType =
        { name, ... }:
        {
          options = {
            name = lib.mkOption {
              type = lib.types.str;
              default = name;
            };
          };
        };
    in
    lib.mkOption {
      default = { };
      type = with lib.types; attrsOf (submodule serviceType);
    };

  config = {
    <<config>>
  };

  _class = "nixos";
}

The mjm.services module makes it easy for individual service modules to describe what they need to run and have the necessary infrastructure created for them automatically. It's meant to be somewhat akin to using a PaaS: by following well-defined patterns, you get a lot of functionality with very little effort.

mjm.spire.entries = lib.mapAttrs' (
  s: _:
  lib.nameValuePair "service-${s}-${config.networking.hostName}" {
    spiffe_id = "svc/${s}";
    parent_id = config.networking.hostName;
  }
) cfg;

Simply by adding a key to mjm.services, a SPIRE entry is created for that service identity on that host. So if I have a machine named "foo" that includes:

mjm.services.bar = {};

Then workload identities with "svc/bar" as their parent ID will be available on "foo". In general, entries for specific systemd units should rely on this rather than using the host as the parent.

Submodules

Other service infrastructure beyond this is available on an opt-in basis.

=> HTTP
=> PostgreSQL
=> S3-compatible storage
=> Secret storage
=> Upstream services