Implementação Azure Resource Manager vs. implementação clássica: Compreender os modelos de implementação e o estado dos seus recursos.

Artigo
03/19/2024

Nota

As informações fornecidas neste artigo destinam-se a ser utilizadas apenas quando migra da implementação clássica para a implementação do Azure Resource Manager.

Neste artigo, vai ficar a saber mais sobre os modelos de implementação Azure Resource Manager e clássica. Estes modelos representam duas formas distingas de implementar e gerir as suas soluções do Azure. Vai trabalhar com estes modelos através de dois conjuntos de APIs diferentes e os recursos implementados podem conter diferenças importantes. Os dois modelos não são compatíveis entre si. Este artigo descreve essas diferenças.

Para simplificar a implementação e gestão de recursos, a Microsoft recomenda que utilize o Resource Manager para todos os recursos novos. Se for possível, a Microsoft recomenda que reimplemente os recursos existentes através do Resource Manager. Se tiver utilizado os Serviços na Nuvem, pode migrar a sua solução para os Serviços na Nuvem (suporte alargado).

Se você é novo no Gerenciador de Recursos, convém primeiro revisar a terminologia definida na visão geral do Gerenciador de Recursos do Azure.

Histórico dos modelos de implementação

Originalmente, o Azure oferecia apenas o modelo de implementação clássica. Neste modelo, cada recurso existia independentemente; não havia forma de agrupar os recursos relacionados. Em vez disso, tinha de acompanhar manualmente quais os recursos que compunham a sua solução ou aplicação e não se esquecer de geri-los através de uma abordagem coordenada. Para implementar uma solução, tinha de criar cada recurso individualmente no portal ou de criar um script que implementasse todos os recursos na ordem certa. Para eliminar uma solução, era necessário eliminar cada recurso individualmente. Não foi possível aplicar e atualizar facilmente as políticas de controle de acesso para recursos relacionados. Por fim, não foi possível aplicar tags a recursos para rotulá-los com termos que ajudam a monitorar seus recursos e gerenciar o faturamento.

Em 2014, o Azure introduziu o Resource Manager, que acrescentou o conceito de grupo de recursos. Os grupos de recursos são um contentor para os recursos que partilham um ciclo de vida comum. O modelo de implementação Resource Manager oferece várias vantagens:

Pode implementar, gerir e monitorizar todos os serviços da sua solução como um grupo, em vez de os processar individualmente.
Pode implementar repetidamente a solução durante o ciclo de vida da mesma e ter a confiança de que os recursos são implementados num estado consistente.
Pode aplicar o controlo de acesso a todos os recursos do seu grupo de recursos e essas políticas são aplicadas automaticamente quando são adicionados recursos novos ao grupo de recursos.
Pode aplicar etiquetas a recursos para organizar logicamente todos os recursos na sua subscrição.
Pode utilizar o JavaScript Object Notation (JSON) para definir a infraestrutura da sua solução. O ficheiro JSON é conhecido como modelo do Resource Manager.
Pode definir as dependências entre os recursos, de modo a que sejam implementados na ordem correta.

Quando o Resource Manager foi acrescentado, todos os recursos foram adicionados retroativamente a grupos de recursos predefinidos. Se você criar um recurso por meio da implantação clássica agora, o recurso será criado automaticamente dentro de um grupo de recursos padrão para esse serviço, mesmo que você não tenha especificado esse grupo de recursos na implantação. No entanto, apenas existir dentro de um grupo de recursos não significa que o recurso foi convertido para o modelo do Resource Manager.

Compreender o suporte para os modelos

Existem três cenários a ter em consideração:

Os Serviços de Nuvem (clássicos) não suportam o modelo de implantação do Resource Manager. Os Serviços de Nuvem (suporte estendido) suportam o modelo de implantação do Resource Manager.
As máquinas virtuais, as contas de armazenamento e as redes virtuais suportam tanto o modelo de implementação clássica, como o Resource Manager.
Todos os outros serviços do Azure suportam o Resource Manager.

