Lägga till logik för villkorsstyrning i ARM-mallar

  • 3 minuter

Du kan behöva distribuera en resurs också, under vissa förhållanden. Ett vanligt fall är att lägga till en lastbalanserare för en virtuell dator. Anta att du har en e-handelswebbplats och att du vill se till att webbplatsen ska kunna hantera ökad trafik under en stor rea. En lastbalanserare är en sorts resurs som du kan associera med en virtuell dator. Genom att lägga till en villkorsstyrd regel kan du antingen aktivera eller inaktivera lastbalanseraren som läggs till för den virtuella datorn.

Tänk dig följande situationer:

  • Befintlig resurs. När du anger en resurs i en mall och distribuerar den sker en av två saker. Antingen distribueras resursen, men om den redan finns så distribueras den inte om. Azure Resource Manager kontrollerar om resursen finns åt dig, det sker implicit. Frågan är om du kan använda den här mekanismen när du funderar på hur du kan kontrollera om någonting finns.
  • Förgreningslogik. Du kanske vill distribuera olika uppsättningar resurser beroende på vilka parametrar du skickar till en mall under distributionen. Det du uttrycker kallas för förgreningslogik. Om parametern har en viss typ av värde väljer du den första grenen. Annars väljer du den andra eller tredje grenen som ska distribueras. Förgreningslogiken fortsätter på det här sättet.

Båda situationerna ovan representerar scenarier där logik för villkorsstyrning används. Logiken ligger antingen i själva Resource Manager-systemet eller så är det något du behöver uttrycka själv.

Villkorlig distribution

Med konstruktionen condition kan du ange om du vill ha något distribuerat eller inte. Det är en egenskap, antingen med värdet true eller false, som du kopplar till ett resurselement. Du hittar vanligtvis en condition konstruktion som ser ut som följande JSON i mallen:

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

I ovanstående JSON läggs en condition-egenskap till i en resurs. Värdet för egenskapen utvärderas till värdet för parametern shouldDeploy.

Utvärdering

Det finns två sätt på vilka konstruktionen condition kan utvärderas. Om du vet lite mer om de här två sätten kan du välja hur du uttrycker logiken för villkorsstyrning. Här är de två olika sätten:

  • Värdet är antingen true/false. Ta följande konstruktion som exempel:

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

    deployAccount-värdet är en parameter vars värde kan skickas under distributionen, eller så kan standardvärdet användas. Oavsett vilken metod som används är värdet antingen false eller true. Om du försöker tilldela ett värde som inte är booleskt leder till ett fel.

  • Det finns ett uttryck som utvärderas till true/false. Här, i stället för att du tilldelar ett strikt true/false-värde till condition-konstruktionen använder du den inbyggda mallfunktionen equals(arg1, arg2). arg1 måste vara lika med arg2 för att funktionen ska utvärderas till true. Nu kan du uttrycka din condition-konstruktion så här:

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

    Med hjälp av funktionen equals() behöver inte längre det värde som du skickar till en parameter vara true eller false. Den måste matcha det andra argumentet i equals()-funktionen. I föregående JSON-exempel måste värdet för parametern newOrExisting matcha strängen new för att funktionen ska utvärderas till true.