CODEWITHSUNDEEP
shelldockerdocker-composedockerfiledocker-entrypoint
dimisjim
dimisjim

Reputation: 425

Env file not properly sourced from entrypoint script

I am trying to source a .env file, from inside a conditional entrypoint.sh script which, part of it, looks like this:

if [ -f "some-env-file.env" ]; then
source some-env-file.env

a simple echo of an environment variable found inside the .env file, just after the above source command, outputs the correct value, and the operations provided after in the entrypoint script, are performed successfully.

However, when I do docker exec -it inside the instantiated container, env file looks like that it isn't sourced. Only when I source it again from there, I get the desirable results. (More specifically, env file is used to point to a specific runtime environment for python. So after entering the container, python is called correctly only when I source the env file again).

What am I doing wrong?

For reference, these are the last lines of my Dockerfile (nothing special about it):

COPY ./entrypoint.sh /
ENTRYPOINT ["/entrypoint.sh"]

The container instantiation is done with a docker-compose yaml.

Thanks in advance and sorry if this has been asked before.

Upvotes: 1

Views: 2590

Answers (2)

dimisjim
dimisjim

Reputation: 425

Adding this to my entrypoint.sh fixed the problem:

cat >> /etc/bash.bashrc <<EOF
if [ -f some-env-file.env ]; then
  source some-env-file.env
fi
EOF

Upvotes: 0

David Maze
David Maze

Reputation: 159040

The Docker startup flow is that Docker sets some environment variables (from the Dockerfile and docker run -e options) and then launches the container's entrypoint. Anything that happens within the entrypoint is outside of Docker's purview. In particular, a debugging shell that gets launched via docker exec is not a child of the entrypoint and won't inherit environment variables that get set there. (NB: I cannot find this explicitly stated in the Docker documentation anywhere.)

One good experiment to try is to run:

% docker run -d --name test busybox sh -c 'sleep 60; sleep 60'
6c6aada7e5299e816e9d12dfab9845cc396485a46d909255375128b87ee5eedf
% docker exec test ps -o pid,ppid,comm
PID   PPID  COMMAND
    1     0 sh
    6     1 sleep
    7     0 ps

The container's root process is a shell, which gets process ID 1, and it launches a sleep subprocess, with process ID 6 and parent process ID 1. The docker exec ps command gets a new process ID, but has an artificial parent process ID of 0 – it is not a child of the container root process.

If you want to debug your image's startup environment, with a typical entrypoint script like

#!/bin/sh
. /env.sh
exec "$@"

you can docker run --rm -it myimage sh and the resulting shell will get launched via your entrypoint script. But as you observe, trying to debug it via docker exec doesn't go through any part of the entrypoint sequence.

Upvotes: 2

Related Questions