Maintaining Open Source Singularity Since 2017
Docker / OCI Compatibility in SingularityCE 3.9.0
By Adam Hughes
The Open Containers Initiative (OCI) image format, which grew out of Docker, is the dominant standard for cloud-focused containerized deployments of software. While it’s possible to work with SingularityCE and never touch a Docker or OCI container, it’s likely you’ll want to run containers that are being distributed through the large public OCI registries such as Docker Hub and Quay.io.
Since Singularity 2.2 the ability to directly run, or build from, most OCI containers has been a key feature of the project. SingularityCE 3.9 continues the trend of providing simpler and more complete compatibility with Docker. We’ve also heavily rewritten the “Support for Docker and OCI Containers” section of our user guide, to more clearly explain the caveats and workarounds sometimes required.
A new --compat flag has been added to turn on a set of common options that are most frequently needed to improve compatibility with Docker images. Because SingularityCE has a different security model than Docker / OCI runtimes, not all concepts map exactly. We also mount directories into the container by default, for convenience, and use less isolation from host devices and networking. This approach has many advantages and makes it easier to e.g. run many parallel workloads on HPC systems, but can affect the execution of some Docker containers. The --compat flag is a quick and easy way to work around most of the differences between SingularityCE and Docker, when needed.
We’ve also introduced a --mount flag, which accepts Docker style syntax to bind mount files and directories into a container. This makes it easier to transition to running containers with SingularityCE, and permits mounting paths that contain certain special characters (not possible with --bind). We’ll be working to support other non-bind mount types in future, for additional compatibility.
For users with NVIDIA GPUs, we’ve provided experimental new functionality to configure the container using the nvidia-container-cli tool from NVIDIA’s libnvidia-container project. This is the same tool that is used to set up GPUs with Docker and other OCI runtimes. Our next blog post will cover this new functionality, and the workflows it permits, in depth.
Finally, we’ve fixed some sharp edges so that Dockerfile LABEL‘s are correctly inherited in a singularity build, and the %files section of our definition files uses the same pattern matching as Dockerfile COPY.
We’re looking forward to continuing this work as we look forward to SingularityCE 4.0. Let us know what’s most important to you via our open SingularityCE roadmap, or our community channels.
Join Our Mailing List
Recent Posts
Related Posts
Laying the Groundwork for 2025: Sylabs’ Vision for Secure Multi-Cloud Solutions
With a legacy rooted in innovation through the work we’ve done with the Singularity platform, Sylabs has consistently worked to provide secure container technology to empower researchers, enterprises, and innovators worldwide. These efforts have paid dividends as we...
Transformative Potential of Confidential Computing to be Explored in SC24 Birds of a Feather Session
Learn about secure multi-party collaboration in confidential computing at SC24, enabling safe data processing in cloud environments.
Creating New Levels of Security with Containers and Confidential Computing
Data breaches are becoming increasingly common. It's more important than ever to find robust solutions that protect sensitive information. Recent high-profile data breaches underscore the necessity for fresh approaches to data protection. Breaches like these are...