Docker approach for multi-conditional pipeline - docker

Question

I'm completely new in Docker. I have the following idea in mind: I need to provide single image that will be able based on runtime arguments like profile/stage and python is included or not perform different scripts.
These scripts are used lot's of params that can be override from outside. I searched over the similar issues but I didn't find anything similar.
I have the following idea in mind but it seems quite difficult to support and ugly I hope someone can provide better solution:
The image content is raw:
FROM openjdk:8
#ARG py_ver=2.7
#RUN if [-z "$py_ver" ] ; then echo python version not provided ; else echo python version is $py_ver ; fi
#FROM python:${py_ver}
# set the working directory in the container
WORKDIR /models
# copy the dependencies file to the working directory
COPY training.sh execution.sh requirements/ ./
#RUN pip install --no-cache-dir -r requirements.txt
ENV profile="training"
ENV pythonEnabled=false
RUN if [ "$profile" = "training" ]; then \
command="java=/usr/bin/java training.sh"; \
else \
command="java=/usr/bin/java execution.sh"; \
fi
ENTRYPOINT ["${command}"]
I suppose I have several issues: 1) I need to have 1 image but based on runtime parameters I need to choose appropriate run script; 2) I have to pass a lot of args to training and execution scripts (app. 6-7 params). It's a bit difficult to do with "-e"
3) My image can download all python versions and use in runtime specified in args version.
I revised docker-compose but it helps if you need to manage several services. It's not my case. I have single service with different setup params and preparation flow. Could someone suggest better approach than having spaghetti if-else conditions for selected in runtime python version and profile?

Answer 1

It might help to look at this question in two parts. First, how can you control what runtime you're using; and second, how can you control what happens when the container runs?
A Docker image typically contains a single application, but if there's a substantial code base and several ways to invoke it, you can package that all together. In Python land, a Flask application and an associated Celery worker might be bundled together, for example. Regardless, the image still contains a single language interpreter and the associated libraries: you wouldn't build an image with three versions of Python and four versions of supporting libraries.
For things that control the single language interpreter and library stack that get built into an image, ARG as you've shown it is the correct way to do it:
ARG py_ver=3.9
RUN apt-get install python${py_ver}
ARG requirements=requirements.txt
RUN pip install -r ${requirements}
If you need to build the same image for multiple language versions, you can build it using a shell loop, or similar automation:
for py_ver in 3.6 3.7 3.8 3.9; do
docker build --build-arg py_ver="$py_ver" -t "myapp:python${py_ver}" .
done
docker run ... myapp:python3.9
As far as what gets run when you launch the container, you have a couple of choices. You can provide an alternate command when you start the container, and the easiest thing to do is to discard the entire "profile" section at the end of the Dockerfile and just provide that:
docker run ... myapp:python3.9 \
training.sh
You mention that a couple of the invocations are more involved. You can wrap these in shell scripts
#!/bin/sh
java -Dfoo=bar -Dbaz.quux.meep=peem ... \
-jar myapp.jar \
arg1 arg2 arg3
and then COPY them into your image into one of the usual executable paths
COPY training-full.sh /usr/local/bin
and then you can just run that script as the main container command
docker run ... myapp:python3.9 training-full.sh
You can, with some care, use ENTRYPOINT here. The important detail is that the CMD gets passed to the ENTRYPOINT as command-line arguments, and in your Dockerfile the ENTRYPOINT generally must have JSON-array syntax. You could in principle use this to create artificial "commands":
#!/bin/sh
case "$1" of
training)
shift
exec training.sh foo bar "$#"
;;
execution)
shift
exec execution.sh "$#"
;;
*)
exec "$#"
;;
esac
Then you can launch the container in a couple of ways
docker run --rm myapp:python3.9 training
docker run --rm myapp:python3.9 execution 'hello world'
docker run --rm myapp:python3.9 ls -l /
docker run --rm -it myapp:python3.9 bash