¿Qué es Azure Resource Manager?

Azure Resource Manager es el servicio de implementación y administración para Azure. Proporciona una capa de administración que le permite crear, actualizar y eliminar recursos de la cuenta de Azure. Se usan las características de administración, como el control de acceso, la auditoría y las etiquetas, para proteger y organizar los recursos después de la implementación.

Para obtener más información sobre las plantillas de Azure Resource Manager (plantillas de ARM), consulte Información general sobre las plantillas de ARM. Para obtener más información sobre Bicep, consulte Introducción a Bicep.

En el vídeo siguiente se describen los conceptos básicos de Azure Resource Manager.

Capa de administración coherente

Cuando envía una solicitud con cualquiera de las API, las herramientas o los SDK de Azure, Resource Manager recibe la solicitud. Autentica y autoriza la solicitud antes de reenviarla al servicio de Azure adecuado. Dado que todas las solicitudes se controlan mediante la misma API, verá resultados y funcionalidades coherentes en todas las distintas herramientas.

En la imagen siguiente se muestra el rol que Azure Resource Manager desempeña en el control de solicitudes de Azure.

Todas las funcionalidades que están disponibles en el portal también lo están con Azure PowerShell, la CLI de Azure, las API REST y los SDK de cliente. Las funcionalidades disponibles originalmente mediante las API se incluyen en el portal a los 180 días de su lanzamiento inicial.

Terminología

Si no conoce Azure Resource Manager, estos son algunos términos con los que puede no estar familiarizado.

• recurso: elemento administrable que está disponible a través de Azure. Las máquinas virtuales, cuentas de almacenamiento, aplicaciones web, bases de datos y redes virtuales son ejemplos de recursos. Los grupos de recursos, las suscripciones, los grupos de administración y las etiquetas también son ejemplos de recursos.
• grupo de recursos: contenedor que almacena los recursos relacionados con una solución de Azure. El grupo de recursos incluye los recursos que se desean administrar como grupo. Decida qué recursos pertenecen a un grupo de recursos según lo que más convenga a su organización. Consulte ¿Qué es un grupo de recursos?.
• proveedor de recursos: un servicio que proporciona recursos de Azure. Por ejemplo, un proveedor de recursos común es Microsoft.Compute, que proporciona el recurso de máquina virtual. Microsoft.Storage es otro proveedor de recursos común. Consulte Tipos y proveedores de recursos.
• Sintaxis declarativa: Sintaxis que permite establecer lo que pretende crear sin tener que escribir la secuencia de comandos de programación para crearla. Las plantillas de ARM y los archivos de Bicep son ejemplos de sintaxis declarativa. En esos archivos, puede definir las propiedades de la infraestructura que se va a implementar en Azure.
• Plantilla de ARM: Archivo de notación de objetos JavaScript (JSON) que define uno o más recursos para implementar en un grupo de recursos, una suscripción, un grupo de administración o un inquilino. La plantilla se puede usar para implementar los recursos de manera repetida y uniforme. Consulte Información general de la implementación de plantillas.
• Archivo de Bicep: Archivo para implementar mediante declaración los recursos de Azure. Bicep es un lenguaje diseñado para proporcionar la mejor experiencia de creación de soluciones de infraestructura como código en Azure. Consulte la Introducción a Bicep.
• Recurso de extensión: un recurso que se agrega a las capacidades de otro recurso. Por ejemplo, una asignación de roles es un recurso de extensión. Se aplica una asignación de roles a cualquier otro recurso para especificar el acceso. Consulte Recursos de extensión.

Para más definiciones de terminología de Azure, consulte Conceptos básicos de Azure.

Ventajas de usar Administrador de recursos

Con Resource Manager puede:

• Administrar la infraestructura mediante plantillas declarativas en lugar de scripts.

• Implementar, administrar y supervisar todos los recursos de la solución en grupo, en lugar de controlarlos individualmente.

• Volver a implementar la solución repetidamente a lo largo del ciclo de vida del desarrollo y tener la seguridad de que los recursos se implementan de forma coherente.

• Definir las dependencias entre recursos de modo que se implementen en el orden correcto.

• Aplicar control de acceso a todos los servicios porque el Control de acceso basado en rol (RBAC) se integra de forma nativa en la plataforma de administración.

• Aplicar etiquetas a los recursos para organizar de manera lógica todos los recursos de la suscripción.

• Aclarar la facturación de su organización viendo los costos de un grupo de recursos que compartan la misma etiqueta.

Descripción del ámbito

