Feature #22134
closedDefine RailsAPI's required environment variables in nginx configuration
Description
Here's how RailsAPI is supposed to read cluster configuration:
- nginx clears the environment except for
TZ
: "By default, nginx removes all environment variables inherited from its parent process except the TZ variable." passenger_load_shell_envvars
is on by default, which means "applications are loaded by running them withbash -l -c
." Note that Passenger's architecture documentation says this is just for usability, not a technical requirement: "This causes bash to load its startup files, e.g. bashrc, profile, etc, after which it executes the SpawnPreparer with the given parameters. The reason why we do this is because a lot of users try to set environment variables in their bashrc, and they expect these environment variables to be picked up by applications spawned by Phusion Passenger. Unfortunately environment variables don’t work that way, but we support it anyway because it is good for usability."- source:services/api/config/arvados_config.rb runs
Open3.capture3("arvados-server", "config-dump", "-config=-", "-skip-legacy", stdin_data: "Clusters: {xxxxx: {}}")
. It findsarvados-server
via thePATH
variable set in step 2.
We recently observed a situation on a couple different clusters running Ubuntu 20.04 where unattended-upgrades automatically upgraded glibc, systemd, and nginx. After nginx got the reload/restart signal, something happened so that Passenger did not pick up environment variables from step 2 like it usually does. It tried to start RailsAPI with PATH=/var/www/arvados-api/shared/vendor_bundle/ruby/2.7.0/bin
, which caused the Open3.capture3
expression to raise an exception, app initialization to fail, and the cluster to go down.
We still do not have a full explanation for why step 2 didn't work as it normally does in this case. However, we can reduce the number of moving pieces here by setting passenger_load_shell_envvars off
and set the environment variables we need with passenger_env_var
. Doing so will make RailsAPI deployment work more consistently by isolating them from configuration changes to the system shell, and it's a relatively straightforward change, so it
seems worth doing.
Updated by Brett Smith 3 months ago
22134-railsapi-envvars @ 99e20892507158365034caaf6373e6c81b2735a4 - developer-run-tests: #4450 and
test-provision: #964
This updates both our installer and documentation to set necessary environtment variables for RailsAPI directly in the nginx Passenger configuration, rather than getting them through the system shell.
- All agreed upon points are implemented / addressed.
- Yes
- Anything not implemented (discovered or discussed during work) has a follow-up story.
- N/A
- Code is tested and passing, both automated and manual, what manual testing was done is described
- See above. Also reviewed docs manually. I also did some spot checks of the RailsAPI code to see if it needed other system environment variables to be set. I didn't find any, but definitely it's not a perfect check, there's a lot of ways we could need them indirectly. test-provision suggests it at least starts okay. If we wanted to do a more thorough test, we could add these configuration lines to one of Curii's own clusters, and see how that goes.
- Documentation has been updated.
- Yes
- Behaves appropriately at the intended scale (describe intended scale).
- No change in scale
- Considered backwards and forwards compatibility issues between client and server.
- N/A
- Follows our coding standards and GUI style guidelines.
- N/A (no style guide for configuration files)
Updated by Lucas Di Pentima 3 months ago
This LGTM. I've manually applied these new config lines to tordo
and everything seems to work without issues.
Updated by Peter Amstutz 3 months ago
- Target version changed from Development 2024-09-25 sprint to Development 2024-10-09 sprint
Updated by Brett Smith 3 months ago
Lucas Di Pentima wrote in #note-4:
This LGTM. I've manually applied these new config lines to
tordo
and everything seems to work without issues.
Thanks. With this in place, I also tested that app/config/initializers/reload_config.rb
still works as intended: I updated /etc/arvados/config.yml
and saw in production.log
that RailsAPI restarted and continued serving requests correctly.
Updated by Brett Smith 3 months ago
- Status changed from In Progress to Resolved
Applied in changeset arvados|8ec11f82326ef5edfcf43f10e08a17aa1494eac7.