This PR installs qgtunnel and updates heroku.yml to initialize a tunnel to the GIS database server when starting the app with gunicorn.
It also updates the release script so fixture data is only loaded against an empty database, addressing deployment failures on staging.
Closes #59.
Demo
From a Heroku shell against the staging app:
# N.b., Prefix any command with bin/qgtunnel to establish the tunnel for that process
~ $ bin/qgtunnel python manage.py shell
Python 3.8.12 (default, Dec 3 2021, 01:52:45)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from django.db import connections
>>> connections['fp_postgis'].ensure_connection()
>>> from asset_dashboard.models import NaturePreserves
>>> NaturePreserves.objects.count()
47
Notes
Outside of version control, I provisioned a QuotaGuard Static add-on for the staging app, asked Garret to whitelist the provided IPs as trusted traffic sources for GIS database, then configured the tunnel following these instructions. The resulting config is committed to version control in this PR to remove our dependency on the QuotaGuard site. I also added the GIS_DATABASE_URL to review app config vars in the Heroku UI.
As this approach relies on static IPs being available, it will only work for apps to which we've attached the QuotaGuard Static add-on. By default, this excludes review apps, and if it's possible, I think it's probably a good idea to write the GIS integration such that the app is resilient enough for testing without access to the GIS database.
For scenarios where we do want GIS access for a review app, QuotaGuard Static instances can be shared between apps, so we can do heroku:attach -a ${REVIEW_APP} quotaguardstatic after the app is initialized. I've gone ahead and tested this approach with the review app created by this PR. Worked as expected!
Testing Instructions
All testing already done.
Already tested the staging site, as documented in the demo section. [DONE]
Confirm a review app is created and can be accessed as normal. [DONE]
Attach the QG Static add-on to the review app and confirm via the shell that the remote GIS database can be access. [DONE]
Overview
This PR installs
qgtunneland updatesheroku.ymlto initialize a tunnel to the GIS database server when starting the app withgunicorn.It also updates the release script so fixture data is only loaded against an empty database, addressing deployment failures on staging.
Closes #59.
Demo
From a Heroku shell against the staging app:
Notes
Outside of version control, I provisioned a QuotaGuard Static add-on for the staging app, asked Garret to whitelist the provided IPs as trusted traffic sources for GIS database, then configured the tunnel following these instructions. The resulting config is committed to version control in this PR to remove our dependency on the QuotaGuard site. I also added the
GIS_DATABASE_URLto review app config vars in the Heroku UI.As this approach relies on static IPs being available, it will only work for apps to which we've attached the QuotaGuard Static add-on. By default, this excludes review apps, and if it's possible, I think it's probably a good idea to write the GIS integration such that the app is resilient enough for testing without access to the GIS database.
For scenarios where we do want GIS access for a review app, QuotaGuard Static instances can be shared between apps, so we can do
heroku:attach -a ${REVIEW_APP} quotaguardstaticafter the app is initialized. I've gone ahead and tested this approach with the review app created by this PR. Worked as expected!Testing Instructions
All testing already done.