Configuration¶
Meteor Azure is configured with a settings file and optionally, a custom web config.
Settings file¶
Your settings file contains Meteor.settings and the Azure Web App details.
It follows the format below:
Note
All fields are requires unless otherwise specified
{
"meteor-azure": {
"siteName": "",
"resourceGroup": "",
"subscriptionId": "",
"deploymentCreds": {
"username": "",
"password": ""
},
// e.g "something.onmicrosoft.com"
// (can be read from the user dropdown in the portal)
"tenantId": "",
"envVariables": {
"MONGO_URL": "",
// "https://<siteName>.azurewebsites.net" or a custom domain if you have set one
"ROOT_URL": ""
// ... other environment variables e.g MONGO_OPLOG_URL, MAIL_URL, etc.
},
// An optional field for selecting deployment slot
// (see below for full instructions)
"slotName": "",
// An optional field for enabling non-interactive login
// (see below for full instructions)
"servicePrincipal": {
"appId": "",
"secret": ""
}
}
// ... keys for Meteor.settings
}
Select deployment slot¶
To target a particular deployment slot, set the “slotName” field to the appropriate postfix and leave “siteName” as the base value.
For example: a deployment slot called “foo-bar-baz” where “foo-bar” is the base value and “baz” is the slot postfix, would have:
{
"siteName": "foo-bar",
"slotName": "baz"
// ...
}
Setup automatic CLI login¶
In scenarios where an interactive login is inconvenient/prohibiting (e.g on a CI server), we can authenticate automatically by creating a service principal and granting resource access.
Follow the Azure instructions to configure this in the portal. Make sure to assign a “Contributor” role within the current subscription, and take note of your key value (which is the “secret”) and application ID.
Add these details to the “servicePrincipal” field and try running the CLI again. You should no longer be prompted for login.
Custom web config¶
The web config is used to configure your IIS web server in Azure. The default values provide a good starting point for most applications.
Some common use cases for a custom file (using the --web-config
option) are described below.
We also have a repository of examples that you can browse through.
Setup HTTPS redirect¶
Note
We do not support the core ‘force-ssl’ package
To handle redirecting users to HTTPS, add an extra rewrite rule (preceding existing rules) and ensure your “ROOT_URL” is given with “https”:
<rewrite>
<rules>
<!-- Force HTTPS -->
<rule name="Redirect to HTTPS" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="^OFF$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
</rule>
<!-- ... other rewrite rules -->
</rules>
</rewrite>
Enable multi-core¶
To fully utilise CPU capacity on multi-core servers (offered by the larger instances), we can load balance between multiple processes of our application on each machine.
This is handled automatically by the IISNode module, and can be enabled by setting the “nodeProcessCountPerApplication” option:
<system.webServer>
<!-- ... -->
<!-- specify number of node processes to be started, setting this to 0
will result in creating one process per each processor on the machine -->
<iisnode nodeProcessCountPerApplication="0" />
</system.webServer>