GOOGLE ADS

Mittwoch, 20. April 2022

Wie übergebe ich das CosmosDb-SQL-Konto als Bizeps-Modulparameter?

Wie würde ich ein Cosmos-DB-Konto erstellen und es als Parameter an ein Bizepsmodul übergeben? Ich möchte dieses Beispiel-Bizepsskript erweitern, indem ich die Rollendefinition und Rollenzuweisung in ein separates Modul verschiebe.

Hier ist mein Versuch, ein Modul zu erstellen (das ein CosmosDBAccount ohne Fehler kompiliert und erstellt):

//@description ('cosmosDbAccount')
//param cosmosDbAccount object
@description ('cosmosDbAccountId')
param cosmosDbAccountId string
@description ('cosmosDbAccountName')
param cosmosDbAccountName string
@description('iteration')
param it int
@description('Principal ID of the managed identity')
param principalId string
var roleDefId = guid('sql-role-definition-', principalId, cosmosDbAccountId)
var roleDefName = 'Custom Read/Write role-${it}'
var roleAssignId = guid(roleDefId, principalId, cosmosDbAccountId)
resource roleDefinition 'Microsoft.DocumentDB/databaseAccounts/sqlRoleDefinitions@2021-06-15' = {
name: '${cosmosDbAccountName}/${roleDefId}'
properties: {
roleName: roleDefName
type: 'CustomRole'
assignableScopes: [
cosmosDbAccountId
]
permissions: [
{
dataActions: [
'Microsoft.DocumentDB/databaseAccounts/readMetadata'
'Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/*'
]
}
]
}
}
resource roleAssignment 'Microsoft.DocumentDB/databaseAccounts/sqlRoleAssignments@2021-06-15' = {
name: '${cosmosDbAccountName}/${roleAssignId}'
properties: {
roleDefinitionId: roleDefinition.id
principalId: principalId
scope: cosmosDbAccountId
}
}

Hier ist mein Versuch, das Modul aufzurufen:

@batchSize(1)
module cosmosRole 'cosmosRole.bicep' = [for (princId, jj) in principals: {
name: 'cosmos-role-definition-and-assignment-${jj}'
params: {
// cosmosDbAccount: cosmosDbAccount
cosmosDbAccountId: cosmosDbAccount.id
cosmosDbAccountName: cosmosDbAccount.name
principalId: princId
it: jj
}
}]

Wie Sie sehen können, verwendet der ursprüngliche Code cosmosDbAccount.id und ich habe dies durch eine Zeichenfolge namens cosmosDbAccountId ersetzt. Wenn ich versuche, den obigen Code zu entkommentieren und das cosmosDbObject zu übergeben und die ursprüngliche Syntax ("cosmosDbAccount.id" und "cosmosDbAccount.name") zu verwenden, erhalte ich diesen Fehler

ERROR:..."Deployment template validation failed: 'The template variable 'roleDefId' is not valid: The language expression property 'id' doesn't exist, available properties are 'apiVersion, location, tags, identity, kind, properties, condition, deploymentResourceLineInfo, existing, isConditionTrue, subscriptionId, resourceGroupName, scope, resourceId, referenceApiVersion, isTemplateResource, isAction, provisioningOperation'.. 

Fragen:

  • Ich würde die ursprüngliche Syntax (weniger Parameter) in meinem neuen Modul bevorzugen. Wie mache ich das?


  • Wie bestätige ich, dass das Skript die Rollenzuordnung und Rollendefinition erstellt hat? Ich kann diese im Azure-Portal nicht finden. Wenn ich die Bizeps-Ausgabeanweisung verwende, werden sie angezeigt, aber ich würde sie gerne auf der Portal-Webseite sehen.



  • Lösung des Problems

    Wenige Dinge hier. Das Übergeben eines Ressourcentypparameters ist eine experimentelle Funktion, Sie müssen sie aktivieren (siehe Vorschlag – Vereinfachung der Ressourcenreferenzierung für weitere Details).

    Bevor Sie Ihre Bizepsdatei bereitstellen, müssen Sie diese Umgebungsvariable festlegen:

    # powershell example
    $env:BICEP_RESOURCE_TYPED_PARAMS_AND_OUTPUTS_EXPERIMENTAL="true"

    Es werden weiterhin Fehler im Visual Studio-Code angezeigt, aber die Bereitstellung war erfolgreich.

    Hier ist das modifizierte Modul mit einem Parameter vom Typ resource:

    param cosmosDbAccount resource 'Microsoft.DocumentDB/databaseAccounts@2021-11-15-preview'
    param it int
    param principalId string
    var roleDefId = guid('sql-role-definition-', principalId, cosmosDbAccount.id)
    var roleDefName = 'Custom Read/Write role-${it}'
    var roleAssignId = guid(roleDefId, principalId, cosmosDbAccount.id)
    resource roleDefinition 'Microsoft.DocumentDB/databaseAccounts/sqlRoleDefinitions@2021-06-15' = {
    name: '${cosmosDbAccount.name}/${roleDefId}'
    properties: {
    roleName: roleDefName
    type: 'CustomRole'
    assignableScopes: [
    cosmosDbAccount.id
    ]
    permissions: [
    {
    dataActions: [
    'Microsoft.DocumentDB/databaseAccounts/readMetadata'
    'Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/*'
    ]
    }
    ]
    }
    }
    resource roleAssignment 'Microsoft.DocumentDB/databaseAccounts/sqlRoleAssignments@2021-06-15' = {
    name: '${cosmosDbAccount.name}/${roleAssignId}'
    properties: {
    roleDefinitionId: roleDefinition.id
    principalId: principalId
    scope: cosmosDbAccount.id
    }
    }

    In der Haupt-Bizepsdatei können wir dann cosmosDbAccountals Parameter übergeben:

    @batchSize(1)
    module cosmosRole 'cosmosRole.bicep' = [for (princId, jj) in principals: if (!empty(principals)) {
    name: 'cosmos-role-definition-and-assignment-${jj}'
    params: {
    cosmosDbAccount: cosmosDbAccount
    principalId: princId
    it: jj
    }
    }]

    Diese Lösung ist noch experimentell, und während der Ausführung az deployment group createvon wird diese große Warnung angezeigt:
    WARNUNG: Ressourcentypisierte Parameter und Ausgaben in ARM sind experimentell und sollten nur zu Testzwecken aktiviert werden. Aktivieren Sie diese Einstellung nicht für Produktionszwecke, oder Sie könnten jederzeit unerwartet kaputt gehen!

    Wenn Sie keine zwei Parameter übergeben möchten, können Sie eine vorhandene Ressource in Ihrem Modul deklarieren und einfach den cosmosDbAccountNameParameter übergeben:

    param cosmosDbAccountName string
    param it int
    param principalId string
    var roleDefId = guid('sql-role-definition-', principalId, cosmosDbAccount.id)
    var roleDefName = 'Custom Read/Write role-${it}'
    var roleAssignId = guid(roleDefId, principalId, cosmosDbAccount.id)
    resource cosmosDbAccount 'Microsoft.DocumentDB/databaseAccounts@2021-11-15-preview' existing = {
    name: cosmosDbAccountName
    }
    resource roleDefinition 'Microsoft.DocumentDB/databaseAccounts/sqlRoleDefinitions@2021-06-15' = {
    name: '${cosmosDbAccount.name}/${roleDefId}'
    properties: {
    roleName: roleDefName
    type: 'CustomRole'
    assignableScopes: [
    cosmosDbAccount.id
    ]
    permissions: [
    {
    dataActions: [
    'Microsoft.DocumentDB/databaseAccounts/readMetadata'
    'Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/*'
    ]
    }
    ]
    }
    }
    resource roleAssignment 'Microsoft.DocumentDB/databaseAccounts/sqlRoleAssignments@2021-06-15' = {
    name: '${cosmosDbAccount.name}/${roleAssignId}'
    properties: {
    roleDefinitionId: roleDefinition.id
    principalId: principalId
    scope: cosmosDbAccount.id
    }
    }

    Ihre Hauptdatei sieht so aus:

    @batchSize(1)
    module cosmosRole 'cosmos-module.bicep' = [for (princId, jj) in principals: if (!empty(principals)) {
    name: 'cosmos-role-definition-and-assignment-${jj}'
    params: {
    cosmosDbAccountName: cosmosDbAccount.name
    principalId: princId
    it: jj
    }
    }]

    Wenn Sie zu Ihrer zweiten Frage zu Ihrem Cosmos-DB-Konto navigieren und dann auf die export template Schaltfläche klicken, sollten Sie die erstellten Rollen und die zugehörigen Zuweisungen sehen können (ich weiß, es ist nicht ideal...):
    Geben Sie hier die Bildbeschreibung ein

    Keine Kommentare:

    Kommentar veröffentlichen

    Warum werden SCHED_FIFO-Threads derselben physischen CPU zugewiesen, obwohl CPUs im Leerlauf verfügbar sind?

    Lösung des Problems Wenn ich das richtig verstehe, versuchen Sie, SCHED_FIFO mit aktiviertem Hyperthreading ("HT") zu verwenden, ...