znmeb
commented
7 years ago I'm doing a docker-compose setup for the Transportation back end that includes the geocoder. I'll be expanding the PostGIS image / container to have all the tables needed for our Django code.
I'm doing this as the add-transpo-backend branch of the existing postgis-geocoder-test repo - see issue https://github.com/hackoregon/postgis-geocoder-test/issues/2.
So I'll have something Transportation can use for a local backend on a Docker host in a day or so. I'm hoping to finish it tomorrow but I have a lecture at Reed in the evening so it may be Thursday. I'll structure it so the core of the PostGIS is re-usuable by other projects; it's just a matter of factoring a bash script into a couple of components.
Sanjuro dropped by the DevOps squad meeting tonight. He shared an idea - on the assumption that multiple teams are using a Geocoder service, it might make more sense to invest in a single instance re-used by multiple projects, than for each project to stand up their own version of such a service.
One idea: re-use the Geocoder that one project stands up as a re-usable service by others.
Another idea: Stand up a Geocoder container that everyone else uses.
Depending on how useful a web service this might be, and how generalized, there is a significant risk that once word of this got out, it would get hammered by the public making use of a 'free' service. That could significantly run up Hack Oregon's bill, unless some restrictions were put in place - such as an authentication key, or IP filters to only expose the service to clients in the Hack Oregon ECS environment.
This won't be a devops priority until we have all the existing requirements met (5 projects' frontend and backend CI/CD pipelines running, the Civic Server and Platform Server running, and the production DNS and/or production cluster running).