What are Containers

The reproducibility problem

You build a variant calling pipeline on your laptop. It runs perfectly. You send it to a collaborator. It breaks immediately.

The problem is rarely your code. It is almost always the environment. Your colleague has a different version of samtools. Their Python is 3.9 instead of 3.11. A shared library is missing. The reference genome index was built with an older version of bwa.

This is the most common problem in computational biology. Published methods fail to reproduce because the software environment is not recorded. A Snakemake or Nextflow pipeline defines the steps, but it does not guarantee the tools will behave the same way on another machine.

What containers solve

A container packages your code, your tools, and all of their dependencies into a single portable unit. It runs the same way on any machine.

Think of it as a lightweight virtual machine that captures your exact software environment. When you share a container image, your collaborator gets the same operating system libraries, the same tool versions, and the same configuration. There is nothing to install separately. There is nothing to configure.

If your pipeline uses STAR 2.7.11b inside a container, every person who runs that container will use STAR 2.7.11b. No surprises.

Containers vs virtual machines

Containers and virtual machines both provide isolation. They differ in how much of the system they replicate.

A virtual machine runs an entire operating system. It includes its own kernel, its own file system, and its own device drivers. This makes VMs heavy. They use gigabytes of disk space. They take minutes to start.

A container shares the host machine’s kernel. It only packages the application layer: your tools, libraries, and configuration files. This makes containers light. They use megabytes of disk space. They start in seconds.

For bioinformatics, containers give you the isolation you need without the overhead you do not.

Why Podman over Docker

Docker has been the standard container tool for years. It works well, but it has a significant security problem. Docker requires a background daemon that runs as root. Any user with access to Docker effectively has root access to the host machine.

This matters in science. On shared servers and HPC clusters, system administrators often refuse to install Docker. The security risk is too high when dozens of researchers share the same machine.

Podman solves this problem. It is a drop-in replacement for Docker with several advantages:

• No root required. Podman runs containers as your normal user without elevated privileges. This is called “rootless” mode. It does not require sudo.
• No daemon. Docker runs a background service at all times. Podman does not. Each container is a regular process managed by your user session.
• Same commands. Every Docker command works with Podman. Replace the word docker with podman and everything works the same way.
• Same images. Podman uses the same Dockerfile format. It pulls the same container images from Docker Hub and other registries.
• HPC friendly. Because Podman needs no root access and no daemon, it is far easier to install on shared systems.

Throughout this tutorial series, we will use Podman. Any Docker tutorial or guide you find online will apply directly. Just swap the command name.

Container images vs containers

These two terms are easy to confuse.

An image is a template. It is a read-only snapshot of a file system containing your tools, libraries, and code. Images are what you build, share, and download.

A container is a running instance of an image. When you start an image, it becomes a container. You can run multiple containers from the same image. Each one is independent.

As an analogy: an image is like a genome reference file. A container is like an alignment job that uses that reference. You run many jobs against the same reference.

Where images come from

You do not have to build every image from scratch. Public registries host thousands of pre-built images.

• Docker Hub is the largest and most well known registry. It hosts official images for tools like Python, R, and Ubuntu.
• Quay.io is a registry run by Red Hat. Many bioinformatics projects host their images here.
• GitHub Container Registry lets project maintainers publish images alongside their source code.
• BioContainers is the most relevant registry for bioinformatics. It provides pre-built images for thousands of tools including samtools, bcftools, STAR, salmon, fastqc, and many more. If a tool is available through Bioconda, it almost certainly has a BioContainers image.

When you need a tool, check BioContainers first. Using a community-maintained image saves time and improves reproducibility across labs.

Installing Podman

On Ubuntu, install Podman with your package manager. This is one of the few commands in this tutorial that requires sudo:

sudo apt install podman

Verify the installation:

podman --version

You should see output like podman version 4.9.3 or similar. The exact version number will vary.

No further configuration is needed. Podman works in rootless mode by default.

Next steps

Now that you understand what containers are and why they matter, the next page covers building your own container images.