nixidy

nixidy to podejście do GitOps dla Kubernetes, w którym manifesty klastra definiuje się nie w YAML-u, a w języku Nix. Zamiast pisać setki linii deklaracji z ograniczonym templatingiem (jak w Helm czy Kustomize), dostajemy pełnoprawny język programowania - z funkcjami, typami, kompozycją modułów i weryfikacją w czasie ewaluacji. Repozytorium z kodem Nix staje się źródłem prawdy o stanie klastra, a wynikowe manifesty są renderowane deterministycznie i synchronizowane z klastrem tak jak w klasycznym GitOps.

Dla ekosystemu EIAC nixidy jest ciekawym przykładem „manage-infrastructure-as-code” doprowadzonego do skrajności - infrastruktura nie jest opisywana danymi (YAML), tylko wyrażana jako program. Dzięki temu łatwiej reużywać logikę między środowiskami, walidować konfigurację statycznie i unikać powtarzalnych bloków, które w czystym YAML-u trzeba kopiować albo sklejać templatingiem tekstowym.

Kiedy używać

• Masz już doświadczenie z Nix (NixOS, nixpkgs, home-manager) i chcesz spójny język konfiguracji od systemu po klaster Kubernetes.
• Helm/Kustomize zaczynają się rozłazić przy dużej liczbie środowisk i potrzebujesz realnej abstrakcji (funkcji, modułów) zamiast templatingu stringów.
• Zależy Ci na deterministycznym, powtarzalnym renderowaniu manifestów i walidacji konfiguracji jeszcze przed wysłaniem do klastra.
• Budujesz platformę wewnętrzną i chcesz dać zespołom typowane, kompozycyjne bloki do składania własnych wdrożeń.

Przykład użycia

{
  clusters.production = {
    resources = {
      namespace.eiac-web = { };

      deployment.eiac-web = {
        replicas = 3;
        image = "registry.eiac.dev/eiac-web:1.4.0";
        namespace = "eiac-web";
      };

      service.eiac-web = {
        selector.app = "eiac-web";
        ports = [ { port = 80; targetPort = 8080; } ];
      };
    };
  };
}