Azure proporciona cuatro niveles de ámbito administración: grupos de administración, suscripciones, grupos de recursos y recursos. En la imagen siguiente se muestra un ejemplo de estos niveles:

Aplicará la configuración de administración en cualquiera de estos niveles de ámbito. El nivel que seleccione determina el grado de amplitud con que se aplica la configuración. Los niveles inferiores heredan la configuración de los niveles superiores. Por ejemplo, al aplicar una directiva a la suscripción, esta se aplica a todos los grupos de recursos y recursos de la suscripción. Al aplicar una directiva al grupo de recursos, esta también se aplica al grupo de recursos y a todos sus recursos. Sin embargo, otro grupo de recursos no tiene la asignación de dicha directiva.

Para obtener información sobre cómo administrar identidades y acceso, vea Microsoft Entra ID.

Puede implementar plantillas en inquilinos, grupos de administración, suscripciones o grupos de recursos.

¿Qué es un grupo de recursos?

Un grupo de recursos es un contenedor que permite administrar recursos relacionados para una solución de Azure. Mediante el grupo de recursos, puede coordinar los cambios en los recursos relacionados. Por ejemplo, puede implementar una actualización en el grupo de recursos y tener confianza en que los recursos se actualizan en una operación coordinada. O bien, cuando haya terminado con la solución, puede eliminar el grupo de recursos y saber que se eliminan todos los recursos.

Hay algunos factores importantes que se deben tener en cuenta al definir el grupo de recursos:

• Todos los recursos del grupo de recursos deben compartir el mismo ciclo de vida. Se implementan, actualizan y eliminan de forma conjunta. Si un recurso, como un servidor, debe existir en un ciclo de implementación diferente, debe estar en otro grupo de recursos.

• Cada recurso solo puede existir en un grupo de recursos.

• Puede agregar o quitar un recurso de un grupo de recursos en cualquier momento.

• Puede mover un recurso de un grupo de recursos a otro. Para obtener más información, consulte Traslado de los recursos a un nuevo grupo de recursos o a una nueva suscripción.

• Los recursos de un grupo de recursos pueden encontrarse en regiones distintas a las del grupo de recursos.

• Al crear un grupo de recursos, es preciso proporcionar una ubicación para ese grupo de recursos.

  Pero puede preguntarse: "¿Por qué necesita un grupo de recursos una ubicación? Y si los recursos pueden tener ubicaciones distintas de las del grupo de recursos, ¿por qué es importante la ubicación de este?"

  Los grupos de recursos almacenan metadatos acerca de los recursos. Al especificar la ubicación del grupo de recursos, se especifica el lugar en que dichos metadatos se almacenan. Por motivos de compatibilidad, es posible que sea preciso asegurarse de que los datos se almacenan en una región concreta.

  Para garantizar la coherencia del estado del grupo de recursos, todas las operaciones del plano de control se enrutarán a través de la ubicación del grupo de recursos. Al seleccionar una ubicación de grupo de recursos, se recomienda seleccionar una ubicación cercana a donde se originen las operaciones de control. Normalmente, esta ubicación es la más cercana a la ubicación actual. Este requisito de enrutamiento solo se aplica a las operaciones del plano de control para el grupo de recursos. No afecta a las solicitudes que se envían a las aplicaciones.

  Si la región de un grupo de recursos no está disponible temporalmente, es posible que no pueda actualizar sus recursos, ya que los metadatos tampoco estarán disponibles. Los recursos de otras regiones siguen funcionando como cabría esperar, pero no podrá actualizarlos. Esta condición también se puede aplicar a recursos globales, como Azure DNS, Azure DNS Private Zones, Azure Traffic Manager y Azure Front Door. Puede ver cuales son los tipos cuyos metadatos administra Azure Resource Manager en la lista de tipos de la tablade recursos de Azure Resource Graph.

  Para más información sobre la creación de aplicaciones confiables, consulte Diseño de aplicaciones de Azure confiables.

• Un grupo de recursos puede utilizarse para definir el ámbito de control de acceso para las acciones administrativas. Para administrar un grupo de recursos, se pueden asignar directivas de Azure, roles de Azure o bloqueos de recursos.

• También, se pueden aplicar etiquetas a un grupo de recursos. Los recursos del grupo de recursos no heredan esas etiquetas.

• Un recurso puede conectarse a los recursos de otros grupos de recursos. Este escenario suele darse cuando los dos recursos están relacionados, pero no comparten el mismo ciclo de vida. Por ejemplo, puede tener una aplicación web que se conecta a una base de datos de un grupo de recursos diferente.

