Use Cases

Why would you need a Singularity Registry Server? The answer is when you would want to be able to manage, organize, and share images, and you don’t want to be limited in the number of builds, or how you build the images.

Personal Use

In this use case, I am an individual user, or share a computer resource with a small group. I decide to run a local Singularity Registry Server (on localhost or 127.0.0.1) that anyone that uses the computer can push images after being built. The images are then accessible on my computer based on the unique resource identifier, without me needing to keep track of where they were built. I can get a summary of image sizes, and search over images to find images of interest. I keep the entire Registry private so it cannot be discovered externally, but create an expiring sharing link to send securely to a collaborator to test one of my pipelines.

Managed Cluster Registry

My university runs a shared computational resource manages a registry on a server next to it. Akin to supplying software modules, the administrators keep a version controlled repo of build recipes, and when software needs to be updated, create a new image with a tag for the version. The users can then use the images by way of specifying the unique resource identifier.

Collaborative Cluster Registry

It’s often the case that pipelines are maintained internally within labs, or eventually discarded after papers are published and graduate students finish. In this use case, a large cluster wants to provide a central, organized resource for the scientific containers generated by its researchers. Perhaps alongside or instead of the core software and tools, this cluster decides to build final or published containers for its users. Building might lead to a private image for use at the institution, or a public image that can be referenced in a publication and easily disseminated. To build, the researcher simply might submit a pull request to a Github repo associated with the registry, it can be built and tested and discussed, and when ready, pushed to the resource from the continuous integration, or by the cluster’s particular build server. Either way, the final upload is an authenticated, single line call to push the image with an appropriate name and tag. If you add plugins you can also have custom authentication and builds (e.g., GitHub webhooks + Google Cloud Build).

If you are a single user and looking for an image management tool, perhaps to work with images in multiple locations beyond a Singularity Registry, Server then you will be interested in the Singularity Global Client.