Skip to content

[#146] Resolve "TECH TASK: paramaterize env file for boost, ansible"

aguestuser requested to merge 146-paramaterize-env-file into master

Closes #146 (closed)

Context

we want a way to both:

  • (1) make it easy for sysadmins who are maintaining multiple instances of signalboost to switch back and forth between using boost on different instances without having to maintain separate copies of the signalboost repo
  • (2) make it hard for team-friendo devs to accidentally use boost to hit prod when they mean to hit their local dev machine (or vice versa)

Changes

to achieve both goals, we:

  • introduce an .env.dev file (stored under encrypted version control via blackbox)
  • put prod credentials into .env and dev credentials into .env.dev (some credentials only belong in one setting, so this eliminates some confusion in the example versions of these files!)
  • read .env in the docker-compose.yml file used on prod and .env.dev in docker-compose-dev.yml and other docker-compose files used in local dev and testing environments
  • modify app/config to always read all host and token configs directly from env vars (so that any given instance of the application can use an arbitrary set of host and token values provided at runtime by the .env file)
  • require an .env_file path to be defined in all boost commands, which can be achieved either:
    • by using a new -e <path/to/.env> flag when invoking boost
    • by exporting a default SIGNALBOOST_ENV_FILE whenever boost is called (iif you
  • if nothing is found

Note: env_file can already be passed as an ansible variable when invoking the provision and deploy playbooks, etc, so we do not modify anything with the ansible tooling. We merely update the boost tooling to be compatible with it.

as side effects, this MR:

  • standardizes usage in all boost commands to always use the -p flag to specify phone numbers (and never use -n).
  • updates the README to document the new flow
  • updates the .env.example and adds a new .env.dev.example to reflect the new flow
  • provides an .env.pentest with values for the pentesting server instance

Usage

Here are steps for team-friendo devs to take to take advantage of the new flows...

Update your files:

  • pull down master and/or fetch master and rebase onto it (to get the latest changes)
  • run bin/blackbox/shred_all_files && bin/blackbox/decrypt_all_files (to get rid of old env files and unlock new ones)
  • examine the content of .env and .env.dev to make sure they look sane

Now you can use the new flow!

To list all channels on your local machine:

boost -e .env.dev list-numbers

To list all channels on prod:

boost -e .env.dev list-numbers

Note that calling the following will now produce an error:

boost list-numbers

To set a default value for the env_file path (so you don't have to use the -e flag over and over again, you can add the following to your ~/.bashrc or equivalent:

export SIGNALBOOST_ENV_PATH=.env.dev

Now when you run boost without an -e flag it will hit dev by default:

boost list-numbers #implicitly sets -e .env.dev

To hit prod instead, you can use -e .env to override the value provided to $SIGBNALBOOST_ENV_PATH:

boost list-numbers -e .env # overrides the .env.dev value set in $SIGNALBOOST_ENV_PATH
Edited by aguestuser

Merge request reports