Add Dockerfile

[MarionBWeinzierl]

Add a Dockerfile which provides the Nextsim installation. This should be put into the repository first. We should also consider uploading it on DockerHub, so that users, but also the Github Actions, can directly use the image.

Steps:

• [x] Add Dockerfile to repository
• [x] Update documentation accordingly
• [x] Consider DockerHub (and, if positive decision is made, upload and document stuff)

[MarionBWeinzierl]

I first thought it would be best to create a light-weight Dockerfile/image based off alpine. However, as the CI tests Ubuntu I started with Dockerfiles based off that. Do you think we should still have a "lighter" alternative @TomMelt @einola @timspainNERSC ?

[TomMelt]

my two cents...

For docker you want alpine. It has a much lower overhead. We could add the alpine build to the CI and then we are covering even more bases. More chance to spot bugs :bug: :mag:

I don't have a strong preference though, as I won't be running it inside docker anyway.

[einola]

I see three ways of structuring the Dockerfile. Which we choose depends on the use case.

1. Everything happens in the Dockerfile, including git pull, cmake, and make
2. The code is copied into the Dockerfile, which then runs cmake and make
3. We mount the src directory inside Docker and leave the running of cmake and make to the user

I guess option 1 is best for general distribution, and option 3 is best for development - but option 3 is much more cumbersome. Option 2 lies somewhere between.

We've used option 3 in the past, where the process is along the lines of

$ docker build . -t nextsim
$ docker run --rm -it -v $PWD:/nextsim -w /nextsim nextsim make

Then, if I modify the code, I can rerun the second command, and the compilation is very quick. But I always have to look up the second command o_o

What do you think about these three options?

[MarionBWeinzierl]

I like to work with 2 for development (using docker run --rm -it --entrypoint bash nextsim to enter the Docker image and then run whatever I like to run). 1 would be cleaner for deployment on Dockerhub. I do not like option 3, as it feels a bit like a half-done job - if we've gone that far with Docker, we might as well build the code.