Closed fschaeffler closed 1 year ago
Thanks for working on this. It's been a while since I've been working on this project and I'm currently not running stratosphere myself. However, these changes look good, I like that they're separate packages. However, could the whitelisting be made optional by a setting?
Good point. Will do the same for the AWS S3 sync, too.
I'm going to merge this so that this becomes the base for future improvements.
Wow, I didn't expect that. I wasn't even aware that I have that PR still open :)
Concerning framework, this PR contains an update to Meteor 1.6.
Added functionalities are as follows.
upload-sync to AWS S3: In order to now loose any files on a failure of the the host-system, all files are getting synchronized with a specified AWS S3 bucket. Whenever there are changes locally, those adjustments are getting synchronized to AWS S3, too. On every start of the stratosphere-server, the local upload-folder is then synchronized with the content from the AWS S3 bucket.
whitelisting of IP-addresses: There's the possibility to add static IP-addresses for whitelisting to the
settings.json
-file, as well as have the list dynamically growing. Clients can request via a HTTP-request to be set on the IP-whitelist with a specified API-key. A call could look like the followingcurl -H 'APIKEY: ACTUAL_API_KEY' http://127.0.0.1/whitelist
.deployable in multi-node environment: The changes in this PR include the possibility of deploying stratosphere in an environment with a load balancer and multiple nodes in the background. In the case of AWS, it's also possible to easily deploy stratosphere as an ElasticBeanstalk application with zodern/mup-aws-beanstalk.