Cas pratiques DevOps avec Nix : standardiser les environnements et fiabiliser la CI/CD

Vous avez des flakes, des devShells, un flake.lock qui verrouille chaque dépendance. Maintenant, comment en faire un usage d’équipe concret ? Ce guide transforme les briques des guides 8 à 10 en six cas pratiques opérationnels : poste de travail standardisé, CI/CD identique au local, checks automatisés, build reproductible d’un outil interne, stratégie de mise à jour et onboarding express. Chaque exemple s’appuie sur la même flake.nix de référence, directement utilisable dans un projet réel.

Ce que vous allez apprendre

• Construire un devShell d’équipe embarquant Terraform, Ansible, kubectl, Helm et les outils de qualité
• Consommer ce devShell dans GitHub Actions et GitLab CI — sans configuration supplémentaire
• Définir des checks reproductibles (lint, format) exécutés localement et en CI avec nix flake check
• Empaqueter un script d’administration comme dérivation Nix reproductible avec writeShellApplication
• Gérer les mises à jour de flake.lock sans surprises pour l’équipe
• Ramener l’onboarding d’un nouveau membre à git clone + nix develop

Dans quel contexte ?

Nix devient particulièrement utile dès qu’une équipe est impliquée :

• Deux ingénieurs ont des versions différentes de Terraform ou d’Ansible — les plans divergent
• La CI installe des paquets avec sudo apt install dans le pipeline, créant des builds fragiles et lents
• Un nouveau contributeur passe une demi-journée à installer l’outillage avant d’écrire la première ligne
• Une mise à jour silencieuse de helm en CI casse le déploiement — impossible de reproduire localement
• Les scripts shell sont valides “sur ma machine” mais pas sur le runner

Un flake.nix versionné avec le code résout structurellement chacun de ces problèmes.

Prérequis

Ce guide fait suite aux guides 8 (environnements), 9 (factorisation) et 10 (flakes). Vous devez :

• avoir Nix installé avec les flakes activés (voir le guide d’installation),
• comprendre la structure d’un flake.nix (inputs, outputs, devShells),
• savoir utiliser nix develop et nix flake check.

Structure du projet de référence

Créez ce projet dans votre répertoire de lab. Tous les cas pratiques utilisent cette même base :

mkdir -p ~/Projets/lab-nix && cd ~/Projets/lab-nix
mkdir -p nix scripts src
git init

• Répertoirelab-nix/

  • flake.nix (point d’entrée — inputs + délégation aux modules)
  • flake.lock (révisions verrouillées — toujours commité dans Git)
  • Répertoirenix/

    • devshells.nix (devShell d’équipe)
    • checks.nix (vérifications automatisables)
    • packages.nix (builds reproductibles)
  • Répertoirescripts/

    • lint.sh (lint shell)
    • validate.sh (validation Terraform)
  • Répertoiresrc/ (code source)

    • …
  • .envrc (activation automatique avec direnv — optionnel)

Le flake.nix racine reste court grâce à la factorisation dans nix/. C’est la convention introduite dans le guide 9.

flake.nix

{
  description = "Boîte à outils DevOps — reproductible pour toute l'équipe";

  inputs = {
    nixpkgs.url     = "github:nixos/nixpkgs/nixos-25.11";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = nixpkgs.legacyPackages.${system};
        src  = ./.;
      in {
        devShells.default = import ./nix/devshells.nix { inherit pkgs; };
        checks            = import ./nix/checks.nix    { inherit pkgs src; };
        packages          = import ./nix/packages.nix  { inherit pkgs; };
      }
    );
}

git add avant toute commande Nix

Les flakes ne voient que les fichiers suivis par Git. Après chaque création de fichier, faites git add <fichier> avant de lancer nix develop, nix build ou nix flake check. Sans cela, Nix ignore silencieusement le fichier.

---

Cas pratique 1 — Boîte à outils DevOps standardisée

L’objectif

Un devShell unique qui embarque tout l’outillage d’une équipe DevOps. Chaque membre entre dans cet environnement avec nix develop et obtient les mêmes versions, peu importe sa distribution ou son historique d’installation.

nix/devshells.nix

{ pkgs }:

pkgs.mkShell {
  name = "devops-toolkit";

  packages = with pkgs; [
    # Contrôle de version
    git
    git-crypt

    # Traitement de données structurées
    jq
    yq-go

    # Qualité de code shell
    shellcheck
    shfmt

    # Infrastructure as Code
    terraform
    opentofu

    # Gestion de configuration
    ansible
    ansible-lint

    # Kubernetes
    kubectl
    helm
    kustomize
    k9s

    # Sécurité
    trivy
    cosign

    # Debug réseau
    curl
    httpie
  ];

  shellHook = ''
    echo "Environnement DevOps actif ($(uname -m))"
    echo "  Terraform : $(terraform version 2>/dev/null | head -1)"
    echo "  kubectl   : $(kubectl version --client 2>/dev/null | head -1)"
    echo "  Helm      : $(helm version --short 2>/dev/null)"
    echo "  Ansible   : $(ansible --version 2>/dev/null | head -1)"
  '';
}

Test

cd ~/Projets/lab-nix
git add flake.nix nix/devshells.nix
nix develop

Environnement DevOps actif (x86_64-linux)
  Terraform : Terraform v1.11.4
  kubectl   : Client Version: v1.31.4
  Helm      : v3.17.2+g4a5b5ed
  Ansible   : ansible [core 2.18.2]

Plusieurs devShells dans un même flake

Pour des équipes aux besoins différents — ops, sécurité, développeurs — créez plusieurs shells nommés dans devshells.nix en retournant un attribute set :

{ pkgs }:
{
  default = pkgs.mkShell { packages = with pkgs; [ terraform ansible kubectl ]; };
  sec     = pkgs.mkShell { packages = with pkgs; [ trivy cosign grype syft ]; };
  dev     = pkgs.mkShell { packages = with pkgs; [ python312 nodejs_22 go ]; };
}

Puis dans flake.nix : devShells = import ./nix/devshells.nix { inherit pkgs; };

Utilisation : nix develop .#sec ou nix develop .#dev.

---

Cas pratique 2 — CI/CD identique au poste local

Le principe

Votre flake.nix est versionné avec le code. La CI le consomme directement avec la même commande qu’en local :

# En local
nix develop --command bash -c "shellcheck scripts/*.sh && terraform -chdir=infra validate"

# En CI — exactement la même commande
nix develop --command bash -c "shellcheck scripts/*.sh && terraform -chdir=infra validate"

GitHub Actions

.github/workflows/ci.yml

name: CI

