Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE REQUEST] Add option do define/use multiple .env-files #61

Closed
Buddinski88 opened this issue Jan 26, 2024 · 10 comments · Fixed by #62
Closed

[FEATURE REQUEST] Add option do define/use multiple .env-files #61

Buddinski88 opened this issue Jan 26, 2024 · 10 comments · Fixed by #62

Comments

@Buddinski88
Copy link

Hi mag37,

first of all, thank you for the well thought-out script. It has directly replaced Watchtower for me and one function is currently missing for my setup.
Is it possible to add the option to the script to specify the file names of the .env files myself and, ideally, more than one?
The background. I have a global.env and local.env.

As the name suggests, the global.env contains variables that can apply to all services.
The local.env is specific to the respective service.

The file structure looks like this:

|-- root
     |-- global.env
     |-- service 1
          |-- local.env
     |-- service 2
          |-- local.env

Not every service requires a global. or local.env, so the command to start the service always varies:

docker compose --env-file ../global.env --env-file local.env up -d
docker compose --env-file ../global.env up -d
docker compose --env-file local.env up -d

Many thanks and best regards,
Buddinski88

@mag37
Copy link
Owner

mag37 commented Jan 26, 2024

Hey, and thank you for the suggestion and well described situation!

Currently the script is checking for

ContEnv=$(docker inspect "$i" --format '{{index .Config.Labels "com.docker.compose.project.environment_file" }}')

Then it's started with something similar to this:

docker compose --env-file "$ContEnv" up -d

Maybe this only works a single env-file? And maybe only if declared through the compose-file?
I'll try to do some testing this weekend and see what I can achieve. But if you can/want I'd gladly receive some more info from how things look at your side of this.

What do you get if you run this on a container with multiple env-files?

docker inspect "ContainerABC" --format '{{index .Config.Labels "com.docker.compose.project.environment_file" }}'

(replace ContainerABC)

@Buddinski88
Copy link
Author

Sure, I'd be happy to give you more insights.

Basically, I don't have any labels for the .env files within docker-compose.yml. I've had some problems with the paths (even if it's only one folder up). That's why I include the files directly when starting the individual compose file.
However, I would also try it again if the script is changed here.
As I understand it so far, the start command only allows one env file?

Here is an example of what docker inspect returns for me when both .env files are given at startup:

docker inspect "cloudflare-ddns" --format '{{index .Config.Labels "com.docker.compose.project.environment_file" }}'

/home/buddy/villa-kunterbunt/global.env,/home/buddy/villa-kunterbunt/cloudflare-ddns/local.env

@mag37
Copy link
Owner

mag37 commented Jan 26, 2024

Thank you thats great info! So the grab of the current env files seems correct.

But you're right the current way only include 1 env file and maybe breaks due to the comma separated list of current files.

I'll do some testing when I have time and see if I can adjust the logic. Thank you.

@mag37
Copy link
Owner

mag37 commented Jan 26, 2024

Done some simple testing on my phone and might have a simple solution ready 😅
Just need some further testing.

But that is not adding the option for custom setting of env-files on the fly, but rather using the list like your test above and just starting the container again with all env-files with ... --env-file /path/file1.env --env-file /path/file2.env

Is this solving your issue?

@Buddinski88
Copy link
Author

I don't think I quite understand your approach. I guess I'm on the wrong track 😅
Do you mean that I would maintain a list containing the env files required for the operation of the respective service?

@mag37
Copy link
Owner

mag37 commented Jan 26, 2024

No sorry, I was unclear.

What the "new version" would do is just look up your specific containers current .env-files and then start that same container with the same .env-files.

I'll describe with your sample above.

  1. You'll run dockcheck and choose to update cloudflare-ddns.
  2. The script would then do a check, as docker inspect "cloudflare-ddns" ..... (in the example above)
  3. It will find the env-files:
    /home/buddy/villa-kunterbunt/global.env,/home/buddy/villa-kunterbunt/cloudflare-ddns/local.env
  4. It will then update the container, then start it with:
    docker compose --env /home/buddy/villa-kunterbunt/global.env --env /home/buddy/villa-kunterbunt/cloudflare-ddns/local.env up -d

No matter how many env files or in which order you've specified them, no matter if they're defined in the compose-file itself or by --env flag.

@Buddinski88
Copy link
Author

Ok, now I've understood. Of course that would be ideal and would cover my case 100%. At least as far as I've seen so far.
Very cool idea. I could have thought of that after you asked with docker inspect 😊

@mag37
Copy link
Owner

mag37 commented Jan 26, 2024

Wonderful!

I've put together a new branch with the adjustments. I've tried it on a few test-containers and it seems to work as planned.
new branch

If you'd like to test it on one of your containers that'd be awesome!
Just clone/download the dockcheck.sh and try to run it with ./dockcheck.sh cloudflare-ddns or some other container that can handle a couple of seconds downtime if you'd need to restart it manually with your correct --env-file flags if it doesnt start as it should.

@Buddinski88
Copy link
Author

That's brilliant. I have just tested it with different services and it always started with the same env files. Even an update with a new image and subsequent start went through without any problems. Thank you very much for the quick help and solution to my enquiry 😊

Are you closing the issue?

@mag37
Copy link
Owner

mag37 commented Jan 27, 2024

Wonderful!
The quick work was thanks to your collaboration and info. Thank you for reporting and testing.

It will close when I merge the branch with main in a bit.

@mag37 mag37 linked a pull request Jan 27, 2024 that will close this issue
@mag37 mag37 closed this as completed in #62 Jan 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants