Docker Singularity Apptainer WSL2

Container Considerations

General

1. user installs Docker for their host (e.g., their laptop) - https://www.docker.com/get-started
2. via commandline or terminal once Docker is installed,
3. For WSL2, best practices include
   1. Install Windows Terminal and make it the default (instead of Command Prompt, cmd)
   2. Before ASGS can be set up in Ubuntu (under WSL2), the packages listed in the ASGS Installing Wiki should be installed with sudo
   3. Install Visual Studio Code for Windows and the Remote WSL Extension within Visual Studio Code
   4. Install Docker Desktop with support for WSL2

ASGS

For the ASGS container (deprecated)

docker run -it asgsdockerhub/2019stable

3. (user observe you are in the ASGS Shell)
4. run "verify" to see Perl and Python env validated,

asgs (default)> verify

Docker image site: https://hub.docker.com/r/asgsdockerhub/2019stable

ADCIRC

Docker

Here is an example of running a test case using the ADCIRC Docker container from Docker Hub. I used the following commands:

docker pull adcircorg/adcirc
git clone https://github.com/adcirc/adcirc-testsuite.git
cd adcirc-testsuite/adcirc/adcirc_shinnecock_inlet
docker container run --user $(id -u) --rm --mount type=bind,src=.,target=/home/adcirc adcircorg/adcirc:latest adcirc 

The only detail not shown in those commands is that I also modified the fort.15 file for the test case so that it generates NetCDF-4 output, since it doesn't by default. Then, I was able to read that output directly with QGIS as a simple showcase of ADCIRC + Docker.

I don't understand the --user $(id -u) option as well as I'd like, but I gather that it's necessary because the ADCIRC container switches to a non-root user (as I understand is good practice) which has an ID of 1001, and that doesn't match the user ID on my system. So when I tried to run without that option, the container didn't have permission to create files, which of course caused an error. One obvious solution to this permissions issue is to just change permissions on the test case directory so that any user can write to it, but the --user option seemed to be a bit cleaner. I don't know if this is the best approach though, so I'll have to look into it more.

Singularity

Example Singularity recipe file

• is based on Rocky Linux 8.5 and includes Intel oneAPI 2021.4 inside
• produces all binaries including utilities
• installs all binaries into /usr/local/bin

Apptainer

Troubleshooting

From Jason: I tried to rebuild an image from Dockerfile.dev but the build failed with messages like the following:

E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/v/vim/vim-runtime_7.4.1689-3ubuntu1.4_all.deb  404  Not Found [IP: 91.189.88.152 80]
E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/v/vim/vim_7.4.1689-3ubuntu1.4_amd64.deb  404  Not Found [IP: 91.189.88.152 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
The command '/bin/sh -c apt-get install -y gfortran wget curl vim screen htop tmux git sudo bc' returned a non-zero code: 100

Docker erroneously seems to see that the apt-get update command was run on the image in the cache, so it doesn't need to be run again. I found more info at the following link:

Leverage Build Cache

I am going to use the --no-cache=true option for docker build. From Brett: Yes, --no-cache=true is how this is handled. The caching of images that have been built is definitely handy in most situations. In this case it seems not - another thing you can do is add apt-get update && in front an additional lines you may end up adding in the Dockerfile.