on: [push, pull_request]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: cachix/install-nix-action@v31
        with:
          github_access_token: ${{ secrets.GITHUB_TOKEN }}
          extra_nix_config: |
            experimental-features = nix-command flakes

      # Cache binaire — réduit drastiquement le temps de téléchargement
      - uses: cachix/cachix-action@v16
        with:
          name: my-org-cache
          authToken: ${{ secrets.CACHIX_AUTH_TOKEN }}

      - name: Vérification de la structure du flake
        run: nix flake check --no-build

      - name: Lint et validation IaC
        run: |
          nix develop --command bash -c "
            shellcheck scripts/*.sh
            terraform -chdir=infra validate
            ansible-lint playbooks/ || true
          "

GitLab CI

.gitlab-ci.yml

image: nixos/nix:2.24.10

variables:
  NIX_CONFIG: "experimental-features = nix-command flakes\naccept-flake-config = true"

# Cache le store Nix entre les jobs du même runner
cache:
  key: nix-store-${CI_RUNNER_ID}
  paths:
    - /nix/store
  policy: pull-push

stages:
  - validate
  - test

flake-check:
  stage: validate
  script:
    - git config --global --add safe.directory "$CI_PROJECT_DIR"
    - nix flake check --no-build

lint:
  stage: validate
  script:
    - nix develop --command shellcheck scripts/*.sh

validate-iac:
  stage: test
  script:
    - nix develop --command terraform -chdir=infra validate
    - nix develop --command ansible-lint playbooks/ || true

Runner auto-hébergé

Sur un runner persistant, installez Nix une seule fois. Le store /nix est partagé entre tous les jobs — plus de re-téléchargement.

# Installation multi-utilisateur sur le serveur de CI
sh <(curl -L https://nixos.org/nix/install) --daemon

# Activer les flakes pour l'utilisateur CI
mkdir -p /home/ci-runner/.config/nix
echo "experimental-features = nix-command flakes" \
  >> /home/ci-runner/.config/nix/nix.conf

Le premier job peuple le store (2-5 minutes). Les suivants réutilisent les paquets déjà présents (< 30 secondes pour nix develop).

Premier run lent, les suivants rapides

Le premier nix develop sur un runner vierge télécharge tous les paquets depuis cache.nixos.org. Avec Cachix ou un runner persistant, les runs suivants réutilisent le cache binaire. Investissez dans cette infrastructure dès le départ — le gain est de 5× à 10× sur le temps de pipeline.

---

Cas pratique 3 — Checks reproductibles avec nix flake check

L’objectif

Définir des vérifications (lint, format) comme des dérivations Nix :

• exécutables en local avec nix flake check,
• intégrées automatiquement en CI,
• mises en cache — un check déjà réussi ne retourne pas.

Définir les checks

nix/checks.nix

{ pkgs, src }:

{
  # Vérification des scripts shell
  shellcheck = pkgs.runCommandLocal "check-shellcheck"
    { buildInputs = [ pkgs.shellcheck ]; }
    ''
      find ${src}/scripts -name "*.sh" -exec shellcheck {} +
      touch $out
    '';

  # Format des fichiers Nix (RFC-style)
  nixfmt = pkgs.runCommandLocal "check-nixfmt"
    { buildInputs = [ pkgs.nixfmt-rfc-style ]; }
    ''
      nixfmt --check ${src}/flake.nix
      find ${src}/nix -name "*.nix" -exec nixfmt --check {} +
      touch $out
    '';
}

src = ./. dans le flake.nix

Le paramètre src vaut ./. dans le flake.nix. Il capture le répertoire courant comme chemin du store Nix au moment de l’évaluation. C’est plus fiable que d’utiliser self directement depuis un fichier importé.

Exécuter les checks

cd ~/Projets/lab-nix
git add nix/checks.nix scripts/

# Tous les checks
nix flake check

# Un seul check, avec trace détaillée si erreur
nix build .#checks.x86_64-linux.shellcheck --show-trace

checking flake output 'checks.x86_64-linux.shellcheck'...
checking flake output 'checks.x86_64-linux.nixfmt'...

Si shellcheck détecte un problème :

checking flake output 'checks.x86_64-linux.shellcheck'...
error: builder for '/nix/store/...-check-shellcheck.drv' failed with exit code 1
       scripts/lint.sh:12:5: warning [SC2086]: Double quote to prevent
       globbing and word splitting.

Intégration CI

En GitLab CI et GitHub Actions, remplacez vos scripts de lint ad hoc par :

nix flake check

C’est une seule commande, indépendante du runner, qui exécute exactement les mêmes vérifications qu’en local.

---

Cas pratique 4 — Build reproductible d’un outil interne

L’objectif

Empaqueter un script d’administration comme dérivation Nix. Le binaire résultant est identique bit à bit sur toutes les machines. Il peut être distribué via un cache binaire ou installé directement avec nix profile install.

Exemple : script d’audit Kubernetes

nix/packages.nix

{ pkgs }:

{
  # Outil d'audit Kubernetes avec ses dépendances exactes embarquées
  k8s-audit = pkgs.writeShellApplication {
    name = "k8s-audit";
    runtimeInputs = with pkgs; [ kubectl jq ];
    text = ''
      echo "=== Noeuds du cluster ==="
      kubectl get nodes -o json \
        | jq -r '.items[] | "\(.metadata.name)\t\(.status.conditions[]
            | select(.type=="Ready") | .status)"'

      echo ""
      echo "=== Pods non Running ==="
      kubectl get pods --all-namespaces \
        --field-selector 'status.phase!=Running,status.phase!=Succeeded' \
        2>/dev/null || echo "(aucun)"

      echo ""
      echo "=== Événements Warning récents ==="
      kubectl get events --all-namespaces \
        --field-selector type=Warning \
        --sort-by='.lastTimestamp' \
        2>/dev/null | tail -15
    '';
  };
}

writeShellApplication vs writeShellScript

pkgs.writeShellApplication est la version recommandée pour des scripts destinés à la distribution :

• set -euo pipefail activé automatiquement
• les runtimeInputs sont isolés dans un PATH dédié (pas de pollution du PATH système)
• shellcheck est exécuté à la construction — un script bugué ne compile pas

pkgs.writeShellScript est plus simple mais sans ces garanties.

Construire, tester, distribuer

cd ~/Projets/lab-nix
git add nix/packages.nix

# Construire
nix build .#k8s-audit

# Tester (le binaire est dans ./result/bin/)
./result/bin/k8s-audit

# Utiliser temporairement sans installer
nix shell .#k8s-audit --command k8s-audit

# Installer dans le profil utilisateur
nix profile install .#k8s-audit

Le binaire k8s-audit embarque ses propres versions de kubectl et jq depuis le store Nix — il fonctionne sur n’importe quelle machine avec Nix installé, sans dépendances système.

---

Cas pratique 5 — Stratégie de mise à jour de flake.lock

Le problème

flake.lock fige la révision de nixpkgs. Il doit être mis à jour régulièrement pour obtenir les correctifs de sécurité et les nouvelles versions d’outils — sans casser l’équipe au passage.

Workflow de mise à jour

1. Créer une branche dédiée

   git checkout -b chore/nix-update-$(date +%Y-%m)

2. Mettre à jour toutes les dépendances

   nix flake update

   Cela recrée flake.lock avec les révisions les plus récentes de chaque input déclaré.

3. Inspecter ce qui a changé

   git diff flake.lock

   "lastModified": 1739000000,
   "lastModified": 1744823519,
   "rev": "d78a5c8a34f5b7e0c4d2e1f3a6b8c9e0f",
   "rev": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",

   La révision de nixpkgs est la seule vraie information. Consultez github.com/NixOS/nixpkgs/compare/<ancienne-rev>...<nouvelle-rev> pour voir les changements inclus.

4. Valider localement

   nix flake check
   nix develop --command bash -c "terraform version && kubectl version --client"

5. Ouvrir une PR/MR

   La CI valide les checks automatiquement. La PR est fusionnée si tout est vert.

6. Rollback si problème

   # Revenir simplement à la révision précédente de nixpkgs
   git revert HEAD
   
   # Ou épingler une révision spécifique
   nix flake lock --update-input nixpkgs \
     --override-input nixpkgs \
     "github:nixos/nixpkgs?rev=d78a5c8a34f5b7e0c4d2e1f3a6b8c9e0f"

Cadence recommandée

Fréquence	Cas d’usage
Hebdomadaire	Équipes avec forte activité CI/CD, dépendances nombreuses
Mensuelle	Projets stables, outillage peu changeant
À la demande	CVE critique dans une dépendance détectée par la veille

Glissez pour voir

Automatiser avec Renovate

Renovate supporte les inputs Nix. Il ouvre automatiquement des PRs avec le diff de flake.lock à chaque nouvelle révision de nixpkgs. C’est identique à la gestion des dépendances npm ou Dependabot/GitHub.

---

Cas pratique 6 — Onboarding express

Un nouveau DevOps rejoint l’équipe. En moins de 15 minutes, il dispose de l’environnement complet.

1. Installer Nix (une seule fois, 3-5 minutes)

   sh <(curl -L https://nixos.org/nix/install) --no-daemon
   source ~/.nix-profile/etc/profile.d/nix.sh

2. Activer les flakes

   mkdir -p ~/.config/nix
   echo "experimental-features = nix-command flakes" >> ~/.config/nix/nix.conf

3. Cloner et entrer dans l’environnement

   git clone https://gitlab.mon-org.example.com/infra/devops-tools.git
   cd devops-tools
   nix develop

4. Vérifier

   terraform version
   kubectl version --client
   helm version
   ansible --version

   Toutes les versions affichées sont identiques à celles du reste de l’équipe.

5. (Optionnel) Activation automatique avec direnv

   nix profile install nixpkgs#direnv
   echo 'eval "$(direnv hook bash)"' >> ~/.bashrc
   source ~/.bashrc
   direnv allow .

   À partir de là, nix develop se déclenche automatiquement à chaque cd dans le répertoire.

Le README d’installation se réduit à ces 5 étapes. Plus de liste de paquets à maintenir, plus de “ça marche chez moi”.

---

Fil rouge : projet Python + Terraform + Ansible

Voici comment les six cas pratiques se combinent dans un projet réaliste.

flake.nix (version complète)

{
  description = "Infra — Python + Terraform + Ansible";

  inputs = {
    nixpkgs.url     = "github:nixos/nixpkgs/nixos-25.11";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = nixpkgs.legacyPackages.${system};
        src  = ./.;
      in {
        # Cas pratique 1 — plusieurs shells selon le rôle
        devShells = {
          default = pkgs.mkShell {
            name = "infra-full";
            packages = with pkgs; [
              python312 python312Packages.boto3
              terraform ansible ansible-lint
              kubectl helm shellcheck shfmt
            ];
            shellHook = ''
              echo "Environnement complet actif"
            '';
          };
          ci = pkgs.mkShell {
            # Shell allégé pour la CI — sans éléments interactifs
            name = "infra-ci";
            packages = with pkgs; [
              python312 terraform ansible kubectl shellcheck
            ];
          };
        };

        # Cas pratique 3 — checks automatisés
        checks = {
          shellcheck = pkgs.runCommandLocal "check-shellcheck"
            { buildInputs = [ pkgs.shellcheck ]; }
            ''
              find ${src}/scripts -name "*.sh" -exec shellcheck {} +
              touch $out
            '';
          nixfmt = pkgs.runCommandLocal "check-nixfmt"
            { buildInputs = [ pkgs.nixfmt-rfc-style ]; }
            ''
              nixfmt --check ${src}/flake.nix
              touch $out
            '';
        };

        # Cas pratique 4 — outil interne empaquetable
        packages.default = pkgs.writeShellApplication {
          name = "infra-status";
          runtimeInputs = with pkgs; [ kubectl jq python312 ];
          text = ''
            echo "=== Cluster status ==="
            kubectl get nodes -o json | jq -r '.items[].metadata.name'
          '';
        };
      }
    );
}

Pipeline CI/CD correspondant :

.github/workflows/ci.yml (fil rouge)

name: Infra CI

on: [push, pull_request]

jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: cachix/install-nix-action@v31
        with:
          github_access_token: ${{ secrets.GITHUB_TOKEN }}
          extra_nix_config: |
            experimental-features = nix-command flakes
      - run: nix flake check
      - run: nix develop .#ci --command terraform -chdir=infra validate
      - run: nix develop .#ci --command ansible-lint playbooks/
      - run: nix build .#infra-status

---

Pièges spécifiques au contexte DevOps

Piège	Impact	Correctif
git add oublié avant nix develop	Nix ignore silencieusement les nouveaux fichiers	git add -A systématique avant toute commande Nix
flake.lock absent du dépôt	Chaque machine ou CI job résout une révision différente	Commiter flake.lock — c’est une fonctionnalité, pas un artefact jetable
Cache Nix absent en CI	Premier job lent (5-10 min de téléchargements)	Configurer Cachix ou un runner persistant avec /nix monté
Trop d’outils dans un seul devShell	Temps d’entrée long, résolution de conflits plus probable	Plusieurs devShells nommés selon le rôle (default, sec, ci)
shellHook lourd	Ralentit chaque nix develop	Garder le shellHook court, déléguer aux scripts
Ignorer nix flake check en PR	Erreurs de structure détectées trop tard	Ajouter nix flake check --no-build comme premier job
Mettre à jour flake.lock sans branche dédiée	Impossible de revenir en arrière proprement	Toujours une branche + PR dédiée pour les mises à jour

Glissez pour voir

---

À retenir

• La flake devient le contrat entre le poste de développement, la CI et les collègues — une seule source de vérité pour toute l’équipe
• nix develop --command ... en CI consomme exactement le même environnement qu’en local — plus de divergence
• flake.lock doit être versionné dans Git — il garantit que tout le monde et la CI travaillent avec les mêmes révisions
• Les checks Nix sont mis en cache : un check déjà réussi ne tourne pas une deuxième fois
• writeShellApplication est le moyen propre d’empaqueter des scripts avec leurs dépendances sans polluer le PATH système
• L’onboarding se résume à : installer Nix une fois + git clone + nix develop
• Mettez flake.lock à jour régulièrement via une PR dédiée — jamais directement sur la branche principale

Prochaines étapes

Comprendre et utiliser les flakes La fondation de ce guide : inputs, outputs, flake.lock et commandes essentielles.

Environnements de développement reproductibles mkShell, shell.nix, direnv — les fondamentaux pour Python, Node.js et Rust.

NixOS : installer et évaluer en VM Aller plus loin : un système entier déclaratif avec NixOS en VM KVM.

Pipelines CI/CD avec GitHub Actions Workflows complets pour la validation, les tests et les déploiements.

×

📖 Voir la documentation →