Load env variables from .warden.env

[indykoning]

Hi,
Is it possible to load the warden variables from a file like .warden.env instead of .env
Or load it from both files?
This because for Laravel the .env file usually contains system-specific or sensitive information. Which you do not want stored in git.
If it does not get committed, all of the container versions will not stay synced per computer.

I would really like to be able to have a .warden.env like file to commit and keep the containers between computers up-to-date

[jerrylopez]

Maybe just moving it to .warden/.env would good here?

[davidalger]

This is a terrific idea, but will pose a few challenges to implement. Docker Compose only introduced the --env-file flag (docker/compose#6535) in v1.25.0 (which is newer than what ships with Ubuntu LTS if I recall) and the flag doesn't support specifying multiple env files, only allows an alternate path. In lieu of using something that docker-compose already supported, it would be possible to parse multiple files into the shell environment but this will be somewhat difficult.

I'm going to keep this in here as an enhancement request for now, but it might not get much attention for a bit.

Here is what I think makes sense though, from a fallback perspective:

• .warden/.env
• .env
• Environment Variables (highest precedence)

To implement this, there would need to be a bash function to parse the dotenv files, and it would need to properly account for special characters and/or whitespace in values (this will take some trickery since dotenv files do not use quotes and do not require escapes like bash does; different semantics) — There are LOTS of "solutions" on the web for this, but most are flawed or way too basic.

As an interim solution, what I've seen done on a Laravel project my colleagues have going is this:

a) Commit a .env.example file to the repo.

b) Have devs copy this file to .env when first cloning the repo where they can configure with sensitive information as needed.

This obviously has the downside of leaving open potential for basic environment details or Laravel settings like cache drivers or PHP Version to easily become different between local setups, but would prevent the accidental committing of sensitive info to the repo.

[indykoning]

Maybe a way around the multiple files issue would be to create a "compiled" version of the env (echo .env > .warden/.env-compiled; echo .warden.env >> .warden/.env-compiled) and load that with the flag.

Of course the issue of the flag being new cannot be worked around, maybe a check can be added for the version and add the flag etc. if the version is high enough

[bbutkovic]

Perhaps as a fallback we could do something along the lines of:

echo $(export $(cat .warden/.env | xargs) && docker-compose up........)

It is a bit of a hack, admittedly, but it should do the trick if someone is running docker-compose that doesn't support --env-file.

Running export in a sub-shell will also mean that user's shell won't need to interact with those environment variables.

Let me know if you'd like me to try something out and submit a PR.

[indykoning]

It looks like it should work. (Edit, one small fix. Remove comments since they do not work with export: echo $(export $(cat .warden/.env | sed 's/#.*//g' | xargs) && docker-compose up........))
For the creation of a "Compiled .env file" i had something along the lines of this in mind:

mkdir -p .warden/.tmp
> .warden/.tmp/.env
for envFile in .warden/.env .env
do
    if test -f "$envFile"; then
        echo "## $envFile" >> .warden/.tmp/.env
        cat "$envFile" >> .warden/.tmp/.env
    fi
done

Which ends up with a file like:

$ cat .warden/.tmp/.env
## .warden/.env
WARDEN_ENV_NAME=domain
WARDEN_ENV_TYPE=laravel
WARDEN_WEB_ROOT=/

TRAEFIK_DOMAIN=domain.test
TRAEFIK_SUBDOMAIN=app

PHP_VERSION=7.3

## .env
APP_URL=http://app.domain.test

APP_ENV=local
APP_DEBUG=true

DB_CONNECTION=mysql
DB_HOST=db
DB_PORT=3306
DB_DATABASE=laravel
DB_USERNAME=laravel
DB_PASSWORD=laravel

CACHE_DRIVER=file
SESSION_DRIVER=file

REDIS_HOST=redis
REDIS_PORT=6379

MAIL_DRIVER=sendmail

