Setup tileserver for public land tiles #155
Conversation
hcooper
requested review from
BenjaminPelletier,
catware2,
dangel-ma and
davantalus
| ports: | ||
| - "7979:7979" | ||
| volumes: | ||
| - /mnt/rwimages/tiles:/data |
There was a problem hiding this comment.
This seems like a new requirement to have for a site deployment -- let's add documentation describing how someone would get the appropriate data since someone couldn't bring up a working site instance without it. These instructions should be complete and sufficient to bring up a deployment of the site, assuming the user has access to the right things (database backup, images folder)
| - ACCEPTED_NETWORKS=172.16.0.0/12 # Only accept connections from docker's internal network | ||
|
|
||
| ropewiki_tileserver: | ||
| image: maptiler/tileserver-gl:latest |
There was a problem hiding this comment.
Can we pin this more specifically? latest tags often break things on a schedule we don't control
| - "7979:7979" | ||
| volumes: | ||
| - /mnt/rwimages/tiles:/data | ||
| command: -c config.json -p 7979 |
There was a problem hiding this comment.
Is this config.json file in the /mnt/rwimages/tiles folder? If so, it seems like it should be tracked in this repo and probably we should build an image based on maptiler/tileserver-gl
|
@BenjaminPelletier - this has been running in production for weeks await review, in the meantime supporting a real world crisis in land management across the US, please don't get hung up on docker tags, and docs no one will read. |
|
@BenjaminPelletier - sorry, I scrambled fucking hard & fast to make this work for multiple communities - so armchair nitpicking isn't going down well. |
|
The big problem RopeWiki had prior to creation of this repository was that the singleton deployment was a one-off sum of many unrepeatable changes. The primary purpose of this repository is to fix that situation by making deployment reproducible. In cases where the resources in the repo aren't sufficient (database backup + images backup), the expectations and procedures are well-documented so that someone with just the repo plus those limited additional resources should reliably be able to successfully deploy. Two of the three comments are targeted at maintaining that core purpose of the repo rather than regressing deployment reproducibility by adding a hidden dependency on content that is only available on the singleton deployment. I'm very open to the possibility that I may have misunderstood what's going on, but it doesn't sound like that's the issue. Deployment into production prior to review is a substantial concern that I'm willing to live with for now because 1) we don't yet have an auto-deploying dev environment to enable low-overhead verification of changes and 2) you've executed the pre-review production deployments very carefully and skillfully. But, "it's been running in production" is not a convincing argument -- RopeWiki ran in production for 6 years, but those 6 years weren't evidence that the system was set up well. We were lucky nothing irrecoverable happened despite its fragility. |
This stands up a map tile server on it's own domain name
tiles.ropewiki.com. The purpose is for serving the public lands at risk of being sold map tiles.The tiles them selves are in
/rw/mount/images/tilesIt's already up and running on the production site.
The domain is fronted by cloudflare for extra caching.
Post about it: https://www.facebook.com/groups/ropewiki/posts/3960980320781946