🎨 Sysprovider Code
Sysprovider LogoWiki
🇪🇸Hosting español para ecommerce

NixOS y Gestión Declarativa de Infraestructura

Actualizado el 2 de marzo de 2026

Introducción: El paradigma de la infraestructura como código

Durante décadas, la administración de sistemas ha sido un arte de artesanía manual. SSH a un servidor, ejecutar apt-get install, modificar un archivo de configuración, reiniciar un servicio. Este enfoque, conocido como gestión imperativa, es frágil, propenso a errores humanos y, sobre todo, no reproducible. Un servidor configurado hace seis meses es una caja negra: nadie sabe exactamente qué paquetes tiene, qué archivos fueron modificados a mano o qué estado real guarda.

Aquí es donde entra NixOS, una distribución Linux que rompe con todo lo anterior. Basada en el gestor de paquetes Nix y el paradigma de gestión declarativa, NixOS permite describir el estado completo de un sistema (paquetes, servicios, usuarios, configuraciones de red, etc.) en un único archivo de configuración. Este artículo explora cómo NixOS, combinado con Flakes y conceptos de infraestructura reproducible, está cambiando las reglas del juego para SysAdmins y equipos de DevOps.

¿Qué hace a NixOS diferente?

La mayoría de las distribuciones (Debian, Ubuntu, Fedora) gestionan el sistema de forma imperativa. Ejecutas comandos que modifican el estado global: /etc, /usr, /var. Si algo falla o quieres revertir un cambio, no hay un mecanismo nativo fiable.

NixOS, en cambio, funciona con un modelo funcional y puro. Todo el sistema se define en un archivo de configuración (o conjunto de archivos) que describe cómo debe ser el sistema, no cómo llegar a él.

Principios clave de NixOS

  • Inmutabilidad del sistema de archivos: Los paquetes se instalan en /nix/store/ con un hash único basado en su contenido y dependencias. No se sobrescriben archivos en /usr/bin/ a menos que se active explícitamente un profile.
  • Reproducibilidad: Dado el mismo archivo de configuración, NixOS produce exactamente el mismo sistema, sin importar la máquina o el momento de la instalación. Esto es oro puro para entornos de staging y producción.
  • Rollbacks atómicos: Cada cambio en la configuración genera una nueva generación. Si algo falla, puedes volver a la generación anterior en segundos desde el arranque del sistema.
  • Gestión de dependencias sin conflictos: Nix permite tener múltiples versiones de un mismo paquete instaladas simultáneamente, ya que cada una vive en su propia ruta hash.

[INFO] NixOS no es solo una distribución para escritorio. Su verdadera potencia se despliega en servidores, clusters y despliegues cloud. Grandes empresas como GitLab, CERN y Tweag lo utilizan en producción.

Nix: El lenguaje y el gestor de paquetes

Para entender NixOS, primero hay que comprender Nix, el gestor de paquetes que lo sustenta. Nix es un lenguaje de programación puramente funcional y lazy, diseñado específicamente para describir derivaciones (paquetes).

Una derivación en Nix es una receta que especifica cómo construir un paquete: fuente, dependencias, pasos de compilación, salida. El resultado siempre es una ruta en /nix/store/ con un hash único.

# Ejemplo simple de una derivación en Nix
{ pkgs ? import <nixpkgs> {} }:

pkgs.stdenv.mkDerivation {
  name = "mi-hello-1.0";
  src = ./.; # Código fuente local
  buildInputs = [ pkgs.gcc ];
  buildPhase = "gcc -o hello hello.c";
  installPhase = "mkdir -p $out/bin; cp hello $out/bin/";
}

Este enfoque tiene implicaciones profundas para la infraestructura reproducible. Ya no dependes de que el mirror de paquetes esté disponible o de que la versión exacta de una librería no haya sido retirada. Todo se construye desde fuentes o cachés inmutables.

Configuración declarativa en NixOS: configuration.nix

El corazón de NixOS es el archivo /etc/nixos/configuration.nix. En él, declaras todo lo que quieres que el sistema tenga. No hay scripts de instalación; solo una descripción del estado deseado.

Veamos un ejemplo típico de un servidor web mínimo:

{ config, pkgs, ... }:

{
  imports = [ <nixpkgs/nixos/modules/profiles/minimal.nix> ];

  boot.loader.grub.device = "/dev/sda";
  fileSystems."/" = { device = "/dev/sda1"; fsType = "ext4"; };

  # Usuario administrador
  users.users.admin = {
    isNormalUser = true;
    extraGroups = [ "wheel" ];
    openssh.authorizedKeys.keys = [ "ssh-rsa AAAAB3... user@host" ];
  };

  # Servicio Nginx
  services.nginx = {
    enable = true;
    virtualHosts."example.com" = {
      root = "/var/www/example";
      enableSSL = true;
      sslCertificate = "/etc/ssl/certs/example.crt";
      sslCertificateKey = "/etc/ssl/private/example.key";
    };
  };

  # Firewall básico
  networking.firewall.allowedTCPPorts = [ 80 443 22 ];

  system.stateVersion = "23.11";
}

