Nix, un meilleur constructeur d’images Docker que le builder d’images de Docker

Nix est meilleur que le builder d’images de Docker

• Nix a trois facettes : gestionnaire de paquets, langage et système d’exploitation.
• Utiliser Nix pour créer des images Docker présente des avantages par rapport au builder d’images intégré à Docker.
• Nix permet de connaître à l’avance toutes les dépendances nécessaires au processus de build et rend possible un build sans connexion Internet.

Les avantages de Nix

• Nix permet de créer des images Docker plus efficacement.
• Nix répartit les dépendances dans un minimum de couches Docker, ce qui limite les changements au strict nécessaire lors des mises à jour.
• Lorsque plusieurs services se trouvent dans le même dépôt, ils peuvent partager les mêmes couches Docker, ce qui améliore l’efficacité.

Exemple d’un service de citations de Douglas Adams

• Le texte explique le processus consistant à packager un programme Go avec Nix puis à le transformer en image Docker.
• La fonction dockerTools.buildLayeredImage permet de créer une image en couches.
• On obtient au final une image de conteneur classique, qui peut être déployée n’importe où.

Avis de GN⁺

• Utiliser Nix peut grandement améliorer la gestion des dépendances et la reproductibilité des builds dans le processus de développement logiciel.
• Par rapport à Docker, Nix peut faire gagner du temps et des ressources sur le long terme grâce au caractère déterministe de ses builds.
• Cependant, les nouveaux concepts et usages de Nix peuvent être assez difficiles pour les débutants et compliquer son intégration dans des pipelines CI/CD existants.
• L’adoption de cette technologie nécessite une phase de formation et d’adaptation au sein de l’équipe, tout en tenant compte de la compatibilité avec l’infrastructure existante.
• Parmi les autres outils offrant des fonctionnalités similaires à Nix, on trouve Guix, qui propose lui aussi une gestion de paquets et des builds déterministes.

[GN⁺]

Avis Hacker News

• J’ai essayé à plusieurs reprises d’apprécier Nix, mais je pense qu’il est temps d’abandonner.

  • J’ai deux systèmes qui utilisent Nix, mais j’ai peur d’y toucher.
  • En théorie, Nix est idempotent et déterministe, mais si l’on ne comprend pas précisément toute la partie dépendances, on peut se retrouver avec des résultats étranges et des erreurs peu utiles.
  • La documentation est très mauvaise, et les tutoriels ne sont utiles qu’en partie.
  • La force de Docker réside dans le chaos lui-même : avec une compréhension de base du shell et du gestionnaire de paquets, on peut construire presque n’importe quoi facilement.

• Nix et NixOS sont dans un état comparable à celui de git avant GitHub.

  • L’idée de base repose sur une informatique plus sérieuse que celle des SVN ou Docker actuels.
  • La sortie de flox a peut-être changé la donne, et flox est facile à utiliser.
  • Sans flakes ni nix-command, Nix n’a pas vraiment de sens, et ils sont expérimentaux et désactivés par défaut.
  • Nix/NixOS ou quelque chose de similaire mettra Docker dans le même état, mais pas avant son moment GitHub.

• J’ai passé 2 à 3 jours à construire des images Docker sur Darwin, et cet article donne l’impression de se moquer de moi.

  • Nix est le meilleur outil pour obtenir ce que l’on veut, mais il a parfois des recoins sombres qui assèchent l’âme.

• Le billet de blog n’explique pas pourquoi les couches Docker partagées sont utiles.

  • Elles le sont à cause du cache. Plus il y a d’images qui partagent les mêmes couches, meilleur est le cache.
  • Nix stocke déjà les dépendances via des hash, donc les couches sont toujours identiques pour une même version et une même configuration.

• L’expérience de construction d’images Docker pour des applications Java avec Nix n’a pas été très agréable.

  • Depuis l’abandon de gradle2nix, il n’existe pas d’alternative claire pour construire des images Docker pour des applications Java basées sur Gradle.

• C’est utile si l’on a déjà adopté Nix, et j’aimerais que des solutions de gestion de paquets plus déclaratives comme Nix ou Guix se démocratisent.

  • Si l’on veut adopter Nix progressivement tout en utilisant Docker, il existe une approche alternative qui consiste à construire la configuration Nix tout en conservant le Dockerfile.

• En tant qu’ingénieur plateforme, j’aimerais aimer Nix, mais ce n’est pas simple pour tout le monde.

  • Par exemple, je préfère ajouter des paquets avec quelque chose comme devbox add python@3.11.

• Nix est incompatible avec l’upstream au point de nécessiter un effort de packaging important pour la plupart des bibliothèques.

  • Pour des bibliothèques C ou C++ complexes, empaqueter et adapter l’ensemble pour Nix représente une part importante du travail.

• J’ai récemment essayé de construire une image de base CI avec Nix, mais l’image était trop volumineuse et certains jobs ne fonctionnaient pas correctement à cause de problèmes de linkage.

  • Pour construire des images multi-architecture, il essaie réellement d’exécuter sur l’autre architecture, ce qui ne prend en charge que la virtualisation matérielle avec qemu.

• J’utilise Dagger, qui résout la plupart des problèmes en tant que deuxième tentative menée par les créateurs de Docker.

  • On peut écrire les pipelines dans le langage que l’on utilise déjà et tirer parti des fonctionnalités avancées de BuildKit, comme les graphes de couches et le cache avancé.