Docker images, what’s the motivation?
I run docker containers on AKS for my open source and would do the same with Armadietto, so that’s not the meaning of my question.
I’m wondering if remotestorage is being positioned as a “here’s a back-end you can stand up for your own individual app”?
Or is it to make it easier to standup remotestorage as a service to let people have a choice when bringing their own data to Web apps?
I think it’s mainly to make it easy to run your own RS server. Both standalone as well as perhaps integrating into the many self-hosting systems that use Docker images these days.
Thanks @raucao , that (standing up as a quick back-end for own app) rings true of the PR I see open (the description).
I imagine, without payment gateway integrations, it’d not be feasible to just take the containers and stand them up as a general remotestorage for the public. Would need to repeat the work 5apps must have done for their offering. I mean, the “free” Web still costs money.
Also, out of the box, when standing up an instance for your own apps’ needs, I don’t think there is a mechanism to prevent people from using the instance for any other remotestorage compatible apps out there.
I think I can make both usages more feasible with ‘ledger based authorizations’… We’ll see.
If you want to stand up a server to support just one app, there are a number of solutions that handle syncing - CouchDB + PouchDB comes to mind.
FWIW, there is a possible mechanism to restrict the apps that can use a RemoteStorage instance: CORS. If the server sends the header
Access-Control-Allow-Origin: https://myhost.com, (rather than the * that is often sent) then requests from web apps not running on https://myhost.com will be rejected. I don’t know of any RS server that can be configured to do that, but it would be straightforward to add.
CORS by itself doesn’t restrict non-browser apps from accessing a host, so this would not be a security measure, so much as a “cut down the traffic” measure.
I wouldn’t advocate adding anything to Armadietto in and around this anyways, especially the containerized one.
This business I’d leave to the reverse proxy in front of the cluster.
The original question was really more about intention, not technical solutions. How is the docker image positioned to be used.
The logging you’ve added, with ability to limit file logging and control stdout, that’s a value-add for my docker/k8s cluster I appreciate (opinion, others run different). But SSL termination, preflight controls, rewrites, that’s what I personally leave for the reverse proxy.