Skip to content

[#146] add ansible tooling omitted in MR !210

aguestuser requested to merge hotfix-add-ansible-tooling-omitted-in-mr-210 into master

context:

  • in MR !210 (merged), we introduced the ability to talk to multiple servers using boost by paramaterizing the .env file that boost 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 to signalboost (except in some rare cases where it defaults to sb_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 and env_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 and ENV_FILE everywhere instead of env_path. (We choose the former since it is what docker-compose uses)
  • note: i thought i had included this in my last MR! (!210 (merged)) apologies for confusion!
Edited by aguestuser

Merge request reports

Loading