Controlar a ordem de implementação ao especificar dependências

  • 3 minutos

Vamos supor que quer implementar um conjunto de recursos no Azure, mas apenas se outro recurso já estiver implementado. Neste ponto, vai precisar de comunicar no modelo que um recurso depende de outro.

Veja a seguir alguns aspetos a considerar:

  • Deve existir alguma coisa para poder implementar outra coisa.

    Por exemplo, imagine que precisa de um cofre de chaves no Azure Key Vault para obter os segredos de que precisa para carregar numa máquina virtual (VM). Ao implementar o cofre de chaves, pode, ao mesmo tempo, implementar o segredo no mesmo modelo. No entanto, o cofre de chaves deve ser implementado antes do segredo. Portanto, o segredo depende do cofre de chaves para existir. O cofre de chaves e o segredo são implementados em série, um após o outro, a começar pelo cofre de chaves, devido à dependência.

  • Posso confiar na forma como as coisas funcionam no Azure Resource Manager?

    O primeiro aspeto a considerar ao verificar se existe outro recurso poderá ser a utilização do Azure PowerShell ou da CLI do Azure para verificar se um recursos existe. Uma solução mais automatizada utiliza a idempotência incorporada do Resource Manager. Se o Resource Manager detetar um recurso definido num modelo que já existe na cloud, não o implementará novamente. Para que esta seja uma abordagem válida, deve compreender como o Resource Manager faz a verificação.

    Nota

    Quando as identidades de recursos existentes correspondem a algo definido num modelo, o Azure Resource Manager compara as propriedades. Se as propriedades tiverem uma correspondência exata, o recurso não é alterado. Se não tiverem, o motor faz as alterações, possivelmente, ao implementar novamente o recurso.

  • Pode aninhar recursos dentro de outro recurso.

    Nos modelos do Azure Resource Manager, pode aninhar recursos dentro de outro recurso. Ao aninhar os recursos, define uma relação entre os recursos aninhados e o recurso principal.

Como posso definir dependências entre os recursos do Azure?

Imagine que pretende garantir que um recurso (por exemplo, uma conta de armazenamento) foi implementado antes de um recurso do qual depende. Como pode verificar se uma conta de armazenamento dependente existe?

Pode começar por inspecionar o estado atual da implementação ao executar os comandos do Azure PowerShell ou da CLI do Azure para verificar a existência da conta de armazenamento. Pode também ver se existe uma construção do Resource Manager que lhe permite fazer a mesma verificação.

Existe uma construção nos modelos do Resource Manager chamada dependsOn. A utilização desta construção faz com que os recursos aguardem até que a implementação do recurso indicado termine.

O que é a construção dependsOn?

É um par chave-valor que lhe permite definir a ordem de implementação entre os recursos. Por vezes, é preciso garantir que um recurso existe antes de outro. Por exemplo, pode precisar que exista uma base de dados antes da aplicação ou que exista um recurso secreto antes de um cofre de chaves.

Coloque a construção dependsOn num recurso que dependa de outros recursos que devem ser implementados primeiro. Um recurso pode depender de mais de um recurso, motivo pelo qual a construção espera uma lista de recursos dependentes como valor.

O exemplo seguinte demonstra como pode expressar esse tipo de dependência no JSON dentro do modelo do ARM:

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

Neste exemplo, está a utilizar o nome do recurso para especificar qual o recurso do qual depende. No entanto, muitos recursos podem ter o mesmo nome. Para garantir que esta comparação faz o que é pretendido, pode utilizar a construção resourceId() para obter o identificador exclusivo do recurso:

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

O código JSON acima cria um ID exclusivo ao combinar o espaço de nomes, o tipo e um nome de variável. Desta forma, garante que o recurso dependente correto está especificado.

O que são os recursos subordinados?

Um recurso subordinado é um recurso que existe apenas dentro do contexto de outro recurso. Um exemplo de tal é uma extensão de máquina virtual, que não pode existir sem uma máquina virtual.

Um código típico para uma relação principal-subordinado num modelo terá o seguinte aspeto:

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

Esta dependência principal-subordinado não cria automaticamente uma dependência na qual o elemento principal é implementado antes do subordinado. Deve tornar a dependência explícita.

Portanto, quando você expressar tal relação, certifique-se de adicionar uma dependsOn construção, como a seguinte:

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