Definiowanie zasobów podrzędnych

5 min

Warto wdrożyć niektóre zasoby tylko w kontekście ich elementu nadrzędnego. Te zasoby są nazywane zasobami podrzędnym. Na platformie Azure istnieje wiele typów zasobów podrzędnych. Oto kilka przykładów:

Nazwisko	Typ zasobu
Podsieci sieci wirtualnej	`Microsoft.Network/virtualNetworks/subnets`
Konfiguracja usługi App Service	`Microsoft.Web/sites/config`
Bazy danych SQL	`Microsoft.Sql/servers/databases`
Rozszerzenia maszyny wirtualnej	`Microsoft.Compute/virtualMachines/extensions`
Kontenery obiektów blob magazynu	`Microsoft.Storage/storageAccounts/blobServices/containers`
Kontenery usługi Azure Cosmos DB	`Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers`

Rozważmy na przykład kontener obiektów blob magazynu. Kontener obiektów blob musi zostać wdrożony na koncie magazynu i nie ma sensu, aby kontener istniał poza kontem magazynu.

Typy zasobów podrzędnych mają dłuższe nazwy z wieloma częściami. Kontener obiektów blob magazynu ma w pełni kwalifikowaną nazwę typu: Microsoft.Storage/storageAccounts/blobServices/containers. Identyfikator zasobu kontenera obiektów blob zawiera nazwę konta magazynu zawierającego kontener oraz nazwę kontenera.

Uwaga

Niektóre zasoby podrzędne mogą mieć taką samą nazwę jak inne typy zasobów podrzędnych z różnych elementów nadrzędnych. Na przykład containers jest typem podrzędnym zarówno kont magazynu, jak i baz danych usługi Azure Cosmos DB. Nazwy są takie same, ale reprezentują różne zasoby, a ich w pełni kwalifikowane nazwy typów są różne.

Jak są zdefiniowane zasoby podrzędne?

Dzięki aplikacji Bicep można deklarować zasoby podrzędne na kilka różnych sposobów. Każdy ze sposobów ma własne zalety, a każdy z nich jest odpowiedni dla niektórych sytuacji, a nie dla innych. Przyjrzyjmy się każdemu podejściu.

Napiwek

Wszystkie poniższe podejścia powodują te same działania wdrażania na platformie Azure. Możesz wybrać podejście, które najlepiej odpowiada Twoim potrzebom bez konieczności martwienia się o coś łamiąc. Możesz też zaktualizować szablon i zmienić używane podejście.

Zasoby zagnieżdżone

Jednym z podejść do definiowania zasobu podrzędnego jest zagnieżdżanie zasobu podrzędnego wewnątrz elementu nadrzędnego. Oto przykład szablonu Bicep, który wdraża maszynę wirtualną i rozszerzenie maszyny wirtualnej. Rozszerzenie maszyny wirtualnej to zasób podrzędny, który zapewnia dodatkowe zachowanie dla maszyny wirtualnej. W takim przypadku rozszerzenie uruchamia skrypt niestandardowy na maszynie wirtualnej po wdrożeniu.

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

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

Zwróć uwagę, że zagnieżdżony zasób ma prostszy typ zasobu niż zwykle. Mimo że w pełni kwalifikowana nazwa typu to Microsoft.Compute/virtualMachines/extensions, zagnieżdżony zasób automatycznie dziedziczy typ zasobu nadrzędnego, dlatego należy określić tylko typ zasobu podrzędnego. extensions

Zwróć również uwagę, że nie określono wersji interfejsu API dla zagnieżdżonego zasobu. Bicep zakłada, że chcesz użyć tej samej wersji interfejsu API co zasób nadrzędny, chociaż możesz zastąpić wersję interfejsu API, jeśli chcesz.

Zagnieżdżony zasób można odwoływać się za pomocą :: operatora . Można na przykład utworzyć dane wyjściowe zwracające pełny identyfikator zasobu rozszerzenia:

output childResourceId string = vm::installCustomScriptExtension.id

Zagnieżdżanie zasobów to prosty sposób deklarowania zasobu podrzędnego. Zagnieżdżanie zasobów sprawia również, że relacja nadrzędny-podrzędna jest oczywista dla każdego, kto czyta szablon. Jeśli jednak masz wiele zasobów zagnieżdżonych lub wiele warstw zagnieżdżania, szablony mogą stać się trudniejsze do odczytania. Zasoby można również zagnieżdżać tylko do pięciu warstw głębokości.

Właściwość nadrzędna

Drugim podejściem jest zadeklarowanie zasobu podrzędnego bez zagnieżdżania. Następnie użyj parent właściwości , aby poinformować Bicep o relacji nadrzędny-podrzędny:

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

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

Zwróć uwagę, że zasób podrzędny parent używa właściwości do odwoływania się do symbolicznej nazwy jej elementu nadrzędnego.