If two of the same variables exist in the env files, the last one takes precedence.
So right now, your base settings for warden would be .warden/.env which would get overwritten by the variable in .env if it exists.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[WinstonN]

The way that I did this, is by setting up another env file that holds the private information. Then inside .warden/warden-env.yml inside my project, I declare those variables like so

version: "3.5"
services:
    php-fpm:
        environment:
            - DATABASE_HOST=${DATABASE_HOST}
            - DATABASE_NAME=${DATABASE_NAME}
            - DATABASE_USER=${DATABASE_USER}
            - DATABASE_PASSWORD=${DATABASE_PASSWORD}
            - REDIS_SESSION_HOST=${REDIS_SESSION_HOST}
            - REDIS_SESSION_PORT=${REDIS_SESSION_PORT}
            - REDIS_SESSION_DB=${REDIS_SESSION_DB}
            - REDIS_CACHE_HOST=${REDIS_CACHE_HOST}
            - REDIS_CACHE_PORT=${REDIS_CACHE_PORT}
            - REDIS_CACHE_DB=${REDIS_CACHE_DB}
            - REDIS_FPC_HOST=${REDIS_FPC_HOST}
            - REDIS_FPC_PORT=${REDIS_FPC_PORT}
            - REDIS_FPC_DB=${REDIS_FPC_DB}
            - ELASTICSEARCH_HOST=${ELASTICSEARCH_HOST}
            - ELASTICSEARCH_PORT=${ELASTICSEARCH_PORT}
            - BLACKFIRE_CLIENT_ID=${BLACKFIRE_CLIENT_ID}
            - BLACKFIRE_CLIENT_TOKEN=${BLACKFIRE_CLIENT_TOKEN}
            - BLACKFIRE_SERVER_ID=${BLACKFIRE_SERVER_ID}
            - BLACKFIRE_SERVER_TOKEN=${BLACKFIRE_SERVER_TOKEN}
        volumes:
            - ./.warden/php/zz-config.ini:/etc/php.d/zz-config.ini
    php-debug:
        environment:
            - DATABASE_HOST=${DATABASE_HOST}
            - DATABASE_NAME=${DATABASE_NAME}
            - DATABASE_USER=${DATABASE_USER}
            - DATABASE_PASSWORD=${DATABASE_PASSWORD}
            - REDIS_SESSION_HOST=${REDIS_SESSION_HOST}
            - REDIS_SESSION_PORT=${REDIS_SESSION_PORT}
            - REDIS_SESSION_DB=${REDIS_SESSION_DB}
            - REDIS_CACHE_HOST=${REDIS_CACHE_HOST}
            - REDIS_CACHE_PORT=${REDIS_CACHE_PORT}
            - REDIS_CACHE_DB=${REDIS_CACHE_DB}
            - REDIS_FPC_HOST=${REDIS_FPC_HOST}
            - REDIS_FPC_PORT=${REDIS_FPC_PORT}
            - REDIS_FPC_DB=${REDIS_FPC_DB}
            - ELASTICSEARCH_HOST=${ELASTICSEARCH_HOST}
            - ELASTICSEARCH_PORT=${ELASTICSEARCH_PORT}
            - BLACKFIRE_CLIENT_ID=${BLACKFIRE_CLIENT_ID}
            - BLACKFIRE_CLIENT_TOKEN=${BLACKFIRE_CLIENT_TOKEN}
            - BLACKFIRE_SERVER_ID=${BLACKFIRE_SERVER_ID}
            - BLACKFIRE_SERVER_TOKEN=${BLACKFIRE_SERVER_TOKEN}
        volumes:
            - ./.warden/php/zz-config.ini:/etc/php.d/zz-config.ini

These variables, and their values will be available inside the docker containers

The reason I don't use an environment file, is that that file is not checked into source control, and won't be available in my CI/CD pipelines for example

Docker breaks, if you reference an env file that does not exist