Nas máquinas virtuais, contas de armazenamento e redes virtuais, se o recurso tiver sido criado com a implementação clássica, tem de continuar a trabalhar no mesmo através de operações clássicas. Se a máquina virtual, conta de armazenamento ou rede virtual tiver sido criada através da implementação Resource Manager, tem de continuar a utilizar operações do Resource Manager. Esta distinção pode ser confusa se a sua subscrição contiver uma mistura de recursos criados com ambos os modelos de implementação. Essa combinação de recursos pode criar resultados inesperados porque os recursos não suportam as mesmas operações.

Em alguns casos, um comando do Resource Manager pode obter informações sobre um recurso criado através da implementação clássica ou pode realizar uma tarefa administrativa, tal como mover um recurso clássico para outro grupo de recursos. Mas, esses casos não devem dar a impressão de que o tipo suporta operações do Resource Manager. Por exemplo, suponha que tem um grupo de recursos que contém uma máquina virtual que foi criada com a implementação clássica. Se executar o seguinte comando do PowerShell do Resource Manager:

Get-AzResource -ResourceGroupName ExampleGroup -ResourceType Microsoft.ClassicCompute/virtualMachines

Devolve a máquina virtual:

Name              : ExampleClassicVM
ResourceId        : /subscriptions/{guid}/resourceGroups/ExampleGroup/providers/Microsoft.ClassicCompute/virtualMachines/ExampleClassicVM
ResourceName      : ExampleClassicVM
ResourceType      : Microsoft.ClassicCompute/virtualMachines
ResourceGroupName : ExampleGroup
Location          : westus
SubscriptionId    : {guid}

No entanto, o cmdlet Get-AzVM do Resource Manager retorna apenas máquinas virtuais implantadas por meio do Resource Manager. O comando a seguir não retorna a máquina virtual criada por meio da implantação clássica.

Get-AzVM -ResourceGroupName ExampleGroup

Só os recursos criados com o Resource Manager suportam etiquetas. Não é possível aplicar tags a recursos clássicos.

Alterações a computação, rede e armazenamento

O diagrama seguinte apresenta recursos de computação, rede e armazenamento implementados através do Resource Manager.

Diagram that shows Resource Manager architecture with SRP, CRP, and NRP.

SRP: Storage Resource Provider, CRP: Compute Resource Provider, NRP: Network Resource Provider

Para obter um diagrama atualizado de uma solução de máquina virtual que usa discos gerenciados, consulte Executar uma VM do Windows no Azure.

Repare nas seguintes relações entre os recursos:

Todos os recursos existem dentro de um grupo de recursos.
A máquina virtual depende de uma conta de armazenamento específica definida no Fornecedor de recursos de armazenamento para armazenar os respetivos discos no armazenamento de blobs (obrigatório).
A máquina virtual faz referência a uma placa de interface de rede específica definida no provedor de recursos de rede (obrigatório) e a um conjunto de disponibilidade definido no provedor de recursos de computação (opcional).
A placa de interface de rede faz referência ao endereço IP atribuído da máquina virtual (obrigatório), à sub-rede da rede virtual para a máquina virtual (obrigatório) e a um Grupo de Segurança de Rede (opcional).
A sub-rede dentro de uma rede virtual referencia um Grupo de Segurança de Rede (opcional).
A instância do balanceador de carga faz referência ao pool de back-end de endereços IP que incluem a placa de interface de rede de uma máquina virtual (opcional) e faz referência a um endereço IP público ou privado do balanceador de carga (opcional).

Seguem-se os componentes e as respetivas relações para a implementação clássica:

Diagram that shows classic architecture for hosting a virtual machine.

A solução clássica para alojar uma máquina virtual inclui:

Os Serviços de Nuvem (clássicos) atuam como um contêiner para hospedar máquinas virtuais (computação). As máquinas virtuais são fornecidas automaticamente com uma placa de interface de rede e um endereço IP atribuído pelo Azure. Além disso, o serviço cloud contém uma instância do balanceador de carga externa, um endereço IP público e pontos finais predefinidos para permitir o tráfego do ambiente de trabalho remoto e do PowerShell remoto para máquinas virtuais baseadas em Windows e o tráfego Secure Shell (SSH) para máquinas virtuais baseadas em Linux.
Uma conta de armazenamento necessária que armazena os discos rígidos virtuais para uma máquina virtual, incluindo o sistema operacional, discos de dados temporários e adicionais (armazenamento).
Uma rede virtual opcional que atua como um contêiner adicional, na qual você pode criar uma estrutura de sub-rede e escolher a sub-rede na qual a máquina virtual está localizada (rede).

