Test drive do Azure Resource Manager

Artigo
11/20/2023

Use esse tipo se você tiver uma oferta no Azure Marketplace ou AppSource, mas quiser criar um test drive apenas com recursos do Azure. Um modelo do Azure Resource Manager (ARM) é um contêiner codificado de recursos do Azure que você projeta para melhor representar sua solução. O test drive usa o modelo ARM fornecido e implanta todos os recursos necessários para um grupo de recursos. Esta é a única opção de test drive para máquinas virtuais ou ofertas de aplicativos do Azure.

Se você não estiver familiarizado com o que é um modelo ARM, leia O que é o Azure Resource Manager? e Entenda a estrutura e a sintaxe dos modelos ARM para entender melhor como criar e testar seus próprios modelos .

Para obter informações sobre um test drive de aplicativo lógico ou hospedado, consulte O que é um test drive?

Gorjeta

Para ver a visão do cliente sobre o test drive no mercado comercial, consulte O que é o Azure Marketplace e O que é o Microsoft AppSource?.

Configuração técnica

Um modelo de implantação contém todos os recursos do Azure que compõem sua solução. Os produtos que se encaixam nesse cenário usam apenas recursos do Azure. Defina as seguintes propriedades no Partner Center:

Regiões (obrigatório) – Atualmente, há 26 regiões suportadas pelo Azure onde seu test drive pode ser disponibilizado. Para obter o melhor desempenho, recomendamos escolher uma região onde você espera que o maior número de clientes esteja localizado. Terá de se certificar de que a sua subscrição tem permissão para implementar todos os recursos necessários em cada uma das regiões que está a selecionar.
Instâncias – Selecione o tipo (quente ou frio) e o número de instâncias disponíveis, que serão multiplicados pelo número de regiões onde sua oferta está disponível.
- Hot – Este tipo de instância é implantado e aguarda acesso por região selecionada. Os clientes podem acessar instantaneamente as instâncias quentes de um test drive, em vez de ter que esperar por uma implantação. A contrapartida é que essas instâncias estão sempre em execução em sua assinatura do Azure, portanto, elas incorrerão em um custo de tempo de atividade maior. É altamente recomendável ter pelo menos uma instância Hot, pois a maioria dos clientes não quer esperar por implantações completas, resultando em uma queda no uso do cliente se nenhuma instância Hot estiver disponível.
- Cold – esse tipo de instância representa o número total de instâncias que podem ser implantadas por região. As instâncias frias exigem que todo o modelo do Test Drive Resource Manager seja implantado quando um cliente solicita o test drive, portanto , as instâncias frias são muito mais lentas para carregar do que as instâncias quentes . A contrapartida é que você só precisa pagar pela duração do test drive, ele nem sempre está sendo executado em sua assinatura do Azure como em uma instância do Hot .
Teste o modelo do Azure Resource Manager – Carregue o .zip que contém seu modelo do Azure Resource Manager. Saiba mais sobre como criar um modelo do Azure Resource Manager no artigo de início rápido Criar e implantar modelos do Azure Resource Manager usando o portal do Azure.

Nota

Para publicar com êxito, é importante validar a formatação do modelo ARM. Duas maneiras de fazer isso são (1) usando uma ferramenta de API online ou (2) com uma implantação de teste.
Duração do test drive (obrigatório) – Insira o número de horas que o test drive permanecerá ativo. O test drive termina automaticamente após este período de tempo terminar. Use apenas números inteiros (por exemplo, "2" horas é válido, "1,5" não é).

Escrever o modelo de test drive

Depois de projetar o pacote de recursos desejado, escreva e crie o modelo ARM do test drive. Como o test drive executa implantações em um modo totalmente automatizado, os modelos de test drive têm algumas restrições:

Parâmetros

A maioria dos modelos tem um conjunto de parâmetros que definem nomes de recursos, tamanhos de recursos (como tipos de contas de armazenamento ou tamanhos de máquinas virtuais), nomes de usuário e senhas, nomes DNS e assim por diante. Ao implantar soluções usando o portal do Azure, você pode preencher manualmente todos esses parâmetros, escolher nomes DNS disponíveis ou nomes de contas de armazenamento e assim por diante.

List of parameters in an Azure Resource Manager

No entanto, o test drive funciona automaticamente, sem interação humana, pelo que suporta apenas um conjunto limitado de categorias de parâmetros. Se um parâmetro no modelo ARM do test drive não se enquadrar em uma das categorias suportadas, você deverá substituir esse parâmetro por uma variável ou valor constante.

Você pode usar qualquer nome válido para seus parâmetros; O test drive reconhece a categoria do parâmetro usando um valor do tipo metadados. Especifique o tipo de metadados para cada parâmetro de modelo, caso contrário, seu modelo não passará na validação:

