Name configMaps after a path in Nix store, just likeyou do for docker images

[arianvp]

This allows your deployment to refer to a specific configmap, and also means that if the configmap changes that the deployment gets redeployed. Also if deployment fails then the previous configmap still exists on rollback.

e.g.:

  kubernetes.resources.deployments.nginx = {
    spec = {
      replicas = 10;
      selector.matchLabels.app = "nginx";
      template = {
        metadata.labels.app = "nginx";
        spec = {
          securityContext.fsGroup = 1000;
          containers.nginx = {
            image = config.docker.images.nginx.path;
            imagePullPolicy = "IfNotPresent";
            volumeMounts."/etc/nginx".name = "config";
          };
          volumes.config.configMap.name = config.kubernetes.resources.nginx-config.path;
        };
      };
    };
  };

  kubernetes.resources.configMaps.nginx-config.data."nginx.conf" = ''
    user nginx nginx;
    daemon off;
    error_log /dev/stdout info;
    pid /dev/null;
    events {}
    http {
      access_log /dev/stdout;
      server {
        listen 80;
        index index.html;
        location / {
          root /var/lib/html;
        }
      }
    }
  '';

And in this example config.kubernetes.resources.nginx-config.path will evaluate to:

"zyy26wn23ac3ivl8lkc6wv2bdyjz99h1-nginx-config"

named after the nix-store path with the /nix/store part stripped.

[arianvp]

This also has the added benefit that asking for the closure of a kubernetes object tells you what resources to apply first using kubectl apply before applying the kubernetes object in question. No need to always deploy namespaces, then configmaps, then secrets, then deployments, but instead just look at the dependency graph of the expressions like other tools do. this will allow us to make a tool akin to nixos-rebuild switch ( how about kubenix-rebuild switch ? ) that will apply the changes to kubernetes cluster in the right order.

[offlinehacker]

This repo has been deprecated, since I stopped maintaining it some time ago. There is a fork maintained by @hall available at https://github.com/hall/kubenix, that has better documentation and looks like a way further.