A tabela seguinte descreve as alterações na forma como os fornecedores de Computação, Rede e Armazenamento interagem:

Item	Clássico	Gestor de Recursos
Serviço em Nuvem para Máquinas Virtuais	O Serviço em Nuvem era um contentor para manter máquinas virtuais que exigiam Disponibilidade a partir de plataforma e o Balanceamento de Carga.	O Serviço em Nuvem já não é um objeto necessário para criar uma Máquina Virtual com o novo modelo.
Redes Virtuais	Uma rede virtual é opcional para a máquina virtual. Se incluída, a rede virtual não pode ser implantada com o Gerenciador de Recursos.	A máquina virtual requer uma rede virtual que tenha sido implementada com o Resource Manager.
Contas de Armazenamento	A máquina virtual requer uma conta de armazenamento que armazena os discos rígidos virtuais para o sistema operacional, temporários e discos de dados adicionais.	A máquina virtual requer uma conta de armazenamento para armazenar os respetivos discos no armazenamento de blobs.
Conjuntos de Disponibilidade	A disponibilidade para a plataforma foi indicada pela configuração do mesmo "AvailabilitySetName" nas Máquinas Virtuais. A contagem máxima de domínios de falhas era 2.	O Conjunto de Disponibilidade é um recurso exposto pelo Fornecedor Microsoft.Compute. As Máquinas Virtuais que requerem elevada disponibilidade têm de ser incluídas no Conjunto de Disponibilidade. A contagem máxima de domínios de falhas é agora 3.
Grupos de Afinidade	Os Grupos de Afinidade eram necessários para criar Redes Virtuais. No entanto, com a introdução das Redes Virtuais Regionais, isso não era mais necessário.	Para simplificar, o conceito de Grupos de Afinidade não existe nas APIs expostas por meio do Gerenciador de Recursos do Azure.
Balanceamento de Carga	A criação de um Serviço em Nuvem fornece um balanceador de carga implícito para as Máquinas Virtuais implementadas.	O Balanceador de Carga é um recurso exposto pelo fornecedor Microsoft.Network. A interface de rede primária das Máquinas Virtuais que precisam de balanceamento de carga deve mencionar o balanceador de carga. Os Balanceadores de Carga podem ser internos ou externos. Uma instância do balanceador de carga referencia o conjunto de back-end de endereços IP que incluem a NIC de uma máquina virtual (opcional) e um endereço IP público ou privado do balanceador de carga (opcional).
Endereço IP Virtual	Os Serviços Cloud obtêm um VIP (Endereço IP Virtual) predefinido quando uma VM é adicionada a um serviço cloud. O Endereço IP Virtual é o endereço associado ao balanceador de carga implícito.	O endereço IP público é um recurso exposto pelo fornecedor Microsoft.Network. O endereço IP público pode ser estático (reservado) ou dinâmico. Os IPs públicos dinâmicos podem ser atribuídos a um Balanceador de Carga. Os IPs Públicos podem ser protegidos utilizando Grupos de Segurança.
Endereço IP Reservado	Pode reservar um Endereço IP no Azure e associá-lo a um Serviço em Nuvem para garantir que o Endereço IP é temporário.	O Endereços IP Público pode ser criado no modo estático e oferece a mesma capacidade dos endereços IP reservados.
Endereço IP Público (PIP) por VM	O Endereço IP Público também pode ser associado diretamente a uma VM.	O endereço IP público é um recurso exposto pelo fornecedor Microsoft.Network. O Endereço IP Público pode ser estático (reservado) ou dinâmico.
Pontos finais	Os Pontos Finais de Entrada tinham de ser configurados numa Máquina Virtual para estarem abertos à conectividade para determinadas portas. Um dos modos comuns de ligar a máquinas virtuais era configurando pontos finais de entrada.	As Regras NAT de Entrada podem ser configuradas em Balanceadores de Carga para obter a mesma capacidade de ativação de pontos finais em portas específicas para estabelecer ligação às VMs.
Nome DNS	Um serviço em nuvem teria de obter um nome DNS implícito globalmente exclusivo. Por exemplo: `mycoffeeshop.cloudapp.net`.	Os Nomes DNS são parâmetros opcionais que podem ser especificados num recurso de Endereço IP Público. O FQDN está no formato `<domainlabel>.<region>.cloudapp.azure.com`.
Interfaces de Rede	As Interfaces de Rede Primária e Secundária e as respetivas propriedades eram definidas como configuração de rede de uma Máquina Virtual.	A Interface de Rede é um recurso exposto pelo Fornecedor Microsoft.Network. O ciclo de vida da Interface de Rede não está vinculado a uma Máquina Virtual. Referencia o endereço IP atribuído da máquina virtual (obrigatório), a sub-rede da rede virtual da máquina virtual (obrigatório) e um Grupo de Segurança de Rede (opcional).

Para saber mais sobre como ligar redes virtuais a partir de modelos de implementação diferentes, veja Connect virtual networks from different deployment models in the portal (Ligar redes virtuais a partir de modelos de implementação diferentes no portal).

Migrar da implementação clássica para Resource Manager

Se você estiver pronto para migrar seus recursos da implantação clássica para a implantação do Resource Manager, consulte:

Technical deep dive on platform-supported migration from classic to Azure Resource Manager (Análise detalhada técnica sobre a migração suportada por plataforma da clássica para Azure Resource Manager)
Platform supported migration of IaaS resources from Classic to Azure Resource Manager (Planear a migração suportada de recursos IaaS de Clássica para Azure Resource Manager)
Migrate IaaS resources from classic to Azure Resource Manager by using Azure PowerShell (Migrar recursos IaaS de clássica para Azure Resource Manager com o Azure PowerShell)
Migrate IaaS resources from classic to Azure Resource Manager by using Azure CLI (Migrar recursos IaaS de clássica para Azure Resource Manager com a CLI do Azure)

Perguntas mais frequentes

Poss criar uma máquina virtual com o Resource Manager para implementar numa rede virtual criada com a implementação clássica?

Esta configuração não é suportada. Não é possível usar o Gerenciador de Recursos para implantar uma máquina virtual em uma rede virtual que foi criada usando a implantação clássica.

Posso criar uma Máquina Virtual com o Resource Manager a partir de uma imagem de utilizador que tenha sido criada com o modelo de implementação clássica?

Esta configuração não é suportada. No entanto, você pode copiar os arquivos de disco rígido virtual de uma conta de armazenamento que foi criada usando o modelo de implantação clássico e adicioná-los a uma nova conta criada por meio do Gerenciador de Recursos.

Qual foi o impacto na quota da minha subscrição?

As quotas das máquinas virtuais, das redes virtuais e das contas de armazenamento criadas com o Azure Resource Manager são separadas das outras quotas. Cada subscrição recebe quotas para criar os recursos com as APIs novas. Pode ler mais sobre as quotas adicionais aqui.

Posso continuar a utilizar os meus scripts automatizados para o aprovisionamento de máquinas virtuais, redes virtuais e contas de armazenamento através das APIs do Resource Manager?

Toda a automatização e os scripts que criou vão continuar a funcionar nas máquinas virtuais e nas redes virtuais existentes criadas no modo Gestão de Serviço do Azure. No entanto, os scripts têm de ser atualizados para utilizar o novo esquema para criarem os mesmos recursos através do modo Azure Resource Manager.

Onde posso encontrar exemplos de modelos do Azure Resource Manager?

Pode encontrar um conjunto abrangente de modelos iniciais em Modelos de Início Rápido do Azure Resource Manager.

Próximos passos

Para ver os comandos para implementar um modelo, veja Deploy an application with Azure Resource Manager template (Implementar uma aplicação com um modelo do Azure Resource Manager).