4.1 Contêineres Guix

A maneira mais fácil de começar é usar guix shell com a opção --container. Veja Invocando guix shell em Manual de Referência GNU Guix para uma referência de opções válidas.

O snippet a seguir gera um processo de shell mínimo com a maioria dos namespaces não compartilhados do sistema. O diretório de trabalho atual é visível para o processo, mas qualquer outra coisa no sistema de arquivos não está disponível. Esse isolamento extremo pode ser muito útil quando você deseja descartar qualquer tipo de interferência de variáveis de ambiente, bibliotecas instaladas globalmente ou arquivos de configuração.

guix shell --container

O trecho a seguir gera um processo de shell mínimo como a maioria dos namespaces não compartilhados do sistema. O diretório de trabalho atual é visível para o processo, mas qualquer outra coisa no sistema de arquivos não está disponível. Esse extremo de isolamento pode ser muito útil quando você deseja descartar qualquer tipo de interferência de variáveis de ambiente, bibliotecas instaladas globalmente ou arquivos de configuração.

$ 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

Não há muito que você possa fazer em um ambiente como esse além de sair dele. Você pode usar ^D ou exit para encerrar esse ambiente de shell limitado.

Você pode tornar outros diretórios disponíveis dentro do ambiente do contêiner; use --expose=DIRECTORY para montar o diretório fornecido como um local somente leitura dentro do contêiner, ou use --share=DIRECTORY para tornar o local gravável. Com um argumento de mapeamento adicional após o nome do diretório, você pode controlar o nome do diretório dentro do contêiner. No exemplo a seguir, mapeamos /etc no sistema host para /the/host/etc dentro de um contêiner no qual os GNU coreutils estão instalados.

$ guix shell --container --share=/etc=/the/host/etc coreutils
$ ls /the/host/etc

Da mesma forma, você pode evitar que o diretório de trabalho atual seja mapeado para o contêiner com a opção --no-cwd. Outra boa ideia é criar um diretório dedicado que servirá como o diretório home do contêiner e gerar o shell do contêiner a partir desse diretório.

Em um sistema estrangeiro, um ambiente de contêiner pode ser usado para compilar software que não pode ser vinculado a bibliotecas do sistema ou à cadeia de ferramentas do compilador do sistema. Um caso de uso comum em um contexto de pesquisa é instalar pacotes de dentro de uma sessão R. Fora de um ambiente de contêiner, há uma boa chance de que a cadeia de ferramentas do compilador estrangeiro e bibliotecas de sistema incompatíveis sejam encontradas primeiro, resultando em binários incompatíveis que não podem ser usados pelo R. Em um shell de contêiner, esse problema desaparece, pois as bibliotecas e executáveis do sistema simplesmente não estão disponíveis devido ao namespace mount não compartilhado.

Vamos pegar um manifesto abrangente que fornece um ambiente de desenvolvimento confortável para uso com R:

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

        ;; base packages
        "bash-minimal"
        "glibc-locales"
        "nss-certs"

        ;; Ferramentas comuns de linha de comando para o caso de o contêiner ficar muito vazio.
        "coreutils"
        "grep"
        "which"
        "wget"
        "sed"

        ;; Ferramenta de marcação R
        "pandoc"

        ;; Cadeia de ferramentas e bibliotecas comuns para "install.packages"
        "gcc-toolchain@10"
        "gfortran-toolchain"
        "gawk"
        "tar"
        "gzip"
        "unzip"
        "make"
        "cmake"
        "pkg-config"
        "cairo"
        "libxt"
        "openssl"
        "curl"
        "zlib"))

Vamos usar isso para executar o R dentro de um ambiente de contêiner. Por conveniência, compartilhamos o namespace net para usar as interfaces de rede do sistema host. Agora podemos construir pacotes R a partir da fonte da maneira tradicional, sem ter que nos preocupar com incompatibilidades ou incompatibilidades de 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())
> # sucesso!

Usar shells de contêiner é divertido, mas eles podem se tornar um pouco trabalhosos quando você quer ir além de apenas um único processo interativo. Algumas tarefas se tornam muito mais fáceis quando se assentam na fundação sólida de um Sistema Guix adequado e seu rico conjunto de serviços de sistema. A próxima seção mostra como iniciar um Sistema Guix completo dentro de um contêiner.