Ahmed Baha Eddine Alimi - B23-SD-01 [Lab18 + Bonus Task]

[3llimi]

Lab 18 — Nix & Reproducible Builds

What was done:

• Replaced traditional Python dependency management (pip install) with a fully declarative Nix-based build system, creating a custom derivation for the DevOps Info Service
• Implemented a manual Python environment using python3.withPackages, explicitly defining runtime dependencies (Flask) and ensuring isolation from system Python
• Built the application via nix-build, producing a deterministic output in /nix/store/... and exposing the executable through a wrapped binary
• Used makeWrapper to correctly configure PYTHONPATH, ensuring the application runs without relying on external environment configuration
• Applied source filtering (cleanSourceWith) to exclude unnecessary files (e.g., .git, caches), reducing closure size and improving build determinism
• Verified reproducibility through:
  • repeated nix-build executions producing identical store paths
  • deletion of store path (nix-store --delete) followed by rebuild yielding the same hash
• Identified and documented a reproducibility edge case where floating <nixpkgs> caused hash drift, explaining why pinning is required

Containerization:

• Created a Nix-based Docker image using dockerTools.buildLayeredImage, reusing the application derivation instead of rebuilding dependencies
• Configured container execution via direct reference to the Nix store binary (${app}/bin/...)
• Ensured deterministic image builds by setting a fixed creation timestamp (created = "1970-01-01T00:00:01Z")
• Built and loaded the image with nix-build docker.nix and docker load, then validated runtime behavior via port mapping
• Verified reproducibility by comparing sha256sum of resulting images across rebuilds (identical hashes)

Comparison & Analysis:

• Compared pip vs Nix:
  • pip relies on mutable environments and unpinned transitive dependencies
  • Nix provides fully hashed, deterministic builds with complete dependency closure
• Compared Docker vs Nix-built images:
  • traditional Docker builds are affected by timestamps and mutable base images
  • Nix images are reproducible due to fixed inputs and content-addressed storage
• Analyzed Docker image layers (docker history) and explained differences in metadata and size tradeoffs

Bonus:

• Introduced Nix Flakes to fully pin dependencies and eliminate floating nixpkgs issues
• Created flake.nix with locked input (nixos-24.11) and reproducible outputs for both application and Docker image
• Generated and used flake.lock to guarantee identical builds across machines and time
• Built outputs via nix build and nix build .#dockerImage, confirming reproducibility
• Compared flakes with traditional Nix and briefly contrasted with tools like Helm for dependency/version management

Outcome:

• Successfully transitioned from imperative to fully reproducible, declarative builds
• Demonstrated reproducibility at both application level (Nix derivation) and container level (Nix Docker image)
• Identified real-world pitfalls (floating dependencies, Docker non-determinism) and addressed them using proper Nix practices
• Bonus implementation ensures long-term reproducibility via flake-based dependency pinning