CODEWITHSUNDEEP
docker
t3ng1l
t3ng1l

Reputation: 1065

Passing --env variables now working with ENTRYPOINT

I have a base docker image from which I'm building my own on top of. I do not have the Dockerfile of the base image.

Basically, the base image takes two --env arg, one to accept their license and one to select which framework should be activated in the container. I have no problem running my container without an ENTRYPOINT as docker run -it -p xxxx:xxxx --env ARG1=x --env ARG2=y <imageID> /bin/bash, and then run the script I would run in ENTRYPOINT inside the container. That works flawless. BUT! I want to make it work with ENTRYPOINT ["/bin/bash", "-c", "myscript.sh"] so that I don't have to go inside the container each time I want to run it. When I use my own entrypoint it's like the container ignore my inputs --env ARG1=x --env ARG2=y.

Could it be that the base image has its own ENTRYPOINT looking for those environment variables? Is there any way to make sure that the base image stills runs its starting script, and then runs mine after?

My Dockerfile: 

FROM base-img

USER root

RUN  apt-get update -y &&  apt-get upgrade -y \
        && apt-get install -y nano \
                apache2 \
                iputils-ping \
                vim \
                emacs


USER user1

ENV PATH="/opt/anaconda3/bin:${PATH}"

RUN conda install jupyter notebook -y

COPY jupyter_notebook_config.py /home/user1/.jupyter/

COPY run-jupyter.sh /home/user1

WORKDIR /home/user1

#ENTRYPOINT ["/bin/bash", "-c", "/home/user1/myscript.sh"]

I've even tried echoing them in ~/.bashrc, but it didnt work... As I said above, my fear is that the base image has some scripts running in the startup depending on what ARG2 is set to..

Upvotes: 1

Views: 147

Answers (2)

BMitch
BMitch

Reputation: 265085

Could it be that the base image has its own ENTRYPOINT looking for those environment variables? Is there any way to make sure that the base image stills runs its starting script, and then runs mine after?

No, an image will only have a single entrypoint. The one you define in your image replaces any entrypoint definition from the parent image.

Upvotes: 0

mviereck
mviereck

Reputation: 1419

Check out ENTRYPOINT of the base image with:

docker inspect --format='{{.Config.Entrypoint}}' BASEIMAGE

(Replace BASEIMAGE with name of base image.)

Probably it will work if you include the ENTRYPOINT command of the base image in your own ENTRYPOINT.

Upvotes: 1

Related Questions