[#146] Resolve "TECH TASK: paramaterize env file for boost, ansible"
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 thedocker-compose.yml
file used on prod and.env.dev
indocker-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 allboost
commands, which can be achieved either:- by using a new
-e <path/to/.env>
flag when invokingboost
- by exporting a default
SIGNALBOOST_ENV_FILE
wheneverboost
is called (iif you
- by using a new
- 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