Open Seltzer opened 4 years ago
@Seltzer Answers to your questions in order:
Thanks for your responses.
Sounds like we should avoid trying to share the cache as we'd be relying on undefined behaviour in any case.
We have an ever-growing whitelist of CORS domains stored in a DB table which we're hoping to add to the response header. I'm not sure how many others are in a similar situation so it's hard to say whether it's justifiable to add it to the roadmap. I suspect the primary use-case it'd be catering for is when you have a multi-tenanted website with maps on it where each tenant has their own domain.
@Seltzer I have not played with it personally, but the tegola s3 cache backend can be used against https://github.com/minio/minio. This might be a viable alternative to the filestore for your situation.
Regarding the whitelist, this sounds more application-specific so I think your idea of a proxy in front of tegola is probably the best idea. I'm happy to leave the conversation open in case anyone else wants to chime in, and I would love to hear what you end up with. I think others will encounter this problem as user adoption grows.
I'm looking into deploying Tegola via the Docker image and I have a few questions. Apologies if I've missed some docs where these are answered.
Does Tegola itself evict entries from its file cache? I assume the cache grows indefinitely until there's no more disk space or tiles are explicitly purged.
Would it be possible for two instances of Tegola (e.g. load balanced) to share a single file cache without issue?
This is an extremely long shot but would you ever consider adding support for dynamic fetching of CORS origins (e.g. from a DB table or REST endpoint)? This has come up because we often provision new websites on the fly and we're trying to avoid having to manually add origins to the list and restart the container when launching a new site. We'll most likely solve this by shoving an in-container reverse proxy in front of Tegola and handling it at that level.
Cheers, Nathan