Journal Créer une archive d'application conteneurisée avec guix pack

Posté par . Licence CC by-sa.
23
30
mai
2017

Sommaire

ou encore, en anglais, "creating standalone binary bundles with guix pack". Il s'agit d'une nouvelle fonctionnalité parue avec GNU GuixSD (la distro) 0.13.0, le 22 mai 2017. Le but est ici de taper une commande simple:

guix pack foo

pour obtenir une archive tarball qui contient les binaires du logiciel foo avec toutes ses dépendances. Il y aussi un raccourci pour donner le résultat à docker mais on va voir les différences d'approches et les bénéfices de guix.

Ce journal reprend les informations de
- l'annonce de GNU Guix 0.13.0: https://www.gnu.org/software/guix/news/gnu-guix-and-guixsd-0.13.0-released.html
- l'article expliquant guix pack: https://www.gnu.org/software/guix/news/creating-bundles-with-guix-pack.html
Autres liens:
- documentation de guix pack: https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00322.html
- GNU Guix: https://www.gnu.org/software/guix/
- GNU Guile: https://www.gnu.org/software/guile/
- journal précédent sur GNU Guix: https://linuxfr.org/users/dzecniv/journaux/gnu-guix-et-guix-sd-0-12-0-la-distro-et-le-gestionnaire-de-paquets-au-paradigme-fonctionnel
- article "Utiliser GNU Guix dans un environnement de super calculateurs" https://matutine.gitlab.io/2016/09/26/gnu-guix-dans-un-environnement-de-supercalculateurs.html
- installer Guix (le gestionnaire de paquets) sans le "make install" final: http://dustycloud.org/blog/guix-package-manager-without-make-install/
- notes sur les containers dans Guix https://github.com/pjotrp/guix-notes/blob/master/CONTAINERS.org

guix pack

Autre exemple: si on tape

guix pack guile emacs geiser

on obtient une archive avec ces trois logiciels et toutes leurs dépendances. Quand on l'extrait, ils vont se ranger dans le répertoire /gnu/store, chacun sous un nom unique qui commence par un hash, dont un est le hash du "profile" qui contient guile, emacs et geiser.

Évidemment on ne peut pas demander à l'utilisateur de taper /gnu/store/war325pv1iixj13k6y8yplzagpknfn0c-profile/bin/guile pour lancer guile, donc guix pack a une option pour créer un lien:

guix pack -S /opt/gnu/bin=bin guile emacs geiser

cette commande crée un lien /opt/gnu/bin vers le répertoire bin du profile du tarball, et ainsi on peut taper /opt/gnu/bin/guile pour lancer Guile.

Le receveur d'un tel tarball peut l'extraire dans le répertoire root, pour créer les répertoires /gnu/ et /opt/gnu/ si nécessaire:

# cd /
# tar xf /path/to/pack.tar.gz
# /opt/gnu/bin/guile --version
guile (GNU Guile) 2.2.0

ou on peut utiliser chroot pour éviter les droits super-admin:

$ mkdir /tmp/pack
$ cd /tmp/pack
$ tar xf /path/to/pack.tar.gz
$ unshare -mrf chroot . /opt/gnu/bin/guile --version
guile (GNU Guile) 2.2.0

L'avantage de tout ceci est donc que comme guix pack inclut tout l'arbre des dépendances, le tarball final contient tout ce dont on a besoin pour lancer le programme Guile et ça fonctionnera sur toute machine qui utilise un kernel Linux.

Compilation croisée

Guix supporte la compilation croisée ("cross compilation"), donc on peut créer des lots pour une plateforme donnée. La commande suivante crée une archive avec les binaires pour GNU/Linux sur ARMv7:

guix pack --target=arm-linux-gnueabihf guile

et la commande suivante pour Windows

guix pack --target=i686-w64-mingw32 guile

Toutes les options de transformation de Guix sont accessibles à guix pack. On pourrait donc par exemple proposer à des utilisateurs-testeurs un exécutable de IceCat avec un snapshot des sources de la branche master:

guix pack icecat --with-source=./icecat-48.8.0.master.tar.gz

Le résultat va être gros dans ce cas, mais ce genre d'utilisation est certainement utile.

Lien avec Docker, avantages

La méthode plus connue en ce moment pour lancer des applications "conteneurisées" ("application bundles") est évidemment Docker. Guix pack contient donc une option pour créer une archive au format Docker:

guix pack -f docker -S /opt/gnu=/ guile emacs geiser

On peut passer le résultat à docker load et l'utiliser avec docker run.

Eh, vous ne disiez pas que l'approche de Docker n'est pas la bonne ?

Oui, nous, les développeurs de Guix, avons déjà dit quelques fois que cette approche est problématique pour plusieurs raisons:

  • la composition: chaque conteneur ("bundle") est livré avec un système d'exploitation complet, modulo le kernel, et il n'y a pas ou peu de partage des ressources (espace disque, mémoire),
  • les mises à jour de sécurité: un développeur doit être minutieux et appliquer les mises à jour de sécurité de tout logiciel contenu dans l'image. Malheureusement c'est très peu fait et ce problème a été reporté en de nombreuses occasions.
  • la reproductibilité: les images Docker, par exemple, sont difficilement voir impossibles à reproduire au bit près, selon la définition de reproducible-builds.org. Tout d'abord, un fichier Dockerfile repose toujours sur une image de base, un gros blob binaire d'une distro modifiée. Par dessus ça on lance des commandes telles que apt-get qui dépendent largement du moment auquel elles sont lancées. Quelques bonnes pratiques recommandent de bien spécifier la version des dépendances, mais cela ne résout pas le problème de fond.
  • l'expérimentation: une fois qu'on a cette grosse image, on peut certes lancer le programme que l'on veut, mais pas beaucoup plus que ça: on n'a pas accès au code source et on aurait du mal à jouer avec les composants de la couche logicielle.

