I’m pretty new to Meteor and I’ve been developing a simple reporting tool to generate graphs and tables based on some data in the companies MSSQL database.
I’ve built the majority of the tool and got it working locally. It uses emgee3/meteor-mssql to connect to the database and import data to local collections. It’s been very easy to set up and it’s working great.
The problems have arisen when deploying to meteor.com for further testing.
Our SQL Server is naturally behind a firewall with IP whitelist rules. After much messing around opening ports for various IPs I have finally written that uses the NPM ‘public-ip’ to find the IP address of where the server is.
This is different from the 7 public IPs you find when pinging myapp.meteor.com, However neither that IP or the 7 public IPs can access our SQL Server.
I’ve been using a simple telnet connection check on the app and it can’t connect when on meteor.com
Is there something I am missing? Has anyone else had any success connecting through a firewall from a deployed meteor app? I know that heroku has ‘Proximo’ for exactly this, is this something I should play with?
Please don’t get me wrong, but trying to connect a free and public app hosting service to your private enterprise infrastructure and expecting it to work flawlessly, even attempting it, all the while labeling the experience a nightmare is injustice to the meteor deploy offering.
You should either host the app internally, or go for one of the many paid alternatives (modulus, heroku, aws, digital ocean etc) who cover at least base enterprise legal requirements.
That being said, *.meteor.com public IP addresses are reverse proxy addresses which load balance back to the meteor app servers which actually host your app.
If you really must use a free service, you could perhaps set up a local endpoint which accepts all connections from any address, and then proxy that connection to your sql server. You could then further filter the incoming packets with application firewall rules o allow only certain SQL based transports.
1 Like
I apologise for the title, it’s perhaps a little harsh and it isn’t intended to reflect on the quality of the service at *.meteor.com, which does what it’s suppose to do very well. Just that I’m having hard time trying to figure it out. Perhaps I will edit the title.
We are looking into meteor and this little app is our first experiment. It’s really just a toy and was never meant to stay on this hosting system. I just wanted to find out if anyone had any experience doing this specific thing.
I’ve already started playing with Heroku and Proximo to see if I get anywhere with that and I will report back my experience.
I see, well, in that case I’d really urge you try out other deployment options since they certainly have their own learning curves and bullet points against your evaluation checklist.
I personally find deploying on a barebones ubuntu server (digital ocean?) using phusion passenger and manage my own mongodb instances with mms (mongodb management service) more favorable due to its flexibility and server density.
Perhaps @sashko might have that IP information if that’s a blocker for your evaluation.
Thanks, yes I might look into Digital Ocean, at the moment I am using Heroku’s free tier for testing. I’be paid for a Proximo developer account ($5) but I can’t get it to work.
You are supposed to wrap the launch command in a the Proximo binary in your Procfile, these are all terms relevant to a Node project but not obvious on a meteor one. I’ve done what I think I’m suppose to do, and I’ve got Heroku support looking at it for me.
I’ll post back here if we get it working with a rough guide on how it was solved.
Hm yes, you’ll probably face that problem in any PaaS provider.
If you want to try DO or any cloud/vps server, you’ll find plenty of literature and examples. Let me know if you need help.