Controllare l'ordine di distribuzione specificando le dipendenze

• 3 minuti

Si supponga di voler distribuire un set di risorse in Azure, ma solo se è già stata distribuita un'altra risorsa. A questo punto è necessario comunicare nel modello che una risorsa dipende da un'altra risorsa.

Questi sono alcuni aspetti da considerare:

• È necessario che esista qualcosa prima di poter distribuire qualcos'altro.

  Ad esempio, supponiamo che sia necessario un insieme di credenziali delle chiavi in Azure Key Vault per poter recuperare i segreti da caricare in una macchina virtuale. Quando si distribuisce l'insieme di credenziali delle chiavi, è possibile distribuirne contemporaneamente il segreto nello stesso modello. Tuttavia, l'insieme di credenziali delle chiavi deve essere distribuito prima del relativo segreto. Il segreto dipende quindi dall'esistenza dell'insieme di credenziali delle chiavi. L'insieme di credenziali delle chiavi e il segreto vengono distribuiti in sequenza, uno dopo l'altro, iniziando dall'insieme di credenziali delle chiavi, a causa della dipendenza.

• È possibile fare affidamento su come funzionano le cose in Azure Resource Manager?

  Per verificare se esiste un'altra risorsa, subito si potrebbe pensare di usare Azure PowerShell o l'interfaccia della riga di comando di Azure per effettuare la verifica. Una soluzione più automatizzata usa l'idempotenza predefinita di Resource Manager. Se Resource Manager individua una risorsa definita in un modello che esiste già nel cloud, non la ridistribuisce. Perché questo approccio sia valido, è necessario comprendere in che modo Resource Manager effettua il controllo.

  Nota

  Quando le identità delle risorse esistenti corrispondono a caratteristiche definite in un modello, Azure Resource Manager confronta le proprietà. Se le proprietà corrispondono esattamente, la risorsa viene lasciata invariata. In caso contrario, il motore apporta le modifiche e, se possibile, ridistribuisce la risorsa.

• È possibile annidare le risorse all'interno di un'altra risorsa.

  Nei modelli di Azure Resource Manager è possibile annidare le risorse all'interno di un'altra risorsa. Annidando le risorse, si definisce una relazione tra le risorse annidate e la risorsa padre.

Come si definiscono le dipendenze tra risorse di Azure?

Si supponga di voler verificare che una risorsa, ad esempio un account di archiviazione, sia stata distribuita prima di una risorsa che la richiede. Come è possibile controllare se l'account di archiviazione dipendente esiste?

È possibile iniziare esaminando lo stato corrente della distribuzione eseguendo Azure PowerShell o i comandi dell'interfaccia della riga di comando di Azure per verificare l'esistenza dell'account di archiviazione. È anche possibile verificare se esiste un costrutto di Resource Manager che consente di effettuare lo stesso controllo.

In Resource Manager è presente un costrutto di questo tipo, denominato dependsOn. L'uso di questo costrutto mette le risorse in attesa fino al completamento della distribuzione della risorsa indicata.

Che cos'è il costrutto dependsOn?

È una coppia chiave-valore che consente di definire l'ordine di distribuzione tra le risorse. In alcuni casi è necessario assicurarsi che esista qualcosa prima di qualcos'altro. Ad esempio, potrebbe essere necessario un database prima di un'app o una risorsa secreto prima di un insieme di credenziali delle chiavi.

Posizionare il costrutto dependsOn in una risorsa che dipende da altre risorse da distribuire per prime. Una risorsa può dipendere da più di una risorsa, per questo motivo il costrutto prevede un elenco di risorse dipendenti come valore.

L'esempio seguente mostra come può essere espressa tale dipendenza in JSON nel modello di ARM:

"resources": [
  {
    "name": "<name of resource that needs to exist first>"
  },
  {
    "name": "someResource",
    "dependsOn": [
      "<name of resource that needs to exist first>"
    ]
  }
]

In questo esempio si usa il nome della risorsa per specificare da quale risorsa si dipende. Tuttavia, molte risorse potrebbero avere lo stesso nome. Per assicurarsi che il confronto avvenga in modo corretto, è possibile usare il costrutto resourceId() per ottenere l'identificatore univoco della risorsa:

"dependsOn": [
  "resourceId('Microsoft.Network/loadBalancers', variables('nameOfLoadBalancer')))"
]

Il codice JSON precedente costruisce un ID univoco combinando lo spazio dei nomi, il tipo e il nome di una variabile. In questo modo, si garantisce che venga specificata la risorsa dipendente corretta.

Che cosa sono le risorse figlio?

Una risorsa figlio è una risorsa che esiste solo nel contesto di un'altra risorsa. Un esempio di risorsa di questo tipo è un'estensione di macchina virtuale, che non può esistere senza una macchina virtuale.

Il codice tipico per una relazione padre-figlio in un modello è simile al seguente:

"resources": [
  {
    "name": "parent-resource",
    "resources": [{
      "name": "child-resource"
    }]
  }
]

Questa dipendenza padre-figlio non crea automaticamente una dipendenza in cui l'elemento padre viene distribuito prima del relativo figlio. È necessario rendere esplicita la dipendenza.

Pertanto, quando si esprime una relazione di questo tipo, assicurarsi di aggiungere un dependsOn costrutto, come illustrato di seguito:

"resources": [
  {
    "name": "parent-resource",
    "resources": [{
      "dependsOn": ["parent-resource"],
      "name": "child resource"
    }]
  }
]