docker2singularity

This is an alternative implementation of docker2singularity that does not rely on Docker in Docker and granting the container full host device root capabilities via the --privileged flag.

(Which should in general be done only if absolutely necessary, could be considered bad practice, and turned out not to be necessary for the local container build workflows described below.)

Use cases

Singularity build

Build a Singularity image from a locally build Docker image,

$ docker pull kathoef/docker2singularity:latest
$ docker build -f Dockerfile -t localhost/test .
$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock:ro -v ${PWD}:/output \
  kathoef/docker2singularity singularity build test.sif docker-daemon://localhost/test:latest

Singularity pull

Build a Singularity image from a remotely hosted Docker image,

$ docker pull kathoef/docker2singularity:latest
$ docker run --rm -v ${PWD}:/output \
  kathoef/docker2singularity singularity pull alpine_latest.sif docker://alpine:latest

Compatibility

These workflows were tested on Linux, MacOS Mojave and Windows 10 (w/ Hyper-V backend) and Docker Desktop with Docker Engine v20.10.6 installed.

For Linux hosts

You might want to fix the Singularity image file ownership after conversion,

$ ls -l test.sif
-rwxr-xr-x 1 root root 2777088 Mai 15 17:19 test.sif
$ sudo chown $(id -u):$(id -g) test.sif
$ ls -l test.sif
-rwxr-xr-x 1 kathoef kathoef 2777088 Mai 15 17:19 test.sif

Background information

The Docker image provided here was originally specified for container image portability tests in order to have a fully controllable Singularity pull environment available.

It turned out that my local Docker image Singularity build tasks also worked quite well and only required the Docker socket to be mounted as read-only.

Since I use these Docker-based local Singularity container image build workflows quite often ¹ I thought I'd provide a bit of a structured ground to this approach. Maybe it happens to be useful to others, feedback is welcome!

References

Singularity/Apptainer,

• https://github.com/singularityhub/docker2singularity (the original!)
• https://sylabs.io/guides/3.7/user-guide/singularity_and_docker.html#locally-available-images-cached-by-docker
• https://github.com/apptainer/singularity

Multi-architecture build,

• https://docs.docker.com/buildx/working-with-buildx/
• https://github.com/docker/setup-buildx-action#with-qemu
• https://github.com/docker/build-push-action/blob/c5e6528d5ddefc82f682165021e05edf58044bce/docs/advanced/test-before-push.md

Footnotes

1. mainly since CI and/or manual DockerHub-based workflows add complexity to a single-user data analysis project that seems unnecessary and also because I have seen singularity pull attempts on e.g. HPC machines failing ↩