Start a docker container from bash script and execute commands on it

Question

I am having a problem running Fenics using their docker container:

Background to this is: One main VM communicates with the user via a REST API and gets one or many tasks to compute in Fenics. Fenics runs on the docker containers. Now the main VM has to orchestrate different worker-VMs using a script.

Example: the user wants to have meshes A and B getting computed using parameter sets x and y. For this two worker-VMs can be used, which have Fenics container installed. How can I start a docker container and pass the parameters into it, by using a bash script?

In the first try I cannot even access a created container on my own computer using a script, since the container exits immediately.

#!/bin/bash

clear
docker run -dit -v $(pwd):/home/fenics/shared -w /home/fenics/shared quay.io/fenicsproject/stable:curre$

OUTPUT=$(docker ps -q | grep "$name")
echo $OUTPUT
docker exec -dit $OUTPUT /bin/bash
docker exec -dit $OUTPUT echo "Hallo"
docker exec -dit $OUTPUT mkdir test
docker exec -dit $OUTPUT echo "Ciao"

If I look into docker ps -a I can only see exited containers.

Two questions arise therefore: Firstly, is this the way to pass the commands appropriately and secondly, how can I keep the container running?

As might be obvious, I have no prior experience using docker and am therefore grateful for any help.

Answer 1

most likely, what you want to do is put your commands into a file commands.sh and then run docker run --rm -v $(pwd):/home/fenics/shared -w /home/fenics/share --entrypoint bash quay.io/fenicsproject/stable:current commands.sh

What this will do is share your folder, launch the fenics container, and execute the shell script inside that container (presumably, your output will write to a file in the shared drive). The --rm part will clean up the container after the run.

I don't actually know what fenics is- if there is some sort of state or initialization, make sure you are taking care of that in your commands.sh file, since over-riding the entrypoint will prevent any fancy init scripts they provided from running. Alternatively, their docker image repo may explain how to feed a custom script to the container.