Al ejecutar nixos-rebuild switch, NixOS:

  1. Calcula la nueva configuración.
  2. Descarga o compila los paquetes necesarios.
  3. Crea una nueva generación en el arrancador.
  4. Activa los cambios (inicia servicios, configura redes, etc.).
  5. Si algo sale mal, puedes reiniciar y seleccionar la generación anterior en GRUB.

Flakes: El estándar moderno para proyectos reproducibles

Aunque NixOS es potente por sí mismo, adolecía de un problema: la gestión de dependencias externas (como nixpkgs) era implícita y podía variar entre máquinas si no se fijaba. Flakes (introducido como característica experimental en Nix 2.4) resuelve esto de raíz.

Un flake es una estructura de proyecto autocontenida que declara explícitamente sus entradas (inputs) y salidas (outputs). Se define en un archivo flake.nix en la raíz del proyecto.

# Ejemplo de flake.nix para un servidor NixOS
{
  description = "Configuración de servidor web reproducible";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-23.11";
    nixpkgs-unstable.url = "github:NixOS/nixpkgs/nixos-unstable";
  };

  outputs = { self, nixpkgs, nixpkgs-unstable, ... }@inputs: {
    nixosConfigurations.servidor-web = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";
      modules = [
        ./configuration.nix
        ({ pkgs, ... }: {
          environment.systemPackages = [ pkgs.curl ];
        })
      ];
      specialArgs = { inherit inputs; };
    };
  };
}

Ventajas de usar Flakes en NixOS

  • Bloqueo de versiones: El archivo flake.lock fija las versiones exactas de todas las dependencias (nixpkgs, módulos externos, etc.). Esto garantiza que dentro de un año, el sistema se construirá exactamente igual.
  • Composición modular: Puedes dividir la configuración en flakes más pequeños (por ejemplo, un flake para la base de datos, otro para el balanceador de carga) y componerlos.
  • Compartición sencilla: Un flake puede ser referenciado por URL de Git, lo que facilita compartir configuraciones entre equipos o máquinas.
  • Entornos de desarrollo reproducibles: Con nix develop, puedes crear shells con herramientas específicas sin contaminar el sistema global.

[TIP] Si estás empezando con NixOS, te recomiendo encarecidamente adoptar Flakes desde el principio. Aunque la configuración inicial es un poco más verbosa, la reproducibilidad que ofrecen es insuperable.

Gestión declarativa de infraestructura: Más allá de una máquina

El verdadero poder de NixOS y Nix se manifiesta cuando gestionas múltiples máquinas (servidores, contenedores, VMs). Aquí es donde entra el concepto de infraestructura como código (IaC) llevado al extremo.

Gestión centralizada con nixosConfigurations

Con Flakes, puedes definir todas tus máquinas en un único repositorio Git. Cada servidor tiene su propia configuración, pero pueden compartir módulos comunes.

# flake.nix (ejemplo de infraestructura multi-máquina)
{
  inputs = { nixpkgs.url = "github:NixOS/nixpkgs/nixos-23.11"; };

  outputs = { self, nixpkgs, ... }: {
    nixosConfigurations = {
      # Servidor de aplicaciones
      app-server = nixpkgs.lib.nixosSystem {
        system = "x86_64-linux";
        modules = [
          ./common/base.nix
          ./roles/app-server.nix
          ./secrets/app-server.nix
        ];
      };
      # Servidor de base de datos
      db-server = nixpkgs.lib.nixosSystem {
        system = "x86_64-linux";
        modules = [
          ./common/base.nix
          ./roles/db-server.nix
          ./secrets/db-server.nix
        ];
      };
      # Balanceador de carga
      lb-server = nixpkgs.lib.nixosSystem {
        system = "x86_64-linux";
        modules = [
          ./common/base.nix
          ./roles/lb-server.nix
          ./secrets/lb-server.nix
        ];
      };
    };
  };
}

Luego, para desplegar cambios en app-server, ejecutas:

nixos-rebuild switch --flake .#app-server --target-host root@192.168.1.10

Esto construye la configuración localmente y la despliega de forma remota. No necesitas herramientas como Ansible o Puppet para la gestión de estado; NixOS lo hace de forma nativa y mucho más fiable.

Contenedores y NixOS

NixOS también es excelente para gestionar contenedores. Puedes definir contenedores NixOS dentro de tu configuración principal, cada uno con su propia configuración declarativa.