Guix se targue de résoudre les problèmes de la "conteneurisation" d'applications sans ces inconvénients. Comment Guix s'imbrique-t-il dans cet écosystème ?

Tout d'abord notons que le cas d'usage de guix pack est légèrement différent. Le but premier de guix pack est de pouvoir tester des applications sur une machine qui n'a pas guix. Pour une mise en production, la recommandation première est d'utiliser directement guix, qui permettra de recevoir les mises à jour de sécurité et de dépasser les limitations données ci-dessus.

Voyons quand même comment la commande guix pack tire son épingle du jeu.

  • composition: plutôt bonne. Si on extrait 2 packs différents, les applications différentes ont un nom de fichier différents dans le /gnu/store (par leur hash), les applications similaires (par exemple GTK+) auront le même nom et seront partagées.
  • mises à jour de sécurité: on peut toujours extraire un pack qui contient les mises à jour mais il est conseillé d'utiliser directement Guix.
  • reproductibilité: les "packs" sont reproductibles au bit près. Actuellement quelques paquets distribués par Guix ne sont pas encore reproductibles. Grâce à cette propriété on peut aussi se créer des packs qui varient légèrement d'un pack donné.

GNU GuixSD 0.13.0

cf les images pour QEMU et l'installation via USB.

  • support de l'UEFI, de Btrfs
  • peut lancer des services systèmes dans des containeurs isolés (article)
  • nouveaux services (Redis, Exim, Open vSwitch,…)
  • 840 nouveaux paquets, pour un total de 5400

À propos de Guix

GNU Guix est un gestionnaire de paquets transactionnel pour le projet GNU. Il peut s'utiliser en parallèle de apt. Il permet des opérations transactionnelles (une installation échoue ? Le système n'est pas modifié), des retours dans l'historique (le nouveau logiciel plante un peu trop ? Je reviens en arrière), il s'utilise avec des profils par utilisateurs, sans droits root, etc. S'inspire à l'origine de Nix et NixOs, mais est écrit entièrement dans le même language, Guile (un interpréteur de Scheme, un lisp). Ceci permet de spécifier une distro entière dans un seul fichier de configuration, dans un language de haut niveau. Développé à l'INRIA Bordeaux.

Et voilà, pour contacter les développeurs nous avons une mailing liste et #guix sur Freenode.

  • # Subuser

    Posté par (page perso) . Évalué à 4.

    C'est intéressant. Ça se rapproche en certains points de subuser dont j'avais parlé ici l'année dernière : https://linuxfr.org/news/subuser-une-sur-couche-a-docker .

    Est-ce que vous envisagez ou est-il déjà possible d'avoir un système de permissions similaire ? Et serait-il envisageable de vous rapprocher de ce projet ?

    Il y a clairement des choses qui se font autour des containers, mais du point de vue utilisateur on a un peu l'impression que ça part dans tous les sens (Docker, lxc, systemd-nspawn, subuser, flatpack, guix, et probablement d'autres). C'est autant de technologies à apprendre, chacune ayant ses avantages/inconvénients, mais du coup on en perd un peu son latin.

    • [^] # Re: Subuser

      Posté par . Évalué à 3.

      salut,

      Est-ce que vous envisagez

      je crains qu'il n'y ait pas de dév guix par ici. On pourrait les pinguer.
      (dsl je crois que le dernier "nous" est trompeur, je traduisais l'article).

      • [^] # Re: Subuser

        Posté par (page perso) . Évalué à 4.

        En effet, j'ai cru que c'était un des dévs qui parlait (et il n'y a pas que le dernier « nous », les 2 sont trompeurs). Je ne vois nulle part une mention que c'est une traduction, du coup ça serait bien de la mettre.

        Merci pour l'article en tout cas.

        • [^] # Re: Subuser

          Posté par . Évalué à 3.

          Je les ai pingués.

          J'en profite pour corriger que jusqu'à présent l'INRIA n'a rien eu à voir dans le dévelopment de Guix. Ludociv Courtès (dév principal) y travaille bien, mais ne travaillait pas sur Guix.

  • # 2 articles en français sur GLMF

    Posté par . Évalué à 3.

  • # Enfin ...

    Posté par . Évalué à 3. Dernière modification le 02/06/17 à 09:10.

    Si j'ai bien tout compris :

    cela permet de créer un paquet de binaire pour une architecture donné dans le but de SIMPLIFIER l'installation et/ou le déploiement.

    un peu comme le langage go qui fournit un binaire un peu plus gras que la normale mais complet et indépendant des autres librairies.

    Si c'est bien cela … alors merci et vivement que cela se diffuse très très vite

    Bon les opérations transactionnelles, c'est pas nouveau AIX doit le faire depuis le siècle dernier mais bon tout appartient à qui sait attendre.

    Sinon merci pour ce travail, je ne sais plus si la notion de librairie partagée venait du temps ou les médias n'avait que très d'espace libre et que la mémoire vive coûtait chère, mais maintenant …

    Même je suis admiratif devant des outils comme apt qui gère bien les dépendances, mais quand ça veux pas …

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.