1. What is Docker?

Docker has gotten so much attention for creating easily reproducible software and computing environments in the last few years, that it is sometimes conflated with container technology generally. But, just as every tissue is not a Kleenex, your workflow can benefit from container technology without using Docker.

While great for some environments, use of Docker creates some security concerns in a shared environment, like a cluster. Livermore Computing supports the use of Singularity and Podman rather than Docker. See below for more info.

2. Docker vs. Singularity vs. Podman

Docker is the best known name in the container world but comes with drawbacks in a High Performance Computing (HPC) environment like Livermore Computing (LC), such as namespace-related security concerns. Ideally, we would work with HPC-friendly container technologies that lack Docker's vulnerabilities but are fully interoperable with Docker -- the industry standard. For example, enabling our users to run pre-existing Docker containers, to build new containers using Dockerfiles, and to run containers with Docker-like syntax all on Livermore Computing machines would allow us to leverage tools and expertise that our users may have developed in other environments.

Singularity offers a flavor of container technology designed for HPC systems that addresses Docker's security concerns. Singularity provides an HPC-compatible container solution that is largely compatible with Docker, allowing you to, for example, pull and build Docker containers from DockerHub, a Docker container registry.

On the other hand, if you want to build a container from scratch, you'll need to use a recipe file (such as a Dockerfile or Singularity definition file), and Singularity definition files are not interoperable with Docker. We recommend using Podman to build containers from Dockerfiles on LC. As you'll see in a later section, you can use podman build to produce a .tar file with a Docker archive format from a Dockerfile. You can then use singularity build to convert your podman-built container to a singularity-compatible version (a .sif) for future use.

3. Where containers can help you

You can share these environments with a colleague or a future version of yourself. If you are using the same container, the two of you can avoid many common concerns tied to reproducibility, dependencies, and versions, and at least one of you will not need to build the software yourself. It also means that containers can get you up and running with a new software relatively quickly.

One caveat to the utility of containers is that the software running on them may not be as performant or efficient as it would be if it were optimized for the particular architecture on which you are running calculations.

4. Examples of when to use a container

• You want to quickly reproduce the workflow of a collaborator to check or extend that collaborator's results.
• You want to try out a new piece of software or software chain on LC systems that isn't currently installed on LC.
• You want to work with a specific version of a software. LC offers the software you want, but not the right version.