Project

General

Profile

Actions

Feature #22134

closed

Define RailsAPI's required environment variables in nginx configuration

Added by Brett Smith 2 months ago. Updated about 2 months ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
Deployment
Story points:
-
Release:
Release relationship:
Auto

Description

Here's how RailsAPI is supposed to read cluster configuration:

  1. nginx clears the environment except for TZ: "By default, nginx removes all environment variables inherited from its parent process except the TZ variable."
  2. passenger_load_shell_envvars is on by default, which means "applications are loaded by running them with bash -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."
  3. source:services/api/config/arvados_config.rb runs Open3.capture3("arvados-server", "config-dump", "-config=-", "-skip-legacy", stdin_data: "Clusters: {xxxxx: {}}"). It finds arvados-server via the PATH 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.


Subtasks 1 (0 open1 closed)

Task #22136: Review 22134-railsapi-envvarsResolvedBrett Smith10/01/2024Actions
Actions #1

Updated by Brett Smith 2 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)
Actions #2

Updated by Brett Smith 2 months ago

  • Status changed from New to In Progress
Actions #3

Updated by Brett Smith 2 months ago

  • Release set to 70
Actions #4

Updated by Lucas Di Pentima about 2 months ago

This LGTM. I've manually applied these new config lines to tordo and everything seems to work without issues.

Actions #5

Updated by Peter Amstutz about 2 months ago

  • Target version changed from Development 2024-09-25 sprint to Development 2024-10-09 sprint
Actions #6

Updated by Brett Smith about 2 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.

Actions #7

Updated by Brett Smith about 2 months ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF