context:
- in MR !210 (merged), we introduced the ability to talk to multiple servers
using boost by paramaterizing the
.env
file thatboost
reads host urls and api tokens from on any given call - we noted in passing that we had already paramaterized
.env
in our ansible workflow, and mistakenly assumed this was enough to use one repo to easily manage multiple remote hosts. - this was a mistake! we neglected to notice or deal with the fact that the host
signalboost
was hardcoded as the host that most of our ansible scripts talk to. - if we wanted a way to use ansible to deploy to
multiple servers without editing
provision.yml
/deploy.yml
, etc. (which risks putting new values under version control and mucking up our workflow for deploying to prod), we should also introduce an ansibel variable that paramaterizes which host any given playbook is targeting at a way that can be overriden at deploy-time - this MR introduces a way to do that!
changes:
- introduce a
sb_host
env var that always defaults tosignalboost
(except in some rare cases where it defaults tosb_backup
for playbooks that target the remote backup server) - document how to use ansible extra variables at deploy-time to
override the default values for both
sb_host
andenv_file
- with this, a user can use one repo to maintain (provision/deploy) multiple different remote instances (QED)
side-effects:
- for consistency, use
env_file
andENV_FILE
everywhere instead ofenv_path
. (We choose the former since it is whatdocker-compose
uses) - note: i thought i had included this in my last MR! (!210 (merged)) apologies for confusion!
Edited by aguestuser