O que é o Azure Resource Manager?

  • Artigo

O Azure Resource Manager é o serviço de implementação e gestão do Azure. Fornece uma camada de gestão que lhe permite criar, atualizar e eliminar recursos na sua conta do Azure. Pode utilizar funcionalidades de gestão, como controlo de acesso, bloqueios e etiquetas, para proteger e organizar os seus recursos após a implementação.

Para saber mais sobre os modelos do Azure Resource Manager (modelos arm), veja a Descrição geral do modelo do ARM. Para saber mais sobre o Bicep, veja Descrição geral do Bicep.

Camada de gestão consistente

Quando envia um pedido através de qualquer uma das APIs, ferramentas ou SDKs do Azure, Resource Manager recebe o pedido. Autentica e autoriza o pedido antes de o reencaminhar para o serviço do Azure adequado. Uma vez que todos os pedidos são processados pela mesma API, vê resultados e capacidades consistentes em todas as ferramentas.

A imagem seguinte mostra a função do Azure Resource Manager no processamento de pedidos do Azure.

Diagrama que mostra a função do Azure Resource Manager no processamento de pedidos do Azure.

Todas as capacidades disponíveis no portal estão também disponíveis no PowerShell, CLI do Azure, APIs REST e SDKs de cliente. A funcionalidade inicialmente lançada através de APIs será representada no portal dentro de 180 dias do lançamento inicial.

Importante

O Azure Resource Manager só suportará o Transport Layer Security (TLS) 1.2 ou posterior até ao outono de 2023. Para obter mais informações, veja Migrating to TLS 1.2 for Azure Resource Manager (Migrar para o TLS 1.2 para o Azure Resource Manager).

Terminologia

Se é a primeira vez que utiliza o Azure Resource Manager, existem alguns termos com os quais poderá não estar familiarizado.

  • resource - Um item gerível que está disponível através do Azure. Máquinas virtuais, contas de armazenamento, aplicações Web, bases de dados e redes virtuais são exemplos de recursos. Os grupos de recursos, as subscrições, os grupos de gestão e as etiquetas também são exemplos de recursos.
  • grupo de recursos – um contentor que contém recursos relacionados para uma solução do Azure. O grupo de recursos inclui os recursos que pretende gerir como um grupo. Decide que recursos pertencem a um grupo de recursos com base no que faz mais sentido para a sua organização. Veja Grupos de recursos.
  • fornecedor de recursos – um serviço que fornece recursos do Azure. Por exemplo, um fornecedor de recursos comum é Microsoft.Compute, que fornece o recurso da máquina virtual. Microsoft.Storage é outro fornecedor de recursos comum. Veja Fornecedores e tipos de recursos.
  • sintaxe declarativa - Sintaxe que lhe permite indicar "Eis o que pretendo criar" sem ter de escrever a sequência de comandos de programação para criá-la. Os modelos arm e os ficheiros Bicep são exemplos de sintaxe declarativa. Nesses ficheiros, define as propriedades da infraestrutura a implementar no Azure.
  • Modelo do ARM – um ficheiro JavaScript Object Notation (JSON) que define um ou mais recursos para implementar num grupo de recursos, subscrição, grupo de gestão ou inquilino. O modelo pode ser utilizado para implementar os recursos de forma consistente e repetida. Veja Descrição geral da implementação de modelos.
  • Ficheiro Bicep – um ficheiro para implementar declarativamente recursos do Azure. O Bicep é uma linguagem que foi concebida para proporcionar a melhor experiência de criação para a infraestrutura como soluções de código no Azure. Veja Descrição geral do Bicep.

Para obter mais definições de terminologia do Azure, veja Conceitos fundamentais do Azure.

Vantagens da utilização do Resource Manager

Com o Resource Manager, pode:

  • Gerir a sua infraestrutura através de modelos declarativos, em vez de scripts.

  • Implemente, faça a gestão e monitorize todos os recursos da sua solução como grupo, em vez de processar esses recursos individualmente.

  • Volte a implementar a sua solução ao longo do ciclo de vida de desenvolvimento, tendo a confiança de que os seus recursos são implementados num estado consistente.

  • Defina as dependências entre os recursos, para que sejam implementados na ordem correta.

  • Aplique o controlo de acesso a todos os serviços porque o controlo de acesso baseado em funções do Azure (RBAC do Azure) está integrado nativamente na plataforma de gestão.

  • Aplique etiquetas a recursos para organizar logicamente todos os recursos na sua subscrição.

  • Clarifique a faturação da sua organização ao ver os custos de um grupo de recursos com a mesma etiqueta.

Compreender o âmbito

O Azure fornece quatro níveis de âmbito: grupos de gestão, subscrições, grupos de recursos e recursos. A imagem seguinte mostra um exemplo destas camadas.

Diagrama que ilustra os quatro níveis de âmbito no Azure: grupos de gestão, subscrições, grupos de recursos e recursos.

Pode aplicar as definições de gestão em qualquer um destes níveis de âmbito. O nível que selecionar determina o quanto a definição é aplicada. Os níveis inferiores herdam as definições de níveis mais altos. Por exemplo, quando aplica uma política à subscrição, a política é aplicada a todos os grupos de recursos e recursos na sua subscrição. Quando aplica uma política no grupo de recursos, essa política é aplicada ao grupo de recursos e a todos os respetivos recursos. No entanto, outro grupo de recursos não tem essa atribuição de política.

