Docker/Apptainer HATS@LPC: Glossary

Docker provides loosely isolated environments called containers.

These containers are lightweight alternatives to virtual machines.

You can package and run software in containers.

You can run many containers simultaneously on a single host machine.

Pull images with docker pull

List images with docker images

Image tags distinguish releases or version and are appended to the image name with a colon

The default registry is Docker Hub

Run containers with docker run

Monitor containers with docker ps

Exit interactive sessions just as you would a shell, with exit

Stop a container with docker stop

Restart stopped containers with docker start

Remove containers with docker rm

Remove images with docker rmi

Perform faster cleanup with docker container prune, docker image prune, and docker system prune

Copy files to an from a container using docker cp

Mount a folder/file inside a container using -v <host path>:<container path>

It is more practical to use light-weight containers and obtain CMSSW via CVMFS.

You can install CVMFS on your local computer.

The cvmfs-automounter allows you to provide CVMFS to other containers on Linux.

Privileged containers can be dangerous.

You can mount CVMFS from within a container on container startup.

The cms-cvmfs-docker image includes a lot of features missing from other CMS images.

It has graphics support, CVMFS mount integrity support, and ID mapping support.

It is Fermilab security compliant.

Full CMSSW release containers are very big.

Standalone CMSSW containers are currently not routinely built due to their size.

They need to be built/requested when needed.

Apptainer needs to be used for running containers on CMSLPC/LXPLUS.

CMS Computing provides a wrapper script to run CMSSW in different Linux environments (SLC5, SLC6, CC7, CC8).

The centrally supported way to run CMSSW in a container is using Apptainer.

To run your own container, you need to run Apptainer manually.

The unpacked.cern.ch CVMFS area provides a very fast way of distributing unpacked docker images for access via Apptainer.

Using this approach you can run versioned and reusable stages of your analysis.

Pre-made images are not an excuse for poor security practices

It’s better to err on the side of caution when building images and running containers

DO NOT store sensitive information in your containers!

Dockerfiles are written as text file commands to the Docker engine

Docker images are built with docker build

Docker images can have multiple tags associated to them

Docker images can use COPY to copy files into them during build

CMD provide defaults for an executing container

CMD can provide options for ENTRYPOINT

ENTRYPOINT allows you to configure commands that will always run for an executing container

GitLab CI allows you to re-build a container that encapsulates the environment each time new commits are pushed to the analysis repo.

This can be accomplished in a scripted manner with Docker-in-Docker or with the use of a Dockerfile, which will specify how to build the environment.

You will need to add an image-building stage to the .gitlab-ci.yml file.

Containers are very extensible

Moby BuildKit is a new build engine for Docker and includes a lot of new and advanced features.

You can mount CVMFS when building images, with some caveats.

Podman can be used as a replacement for Docker in almost every circumstance.

Buildah is a powerful image building platform with fine control over how layers are created.

Rootless Podman is a safe way to allow non-root users to run containers on shared resources.

Use the containerize.sh script within the FNALLPC/lpc-scripts package in order to make an image containing an arbitrary CMSSW directory.