{ config, pkts, ... }: {
  containers.database = {
    autoStart = true;
    privateNetwork = true;
    hostAddress = "10.100.0.1";
    localAddress = "10.100.0.2";
    config = { config, pkgs, ... }: {
      services.postgresql = {
        enable = true;
        package = pkgs.postgresql_15;
      };
    };
  };
}

Esto levanta un contenedor con PostgreSQL, completamente aislado y configurado desde el mismo archivo de configuración del host. No hay Dockerfiles, no hay capas de abstracción: es Nix puro.

Infraestructura reproducible en la práctica

¿Qué significa realmente tener una infraestructura reproducible? Veamos un escenario típico:

  1. Desarrollo: Un desarrollador crea un flake para su aplicación. Incluye la configuración de Nginx, PostgreSQL y Redis.
  2. CI/CD: El pipeline de integración continua ejecuta nix build .#nixosConfigurations.app-server.config.system.build.toplevel. Esto construye la imagen del sistema completa.
  3. Testing: La misma imagen se despliega en un entorno de staging. Como todo está fijado en flake.lock, no hay sorpresas.
  4. Producción: Se despliega la misma imagen binaria en los servidores de producción. El hash del almacén es idéntico al de staging.

Si una versión de PostgreSQL introduce un bug, no tienes que preocuparte porque la versión exacta está fijada. Si necesitas revertir un despliegue, solo cambias la generación en el arranque.

Desafíos y consideraciones

NixOS no es perfecto. Tiene una curva de aprendizaje pronunciada, especialmente para quienes vienen de distribuciones tradicionales.

Curva de aprendizaje

  • Lenguaje Nix: Aunque es simple, su sintaxis funcional y lazy puede resultar extraña al principio.
  • Documentación fragmentada: La documentación oficial ha mejorado mucho, pero todavía hay áreas donde la mejor fuente son los foros o el código fuente de nixpkgs.
  • Depuración: Cuando algo falla, los mensajes de error pueden ser crípticos. La inmutabilidad hace que sea difícil "meter mano" para arreglar algo sobre la marcha.

Compatibilidad

  • No todos los paquetes de software están empaquetados para Nix. Aunque nixpkgs es enorme, algunos programas propietarios o muy específicos pueden no estar disponibles.
  • Las aplicaciones que dependen de rutas estándar del sistema de archivos (como /usr/lib) pueden requerir parches.

[WARNING] No intentes convertir un servidor Ubuntu a NixOS de un día para otro. Empieza con un proyecto pequeño, como un servidor personal o un servicio secundario. La experiencia que ganes te permitirá afrontar migraciones más grandes con confianza.

Herramientas del ecosistema Nix

El ecosistema alrededor de Nix y NixOS es rico y está en constante crecimiento.

  • nixpkgs: El repositorio oficial de paquetes. Más de 80,000 paquetes mantenidos por la comunidad.
  • nixos-anywhere: Herramienta para instalar NixOS en máquinas sin necesidad de un medio de instalación físico.
  • deploy-rs: Herramienta para despliegues remotos rápidos y seguros con NixOS.
  • nix-direnv: Integración de Nix con direnv para entornos de desarrollo automáticos.
  • colmena: Gestor de despliegues para múltiples máquinas NixOS, similar a Ansible pero nativo.

Conclusión: ¿Merece la pena NixOS?

Si eres un SysAdmin o DevOps que valora la reproducibilidad, la fiabilidad y la gestión declarativa por encima de la familiaridad, NixOS es una opción que debes explorar seriamente. No es una distribución para todos los casos, pero para infraestructura crítica, entornos de CI/CD, clusters de investigación o simplemente para tener un control total sobre tu sistema, es difícil de superar.

La combinación de NixOS con Flakes ofrece un nivel de determinismo que otras herramientas de IaC (como Ansible, Puppet o Terraform) no pueden igualar, porque no solo gestionan la configuración, sino también los propios paquetes y sus dependencias.

Empieza poco a poco. Instala NixOS en una máquina virtual. Define tu primer flake. Despliega un servicio. Cuando veas que un nixos-rebuild switch revierte un cambio roto en segundos, entenderás por qué muchos consideran que NixOS es el futuro de la administración de sistemas.

[TIP] Únete a la comunidad. El canal de Matrix #nixos:matrix.org y el foro de Discourse son excelentes lugares para resolver dudas. La comunidad es conocida por ser acogedora y servicial.

Este artículo ha sido escrito por un redactor técnico experto en SysAdmin y SEO. Si te ha resultado útil, compártelo con otros profesionales que busquen llevar su infraestructura al siguiente nivel de reproducibilidad.

¿Necesitas ayuda?Son dos de nuestros técnicos, Agustín y Mikel, y están disponibles para resolver cualquier problema.

Hablar con ellos ahora
Agustín y Mikel