Al revisar F26～F29 — Qué es lo que aún no se ha fijado

En F26 fijamos las dependencias del paquete, y en F27～F29 fijamos el orden de ejecución. Sin embargo, queda una cosa por fijar — el propio sistema operativo. Aunque el Pixi.toml sea el mismo, si la versión del kernel de Linux o las librerías del sistema (glibc, etc.) son diferentes, pueden producirse resultados sutilmente distintos. Esta es la causa fundamental de la conocida frustración de "en mi ordenador funcionaba, pero en el servidor no". Un contenedor (container) elimina este problema al agrupar todo el entorno de ejecución en una única unidad sellada.

Principio — Sellado mediante aislamiento de procesos, no mediante máquinas virtuales

Diferencia decisiva con las máquinas virtuales

Al tener el primer contacto con los contenedores, es fácil confundirlos con las máquinas virtuales (VM). Mientras que una VM emula el propio hardware para iniciar de nuevo todo el SO invitado (incluido el kernel), un contenedor comparte el kernel del host y solo aísla los procesos, el sistema de archivos y la red mediante funciones del kernel de Linux llamadas namespace y cgroup.

$\text{tiempo de arranque de la VM} \approx \text{decenas de segundos～varios minutos} \qquad \text{tiempo de inicio del contenedor} \approx \text{cientos de milisegundos～segundos}$

Al no tener que iniciar un nuevo kernel, los contenedores son mucho más ligeros y arrancan más rápido que las VM. En cambio, dado que comparten el kernel con el host, el nivel de aislamiento es menor que el de una VM.

Capas de imagen y caché

Una imagen de Docker tiene una estructura compuesta por múltiples capas (layers) de solo lectura apiladas. Cada comando de Dockerfile crea una nueva capa, y si el contenido de la capa no cambia, dicha capa se almacena en caché para ser reutilizada.

# Ejemplo de Dockerfile — imagen mínima que encapsula bwa+samtools
FROM condaforge/mambaforge:latest

RUN mamba install -y -c bioconda -c conda-forge \
    bwa=0.7.17 samtools=1.19 \
    && mamba clean -afy

WORKDIR /data
ENTRYPOINT ["bash"]

Gracias a esta estructura de capas, es posible optimizar el proceso reutilizando la caché para la parte frontal de la imagen (por ejemplo: imagen base, instalación de dependencias que no cambian con frecuencia) y reconstruyendo únicamente la parte posterior (código de la aplicación que cambia frecuentemente).

Docker y Apptainer (antes Singularity) — ¿Por qué el HPC no utiliza Docker tal cual?

Una instalación básica de Docker (rootful) tiene una estructura que ejecuta un demonio con altos privilegios permanentemente en segundo plano. En un clúster de HPC compartido por múltiples usuarios, permitir la ejecución de este tipo de demonios a cada usuario es inaceptable desde el punto de vista de la seguridad. Aunque Docker cuenta con un modo rootless, es necesario revisar conjuntamente las políticas institucionales y las limitaciones de funcionalidad. Apptainer (antes Singularity) es un runtime de contenedores especializado en HPC diseñado para resolver este problema, permitiendo ejecutar contenedores con privilegios de usuario común sin necesidad de un demonio permanente independiente.

$\text{Docker (rootful por defecto)}: \text{demonio con altos privilegios} \qquad \text{Apptainer}: \text{sin necesidad de demonio, ejecución con privilegios de usuario}$

Por esta razón, Docker suele utilizarse como estándar en la nube y estaciones de trabajo personales, mientras que Apptainer/Singularity es el estándar común en clústeres de HPC compartidos en universidades e institutos de investigación. El hecho de que nf-core (F29) soporte tanto -profile docker como -profile singularity es precisamente para cubrir ambos entornos.

Ejemplo de cálculo manual: Tamaño de la imagen y tiempo de transferencia

Supongamos que tenemos una imagen con una imagen base de 500MB y una capa de paquetes de bioconda de 300MB añadida. El tamaño total de la imagen es

$500 + 300 = 800\text{MB}$