Para obter informações sobre como gerir identidades e acesso, veja Azure Active Directory.

Pode implementar modelos em inquilinos, grupos de gestão, subscrições ou grupos de recursos.

Grupos de recursos

Existem alguns fatores importantes a considerar ao definir o grupo de recursos:

  • Todos os recursos no grupo de recursos devem partilhar o mesmo ciclo de vida. Implemente-os, atualize-os e elimine-os em conjunto. Se um recurso, como um servidor, precisar de existir num ciclo de implementação diferente, deverá estar noutro grupo de recursos.

  • Cada recurso só pode existir num único grupo de recursos.

  • Pode adicionar ou remover um recurso de um grupo de recursos em qualquer altura.

  • Pode mover um recurso de um grupo de recursos para outro grupo. Para obter mais informações, consulte Mover recursos para um novo grupo de recursos ou subscrição.

  • Os recursos num grupo de recursos podem estar localizados em regiões diferentes do grupo de recursos.

  • Quando cria um grupo de recursos, tem de fornecer uma localização para esse grupo de recursos.

    Pode perguntar-se, "Porque é que um grupo de recursos necessita de uma localização? E, se os recursos podem ter diferentes localizações em relação ao grupo de recursos, por que motivo é que a localização do grupo de recursos é sequer relevante?"

    O grupo de recursos armazena metadados sobre os recursos. Quando especifica uma localização para o grupo de recursos, está a especificar onde esses metadados estão armazenados. Por motivos de conformidade, poderá ter de certificar que os dados estão armazenados numa determinada região.

    Para garantir a consistência do estado do grupo de recursos, todas as operações do plano de controlo são encaminhadas através da localização do grupo de recursos. Ao selecionar uma localização do grupo de recursos, recomendamos que selecione uma localização próxima da origem das operações de controlo. Normalmente, esta localização é a mais próxima da sua localização atual. Este requisito de encaminhamento aplica-se apenas às operações do plano de controlo do grupo de recursos. Não afeta os pedidos que são enviados para as suas aplicações.

    Se a região de um grupo de recursos estiver temporariamente indisponível, não poderá atualizar os recursos no grupo de recursos porque os metadados não estão disponíveis. Os recursos noutras regiões continuarão a funcionar como esperado, mas não poderá atualizá-los.

    Para obter mais informações sobre a criação de aplicações fiáveis, veja Conceber aplicações fiáveis do Azure.

  • Um grupo de recursos pode ser utilizado para definir o âmbito do controlo de acesso para ações administrativas. Para gerir um grupo de recursos, pode atribuir Políticas do Azure, funções do Azure ou bloqueios de recursos.

  • Pode aplicar etiquetas a um grupo de recursos. Os recursos no grupo de recursos não herdam essas etiquetas.

  • Um recurso pode ligar-se a recursos noutros grupos de recursos. Este cenário é comum quando os dois recursos estão relacionados, mas não partilham o mesmo ciclo de vida. Por exemplo, pode ter uma aplicação Web que se liga a uma base de dados num grupo de recursos diferente.

  • Quando elimina um grupo de recursos, todos os recursos no grupo de recursos também são eliminados. Para obter informações sobre como o Azure Resource Manager orquestra essas eliminações, veja Eliminação de recursos e grupo de recursos do Azure Resource Manager.

  • Pode implementar até 800 instâncias de um tipo de recurso em cada grupo de recursos. Alguns tipos de recursos estão isentos do limite de 800 instâncias. Para obter mais informações, veja Limites do grupo de recursos.

  • Alguns recursos podem existir fora de um grupo de recursos. Estes recursos são implementados na subscrição, grupo de gestão ou inquilino. Apenas são suportados tipos de recursos específicos nestes âmbitos.

  • Para criar um grupo de recursos, pode utilizar o portal, o PowerShell, a CLI do Azure ou um modelo do ARM.

Resiliência do Azure Resource Manager

O serviço Resource Manager do Azure foi concebido para resiliência e disponibilidade contínua. Resource Manager e controlar operações do plano (pedidos enviados para management.azure.com) na API REST são:

  • Distribuído entre regiões. O Azure Resource Manager tem uma instância separada em cada região do Azure, o que significa que uma falha da instância do Azure Resource Manager numa região não afetará a disponibilidade do Azure Resource Manager ou de outros serviços do Azure noutra região. Embora o Azure Resource Manager esteja distribuído por regiões, alguns serviços são regionais. Esta distinção significa que, embora o processamento inicial da operação do plano de controlo seja resiliente, o pedido pode ser suscetível a interrupções regionais quando reencaminhado para o serviço.

  • Distribuído por Zonas de Disponibilidade (e regiões) em localizações com vários Zonas de Disponibilidade. Esta distribuição garante que quando uma região perde uma ou mais zonas, o Azure Resource Manager pode efetuar a ativação pós-falha para outra zona ou para outra região para continuar a fornecer capacidade de plano de controlo para os recursos.

  • Não dependente de um único datacenter lógico.

  • Nunca retirado para atividades de manutenção.

Esta resiliência aplica-se aos serviços que recebem pedidos através de Resource Manager. Por exemplo, Key Vault beneficia desta resiliência.

Passos seguintes