Gyermekerőforrások definiálása

  • 5 perc

Érdemes egyes erőforrásokat csak a szülő környezetében üzembe helyezni. Ezeket az erőforrásokat gyermekerőforrásoknak nevezzük. Az Azure-ban számos gyermekerőforrás-típus létezik. Here are a few examples:

Név Erőforrás típusa
Virtuális hálózati alhálózatok Microsoft.Network/virtualNetworks/subnets
App Service-konfiguráció Microsoft.Web/sites/config
SQL-adatbázisok Microsoft.Sql/servers/databases
Virtuálisgép-bővítmények Microsoft.Compute/virtualMachines/extensions
Tárolóblobtárolók Microsoft.Storage/storageAccounts/blobServices/containers
Azure Cosmos DB-tárolók Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers

Vegyük például egy tárolóblobtárolót. A blobtárolót egy tárfiókba kell telepíteni, és nincs értelme egy tárolónak a tárfiókon kívül léteznie.

A gyermekerőforrás-típusok neve hosszabb, több részből áll. A tároló blobtárolóinak ez a teljes típusneve van: Microsoft.Storage/storageAccounts/blobServices/containers. A blobtároló erőforrás-azonosítója tartalmazza a tárolót tartalmazó tárfiók nevét és a tároló nevét.

Megjegyzés:

Egyes gyermekerőforrások neve megegyezhet a különböző szülők más gyermekerőforrás-típusaival. Ilyen például containers a tárfiókok és az Azure Cosmos DB-adatbázisok gyermektípusa. A nevek azonosak, de különböző erőforrásokat jelölnek, és teljesen minősített típusnevük eltérő.

Hogyan vannak definiálva a gyermekerőforrások?

A Bicep használatával többféleképpen deklarálhatja a gyermekerőforrásokat. Minden útnak megvannak a maga előnyei, és mindegyik alkalmas bizonyos helyzetekre, és nem mások számára. Tekintsük át az egyes megközelítéseket.

Tipp.

Az alábbi megközelítések mindegyike ugyanazt az üzembehelyezési tevékenységet eredményezi az Azure-ban. Kiválaszthatja az igényeinek leginkább megfelelő megközelítést anélkül, hogy aggódnia kellene valami feltörése miatt. Emellett frissítheti a sablont, és módosíthatja a használt megközelítést.

Beágyazott erőforrások

A gyermekerőforrás meghatározásának egyik módszere a gyermekerőforrás beágyazása a szülőbe. Íme egy példa egy Bicep-sablonra, amely egy virtuális gépet és egy virtuálisgép-bővítményt helyez üzembe. A virtuálisgép-bővítmények olyan gyermekerőforrások, amelyek további viselkedést biztosítanak a virtuális gépek számára. Ebben az esetben a bővítmény egy egyéni szkriptet futtat a virtuális gépen az üzembe helyezés után.

resource vm 'Microsoft.Compute/virtualMachines@2020-06-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }

  resource installCustomScriptExtension 'extensions' = {
    name: 'InstallCustomScript'
    location: location
    properties: {
      // ...
    }
  }
}

Figyelje meg, hogy a beágyazott erőforrás a szokásosnál egyszerűbb erőforrástípussal rendelkezik. Annak ellenére, hogy a teljes típusnév az Microsoft.Compute/virtualMachines/extensions, a beágyazott erőforrás automatikusan örökli a szülő erőforrástípusát, ezért csak a gyermekerőforrás-típust extensionskell megadnia.

Azt is figyelje meg, hogy nincs megadva API-verzió a beágyazott erőforráshoz. A Bicep feltételezi, hogy ugyanazt az API-verziót szeretné használni, mint a szülőerőforrás, bár igény szerint felülbírálhatja az API-verziót.

Az operátorral :: beágyazott erőforrásra hivatkozhat. Létrehozhat például egy kimenetet, amely a bővítmény teljes erőforrás-azonosítóját adja vissza:

output childResourceId string = vm::installCustomScriptExtension.id

Az erőforrások beágyazásával egyszerűen deklarálhat gyermekerőforrást. Az erőforrások beágyazása a szülő-gyermek kapcsolatot is nyilvánvalóvá teszi a sablont olvasottak számára. Ha azonban sok beágyazott erőforrással vagy több rétegbe ágyazott erőforrással rendelkezik, a sablonok olvasása nehezebbé válhat. Az erőforrásokat legfeljebb öt réteg mélyre is beágyazhatja.

Szülőtulajdonság

A második módszer a gyermekerőforrás beágyazás nélküli deklarálása. Ezután a parent tulajdonság használatával tájékoztassa a Bicepet a szülő-gyermek kapcsolatról:

resource vm 'Microsoft.Compute/virtualMachines@2020-06-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }
}

resource installCustomScriptExtension 'Microsoft.Compute/virtualMachines/extensions@2020-06-01' = {
  parent: vm
  name: 'InstallCustomScript'
  location: location
  properties: {
    // ...
  }
}

Figyelje meg, hogy a gyermekerőforrás a parent tulajdonság használatával hivatkozik a szülő szimbolikus nevére.

A szülőre való hivatkozás egy másik egyszerű módszer a gyermekerőforrás deklarálására. A Bicep megérti a szülő- és gyermekerőforrások közötti kapcsolatot, ezért nem kell megadnia a teljes erőforrásnevet, és nem kell függőséget beállítania az erőforrások között. A megközelítés azt is elkerüli, hogy túl sok beágyazás legyen, ami nehezen olvashatóvá válhat. Azonban explicit módon meg kell adnia a teljes erőforrástípust és AZ API-verziót minden alkalommal, amikor gyermekerőforrást határoz meg a parent tulajdonság használatával.

Ha a parent tulajdonsággal deklarált gyermekerőforrásra szeretne hivatkozni, használja annak szimbolikus nevét, ahogyan egy normál szülőerőforrás esetében tenné:

output childResourceId string = installCustomScriptExtension.id

Az erőforrás nevének létrehozása

Vannak olyan körülmények, amikor nem használhat beágyazott erőforrásokat vagy kulcsszót parent . Ilyen például, ha gyermekerőforrásokat deklarál egy for cikluson belül, vagy ha összetett kifejezésekkel kell dinamikusan kijelölnie egy szülőerőforrást egy gyermek számára. Ilyen helyzetekben a gyermekerőforrás üzembe helyezéséhez manuálisan kell létrehoznia a gyermekerőforrás nevét, hogy az tartalmazza a szülőerőforrás nevét, ahogy az itt látható:

resource vm 'Microsoft.Compute/virtualMachines@2020-06-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }
}

resource installCustomScriptExtension 'Microsoft.Compute/virtualMachines/extensions@2020-06-01' = {
  name: '${vm.name}/InstallCustomScript'
  location: location
  properties: {
    // ...
  }
}

Figyelje meg, hogy ez a példa sztringinterpolációval fűzi hozzá a virtuálisgép-erőforrás name tulajdonságát a gyermekerőforrás nevéhez. A Bicep tisztában van azzal, hogy függőség van a gyermek és a szülőerőforrások között. A gyermekerőforrás nevét a változó használatával vmName deklarálhatja. Ha mégis ezt teszi, az üzembe helyezés meghiúsulhat, mert a Bicep nem értené meg, hogy a szülőerőforrást a gyermekerőforrás előtt kell üzembe helyezni:

A probléma megoldásához manuálisan is tájékoztathatja a Bicepet a függőségről a kulcsszó használatával, ahogyan az dependsOn itt látható:

resource vm 'Microsoft.Compute/virtualMachines@2020-06-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }
}

resource installCustomScriptExtension 'Microsoft.Compute/virtualMachines/extensions@2020-06-01' = {
  name: '${vmName}/InstallCustomScript'
  dependsOn: [
    vm
  ]
  //...
}

