search

OSIPI / TF2.4_IVIM-MRI_CodeCollection

OSIPI TF2.4: IVIM MRI code collection
Apache License 2.0
9 stars 27 forks source link

[Feature] Docker container #64

Closed etpeterson closed 3 months ago

etpeterson commented 4 months ago

Feature description

Dockerize the code so that processing could be run from the command line, e.g. docker run

Describe the solution

This would simply put the OSIPI code inside of a docker container that could be run on the command line. Something like this for now: https://stackoverflow.com/questions/42625947/docker-input-output-outside-the-container

Just to run one and exit. Future work would be to keep it alive for future connections.

Describe alternatives

The current approach doesn't use the docker container. This would allow for someone to run the processing without installing anything other than docker and downloading our image. Further work could make it more of a server architecture, but this is the first step.

Other containerization could be used as well, such as singularity. Perhaps both could be supported in the future.

Additional context

No response

Are you working on this?

None

Unique-Usman commented 3 months ago

@etpeterson, following up with this, I have some questions.

  1. By dockerizing the code, we are basically dockerizing this wrap script created in https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/issues/58?
  2. This is regarding how the input and the output data will be mounted when running the docker image, I am thinking bind mounting might be better since the input and output might keep changing, and I do not think we have all the input data in the repository as some are gotten from zenodo. What do you think ?
etpeterson commented 3 months ago

Yes, I think you're correct for both. However, the data should be provided and not downloaded from zenodo. We can assume people will send data in - essentially point to some files or folders. In fact that should be a requirement.