Deploy different Meteor settings per site #59
Comments
|
Yes - this is implemented in v2.1.0-rc.6 (we've been using it in production for the last few months to deploy across multiple regions). Just format the meteor-azure key as an array of objects with the regular format - so e.g {
// ... keys for Meteor.settings
"meteor-azure": [
{
"siteName": "app name",
"resourceGroup": "resource group",
"subscriptionId": "subscription ID",
"tenantId": "tenant ID",
"deploymentCreds": {
"username": "username",
"password": "password"
},
"envVariables": {
"ROOT_URL": "https://<app name>.azurewebsites.net",
"MONGO_URL": "MongoDB URL"
}
},
{
// ... site 2 settings
},
{
// ... site 3 settings
},
// ...
]
}Let me know if you have any issues - this should be released officially in the next couple weeks with proper docs. |
|
@ramijarrar can I specify a different a meteor setting object for each app? |
|
Not at this stage - what's the use case? I can definitely add an option to override specific keys per site, but it might be cleaner to just allow an array of paths in the CLI. |
ramijarrar
changed the title
|
We have the same app in multiple regions and also a staging app and several development apps for developers. Each has its own set of keys stored in meteor settings. With meteor up, we could deploy the same bundle to different server/meteor settings with |
|
Okay, I think the cleanest solution will be to accept a list of paths in the deploy command. We have a similar need for an upcoming project so might have some time to work on this later tonight. On a separate note - what service are you using to route traffic between regions? |
|
Each region has its own subdomain and a separate login server to redirect users to the right one. We also have a AWS load balancer for each region, which balances multiple servers. Azure web apps should make that process much simpler. |
|
@ramijarrar If this feature takes too long to finish, can you add a quick option to ignore meteor settings? We can always set the |
|
Have just released v2.1.0-rc.7 which accepts a comma separated list of settings files e.g
Also - we've implemented an option to select Node architecture (assuming you are on Meteor 1.6+):
Let me know if you have any issues with the above. |
|
I these errors when deploying just 1 app:
|
|
It suddenly just works, I did not change any settings. But I notice that websocket fails to connect occasionally, maybe 1 out of 10 times. It's much less frequent than deploying to linux/docker web apps though. |
|
Have you changed the host architecture to 64-bit in the Azure portal? Also are you using a custom server initialization script? (FYI, the multi-settings deployment is not dependent on architecture in any way) |
|
Yeah I changed the platform architecture to 64-bit and used
No I did not customize any script. But is there a way to install non-npm dependencies like wkhtmltopdf or phantomjs? |
|
When I tried using 32-bit, I got these errors:
The app was basically delayed to launch for 4 minutes due to these errors. This is not an issue when deploying a new app, but a problem for updating existing apps. |
|
Did you see these errors previously with the single setting deploy? Looks to me like a bundling issue - this can happen if local node_modules is inconsistent (best way to prevent this is by running Regarding wkhtmltopdf/similar tools - you can manually install/configure most of these with the Kudu console (there are some sandbox restrictions which are described here). |
|
Yes I always run |
|
There shouldn't be any issue building from Mac/Linux. From what I can tell, the errors are only happening once the server boots up which indicates these are likely reproducible in a local There seems to be some related threads on github (meteor/meteor#8004) and forums (here and here) - can you confirm which version of Meteor you're using and what the command output looks like in debug mode? I'm also investigating the possibility that this could be happening as a result of cached packages not switching architecture properly - can you confirm if the errors go away when deploying to an empty app service with default architecture? |
|
@WayneUong Just wondering if you are still seeing these issues / if you had a chance to investigate further? We have started using this across a few production applications in the last few weeks and are probably looking to release officially in the coming days. |
|
@ramijarrar Sorry for the late reply. I just tested this today on a fresh web app, with 64-bit enabled, and deployed with
This is for a single app. No scaling or any additional options. We also deployed fine using docker. |
|
It would eventually deploy, but not without restarting a few times due to the above error.
|
|
So I deployed a bare app with |
|
I'll see if I can reproduce with a bare |
|
Closing - moved to #60 |
Is there a way to deploy the same meteor app to multiple web apps, but with different settings, without having to rebuild them every time? Thank you.
The text was updated successfully, but these errors were encountered: