Incorporación de lógica condicional a las plantillas de ARM
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 integradaequals(arg1, arg2)
.arg1
debe ser igual aarg2
para que la función se evalúe como true. Ahora, la construccióncondition
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 sertrue
ofalse
. Debe coincidir con el segundo argumento de la funciónequals()
. En el ejemplo JSON anterior, el valor del parámetronewOrExisting
debe coincidir con la cadenanew
para que la función se evalúe comotrue
.