[Feature Request] Global Environmental Variables

[MrTheoW]

It would be awesome to be able to set some global env. variables.
Like things that doesn't change as:

• Time Zone
• PGID & PUID
• Docker Data Dir Location

It would be nice to be able to name a variable and give it a value so the variable could be used in the stacks / containers.

[TheRealGramdalf]

I recently came across fragments and extensions - I think an integration of this would be the best way to implement this.

Here's my thoughts on how this might end up working:

• Global configurations are kept in the primary dockge compose.yaml
• Other stacks can reference these global config options, and optionally override them on a per-stack basis
• App templates may optionally be integrated into this setup - for example with TZ, containers can reference the dockge compose file in order to fill that environment variable
• If a container uses a different name for a variable, it can be set with something like - CUSTOM_TZ=$TZ (using basic shell syntax, I'm not exactly sure of the proper compose syntax for variables)
• An added bonus would be a simple UI to manage allocations - say you have two stacks, stack A and stack B. Stack A supports time zone and PG/UID, but stack B only supports time zone - a drag n drop/checklist UI to select which variables a container pulls from dockge would be nice

Since dockge in the vast majority of cases defines your docker environment, it makes sense that it would contain these configuration options.

[supacoda10]

Or maybe something like Dokemon (https://dokemon.dev) does would be nice too. You can define environments in it and variables under an environment. Then assign the environment to the node. All variables in that environment are then set for all stacks in that node. This is useful in our company where we have QA, UAT, Production environments.

I like Dockge because it shows everything related to a stack on one page which is cool. Would be nice to have something like this in Dockge.

[MikyWoW]

You can also use simple .env file in same directory as compose.yaml for per stack enviroment variables.

With global env then run compose command like this docker compose --env-file ./../global.env --env-file .env up -d

https://docs.docker.com/compose/environment-variables/set-environment-variables/

[FallenLeave91]

An option to change the data dir would be apreciated since i store my stack under /app and don´t want to move it. This is in conflict with the default config dir in /app/data

[louislam]

Good point. I shouldn't put the whole dockge application in /app, as the name is a bit common.

[trythatagain]

I use OMV and the compose plugin, which is very nice, but I like new things as well, so I'm enjoying Dockge. But I am missing the global env file I have with the compose plugin, so as mrTheoW mentions, I have my most used directories in there, TZ, PUID etc, things that don't really change.
It's a really nice feature, plus as mentioned here also you can use a local env as well.

I'd quite like to create a global env file, stored either in the root of the stacks directory, or wherever really, and then an option in the settings to state the path, and perhaps a checkbox to state a global env file is available, or if it's easier have a 0 byte file auto created and called every time Dockge does and up.

[synapseattack]

Also a fellow OMV user and I too miss having a globals file for variables that can be used.

[richard-edwards]

I've been using the .env file in the same folder as compose.yml and it's working well. Would be nice to be able to quickly edit that in the interface along with the compose file.

[trythatagain]

I get that, but it means you've got to copy .env every time you create a new stack, whereas if you had a global .env and Dockge knows the path, when it does the 'compose up' it includes that as default. One less thing to have to remember to do.

I just checked using OMV compose plugin, which has a default .env for each stack dir, it will startup if the ,env file is 0 bytes. So I assume if a global .env was created when Dockge first runs, with a description in the file, then when the 'compose up' includes the global .env in it's run argument then everything will run as wanted and those of use who want a global .env file will be extremely happy :)

[DarkPhyber-hg]

putting in a vote for this.

[syko9000]

I was rearranging my stacks and now I really want this... I'm going to implement this @louislam and you can decide if you accept it. Might be a few days or the weekend though.

[syko9000]

I have the UI in place and it works with the docker compose up call but the PORT detection through the env parsing library being used needs augmented to read the two files and to process each file's values through the variables known in the files. It's actually complicated...

global

PORT=1
PORT=${PORT}2
PORT=${PORT}3

local

PORT=${PORT}4
PORT=${PORT}5
PORT2=${PORT}6
PORT2=${PORT2}7

then a service with an environment var of PORT=$PORT and PORT2=$PORT2 for some reason yields PORT=1235 and PORT2=12367

In the ports: section it comes back as

So it seems iterative inside a file, but first pass when applying to the next file followed iteratively. Very weird.

Edge cases are a nightmare. Hope to get it tomorrow.

[louislam]

I think they are really edge cases and maybe even invalid? Because key should be unique in my opinion.

And I also don't expected that the envsubst operation is happening inside .env files. (Need to verify how docker-compose does)

We can assume that the key must be unique and the local one should have the highest priority.

Otherwise, it will be super complicated.

[trythatagain]

I think you're correct, the local.env file should take priority. I don't program, but does compose up, not do this for you? Especially if you're adding both env file names to the compose up command?

[syko9000]

Docker compose definitely allows for the substitutions within the .env file and it didn't complain with my test case at all having duplicate keys. Just like in BASH you can redefine vars all you want.

Even further it allows for nested things like AUX_PORT=${PORT:-${DEFAULT_PORT:-8080}} within the same file (ie putting this in global.env and defining DEFAULT_PORT in .env does not cause AUX_PORT to re-evaluate, luckily)

[syko9000]

@trythatagain, yes, docker compose handles all of it as far as the running containers are concerned. But we have to emulate what compose does in certain situations so that the UI matches the real result.

Unless, don't show the port at all if the container isn't running and if the container is running run a docker container inspect ... and pull the port number that was resolved by compose out for the UI?

[aviellg]

for the interface maybe take inspiration from yacht project , it will be better if you can create new veriables

[bverkron]

I would also love this feature. I have many containers that share certain env variables and it's tedious to always copy / paste them into individual stack configs and repeat the process if values change.

[hilsonp]

Thank you @louislam for the nice project. This is immensely useful !
And thank you @syko9000 for the contribution.
Impatient to get the 1.5 release.
In the mean time, is there any way to beta test it ?
Do you have a little HowTo build the dockge docker image ?

[RafaelSchridi]

Would also love to test this, is there a docker tag for the pull request?

[RafaelSchridi]

For anyone interested

git clone https://github.com/syko9000/dockge.git
git checkout master.global.env
npm install (you need node ~18.17.1, you can use nvm for this)
npm run build:frontend 
sudo docker buildx build -t louislam/dockge:pr387 --target release -f ./docker/Dockerfile .

Now you can use the image louislam/dockge:pr387 to rebuild your container

[raphaelgrau]

Any progress on this? Much needed feature!

[benblustey]

Symbolic link is a good call. Worked perfectly for me.

[bverkron]

Can you have an additional .env file inside each app’s folder or are you restricted to a single global .env?

[zdhoward]

This way is just using the symbolic link, so it only refers back to the global .env
If you just put a normal .env in the apps folder then it won't refer to the global .env at all, but this is the same as just adding a new stack in dockge directly

[bverkron]

Right, but as wondering if docker had a mechanism to allow for multiple .env files, so you could have the global one and app specific one, but I don’t think so. Thought maybe you found way :)

[TheRealGramdalf]

There is in fact a way to do that - you can either edit the docker daemon settings to add additional names to search (like .env.local), or add ./.env.local to an environment_files directive