• Al eliminar un grupo de recursos, también se eliminan todos los recursos que contiene. Para información sobre cómo Azure Resource Manager organiza esas eliminaciones, consulte Eliminación de grupos de recursos y recursos en Azure Resource Manager.

• Se pueden implementar hasta 800 instancias de un tipo de recurso en cada grupo de recursos. Algunos tipos de recursos están exentos del límite de 800 instancias. Para más información, consulte Límites del grupo de recursos.

• Algunos recursos pueden existir fuera de un grupo de recursos. Estos recursos se implementan en la suscripción, el grupo de administración o el inquilino. En estos ámbitos solo se admiten tipos de recursos específicos.

• Para crear un grupo de recursos, puede usar el portal, PowerShell, la CLI de Azure o una plantilla de Resource Manager.

Resistencia de Azure Resource Manager

El servicio Azure Resource Manager está diseñado para proporcionar resistencia y disponibilidad continua. Las operaciones de Resource Manager y del plano de control (solicitudes enviadas a management.azure.com) en la API REST:

• Se distribuyen entre regiones. Azure Resource Manager tiene una instancia independiente en cada región de Azure, por lo que un error de la instancia de Azure Resource Manager en una región no afecta a la disponibilidad de Azure Resource Manager u otros servicios de Azure en otra región. Aunque Azure Resource Manager se distribuye entre regiones, algunos servicios son regionales. Esta distinción significa que, aunque el control inicial de la operación del plano de control es resistente, la solicitud puede ser susceptible a interrupciones regionales cuando se reenvía al servicio.

• Se distribuyen entre las zonas de disponibilidad (y regiones) en aquellas ubicaciones que tienen varias zonas de disponibilidad. Esta distribución garantiza que, cuando una región pierde una o varias zonas, Azure Resource Manager puede conmutar por error a otra zona o a otra región para seguir proporcionando funcionalidad del plano de control para los recursos.

• No dependen de un solo centro de datos lógicos.

• Nunca se interrumpen debido a actividades de mantenimiento.

Esta resistencia se aplica a los servicios que reciben las solicitudes a través de Resource Manager. Por ejemplo, Key Vault se beneficia de esta resistencia.

Alineación de la ubicación del grupo de recursos

Para reducir el impacto de las interrupciones regionales, se recomienda localizar recursos en la misma región que el grupo de recursos.

La ubicación del grupo de recursos es donde Azure Resource Manager almacena los metadatos de los recursos del grupo de recursos. Azure Resource Manager usa esta ubicación para el enrutamiento y el almacenamiento en caché. Por ejemplo, al enumerar los recursos en los ámbitos de suscripción o grupo de recursos, Azure Resource Manager obtiene la información de la memoria caché.

Si la región del grupo de recursos no está disponible, Azure Resource Manager no puede actualizar los metadatos del recurso y bloquea las llamadas de escritura. Al colocar el recurso y la región del grupo de recursos, se reduce el riesgo de que la región no esté disponible porque los recursos y metadatos existen en una región en lugar de en varias regiones.

Resolución de operaciones simultáneas

Cuando dos o más operaciones intentan actualizar el mismo recurso al mismo tiempo, Azure Resource Manager detecta el conflicto y solo permite que una operación se complete correctamente. Azure Resource Manager bloquea las demás operaciones y devuelve un error.

La actualización simultánea de recursos pueden provocar resultados inesperados. Esta resolución garantiza que las actualizaciones sean deterministas y confiables. Conoce el estado de los recursos y evita cualquier incoherencia o pérdida de datos.

Supongamos que tiene dos solicitudes (A y B) que intentan actualizar el mismo recurso al mismo tiempo. Si la solicitud A finaliza antes de la solicitud B, la solicitud A se realiza correctamente y se produce un error en la solicitud B. La solicitud B devuelve el error 409. Después de obtener ese código de error, puede obtener el estado actualizado del recurso y determinar si desea volver a enviar la solicitud B.

Pasos siguientes

• Para más información sobre los límites que se aplican a los servicios de Azure, consulte Límites, cuotas y restricciones de suscripción y servicios de Microsoft Azure.

• Para más información sobre cómo mover recursos, consulte Traslado de los recursos a un nuevo grupo de recursos o a una nueva suscripción.

• Para información sobre el etiquetado de recursos, consulte Uso de etiquetas para organizar los recursos.

• Para más información sobre el bloqueo de recursos, consulte Bloqueo de recursos para impedir cambios inesperados.