Incorporación de lógica condicional a las plantillas de ARM

Completado

En algunas condiciones, es posible que tenga que implementar un recurso opcionalmente. Un caso común es agregar un equilibrador de carga en una máquina virtual. Supongamos que tiene un sitio de comercio electrónico y quiere asegurarse de que el sitio puede resistir el aumento del tráfico de una gran venta. Un equilibrador de carga es un tipo de recurso que puede asociar a una máquina virtual. Al agregar una regla condicionalmente, habilita o deshabilita el equilibrador de carga que se aplica a la máquina virtual en cuestión.

Imagine las situaciones siguientes:

  • Recurso ya existente. Cuando especifica un recurso en una plantilla y lo implementa, se da una de estas dos situaciones. El recurso está implementado o no lo está si ya existe. Comprobar si un recurso existe es algo que Azure Resource Manager hace automáticamente; está implícito. La cuestión es si puede usar este mecanismo a su favor cuando piense en cómo puede comprobar la existencia de algo.
  • Lógica de bifurcación. En función de los parámetros que se pasen a una plantilla, es posible que en el momento de la implementación quiera implementar otro conjunto de recursos. Lo que se expresa es algo conocido como lógica de bifurcación. Si el parámetro tiene un tipo de valor determinado, seleccione la primera rama. Si no, seleccione la segunda o la tercera rama para implementarla. La lógica de bifurcación continúa de esta manera.

En las dos situaciones anteriores se representan escenarios en los que se aplica la lógica condicional. La lógica se encuentra en el propio sistema Resource Manager o es algo que tiene que expresar explícitamente.

Implementación condicional

La construcción condition le permite expresar si quiere que algo se implemente o no. Es una propiedad, con un valor true o false, que se incluye junto con un elemento de recurso. Normalmente, se busca una construcción condition que se parezca al siguiente JSON en la plantilla:

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

En el código JSON anterior, se agrega una propiedad condition a un recurso. El valor de la propiedad se evaluará como el valor del parámetro shouldDeploy.

Evaluación

Hay dos maneras en las que se puede evaluar la construcción condition. Conocer estas dos maneras podría afectar a la forma de expresar la lógica condicional. Las dos maneras diferentes son:

  • El valor es true/false. Considere la siguiente construcción, por ejemplo:

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

    El valor deployAccount es un parámetro cuyo valor se puede pasar en el momento de la implementación o se puede revertir al valor predeterminado. Independientemente del método utilizado, el valor es estrictamente false o true. Si intenta asignar otro valor que no sea booleano, se producirá un error.

  • Hay una expresión que se evalúa como true/false. Aquí, en lugar de asignar un valor estricto true/false a la construcción condition, se usa la función de plantilla integrada equals(arg1, arg2). arg1 debe ser igual a arg2 para que la función se evalúe como true. Ahora, la construcción condition puede expresarse de la siguiente manera:

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

    Con la función equals(), el valor que se pase a un parámetro ya no tiene que ser true o false. Debe coincidir con el segundo argumento de la función equals(). En el ejemplo JSON anterior, el valor del parámetro newOrExisting debe coincidir con la cadena new para que la función se evalúe como true.