We finally made some progress on this on our end (see here). Some gotchas we encountered along the way:
- Singularity support. Because docker requires sudo access, it’s generally not an option on computing clusters. You can pull images from docker hub into Singularity 2.3+ fairly easily and run them unprivileged.
- We needed a meta-versioning system. For both the image itself and to track the versions of bundled software. We ended up going with a fairly non-portable solution involving a couple custom scripts where versions numbers for software are kept in a yaml file with the Dockerfile, and these files are parsed during build to determine software versions to install.
- We used version number tags on our repositories and mapped them to image tags on docker hub to create versioned builds. It works fine, but it’s not as automated as I’d like.
- We did something similar for tracking build information, such as the image build date and changesets for installations from repositories that are unversioned. Storing the information inside the image as a
/Build.yamlfile.
It’s my understanding, possibly incorrect, that cwltool is currently dependent upon docker and won’t work with singularity images. Does anyone know anything about this? We haven’t gotten very far into CWL yet, but this would be a deal breaker for us if that’s the case, because we couldn’t use it on our computing cluster.
Also, I’m not terribly thrilled with how we implemented the meta-versioning system (items 2-3), because it’s not very generalized. I couldn’t think of anything better at the time. If anyone knows of a more robust solution, that isn’t too complication, I’d love to hear about it.