"parameters": {
  ...
  "username": {
    "type": "string",
    "metadata": {
      "type": "username"
    }
  },
  ...
}

Nota

Todos os parâmetros são opcionais, portanto, se você não quiser usar nenhum, não precisa.

Tipos de metadados de parâmetros aceitos

Tipo de metadados	Tipo de parâmetro	Description	Valor da amostra
Baseuri	string	URI base do seu pacote de implantação	`https://<..>.blob.core.windows.net/<..>`
nome de utilizador	string	Novo nome de usuário aleatório.	admin68876
palavra-passe	string segura	Nova palavra-passe aleatória	Lp! ACS^2kh
ID da sessão	string	GUID (ID exclusivo da sessão de test drive)	b8c8693e-5673-449c-badd-257a405a6dee

Baseuri

O test drive inicializa esse parâmetro com um Uri de base do seu pacote de implantação para que você possa usar esse parâmetro para construir um Uri de qualquer arquivo incluído no pacote.

Nota

O baseUri parâmetro não pode ser usado em conjunto com uma extensão de script personalizada.

"parameters": {
  ...
  "baseuri": {
    "type": "string",
    "metadata": {
      "type": "baseuri",
      "description": "Base Uri of the deployment package."
    }
  },
  ...
}

Use esse parâmetro dentro do modelo para construir um Uri de qualquer arquivo do pacote de implantação do test drive. O exemplo a seguir mostra como construir um Uri do modelo vinculado:

"templateLink": {
  "uri": "[concat(parameters('baseuri'),'templates/solution.json')]",
  "contentVersion": "1.0.0.0"
}

nome de utilizador

O test drive inicializa esse parâmetro com um novo nome de usuário aleatório:

"parameters": {
  ...
  "username": {
    "type": "string",
    "metadata": {
      "type": "username",
      "description": "Solution admin name."
    }
  },
  ...
}

Valor da amostra: admin68876

Você pode usar nomes de usuário aleatórios ou constantes para sua solução.

password

O test drive inicializa este parâmetro com uma nova senha aleatória:

"parameters": {
  ...
  "password": {
    "type": "securestring",
    "metadata": {
      "type": "password",
      "description": "Solution admin password."
    }
  },
  ...
}

Valor da amostra: Lp!ACS^2kh

Você pode usar senhas aleatórias ou constantes para sua solução.

ID da sessão

O test drive inicializa esse parâmetro com um GUID exclusivo que representa o ID da sessão do test drive:

"parameters": {
  ...
  "sessionid": {
    "type": "string",
    "metadata": {
      "type": "sessionid",
      "description": "Unique test drive session id."
    }
  },
  ...
}

Valor da amostra: b8c8693e-5673-449c-badd-257a405a6dee

Você pode usar esse parâmetro para identificar exclusivamente a sessão de test drive, se necessário.

Nomes Únicos

Alguns recursos do Azure, como contas de armazenamento ou nomes DNS, requerem nomes globalmente exclusivos. Isso significa que toda vez que o test drive implanta o modelo ARM, ele cria um novo grupo de recursos com um nome exclusivo para todos os seus recursos. Portanto, você deve usar a função uniquestring concatenada com seus nomes de variáveis em IDs de grupo de recursos para gerar valores exclusivos aleatórios:

"variables": {
  ...
  "domainNameLabel": "[concat('contosovm',uniquestring(resourceGroup().id))]",
  "storageAccountName": "[concat('contosodisk',uniquestring(resourceGroup().id))]",
  ...
}

Certifique-se de concatenar suas cadeias de caracteres de parâmetro/variável () com uma saída de cadeia de caracteres exclusiva (contosovmresourceGroup().id), pois isso garante a exclusividade e a confiabilidade de cada variável.

Por exemplo, a maioria dos nomes de recursos não pode começar com um dígito, mas uma função de cadeia de caracteres exclusiva pode retornar uma cadeia de caracteres, que começa com um dígito. Portanto, se você usar a saída de cadeia de caracteres exclusiva bruta, suas implantações falharão.

Você pode encontrar informações adicionais sobre regras e restrições de nomenclatura de recursos em Desenvolver sua estratégia de nomenclatura e marcação para recursos do Azure.

Local de implantação

Você pode disponibilizar seu test drive em diferentes regiões do Azure.

Quando o test drive cria uma instância do Lab, ele sempre cria um grupo de recursos em uma das regiões selecionadas e, em seguida, executa seu modelo de implantação nesse contexto de grupo. Portanto, seu modelo deve escolher o local de implantação do grupo de recursos:

"variables": {
  ...
  "location": "[resourceGroup().location]",
  ...
}

E, em seguida, use esse local para cada recurso de uma instância específica do Lab:

"resources": [
  {
    "type": "Microsoft.Storage/storageAccounts",
    "location": "[variables('location')]",
    ...
  },
  {
    "type": "Microsoft.Network/publicIPAddresses",
    "location": "[variables('location')]",
    ...
  },
  {
    "type": "Microsoft.Network/virtualNetworks",
    "location": "[variables('location')]",
    ...
  },
  {
    "type": "Microsoft.Network/networkInterfaces",
    "location": "[variables('location')]",
    ...
  },
  {
    "type": "Microsoft.Compute/virtualMachines",
    "location": "[variables('location')]",
    ...
  }
]

Certifique-se de que sua assinatura tenha permissão para implantar todos os recursos desejados em cada uma das regiões selecionadas. Certifique-se também de que as imagens da máquina virtual estejam disponíveis em todas as regiões habilitadas, caso contrário, seu modelo de implantação não funcionará para algumas regiões.

Resultados

Normalmente, com modelos do Resource Manager, você pode implantar sem produzir nenhuma saída. Isso ocorre porque você conhece todos os valores usados para preencher os parâmetros do modelo e sempre pode inspecionar manualmente as propriedades de qualquer recurso.

Para modelos do Test Drive Resource Manager, no entanto, é importante retornar ao test drive todas as informações necessárias para obter acesso ao laboratório (URIs do site, nomes de host da máquina virtual, nomes de usuário e senhas). Certifique-se de que todos os seus nomes de saída sejam legíveis, pois essas variáveis são apresentadas ao cliente.

Não há restrições relacionadas às saídas do modelo. O test drive converte todos os valores de saída em strings, portanto, se você enviar um objeto para a saída, um usuário verá a string JSON.

Exemplo:

"outputs": {
  "Host Name": {
    "type": "string",
    "value": "[reference(variables('pubIpId')).dnsSettings.fqdn]"
  },
  "User Name": {
    "type": "string",
    "value": "[parameters('adminName')]"
  },
  "Password": {
    "type": "string",
    "value": "[parameters('adminPassword')]"
  }
}

Limites de subscrição

Não se esqueça dos limites de subscrição e serviço. Por exemplo, se você quiser implantar até dez máquinas virtuais de 4 núcleos, precisará garantir que a assinatura usada para seu laboratório permita que você use 40 núcleos. Para obter mais informações sobre a assinatura do Azure e os limites de serviço, consulte Limites de assinatura e serviço, cotas e restrições do Azure. Como vários test drives podem ser feitos ao mesmo tempo, verifique se sua assinatura pode lidar com o número de núcleos multiplicado pelo número total de test drives simultâneos que podem ser feitos.

O que carregar

O modelo ARM do test drive é carregado como um arquivo zip, que pode incluir vários artefatos de implantação, mas deve ter um arquivo chamado main-template.json. Este é o modelo de implantação ARM que o test drive usa para instanciar um laboratório. Se você tiver recursos adicionais além desse arquivo, poderá consultá-los como recursos externos dentro do modelo ou incluí-los no arquivo zip.

Durante a certificação de publicação, o test drive descompacta seu pacote de implantação e coloca seu conteúdo em um contêiner de blob de test drive interno. A estrutura do contêiner reflete a estrutura do seu pacote de implantação:

pacote.zip	Contêiner de blob do test drive
`main-template.json`	`https:\//\<\...\>.blob.core.windows.net/\<\...\>/main-template.json`
`templates/solution.json`	`https:\//\<\...\>.blob.core.windows.net/\<\...\>/templates/solution.json`
`scripts/warmup.ps1`	`https:\//\<\...\>.blob.core.windows.net/\<\...\>/scripts/warmup.ps1`

Chamamos um Uri desse contêiner de blob de Base Uri. Como cada revisão do seu laboratório tem seu próprio contêiner de blob, cada revisão do seu laboratório tem seu próprio Uri de base. O test drive pode passar um Uri base do pacote de implantação descompactado para o modelo por meio dos parâmetros do modelo.

Exemplos de modelo de transformação para test drive

O processo de transformar uma arquitetura de recursos em um modelo de Test Drive do Resource Manager pode ser assustador. Para obter ajuda adicional, consulte estes exemplos de como transformar melhor os modelos de implantação atuais em O que é um test drive?.

Detalhes da subscrição de implementação do test drive

A seção final a ser concluída é poder implantar os test drives automaticamente conectando sua Assinatura do Azure e a ID do Microsoft Entra.

Test drive deployment subscription details

Obtenha uma ID de Assinatura do Azure. Isso concede acesso aos serviços do Azure e ao portal do Azure. A assinatura é onde o uso de recursos é relatado e os serviços são cobrados. Se você ainda não tiver uma assinatura separada do Azure apenas para test drives, crie uma. Você pode encontrar IDs de Assinatura do Azure (como 1a83645ac-1234-5ab6-6789-1h234g764ghty1) entrando no portal do Azure e selecionando Assinaturas no menu de navegação à esquerda.
Obtenha uma ID de locatário do Microsoft Entra. Se você já tiver uma ID de locatário disponível, poderá encontrá-la na ID do diretório de propriedades>do Microsoft Entra ID:>

