Specify a convention for entrypoint commands in docker image #4440
bilalshaikh42
started this conversation in
Discussions
Replies: 2 comments
-
@jonrkarr do you have any thoughts on this? |
Beta Was this translation helpful? Give feedback.
0 replies
-
Its possible to inspect a Docker image to determine what the entrypoint is. I think this information could be used rather than asking developers to repeat this in our specifications.
For Python, see https://docker-py.readthedocs.io/en/stable/api.html. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Motivation
I have been experimenting with running the BioSimulator containers in an Argo Workflows environment. Due to limitations in the way that Kubernetes can execute containers, the configuration of the workflow requires specifying the command to be run in the container. That is, it cannot simply use the default entry point, and the command must be manually specified.
Issue
I was able to set the command for the simulators easily, but simply using
biosimulators-{{simulatorName}}
as the default command. This works for all the python based simulators, but not for the Vcell container. I assumed VCell must not follow the convention that the python apps do, so triedvcell
which also didn't work. Turns out, the entry point for the VCell container is actually/usr/local/app/vcell/installDir/docker_run.sh
, which is not at all obviousPotential Solutions
We might want to add to the conventions of docker images or command-line interfaces that the entry point/ command to run the biosimulators compatible simulation tool follow some convention, such as
biosimulators-{{simulatorName}}
orsimulatorName
. This would add a level of consistency when trying to use the tools within the container environment (meaning, working in or developing within a running container rather than simply passing in arguments to the container) and also enable a consistent approach to the workflow issue described above.Potential Problems
The biosimulators prefix options would mean that all simulation tool developers would need to make a wrapper for their tool, rather than just having the tool follow the standard interface.
We could require that the command be the name of the simulator, but this seems to go too far into dictating the development of the tool itself rather than the interface. A tool might want to have a simple command to invoke it rather than its full name for example.
One potential work around would be to register an alias in the path of the docker images, so that
simulatorName
automatically points to the default entrypoint.Beta Was this translation helpful? Give feedback.
All reactions