Adicionar a lógica condicional aos modelos do ARM

Concluído

Talvez seja necessário implementar um recurso opcionalmente, em determinadas condições. Um caso comum é a adição de um balanceador de carga numa VM. Vamos supor que tem um site de comércio eletrónico e quer garantir que o mesmo consegue resistir ao aumento do tráfego de uma grande promoção. Um balanceador de carga é um tipo de recurso que pode associar a uma VM. Ao adicionar uma regra condicionalmente, ativa ou desativa o balanceador de carga que está a ser aplicado à VM em questão.

Imagine as seguintes situações:

• Recurso pré-existente. Quando especifica um recurso num modelo e o implementa, podem acontecer duas coisas. O recurso é implementado ou não será implementado se já existir. Verificar se um recurso existe é algo que o Azure Resource Manager faz; está implícito. A pergunta é se consegue tirar partido deste mecanismo para benefício próprio quando pondera sobre como pode verificar a pré-existência de algo.
• Lógica de ramificação. Dependendo dos parâmetros que transmite a um modelo, no momento da implementação, talvez queira implementar um conjunto de recursos diferente. O que está a expressar é algo conhecido como a lógica de ramificação. Se o parâmetro tiver um determinado tipo de valor, selecione o primeiro ramo. Caso contrário, selecione o segundo ou terceiro ramo a ser implementado. A lógica de ramificação continua desta forma.

Ambas as situações acima representam cenários em que a lógica condicional está a ser aplicada. A lógica está no próprio sistema do Resource Manager ou é algo que precisa de expressar explicitamente.

Implementação condicional

A condition construção permite que você expresse se deseja que algo seja implantado ou não. É uma propriedade com um valor de true ou false que anexa a um elemento de recurso. Normalmente, você encontraria uma condition construção parecida com o seguinte JSON em seu modelo:

"resources" : [
  {
    "condition": "[parameters('shouldDeploy')]"
  }
]

No JSON acima, é adicionada uma propriedade condition a um recurso. O valor da propriedade será avaliado como o valor do parâmetro shouldDeploy.

Avaliação

Há duas maneiras pelas quais o constructo condition pode ser avaliado. Conhecer estas duas formas pode afetar a forma como opta por expressar a lógica condicional. As duas formas diferentes são:

• O valor é true ou false. Por exemplo, considere a seguinte construção:

  "condition": "[parameters('deployAccount')]"
  

  O valor deployAccount é um parâmetro cujo valor pode ser transmitido no momento da implementação ou pode voltar ao valor predefinido. Independentemente da abordagem utilizada, o valor é false ou true. A tentativa de atribuir outro valor que não seja um Booleano resultará num erro.

• Há uma expressão que avalia como true/false. Neste caso, em vez de atribuir um valor true/false rigoroso à construção condition, utiliza a função do modelo incorporado equals(arg1, arg2). arg1 precisa de ser igual a arg2 para que a função seja avaliada como true. A construção condition pode agora ser expressa da seguinte forma:

  "condition": "[equals(parameters('newOrExisting'),'new')]"
  

  Se utilizar a função equals(), o valor que transmite para um parâmetro já não precisa de ser true ou false. Tem de corresponder ao segundo argumento na função equals(). No exemplo de JSON anterior, o valor do parâmetro newOrExisting precisa de corresponder à cadeia new para a função ser avaliada como true.