8000 Read environment variables from file · Issue #771 · Supervisor/supervisor · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Read environment variables from file #771

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.

Sign up for GitHub

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

Jump to bottom
Closed
standa4 opened this issue Jun 13, 2016 · 20 comments
Closed

Read environment variables from file #771

standa4 opened this issue Jun 13, 2016 · 20 comments
Labels
environment

Comments

@standa4
Copy link
standa4 commented Jun 13, 2016

Hello,

is it possible read the environment variables from file or are you planning to add this feature?
It would be useful in case where I have multiple applications managed by supervisord and these applications share the same env vars. I don't want to edit multiple conf files. These variables can be stored in one file and read from it.

Thank you.
@mnaberez
Copy link
Member

There is an environment= option in the [supervisord] section. Put the variables in the [supervisord] section and they will be inherited by all subprocesses.

@standa4 standa4 mentioned this issue Jun 16, 2016
Open
@Choms
Copy link
Choms commented Aug 28, 2018

Hi,

This is not an appropriate answer, you are not only not answering to @standa4's question, but you are also treating him in a condescending way, like if he was stupid enough as for not reading the documentation that clearly states how to use the environment line...

I'll exemplify his request with another example I think would be more helpful on depicting the issue... let's say I have a bash script with a conditional that checks some system parameters, and based on that sets one env with a value or a different one that I'll use in my program... it would be really helpful to be able of sourcing that file from the supervisord configuration file. (inb4 just create a bash wrapper that executes your program and call the wrapper from supervisord)

Now the actual question was "are you planning to add this feature?" - Can we please get a yes/no answer (I'm guessing it's a "no" based on the date of this issue and the other related issues that were closed too), and, if you feel generous enough, an argument for your decision?

Thanks

@mnaberez
Copy link
Member

This is not an appropriate answer, you are not only not answering to @standa4's question, but you are also treating him in a condescending way, like if he was stupid enough as for not reading the documentation that clearly states how to use the environment line...

The question asked for a single place to define environment variables, citing a desire to not modify multiple config files. Putting the variables in [supervisord] section of the root config file seems to meet those requirements. There are two places that environment= can be specified in the config file(s). One is any [program:x] section where the variables will be applied only to that program. The other is in the [supervisord] section, where the variables will inherited by all programs. My response was intended to be helpful, not condescending. There's a lot of documentation, and it's easy to miss details like this.

Now the actual question was "are you planning to add this feature?" - Can we please get a yes/no answer (I'm guessing it's a "no" based on the date of this issue and the other related issues that were closed too), and, if you feel generous enough, an argument for your decision?

There are not currently plans to add a separate type of config file just for environment variables. Since this has already been discussed in other issues, please refer to those issues.

@Supervisor Supervisor deleted a comment from frutik Feb 15, 2020
@Supervisor Supervisor deleted a comment from frutik Feb 15, 2020
@mnaberez

This comment has been minimized.

Sign in to view
@stephendwolff
Copy link

I came to this question - thinking that the original poster meant literally from a file ie a .env file as other applications use, rather than the environment variables being shared by supervisord itself. So, i suspect this is not solved, and the OP just got fed up!

@ericholscher
Copy link

Agreed. Not being able to read this data from a file is a pretty big missing feature. I have a standard way of defining the env for all my programs, except supervisord. I'd +1 adding functionality for this.

@szthanatos
Copy link

Same question.
How to get variables from a .env file instead of write everything into supervisor conf file.
It make me feel like living in Classical-Python2-Age.

@aaronbriel
Copy link

I've had to work around this by executing a bash script in the command that sources my .env file.

@ospalax
Copy link
ospalax commented Dec 16, 2020

I don't know how others are treating theirs supervisor's config files (service inis) but I am trying to use them as generic as possible and if some service needs to have env populated with some service specific variables then I want to (need to) source them somehow from envfile.

Your answer is to hard-wire env vars inside the service config file??

There are already existing use-cases like this sshd service in the form of systemd unit:

[Service]
Type=notify
EnvironmentFile=-/etc/crypto-policies/back-ends/opensshserver.config
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS $CRYPTO_POLICY
ExecReload=/bin/kill -HUP $MAINPID

@CallMarl
Copy link

J'ai dû contourner ce problème en exécutant un script bash dans la commande qui source mon fichier .env.

Can you please share command detail?

@ShivKJ
Copy link
ShivKJ commented Aug 19, 2021

Is it resolved?

@rrauenza
Copy link
rrauenza commented Dec 2, 2021 •
edited
Loading

Explaining a use case for this -- hashicorp's vault drops secrets into files. I'd like to be able to drop some authentication keys as a .env file with root only read permissions and have supervisord pick those up when I restart the service.

(I don't want vault messing with the supervisord config files directly.)

I think the only workaround is command='/bin/sh -c "source /var/lib/vault/secret.env && run_my_service"'

edit: not sure why I said only workaround. Another work around is to make a shell script run_my_service_with_environment that sources the secret env vars.

@thisven
Copy link
thisven commented Dec 18, 2021

Thanks for sharing that workaround. As long as there are no plans on implementing the appreciated variable for service files, this is kind of a consolation.

@balanikaran
Copy link

Hey, is this feature in pipeline?

@benzkji
Copy link
benzkji commented May 12, 2022

There are many use cases for this, .env files are widely used nowadays, I dont see a reason to not implement it. Also, specifying the vars under [supervisord] is by far not a solution, as normaly, each program is supposed to have it's own .env.

@benzkji
Copy link
benzkji commented May 12, 2022 •
edited
Loading

@balanikaran no, the issue is currently closed, so I guess it's ... not on the radar. Fingers crossed this gets a revival some day!

@benzkji
Copy link
benzkji commented May 12, 2022

another real argument is the "secret" nature of .env files, they often get their content out of an encrpyted file, and just cannot be written directly into a supervisor config file. as @rrauenza indirectly shows in his example.

anyway, thanks for listening ;-)

@javilm javilm mentioned this issue Feb 9, 2023
Closed
@mnaberez
Copy link
Member
mnaberez commented Feb 9, 2023

Moved from #1574

I know this has been requested before in #771 and closed, but I'll request it again:

Please implement the ability to read the environment variables for a process from a file.

Use case

I have a number of Flask applications running under Supervisor. These applications have secrets that can't be commited to GitHub, such as database passwords, session secrets, etc. Because of this, the applications read these secrets from environment variables during initialization.

Currently, adding a new secret requires editing the supervisord.conf file. My users can't do that by themselves because they don't have admin access on this application server.

Alternatives

There are ways to work around this limitation in supervisor, such as:

Add code to the application so it reads the secrets from a file on startup
Set up a secrets management tool such as Hashicorp Vault

Both of these add complexity (a lot in the case of Vault) that could be avoided by implementing this functionality in supervisor.

@hevisko
Copy link
hevisko commented Feb 24, 2023

Scrolling through this, having similar need(s)
I suspect the real answer is: Do the needed work & code and present a pull request

@benzkji
Copy link
benzkji commented Feb 24, 2023

@hevisko no exactly :-) As this issue has been closed, you'll need to check possibilities to have it merged, otherwise you'll do it for yourself and your frustration only.

As @mnaberez states, there are no plans developing this feature...that could mean no plans to merge a PR, or not...

@sailist sailist mentioned this issue Mar 14, 2024
Closed
@ccoVeille ccoVeille mentioned this issue Jun 3, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
environment
Milestone
No milestone
Development

No branches or pull requests
0