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

Environment variables are not cleaned up #263

Open
aurelienshz opened this issue Jul 4, 2019 · 4 comments
Open

Environment variables are not cleaned up #263

aurelienshz opened this issue Jul 4, 2019 · 4 comments

Comments

@aurelienshz
Copy link

aurelienshz commented Jul 4, 2019

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:

  • if this expected? If so, should the documentation be updated? (happy to submit a PR)
  • otherwise, should this be fixed?

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:

# docker-compose.yml:
services:
  app:
    build: .
    environment:
      TEST_ENV_VAR: ${TEST_ENV_VAR}
# .env
TEST_ENV_VAR=test1234
# Dockerfile:
FROM phusion/passenger-ruby25:1.0.5
# Allow nginx to pass environment variables to the app at runtime:
COPY ./docker/env.conf /etc/nginx/main.d/env.conf
# [...] Copy the app's files, install dependencies, etc.

env.conf does not contain any line like env TEST_ENV_VAR;, yet the following is possible:

$ sudo docker-compose build
$ sudo docker-compose up -d
$ sudo docker-compose exec app bash
# The environment variable is in the container's environment:
root@c4503f22222e:/home/app# printenv | grep TEST_ENV_VAR
TEST_ENV_VAR=test1234
# Our nginx config doesn't contain anything to pass the env var to the child processes:
root@c4503f22222e:/home/app# cat /etc/nginx/main.d/db-env.conf | grep TEST_ENV_VAR
# Yet Rails has loaded the environment variable:
root@c4503f22222e:/home/app# cd webapp/
root@c4503f22222e:/home/app/webapp# bin/rails c
Running via Spring preloader in process 3004
Loading production environment (Rails 5.2.0)
2.5.1 :001 > ENV['TEST_ENV_VAR']
 => "test1234" 
@CamJN
Copy link
Member

CamJN commented Jul 4, 2019

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.

@aurelienshz
Copy link
Author

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).

@CamJN
Copy link
Member

CamJN commented Jul 4, 2019

Well, I'd be open to a PR to document additional ways to set env vars.

@aurelienshz
Copy link
Author

aurelienshz commented Jul 4, 2019

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.

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

No branches or pull requests

2 participants