Tipp.

Általában érdemes elkerülni az erőforrásnevek létrehozásának elkerülését, mert a Bicep által nyújtott előnyök nagy részét elveszíti, amikor megérti az erőforrások közötti kapcsolatokat. Ezt a lehetőséget csak akkor használja, ha a gyermekerőforrások deklarálásához nem használhatja a többi módszer egyikét.

Gyermekerőforrás-azonosítók

A gyermekerőforrás-azonosító létrehozásához a szülő erőforrás-azonosítóját is be kell írnia, majd hozzá kell fűznie a gyermekerőforrás típusát és nevét. Vegyük például egy Azure Cosmos DB-fiók nevét toyrnd. Az Azure Cosmos DB erőforrás-szolgáltató egy úgynevezett databaseAccountstípust tesz elérhetővé, amely az üzembe helyezendő szülőerőforrás:

/subscriptions/A123b4567c-1234-1a2b-2b1a-1234abc12345/resourceGroups/ToyDevelopment/providers/Microsoft.DocumentDB/databaseAccounts/toyrnd

Íme egy vizualizáció, amely ugyanazt az erőforrás-azonosítót ábrázolja:

Resource ID for an Azure Cosmos DB account, split with the key-value pair on a separate line.

Ha hozzáadunk egy adatbázist ehhez a fiókhoz, használhatjuk a sqlDatabases gyermekerőforrás típusát. Adjunk hozzá egy Azure Cosmos DB-fiókhoz elnevezett FlightTests adatbázist, és tekintsük meg a gyermekerőforrás-azonosítót:

/subscriptions/A123b4567c-1234-1a2b-2b1a-1234abc12345/resourceGroups/ToyDevelopment/providers/Microsoft.DocumentDB/databaseAccounts/toyrnd/sqlDatabases/FlightTests

Íme egy vizuális ábrázolás:

Child resource ID for an Azure Cosmos DB database, split with the key-value pair on a separate line.

Több szintű gyermekerőforrással is rendelkezhet. Íme egy példa erőforrás-azonosító, amely egy két gyermekszintű tárfiókot jelenít meg:

/subscriptions/A123b4567c-1234-1a2b-2b1a-1234abc12345/resourceGroups/ToyDevelopment/providers/Microsoft.Storage/storageAccounts/secrettoys/blobServices/default/containers/glitterspecs

Íme egy vizualizáció ugyanarra az erőforrás-azonosítóra:

Child resource ID for a storage account with blob container, split with the key-value pair on a separate line.

Ez az erőforrás-azonosító több összetevőből áll:

  • Minden a secrettoys szülőerőforrás-azonosító.

  • blobServices azt jelzi, hogy az erőforrás egy gyermek típusú, úgynevezett blobServices.

    Megjegyzés:

    Nem kell saját maga létrehoznia blobServices az erőforrásokat. Az Microsoft.Storage erőforrás-szolgáltató automatikusan létrehozza ezt az erőforrást a tárfiók létrehozásakor. Ezt az erőforrástípust néha implicit erőforrásnak is nevezik. Meglehetősen szokatlanok, de az Azure-ban megtalálja őket.

  • default a gyermekerőforrás neve blobServices .

    Megjegyzés:

    Néha csak egy gyermekerőforrás egyetlen példánya engedélyezett. Ezt a példánytípust singletonnak nevezik, és gyakran nevezik el.default

  • containers azt jelzi, hogy az erőforrás egy gyermek típusú, úgynevezett containers.

  • glitterspecs A blobtároló neve.

Ha gyermekerőforrásokkal dolgozik, az erőforrás-azonosítók hosszú ideig tarthatnak, és bonyolultnak tűnhetnek. Ha azonban az erőforrás-azonosítót az összetevőkre bontja, könnyebben megértheti, hogyan épül fel az erőforrás. Az erőforrás-azonosítók fontos jeleket is adhatnak az erőforrás viselkedéséről.