Open aurelienshz opened 5 years ago
I believe rails c
starts a copy of your app running as a child of your shell, rather than attach to the app running under nginx. So I think this is a red-herring.
Ah... Maybe my repro steps are not perfectly describing the issue. But I can confirm that the web app we're running is getting those environment variables as well. They're critical to the app, and they're marked as mandatory using a Figaro initializer (which means the app wouldn't even start if they weren't defined).
Well, I'd be open to a PR to document additional ways to set env vars.
I'm not quite sure I understand how this is an additional way to set an env var.
The variable is set up in the container's environment (using docker-compose, but under the hood, it's the same thing as using -e
on the docker
command), and it's visible to the Rails app without setting up any env
instructions in the Nginx config. I may be misunderstanding the documentation at https://github.com/phusion/passenger-docker#setting-environment-variables-in-nginx, but it feels to me like the documentation describes this as impossible, yet it is working perfectly fine.
I'm totally fine with it, as long as this is not a bug which will be fixed in a future version and may break apps very unexpectedly.
Hey there! 👋
We're using this image (
phusion/passenger-ruby25:1.0.5
) to run a Rails app, and we are not seeing the behavior documented at https://github.com/phusion/passenger-docker#setting-environment-variables-in-nginx. Environment variables that are set up through Docker Compose .env mechanism are visible to the Rails app.My question is:
My biggest concern is that this is fixed inadvertently in a further version, and apps suddenly start breaking for obscure reasons when updating the Phusion Passenger image version.
Reproduction steps
We are using docker-compose. Here are relevant extracts and reproduction steps:
env.conf
does not contain any line likeenv TEST_ENV_VAR;
, yet the following is possible: