i get crazy with the env_file setting inside my docker-compose.yml.
when i name the file .env and put it in the root of my project everything works fine. the main point of having this env file was to have multiple enviroments (dev, staging, production) where i made my settings.
as soon i name my file different (for example dev.env and put it inside a env folder) and try to load it inside my docker-compose file it won't work.
i make a simple example to make things clear.
for simplicity i use one variable DC_DOCKERFILE where i define what dockerfile to load.
file: .env in the root folder:
COMPOSE_PROJECT_NAME=test
DC_DOCKERFILE=./Dockerfile.bash.dev
file: docker-compose.yml:
version: "2"
services:
bash:
build:
context: .
dockerfile: ${DC_DOCKERFILE}
and docker-compose config shows everything is cool and build works as well:
networks: {}
services:
bash:
build:
context: /devops/myproject
dockerfile: ./Dockerfile.bash.dev
version: '2.0'
volumes: {}
now the point which freaks me out:
create a folder env in the root of the project
move .env to ./env/dev.env
add env_file: ./env/dev.env inside my docker-compose.yml
env content looks same like above so i don't post the content again.
my new docker-compose.yml:
version: "2"
services:
bash:
env_file: ./env/dev.env
build:
context: .
dockerfile: ${DC_DOCKERFILE}
only change, add the env_file settings.
and now i docker-compose config gives me this:
networks: {}
services:
bash:
build:
context: /devops/myproject
dockerfile: ''
environment:
COMPOSE_PROJECT_NAME: test
DC_DOCKERFILE: ./Dockerfile.bash.dev
version: '2.0'
volumes: {}
say what? where the hack is my dockerfile settings?
of course docker-compose build don't like that too and bothers with:
docker-compose build --force-rm --no-cache
WARNING: The DC_DOCKERFILE variable is not set. Defaulting to a blank string.
Building bash
ERROR: Cannot locate specified Dockerfile: Dockerfile
the variables get loaded but somehow not assigned.
so i don't get it.
am i maybe wrong and i can't use the env file for docker-compose stuff inside the docker-compose.yml file. would make sence that it need to be loaded first somehow via docker-compose parameter or something but after i spend so much time i want to know if i can load it inside or not :)
thanks for help and hell yeah for open source and the awesome community.
peace out
When .env file is present in the folder docker-compose command is executed, those environment variables are used as environment variables for docker-compose execution and variable substitution. (https://docs.docker.com/compose/env-file/).
However when you define env_file option to your service, the service will get those variables from the file as environment variables and those are not used for variable substitution.
Related
I have a .env file like this:
PROJECT_DIR=./test_dir
SUB_DIR=$(PROJECT_DIR)/sub_dir
And docker-compose.yml file like this:
version: '3.5'
services:
service_nginx:
image: nginx
volumes:
- ${SUB_DIR}:/var/www/html
But I can't use $SUB_DIR in docker-compose.yml file for volume, I got error like this:
ERROR: Named volume "$(PROJECT_DIR)/sub_dir:/var/www/html:rw" is used in service "service_nginx" but no declaration was found in the volumes section.
Update your env file as follows
export PROJECT_DIR=./test_dir
export SUB_DIR=$(PROJECT_DIR)/sub_dir
Then run the following command to read the varialbes;
. ./.env
Then deploy the stack from same terminal session.
My docker-compose.yml
version: '3'
services:
test:
build: .
My Dockerfile
FROM alpine:latest
ENTRYPOINT echo $ARG1 $ARG2
My .env file
ARG1=argument100
ARG2=argument200
If I run docker-compose run test the empty line got printed. However, it I add env_file section to my docker-compose.yml I am getting the expected output.
New docker-compose.yml
version: '3'
services:
test:
build: .
env_file:
- .env
Running docker-compose again
$ docker-compose run test
argument100 argument200
Am I using an illegal way to pass arguments to the ENTRYPOINT command inside the Docker? Why is .env not loaded automatically upon docker-compose run?
The .env file is used to set variables in the docker-compose command itself that can be used to expand variables in the docker-compose.yml file itself. The env_file specification will define variables inside the containers. They operate at two different levels.
There's also a third type of variable, build args, that can be injected into the building of an image.
Each of these has a distinct purpose, and are not multiple ways to do the same thing.
I have a .env file with a large list of variables in the root of my node project. In the root is also my docker-compose.yml file:
version: '3'
services:
api:
build: .
env_file:
- .env
ports:
- 5000:5000
I'm trying to pass in these variables to Docker (from here), but when I run docker-compose up, I'm running into an error in my node app because it doesn't have access to these variables. What am I doing wrong? Thanks.
Change the file name to something different like node.env. The .env file is used by the docker-compose itself to define the content of the docker-compose file itself.
Example:
$ cat .env
TAG=v1.5
$ cat docker-compose.yml
version: '3'
services:
web:
image: "webapp:${TAG}"
The content of this file is not used inside the docker instance itself.
I have a cache folder and the path is stored in an evironment variable: $LOCAL_CACHE (export LOCAL_CACHE=/home/me/path/to/any/cache/folder)
Now I want to append some additional folders inside my .env file:
My .env file:
LOCAL_COMPOSER_DIR=${LOCAL_CACHE}/composer
LOCAL_NPM_DIR=${LOCAL_CACHE}/npm
LOCAL_BOWER_DIR=${LOCAL_CACHE}/bower
My docker_compose.yml looks like that:
version: '2'
services:
composer:
env_file: .env
image: composer/composer
volumes:
- ./src:${APP_ROOT}
- ${LOCAL_COMPOSER_DIR}:/composer
working_dir: ${APP_ROOT}
When I start the service with docker-compose run composer instal. ... it stops with following error: ERROR: Named volume "$LOCAL_CACHE"/composer":/composer:rw" is used in service "composer" but no declaration was found in the volumes section.
I'm not shure but it seems, the .env file doesn't support the use of variables.
Yes. Into .env file you can not use variables. Suddenly but true. Actual for docker compose version 1.8.
But you can use variables into docker-compose.yml file like
volumes:
- ${LOCAL_COMPOSER_DIR}/${CACHE_DIR}:/composer/${CACHE_DIR}
This answer suggest us another way.
Having the following docker-compose file:
db:
build: .
environment:
- MYSQL_ROOT_PASSWORD=password
- ENV=test
env_file: .env
Is there any way to use the env variables declared in docker-compose.yml (either as environment or declared in the env_file) as part of Dockerfile without declaring them in the Dockerfile? Something like this:
FROM java:7
ADD ${ENV}/data.xml /data/
CMD ["run.sh"]
Although this question was asked long ago, there is an answer to a similar question here: Pass environment variables from docker-compose to container at build stage
Basically, to use variables at the container's build time one has to define the variable in docker-compose.yml:
build:
context: .
args:
MYSQL_ROOT_PASSWORD: password
ENV: test
and then reference it in the Dockerfile using ARG:
ARG MYSQL_ROOT_PASSWORD
ARG ENV
ADD ${ENV}/data.xml /data/
Concerning environment variables defined in an *.env file, I believe that they can't be passed to the container at build time.
It works ok this way:
docker-compose.yml
version: '3.5'
services:
container:
build:
context: .
args:
ENV: ${ENV} # from .env file
env_file:
- .env
Dockerfile
# from compose args
ARG ENV
ADD ${ENV}/data.xml /data/
.env
ENV=myenv
Thus all the values are taken from .env file
This approach goes against the 'build once, run anywhere' theory behind Docker and most DevOps approaches. With this approach you'll need to build a container for every environment you expect to use. By doing so you can't safely say if a container works in the dev environment it will work in staging and production since you aren't using the same container.
You'd be better off adding all config files you need on to the container and writing an entrypoint script that selects/copies the data for that environment to the correct location when the container starts. You can also apply this approach to other config on the container, like templated Apache config using jinja2 templates etc.