Azure-cosmos-dotnet-v2: Get connection string as output of AzureRM template

[fleed]

Can I get the (primary or secondary) connection string as output of an AzureRM template? Where can I find the documentation about the Microsoft.DocumentDB/databaseAccounts resource type?

[dmakwana]

@fleed For non-mongo accounts, the connection strings are built from the URI and the primary/secondary key with the following format (AccountEndpoint=/;AccountKey=;) The account keys are obtainable through various methods: REST API, Portal and Azure Powershell:

$keys = Invoke-AzureRmResourceAction -Action listKeys -ResourceType "Microsoft.DocumentDb/databaseAccounts" -ApiVersion "2015-04-08" -ResourceGroupName "rg-test" -Name "docdb-test"

For mongo accounts, we will be exposing an AzureRM action to list connection strings very soon. This will work very similarly to the powershell command above.

More documentation can be found here

Edit:The endpoint URI can be obtained by performing a GET on the database account

[atrauzzi]

@dmakwana - Did this ever end up getting implemented? I'm looking to get the mongodb connection string as a value while inside of my resource template, but can't figure out the right place to look.

[rolandoldengarm]

Yes I'm interested as well...

For Azure CLI there is a PR already: https://github.com/Azure/azure-cli/pull/2580

But I would like something similar for Azure Powershell

[dmakwana]

To obtain the connection string for mongo accounts:

@rolandoldengarm The documentation has yet to be updated, but you can execute the action in PowerShell with the following command:

Invoke-AzureRmResourceAction -Action listConnectionStrings -ResourceType "Microsoft.DocumentDb/databaseAccounts" -ApiVersion "2015-04-08" -ResourceGroupName "<resource-group-name>" -Name "<database-account-name>"

@atrauzzi The action endpoint is exposed. You can now obtain the connection string via the REST API (https://docs.microsoft.com/en-us/rest/api/documentdbresourceprovider/databaseaccounts#DatabaseAccounts_ListConnectionStrings)and PowerShell (see example above). The Azure/azure-cli#2580 (https://github.com/Azure/azure-cli/pull/2580) PR adds the functionality to obtain the connection string from Azure CLI 2.0

[atrauzzi]

@dmakwana I need to obtain it as part of my ARM template so that I can assign it to other resources as they are being provisioned, not via any API as that's not available to me from within the template.

[dmakwana]

@atrauzzi The connection strings/account keys will not be exposed as part of the ARM resource. The way to obtain the connection strings/account keys is once the account is provisioned, you need to make a separate call to get this info

[atrauzzi]

I think you're missing my point: It's extremely inconvenient to have to do exactly that.

You're suggesting an entire scripting implementation on top of the declarative convenience of resource templates. That's not a solution, that's a workaround.

[rolandoldengarm]

Yes, exactly the reason why I am now writing scripts to deploy my resources in a certain order (like DB, Mongo, SQL, etc). In the end I will deploy our API where I grab all the connection strings from the other resources via PowerShell and inject that as parameters for the API template.
Not elegant, but you have full control. ARM templates will never fully replace custom scripts IMO.

[atrauzzi]

Well, they could if the answer to issues like these stopped being _cobble it together_.

[bertramn]

One can do something like this "[listKeys(resourceId('Microsoft.DocumentDb/databaseAccounts', parameters('database_name')), '2015-04-08').primaryMasterKey]" in an ARM template. Why can't something like this work "[listConnectionStrings(resourceId('Microsoft.DocumentDb/databaseAccounts', parameters('database_name')), '2015-04-08')]" ?

[hami89]

Not the most convenient solution, but you can always concat the connection string in the template:
assuming that the name of the created database was "[parameters('databaseAccountName')]"

The connection string will be:
"[concat('mongodb://', parameters('databaseAccountName'), ':', listKeys(resourceId('Microsoft.DocumentDb/databaseAccounts', parameters('databaseAccountName')), '2015-04-08').primaryMasterKey, '@', parameters('databaseAccountName'), '.documents.azure.com:10250/?ssl=true')]"

[stephenctw]

Can I get the Event Hub compatible endpoint connection string of an IoT Hub from an ARM template?

[surabhshah]

Hi @606simps ,

You could do something like below to get event hub compatible endpoint connection string

[concat('Endpoint=',reference(resourceId('Microsoft.Devices/IoTHubs',variables('iotHubName'))).eventHubEndpoints.events.endpoint,';SharedAccessKeyName=iothubowner;SharedAccessKey=',listKeys(resourceId('Microsoft.Devices/IotHubs',variables('iotHubName')),'2016-02-03').value[0].primaryKey)]

Hope it helps!

[joeizy]

I understand that in .NET the SDK uses the URI and the KEY for connection but the CosmosDBTrigger for Azure Functions uses a connection string. It would be much better to include a connection string as part of the ARM template than to have to run an additional script.

Notification Hubs exposes this via its listKeys action. It's not as intuitive as a listConnectionStrings action for, but at least it solves the problem.

{
    "name": "NOTIFICATIONHUB_CONNECTIONSTRING",
    "value": "[listKeys(resourceId('Microsoft.NotificationHubs/namespaces/notificationHubs/authorizationRules', variables('hubNamespaceName'), variables('hubName'), 'DefaultFullSharedAccessSignature'), '2017-04-01').primaryConnectionString]"
 }

Here's a snippet for a Function App;

{
  "apiVersion": "2016-03-01",
  "name": "[variables('funcAppName')]",
  "type": "Microsoft.Web/sites",
  "properties": {
    "name": "[variables('funcAppName')]",
    "siteConfig": {
      "appSettings": [
        {
          "name": "AzureWebJobsDashboard",
          "value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'),';AccountKey=',listKeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName')), '2015-05-01-preview').key1)]"
        },
        {
          "name": "APPINSIGHTS_INSTRUMENTATIONKEY",
          "value": "[reference(resourceId(parameters('appinsights_resource_group'), 'microsoft.insights/components/', parameters('appinsights_name')), '2015-05-01').InstrumentationKey]"
        },
        {
          "name": "NOTIFICATIONHUB_CONNECTIONSTRING",
          "value": "[listKeys(resourceId('Microsoft.NotificationHubs/namespaces/notificationHubs/authorizationRules', variables('hubNamespaceName'), variables('hubName'), 'DefaultFullSharedAccessSignature'), '2017-04-01').primaryConnectionString]"
        }
    ]
   }
   ....
}

See the difference between a Storage Connection string that is concat together and the other values that are referenced. Much cleaner, more powerful, more flexible, and less error prone. The reference and similar will error out if you typo or get something wrong, the concat approach won't. Running an external PowerShell script seems silly for something so common.

[gwendalbroudinpro]

Is there any progress on this issue ? It still has the "pending confirmation" label