4.1 Conteneurs Guix

La manière la plus simple de démarrer est d’utiliser guix shell avec l’option --container. Voir Invoquer guix shell dans le manuel de référence de GNU Guix pour la référence des options valides.

Le bout de code suivant démarre un shell minimal avec la plupart des espaces de noms départagés du système. Le répertoire de travail actuel est visible pour le processus, mais tout le reste du système de fichiers est indisponible. Cette isolation extrême peut être très utile si vous voulez écarter toute interférence des variables d’environnement, des bibliothèques installées globalement ou des fichiers de configuration.

guix shell --container

C’est un environnement vierge, aride et désolé. Vous trouverez que même GNU coreutils n’y est pas disponible, donc pour explorer cet environnement désert vous devrez utiliser les commandes internes au shell. Même le répertoire /gnu/store habituellement énorme est réduit à peau de chagrin.

$ echo /gnu/store/*
/gnu/store/…-gcc-10.3.0-lib
/gnu/store/…-glibc-2.33
/gnu/store/…-bash-static-5.1.8
/gnu/store/…-ncurses-6.2.20210619
/gnu/store/…-bash-5.1.8
/gnu/store/…-profile
/gnu/store/…-readline-8.1.1

Vous ne pouvez pas faire grand chose de plus dans un environnement comme celui-ci à part en sortir. Vous pouvez utiliser Ctrl-D ou exit pour quitter cet environnement shell limité.

Vous pouvez rendre d’autres répertoires disponibles à l’intérieur de l’environnement du conteneur. Utilisez --expose=RÉPERTOIRE pour créer un montage lié au répertoire donné en lecture-seule à l’intérieur du conteneur, ou utilisez --share=RÉPERTOIRE pour rendre cet emplacement inscriptible. Avec un argument de correspondance supplémentaire après le nom du répertoire vous pouvez contrôler le nom du répertoire lié dans le conteneur. Dans l’exemple suivant nous faisons correspondre /etc du système hôte à /l/hôte/etc dans un conteneur dans lequel GNU coreutils est installé.

$ guix shell --container --share=/etc=/l/hôte/etc coreutils
$ ls /l/hôte/etc

De même, vous pouvez empêcher le répertoire actuel d’être ajouté au conteneur avec l’option --no-cwd. Une autre bonne idée est de créer un répertoire dédié qui servira de répertoire personnel dans le conteneur et de démarrer le shell du conteneur dans ce répertoire.

Sur un système externe un environnement de conteneur peut être utilisé pour compiler un logiciel qui ne peut pas être lié aux bibliothèques du système ou avec la chaine d’outils du système. Un cas d’utilisation courant dans le contexte de la recherche est l’installation de paquets à partir d’une session R. En dehors de l’environnement du conteneur il est fort probable que la chaine de compilation externe et les bibliothèques systèmes incompatibles soient trouvés en premier, ce qui créer des binaires incompatibles qui ne peuvent pas être utilisés dans R. Dans un conteneur ce problème disparait car les bibliothèques du système et les executables ne sont simplement pas disponibles à cause de l’espace de nom mount départagé.

Prenons un manifeste complet pour fournir un environnement de développement confortable pour R :

(specifications->manifest
  (list "r-minimal"

        ;; paquets de base
        "bash-minimal"
        "glibc-locales"
        "nss-certs"

        ;; Outils en ligne de commande usuels, sans lesquels le conteneur est trop vide.
        "coreutils"
        "grep"
        "which"
        "wget"
        "sed"

        ;; outils markdown pour R
        "pandoc"

        ;; Chaine d'outils et bibliothèques courantes pour « install.packages »
        "gcc-toolchain@10"
        "gfortran-toolchain"
        "gawk"
        "tar"
        "gzip"
        "unzip"
        "make"
        "cmake"
        "pkg-config"
        "cairo"
        "libxt"
        "openssl"
        "curl"
        "zlib"))

Utilisons cela pour lancer R dans un environnement de conteneur. Pour se simplifier la vie, nous partageons l’espace de nom net pour utiliser les interfaces réseau du système hôte. Maintenant nous pouvons construire des paquets R à partir des sources de la manière traditionnelle sans avoir à se soucier des incompatibilités d’ABI.

$ guix shell --container --network --manifest=manifest.scm -- R

R version 4.2.1 (2022-06-23) -- "Funny-Looking Kid"
Copyright (C) 2022 The R Foundation for Statistical Computing
…
> e <- Sys.getenv("GUIX_ENVIRONMENT")
> Sys.setenv(GIT_SSL_CAINFO=paste0(e, "/etc/ssl/certs/ca-certificates.crt"))
> Sys.setenv(SSL_CERT_FILE=paste0(e, "/etc/ssl/certs/ca-certificates.crt"))
> Sys.setenv(SSL_CERT_DIR=paste0(e, "/etc/ssl/certs"))
> install.packages("Cairo", lib=paste0(getwd()))
…
* installing *source* package 'Cairo' ...
…
* DONE (Cairo)

The downloaded source packages are in
	'/tmp/RtmpCuwdwM/downloaded_packages'
> library("Cairo", lib=getwd())
> # success!

Utiliser des shells conteneurs est amusant, mais ils peuvent devenir un peu embêtant quand vous voulez plus qu’un seul processus interactif. Certaines tâches deviennent plus faciles lorsqu’elles se reposent sur les fondations solides d’un système Guix et de son riche ensemble de services systèmes. La section suivante vous montre comment lancer un système Guix complet à l’intérieur d’un conteneur.