Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
ability to automatically use ENV variables the you input into Opsworks #28
would be great to create an
When you have a bunch of ENV variables, like AWS_SECRET, or STRIPE... those are cool to keep in Opsworks in their console; but to get them into the app during deploy, you have to use (if you don't role your own) a gem like Figaro which takes an
As an aside: I did notice whilst doing this that all ENV variables that you enter into the Opsworks console are also passed, along with
So I'm all ears if I did this thing wrong, and you have a better way man. I was in a pinch and this is what i had to do to get past it.
I get what pjammer wants. Basically if you're booting up a process that's not unicorn, you'll want all the environment variables.
Right now you only get that directly booting unicorn. https://github.com/ajgon/opsworks_ruby/blob/master/templates/default/unicorn.conf.erb#L23
I think the advantages to having a yml are obvious. we dont need to insert the database configs into unicorn every time because its already available when the rails environment loads. If we want to spin up a non unicorn process like sidekiq it knows about the database too. Someone might want to ssh into a machine and boot up the rails console, they wouldn't need to enter in every variable into the command line.
@pjammer what you want is available already in open source projects. for example i've used this before https://github.com/joeyAghion/opsworks_custom_env
making the case to have it included in this project, i don't know. I think its up to @ajgon
Ah, now I see it. I like the idea - added support for both
However I disagree, with a concept to remove those ENV for appserver/worker raw configuration files. The reason behind this is, that some people might not want/know/need to use them, and I want to make those scripts as less dependant on other gems as possible.
I can hardly wait to update my opsworks stack to this latest cookbook. I hate dependencies too, but for some reason what
Did you happen to fix the fact that unicorn gets ALL the
> grep -c "WARNING" log/unicorn.stderr.log 493
example line is:
Basically 11 lines each time the reaper comes. or during a deploy... unclear as to why yet, but instead of just passing the UNICORN based envs, the whole kit'n caboodle comes over.