Running the JLab CE container
Overview
Teaching: 5 min
Exercises: 10 minQuestions
How can we replicate the Jefferson Lab Common Environment on other systems?
Objectives
Understand how tags are used to version containers.
Load and use the Jefferson Lab Common Environment on the interactive farm nodes.
Tags: versioning of containers
In the previous episode we downloaded the lolcow container, at
shub://GodloveD/lolcow and the container was stored with the filename
GodloveD-lolcow-master-latest.simg. Let’s analyze that URL and filename.
shubindicates that the URL points to a Singularity Hub location.GodloveDis the user who provided this container (David Godlove, if you must know, see for example this GitHub page).lolcowis the name of the repository that was used to build this container.masteris the branch from which the container was built.latestis the tag of the container, with latest for the most recent build.
The tag is commonly used for versioning of containers. By specifying the URL as
shub://GodloveD/lolcow:latest we can explicitly ask for the latest version of
the lolcow container.
Since there is not a lot of versioning one can do on this container, we will first introduce a container where versions ARE important.
Retrieving the Jefferson Lab Common Environment container from Singularity Hub
Now that we have the basics of containers behind us, we can use our first ‘useful’ physics container: the Jefferson Lab Common Environment container. This container replicates the scientific software suite that is installed on the interactive farm nodes, but packages it up in a nice container.
Of course, there is no real practical need to load the Jefferson Lab Common Environment on a Jefferson Lab interactive farm node, but bear with me for now.
Here is how we download the container:
singularity pull shub://JeffersonLab/jlabce:2.1
singularity shell JeffersonLab-jlabce-master-2.1.simg
Notice how we specified as the tag 2.1 which will instruct singularity to
retrieve container version 2.1. We could also retrieve versions 2.0 and 2.2.
In fact, the three available containers are listed on the Singularity Hub page.
We could have used the singularity shell command as well, but this
demonstrates how with pull we can separate the downloading from running (when
using the container as an appliance) or opening a shell (when using the
container as an environment).
Retrieve the Jefferson Lab Common Environment container, tag 2.2
- Navigate to a directory where you can write large files
mkdir -p /volatile/hallc/qweak/$USER/singularity cd /volatile/hallc/qweak/$USER/singularity- Retrieve the Jefferson Lab Common Environment container, tag 2.2, with
singularity pull.Solution
Using the Jefferson Lab Common Environment container
We can open a shell inside the Jefferson Lab Common Environment container, but we still need to setup the actual environment (just as simply logging in on the interactive farm nodes does not give you access to the scientific software).
Because the operating system in the container is technically different from the host operating system, and because singularity shell inherits environment variables, we must unset the variable OSRELEASE inside the container with
unset OSRELEASE
Note: Once inside the container we are using the bash shell, regardless of what your setup may be outside the container.
Once OSRELEASE is unset we can simply load the Common Environment load script:
source /jlab/2.2/ce/jlab.sh
This will load the Jefferson Lab Common Environment, version 2.2. Note that the container with tag 2.2 only contains the Jefferson Lab Common Environment, version 2.2.
Load the Jefferson Lab Common Environment, version 2.2
- Open a shell in the JeffersonLab-jlabce-master-2.2.simg container.
- Unset the OSRELEASE variable
- Load the Jefferson Lab Common Environment, version 2.2.
Solution
Key Points
The Jefferson Lab Common Environment containers provide a standard environment.