Si descargamos esta imagen por primera vez en 10 nodos del clúster a través de una red de 100Mbps (aprox. 12.5MB/s):

\frac{800\text{MB}}{12.5\text{MB/s} \approx 64\text{segundos/nodo}

Si la capa de la imagen base ya está almacenada en la caché de cada nodo (reutilización de capas), los datos que realmente deben descargarse son solo 300MB, por lo que:

$\frac{300\text{MB}}{12.5\text{MB/s}} = 24\text{segundos/nodo}$

De esta manera, se puede estimar el impacto que tiene el almacenamiento en caché de capas en el tiempo de despliegue real.

Práctica: Ejecución inmediata de herramientas con imágenes de Biocontainers

# SageMaker Studio Lab o un entorno con Docker instalado.
# Biocontainers es el repositorio oficial de imágenes de contenedor generadas automáticamente para cada paquete de Bioconda.

# Sin construir una imagen propia, se descarga y usa directamente una que ya contiene samtools.
docker pull quay.io/biocontainers/samtools:1.19--h50ea8bc_1

docker run --rm -v $(pwd):/data quay.io/biocontainers/samtools:1.19--h50ea8bc_1 \
  samtools view -h /data/sample.bam | head -5

# Ejecutar la misma imagen con Apptainer (entorno HPC, con permisos de usuario y sin daemon)
apptainer exec docker://quay.io/biocontainers/samtools:1.19--h50ea8bc_1 \
  samtools view -h sample.bam | head -5

-v $(pwd):/data es una opción que monta el directorio actual del host en la ruta /data dentro del contenedor. Aunque el contenedor en sí está aislado, el núcleo del aislamiento de contenedores radica en que solo se intercambian archivos con el host a través de las rutas montadas explícitamente de esta manera.

Mapeo de CS

• Virtualización a nivel de sistema operativo (OS-level virtualization): La tecnología de contenedores, que aísla procesos mediante espacios de nombres y cgroups, es una aplicación práctica de los mecanismos de aislamiento de procesos y limitación de recursos estudiados en las clases de sistemas operativos.
• Caché por capas y direccionamiento basado en contenido: El modo en que las capas de la imagen de Docker se identifican y almacenan en caché mediante hashes comparte principios de diseño con el caché de hash de contenido del -resume analizado en F28.
• Infraestructura inmutable (immutable infrastructure): La práctica de construir una imagen de contenedor una vez y no modificarla durante la ejecución, reemplazando las nuevas versiones con nuevas imágenes, refleja la misma filosofía del patrón de infraestructura inmutable en la gestión de infraestructura en la nube.

Errores frecuentes

• Solicitar imágenes de Docker directamente al HPC en modo privilegiado (privileged): La mayoría de los administradores de HPC no permiten la ejecución del demonio de Docker por razones de seguridad. En un entorno de clúster, se debe diseñar la imagen teniendo en cuenta desde el principio la compatibilidad con Apptainer.
• Generación de archivos de resultado de gran tamaño dentro del contenedor y omisión del montaje: Sin un montaje de volumen, los resultados permanecen únicamente en la capa de escritura del contenedor, lo que dificulta su recuperación y gestión; si se ejecutó con --rm, desaparecerán junto con la eliminación del contenedor. Es fundamental verificar que las rutas donde deben almacenarse los resultados estén montadas con el host.

Para profundizar más

El texto ha sido reescrito directamente por el equipo de investigación de BPD. Profundice consultando el artículo original y los materiales oficiales.

• Artículo original de Biocontainers: da Veiga Leprevost et al. (2017), BioContainers: an open-source and community-driven framework for software standardization, Bioinformatics 33(16).
• Artículo original de Apptainer (Singularity): Kurtzer et al. (2017), Singularity: Scientific containers for mobility of compute, PLOS ONE 12(5).
• Broad Institute — Guía práctica de contenedores: Documentación oficial sobre el uso de contenedores de GATK4.

En el siguiente capítulo (F31), se abordará cómo ejecutar a gran escala estos contenedores encapsulados en el programador Slurm de un clúster HPC real, así como los cuellos de botella de E/S.