Takie podejście do odwoływania się do elementu nadrzędnego jest innym łatwym sposobem deklarowania zasobu podrzędnego. Bicep rozumie relację między zasobami nadrzędnymi i podrzędnymi, więc nie trzeba określać w pełni kwalifikowanej nazwy zasobu ani konfigurować zależności między zasobami. Takie podejście pozwala również uniknąć zbyt dużego zagnieżdżania, co może stać się trudne do odczytania. Należy jednak jawnie określić pełny typ zasobu i wersję interfejsu API za każdym razem, gdy zdefiniujesz zasób podrzędny parent przy użyciu właściwości .

Aby odwołać się do zasobu podrzędnego zadeklarowanego za pomocą parent właściwości, użyj jej symbolicznej nazwy, tak jak w przypadku normalnego zasobu nadrzędnego:

output childResourceId string = installCustomScriptExtension.id

Konstruowanie nazwy zasobu

Istnieją pewne okoliczności, w których nie można używać zasobów zagnieżdżonych ani słowa kluczowego parent . Przykłady obejmują deklarowanie zasobów podrzędnych w for pętli lub konieczność dynamicznego wybierania zasobu nadrzędnego dla elementu podrzędnego za pomocą wyrażeń złożonych. W takich sytuacjach można wdrożyć zasób podrzędny, ręcznie tworząc nazwę zasobu podrzędnego, tak aby zawierała nazwę zasobu nadrzędnego, jak pokazano poniżej:

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

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

Zwróć uwagę, że w tym przykładzie użyto interpolacji ciągów, aby dołączyć właściwość zasobu name maszyny wirtualnej do nazwy zasobu podrzędnego. Bicep rozumie, że istnieje zależność między zasobami podrzędnymi i nadrzędnymi. Zamiast tego można zadeklarować nazwę zasobu podrzędnego przy użyciu zmiennej vmName . Jeśli jednak wdrożenie może zakończyć się niepowodzeniem, ponieważ Bicep nie rozumie, że zasób nadrzędny musi zostać wdrożony przed zasobem podrzędnym:

Aby rozwiązać tę sytuację, możesz ręcznie poinformować Bicep o zależności za pomocą słowa kluczowego dependsOn , jak pokazano poniżej:

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

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

Napiwek

Zazwyczaj najlepiej jest unikać tworzenia nazw zasobów, ponieważ tracisz wiele korzyści, które firma Bicep może zapewnić, gdy rozumie relacje między zasobami. Użyj tej opcji tylko wtedy, gdy nie można użyć jednego z innych metod deklarowania zasobów podrzędnych.

Identyfikatory zasobów podrzędnych

Należy rozpocząć tworzenie identyfikatora zasobu podrzędnego, dołączając identyfikator zasobu nadrzędnego, a następnie dołączając nazwę i typ zasobu podrzędnego. Rozważmy na przykład konto usługi Azure Cosmos DB o nazwie toyrnd. Dostawca zasobów usługi Azure Cosmos DB uwidacznia typ o nazwie databaseAccounts, który jest wdrażanym zasobem nadrzędnym:

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

Oto wizualizacja przedstawiająca ten sam identyfikator zasobu:

Identyfikator zasobu dla konta usługi Azure Cosmos DB podzielony na parę klucz-wartość w osobnym wierszu.

Jeśli dodamy bazę danych do tego konta, możemy użyć typu zasobu podrzędnego sqlDatabases . Dodajmy bazę danych o nazwie FlightTests do konta usługi Azure Cosmos DB i przyjrzyjmy się identyfikatorowi zasobu podrzędnego:

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

Oto wizualna reprezentacja:

Identyfikator zasobu podrzędnego dla bazy danych usługi Azure Cosmos DB podzielony na parę klucz-wartość w osobnym wierszu.

Można mieć wiele poziomów zasobów podrzędnych. Oto przykładowy identyfikator zasobu, który pokazuje konto magazynu z dwoma poziomami podrzędnymi:

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

Oto wizualna reprezentacja tego samego identyfikatora zasobu:

Identyfikator zasobu podrzędnego dla konta magazynu z kontenerem obiektów blob podzielony na parę klucz-wartość w osobnym wierszu.

Ten identyfikator zasobu zawiera kilka składników:

Wszystko, do secrettoys czego należy, to identyfikator zasobu nadrzędnego.
blobServices wskazuje, że zasób znajduje się w obrębie typu zasobu podrzędnego o nazwie blobServices.

Uwaga

Nie musisz samodzielnie tworzyć blobServices zasobów. Dostawca Microsoft.Storage zasobów automatycznie tworzy ten zasób podczas tworzenia konta magazynu. Ten typ zasobu jest czasami nazywany niejawnym zasobem. Są one dość rzadkie, ale znajdziesz je na całej platformie Azure.
default to nazwa zasobu podrzędnego blobServices .

Uwaga

Czasami dozwolone jest tylko jedno wystąpienie zasobu podrzędnego. Ten typ wystąpienia jest nazywany pojedynczym wystąpieniem i często otrzymuje nazwę default.
containers wskazuje, że zasób znajduje się w obrębie typu zasobu podrzędnego o nazwie containers.
glitterspecs to nazwa kontenera obiektów blob.