Control del orden de implementación mediante la especificación de dependencias

  • 3 minutos

Supongamos que quiere implementar un conjunto de recursos en Azure, pero solo si ya se ha implementado otro recurso. Llegados este punto, debe comunicar en la plantilla que un recurso depende de otro.

Estos son algunos aspectos que se deben tener en cuenta:

  • Debe existir algo antes de que se pueda implementar otra cosa

    Por ejemplo, suponga que necesita un almacén de claves para capturar los secretos que se deben cargar en una máquina virtual. Al implementar ese almacén de claves, puede implementar al mismo tiempo su secreto correspondiente dentro de la misma plantilla. A pesar de esto, el almacén de claves se debe implementar antes que su secreto. Por lo tanto, el secreto depende del almacén de claves para existir. El almacén de claves y el secreto se implementan en serie, uno después de otro, empezando por el almacén de claves (debido a la dependencia).

  • ¿Puedo fiarme de cómo funcionan las cosas en Azure Resource Manager?

    Su primera reacción al comprobar si existe otro recurso podría ser usar Azure PowerShell o la CLI de Azure para ello. Una solución más automatizada sería la idempotencia integrada de Resource Manager. Si Resource Manager encuentra un recurso definido en una plantilla que ya existe en la nube, no lo vuelve a implementar. Para que este enfoque sea válido, debe entender cómo Resource Manager realiza la comprobación.

    Nota:

    Cuando las identidades de recursos existentes coinciden con algo definido en una plantilla, Azure Resource Manager compara las propiedades. Si coinciden exactamente, el recurso se deja a tal cual; si no, el motor realiza los cambios, con la posibilidad de volver a implementar el recurso.

  • Se pueden anidar recursos dentro de otro recurso

    En las plantillas de Azure Resource Manager se pueden anidar recursos dentro de otro recurso. Al anidar recursos, se define una relación entre los recursos anidados y el recurso principal.

¿Cómo puedo definir dependencias entre recursos de Azure?

Imagine que quiere asegurarse de que un recurso (por ejemplo, una cuenta de almacenamiento) se ha implementado antes que un recurso que lo necesite. ¿Cómo puede comprobar si existe la cuenta de almacenamiento dependiente?

Para empezar, puede inspeccionar el estado actual de la implementación mediante la ejecución de comandos de Azure PowerShell o la CLI de Azure para comprobar la existencia de la cuenta de almacenamiento. También puede ver si hay una construcción de Resource Manager que le permita realizar la misma comprobación.

Existe una construcción de este tipo en las plantillas de Resource Manager denominada dependsOn. El uso de esta construcción hace que los recursos esperen a que finalice la implementación del recurso señalado.

¿Qué es la construcción dependsOn?

Es un par clave-valor que permite definir el orden de implementación entre recursos. A veces es necesario asegurarse de que existe algo antes que otra cosa. Por ejemplo, podría ser necesario que exista una base de datos antes de una aplicación, o que exista un recurso secreto antes de un almacén de claves.

Coloque la construcción dependsOn en un recurso que dependa de otros recursos que se van a implementar en primer lugar. Un recurso puede depender de más de un recurso, por lo que la construcción espera una lista de recursos dependientes como valor.

En el siguiente ejemplo se muestra cómo se puede expresar una dependencia de este tipo en JSON dentro de la plantilla de ARM:

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

En este ejemplo se usa el nombre del recurso para especificar el recurso del que depende. A pesar de esto, muchos recursos pueden tener el mismo nombre. Para tener la seguridad de que esta comparación hace lo que desea, puede usar en su lugar la construcción resourceId() para obtener el identificador de recurso único:

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

El código JSON anterior crea un identificador único mediante la combinación del espacio de nombres, el tipo y un nombre de variable. De este modo, tendrá la seguridad de que se especifica el recurso dependiente correcto.

¿Qué son los recursos secundarios?

Un recurso secundario es un recurso que solo existe en el contexto de otro recurso. Un ejemplo de esto es una extensión de máquina virtual, que no puede existir sin una máquina virtual.

Un código típico de una relación principal-secundario en una plantilla tiene el siguiente aspecto:

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

Esta dependencia principal-secundario no crea automáticamente una dependencia en la que el elemento principal se implementa antes que su elemento secundario. Debe hacer que la dependencia sea explícita.

Por lo tanto, al expresar una relación de este tipo, asegúrese de agregar una construcción dependsOn como la siguiente:

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