Se você não tiver uma ID de locatário, crie uma nova na ID do Microsoft Entra. Para obter ajuda com a configuração de um locatário, consulte Guia de início rápido: configurar um locatário.
Provisione o aplicativo Microsoft Test-Drive para seu locatário. Usaremos este aplicativo para executar operações em seus recursos de test drive.
1. Se você ainda não o tem, instale o módulo Azure Az PowerShell.
2. Adicione a entidade de serviço para o aplicativo Microsoft Test-Drive.
  1. Execute Connect-AzAccount e forneça credenciais para entrar em sua conta do Azure, que requer a função interna de AdministradorGlobal do Microsoft Entra ID.
  2. Crie uma nova entidade de serviço: New-AzADServicePrincipal -ApplicationId d7e39695-0b24-441c-a140-047800a05ede -DisplayName 'Microsoft TestDrive'.
  3. Verifique se a entidade de serviço foi criada: Get-AzADServicePrincipal -DisplayName 'Microsoft TestDrive'.
Para a ID do Aplicativo Microsoft Entra, cole esta ID de Aplicativo: d7e39695-0b24-441c-a140-047800a05ede.
Para o Microsoft Entra App Key, como nenhum segredo é necessário, insira um segredo fictício, como "no-secret".
Como estamos usando o aplicativo para implantar na assinatura, precisamos adicionar o aplicativo como um colaborador na assinatura, no portal do Azure ou no PowerShell:
1. No portal do Azure:
  1. Selecione a assinatura que está sendo usada para o test drive.
  2. Selecione Controlo de acesso (IAM) .
  3. Selecione Adicionar > atribuição de função.
  4. Na guia Função, selecione Colaborador.
  5. Na guia Membros, selecione Usuário, grupo ou entidade de serviço e escolha Selecionar membros.
  6. Selecione a entidade de serviço Microsoft TestDrive que você criou anteriormente.
  7. No separador Rever + atribuir, selecione Rever + atribuir para atribuir a função.
    
    Para obter mais informações sobre atribuições de função, consulte Atribuir funções do Azure usando o portal do Azure
2. Se estiver usando o PowerShell:
  1. Execute isso para obter a ID do objeto ServicePrincipal: (Get-AzADServicePrincipal -DisplayName 'Microsoft TestDrive').id.
  2. Execute isso com o ObjectId e a ID da assinatura: New-AzRoleAssignment -ObjectId <objectId> -RoleDefinitionName Contributor -Scope /subscriptions/<subscriptionId>.

Nota

Antes de excluir o appID antigo, vá para o portal do Azure, depois para Grupos de recursos e procure CloudTry_. Verifique a coluna Evento iniciado por .

Não exclua o appID antigo a menos que pelo menos um recurso (nome da operação) esteja definido como Microsoft TestDrive.

Para excluir o appID, no menu de navegação esquerdo, selecione Registros de aplicativos do Microsoft Entra ID>e, em seguida, a guia Todos os aplicativos. Escolha seu aplicativo e selecione Excluir.

Voltar a publicar

Agora que todos os campos do test drive estão completos, publique novamente a sua oferta. Depois que seu test drive for aprovado na certificação, teste a experiência do cliente na visualização da sua oferta:

Inicie um test drive na interface do usuário.
Abra sua assinatura do Azure dentro do portal do Azure.
Verifique se o test drive está sendo implantado corretamente.

Não exclua nenhuma instância de test drive provisionada para seus clientes; o serviço de test drive limpará automaticamente esses Grupos de Recursos depois que um cliente terminar de usá-lo.

Quando estiver confortável com a sua oferta de Pré-visualização, está na hora de entrar em funcionamento! Há um processo de revisão final para verificar toda a experiência de ponta a ponta. Se rejeitarmos a oferta, enviaremos um e-mail para o contato de engenharia da sua oferta explicando o que precisa ser corrigido.

Próximos passos

Se você estava seguindo as instruções para criar sua oferta no Partner Center, use a seta para trás para retornar a esse tópico.
Saiba mais sobre outros tipos de test drives em O que é um test drive?.

Test drive do Azure Resource Manager

Configuração técnica

Escrever o modelo de test drive

Parâmetros

Tipos de metadados de parâmetros aceitos

Baseuri

nome de utilizador

password

ID da sessão

Nomes Únicos

Local de implantação

Resultados

Limites de subscrição

O que carregar

Exemplos de modelo de transformação para test drive

Detalhes da subscrição de implementação do test drive

Voltar a publicar

Próximos passos

Comentários

Comentários

Recursos adicionais