Containers on Fiji

Containers are a popular way to package up a specific piece of software so that it's available to run consistently for anyone who wants to use it. The most popular technology to create and run containers today is Docker, and while that is the case, Docker poses some security threats that can be mitigated by using other technology. As such, BIT provides Singularity for users on the compute cluster. The good news is, it's easy to pull a Docker container image and "convert" it for use with Singularity, and when in doubt, BIT will always be available to help you with this process. Below, we document the most common Singularity use-cases, but for any additional questions or to request we build a container for you, please submit a ticket. Note: Any versions of containers that we've already built on Fiji are available in /scratch/Shares/public/singularity.

Singularity Versions on Fiji

While most software installed on Fiji is only available by using the modules system, there is a default Singularity version available to anyone once they login, and it's typically the newest. This version is built and packaged by the CentOS maintainers, so it is a trusted build and we are able to rely on it. To verify this, we can use which to see that it's in our path directly after logging in:

You can still load a specific (older) version of Singularity using Lmod and the module commands. If you need a version you don't see listed, submit a ticket. To see all available Singularity versions:

Pulling and Running a Docker Container with Singularity

There's no doubt that most software you may want to utilize is available on the Docker Hub. Again, it's easy to use these images with Singularity. The example we always like to use is Graph Tool, as it's a very complicated tool to install properly on the compute cluster. Getting a Singularity image file for Graph Tool is easy, though (your output will likely differ slightly):

Using the software in the container is just as easy! Let's assume you want to run an iPython session inside of the container (so you have access to Graph Tool). The singularity run command will allow you to do just that using your newly created Singularity image file:

Though there is no real indication other than the iPython prompt that appeared, rest-assured the iPython session is inside of the container and all libraries required to use Graph Tool are available, too!

Bind Paths in Containers

By default, you'll notice that inside of a container your home directory, /Users/<yourIdentikey>, is always available. In addition, the directory that you run a container from is also available. This means if you have your containers in your base scratch directory, /scratch/Users/<yourIdentikey>, you will have access to both your home and scratch directories in the container. You can see this for yourself by pulling a very simple CentOS container with no special software or tools available in it and checking for some files or folders in your home and scratch directories. Typically, a container like this is used as a building block or starting point for creating your own containers:

After pulling the container to your top-level scratch directory, execute a bash shell inside of it and check for your home and scratch directories to ensure they're available inside of the container. Note that by default, your pwd in the container is where you executed singularity run from! Also, to exit an interactive shell inside of a container, just type exit.

There will be cases where you want to include other (potentially many!) paths in your container environment, though. Or sometimes you can just use custom bind paths to trick software into writing things somewhere more convenient. For example, let's assume you want to run a program, available in a container, that writes many, many GB to /tmp. On a standard Fiji compute node, /tmp is only 100G, so you will definitely run out of space. We can bind /tmp in our container to /scratch/Users/<yourIdentikey> on the underlying filesystem. For all of the following, you are going to use the same base CentOS image as before. To demonstrate in full, first create a tmp directory in your own scratch space:

Next, execute a bash shell inside of the container using singularity run. This time, though, be sure to note the bind path to add to your command. Once inside of the container, navigate to /tmp, use touch to create a new, empty file, exit the container, and you'll see that it was actually created in your tmp directory on scratch:

Choosing where to store temporary files created inside of a container isn't the only use for bind paths, though, so adapt them to suit your needs! This is the primary means for accessing data in a container that originates outside of the container, and for ensuring data created inside of the container is available after the container finishes running.

Container Caveats

Of course with ANY software or technology, especially depending on implementation, there are some drawbacks and caveats. Here are a few things to be mindful of on Fiji.

1. root access is required for building containers (using singularity build). If you want a container built directly on Fiji, you will have to submit a ticket to request assistance. Otherwise, you are welcome to build the container on your own machine and copy it onto Fiji. Usually this will work even across different versions of Singularity.
2. Trying to inject software int provided by modules (anything in /opt on Fiji) into your container through the use of bind mounts occasionally works, but often it doesn't. The best results come when you are using a CentOS 7 container while trying this, as all of our software is built and tested on CentOS 7.