Test drive do Azure Resource Manager

Use esse teste se você tem uma oferta no Azure Marketplace ou no AppSource, mas quer criar um test drive apenas com recursos do Azure. Um modelo do ARM (Azure Resource Manager) é um contêiner codificado de recursos do Azure que você cria para representar melhor sua solução. O test drive usa o modelo do 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 para ofertas de aplicativo do Azure.

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

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

Configurações técnicas

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

• Regiões (obrigatório) – atualmente, há 26 regiões compatíveis com o Azure onde seu test drive pode ser disponibilizado. Para obter o melhor desempenho, é recomendável escolher uma região em que o maior número de clientes esteja localizado. Você precisará garantir que sua assinatura tenha permissão para implantar todos os recursos necessários em cada uma das regiões selecionadas.

• Instâncias – selecione o tipo (frequente ou ocasional) e o número de instâncias disponíveis, que serão multiplicadas pelo número de regiões em que sua oferta está disponível.

  • Frequente – esse tipo de instância está implantada e aguardando acesso pela região selecionada. Os clientes podem acessar essas instâncias frequentes de um test drive instantaneamente em vez de ter que esperar por uma implantação. A desvantagem é 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 frequente , pois a maioria dos clientes não deseja esperar por implantações completas, resultando em uma queda no uso do cliente se nenhuma instância frequente estiver disponível.

  • Ocasional – esse tipo de instância representa o número total de instâncias que é possível implantar por região. As instâncias ocasionais exigem que o modelo do Resource Manager para test drive inteiro passe por uma implantação no momento em que um cliente solicita o test drive; portanto, carregam muito mais lentamente que as instâncias frequentes. A desvantagem é que você só precisa pagar pela duração do test drive, ele nem sempre está em execução em sua assinatura do Azure como em uma instância quente .

• Modelo do Azure Resource Manager para test drive – carregue o .zip que contém o modelo do Azure Resource Manager. Saiba mais sobre como criar um modelo de Azure Resource Manager no artigo de início rápido Criar e implantar modelos de Azure Resource Manager usando o portal do Azure.

  Observação

  Para publicar com sucesso, é importante validar a formatação do modelo do ARM. Duas maneiras de fazer isso são (1) usar 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 pelo qual o test drive permanecerá ativo. O test drive é encerrado automaticamente após o término desse período de tempo. Use apenas números inteiros (por exemplo, "2" horas é válido, "1,5" não é).

Gravar o modelo do test drive

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

Parâmetros

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

No entanto, o test drive funciona de modo automático, sem interação humana e, por isso, dá suporte apenas a um conjunto limitado de categorias de parâmetros. Se um parâmetro no modelo do ARM para test drive não se encaixar em uma das categorias com suporte, será necessário 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 o valor do tipo de metadados. Especifique metadata-type para cada parâmetro de modelo, caso contrário, seu modelo não passará na validação:

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

Tipos de metadados de parâmetros aceitos

baseuri

O test drive inicializa esse parâmetro com um URI base do seu pacote de implantação; portanto, você pode usar esse parâmetro para construir o URI de qualquer arquivo incluído no seu pacote.

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

Use esse parâmetro no seu modelo para construir um URI de qualquer arquivo do seu pacote de implantação do test drive. O seguinte abaixo mostra como construir um URI do modelo vinculado:

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

nome de usuário

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 de exemplo: admin68876

É possível usar nomes de usuário aleatórios ou constantes para sua solução.

password

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

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

Valor de exemplo: Lp!ACS^2kh

É possível usar senhas aleatórias ou constantes para sua solução.

session ID

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

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

Valor de exemplo: b8c8693e-5673-449c-badd-257a405a6dee

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

Nomes exclusivos

Alguns recursos do Azure, como contas de armazenamento ou nomes DNS, requerem nomes globalmente exclusivos. Isso significa que sempre que o test drive implantar o modelo do ARM, será criado um grupo de recursos com um nome exclusivo para todos os seus recursos. Portanto, você deve usar a função uniquestring concatenada com seus nomes variáveis nas IDs do 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âmetros/variáveis (contosovm) com uma saída de cadeia de caracteres exclusiva (resourceGroup().id), porque 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 a função de cadeia de caracteres exclusiva pode retornar uma cadeia de caracteres, que começa com um dígito. Portanto, se usar uma 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 da implantação

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

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

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

E, em seguida, usar esse local para todos os recursos para uma instância de laboratório específica:

"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 tem permissão para implantar todos os recursos que você deseja em cada uma das regiões escolhidas. Verifique também se as imagens da máquina virtual estão disponíveis em todas as regiões que você habilitará, caso contrário, o modelo de implantação não funcionará para algumas regiões.

Saídas

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

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

Não existem restrições relacionadas às saídas do modelo. O test drive converte todos os valores de saída em cadeias de caracteres. Se você enviar um objeto para a saída, um usuário verá uma cadeia de caracteres 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 assinatura

Não se esqueça dos limites de assinatura e de serviço. Por exemplo, se quiser implantar até dez máquinas virtuais com quatro núcleos, verifique se a assinatura usada para seu laboratório permite o uso de 40 núcleos. Para obter mais informações sobre a assinatura do Azure e os limites do serviço, confira Assinatura do Azure e limites, cotas e restrições do serviço. Como podem ser feitos vários test drive ao mesmo tempo, certifique-se de que sua assinatura pode lidar com o número de núcleos multiplicado pelo número total de test drives simultâneos que podem ser realizados.

O que deve ser transferido por upload

O modelo do ARM para 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. Esse é o modelo de implantação do ARM que o test drive usa para criar uma instância de laboratório. Se você tem recursos adicionais além desse arquivo, você pode referenciá-los como recursos externos dentro do modelo ou incluí-los no arquivo zip.

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

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

Transformar exemplos de modelo para test drive

O processo de transformar uma arquitetura de recursos em um modelo do Resource Manager para test drive pode ser desanimador. Para obter ajuda adicional, confira os exemplos de como transformar os modelos de implantação atuais em O que é um test drive?.

Detalhes da assinatura para implantaçã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.

1. Obtenha uma ID de assinatura do Azure. 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 as IDs de assinatura do Azure (como 1a83645ac-1234-5ab6-6789-1h234g764ghty1) entrando no portal do Azure e selecionando Assinaturas no menu de navegação esquerdo.

   

2. 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>da ID>do Microsoft Entra:

   

   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, confira Guia de início rápido: configurar um locatário.

3. Provisione o aplicativo Microsoft Test-Drive para o seu locatário. Usaremos esse aplicativo para executar operações em seus recursos de test drive.

   1. Se você ainda não o tiver, instale o módulo do Azure Az PowerShell.
   2. Adicione a entidade de serviço do aplicativo Microsoft Test-Drive.

      1. Execute Connect-AzAccount e forneça credenciais para entrar em sua conta do Azure, o que requer o mínimo de funções privilegiadas de ID do Microsoft Entra por função interna de tarefa.

      2. Crie uma 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'.

4. Para a ID do aplicativo Microsoft Entra, cole esta ID do aplicativo: d7e39695-0b24-441c-a140-047800a05ede.

5. Para a chave do aplicativo Microsoft Entra, como nenhum segredo é necessário, insira um segredo fictício, como "sem segredo".

6. Como estamos usando o aplicativo para implantar na assinatura, precisamos adicionar o aplicativo como 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 IAM (Controle de acesso) .

      3. Selecione Adicionar > 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, em seguida, selecione Selecionar membros.

      6. Selecione a entidade de serviço Microsoft TestDrive criada anteriormente.

      7. Na guia Examinar + atribuir, selecione Examinar + atribuir para atribuir a função.

         Para obter mais informações sobre atribuições de função, confira Atribuir funções do Azure usando o portal do Azure

   2. Se estiver usando o PowerShell:

      1. Execute isto para obter a ID de objeto do ServicePrincipal: (Get-AzADServicePrincipal -DisplayName 'Microsoft TestDrive').id.
      2. Execute isto com a ObjectId e a ID da assinatura: New-AzRoleAssignment -ObjectId <objectId> -RoleDefinitionName Contributor -Scope /subscriptions/<subscriptionId>.

Republicar

Agora que todos os campos do test drive estão completos, Republique a oferta. Quando o test drive passar na certificação, você deve testar a experiência do cliente na versão prévia da oferta:

1. Inicie um test drive na interface do usuário.

2. Abra sua assinatura do Azure no portal do Azure.

3. Verifique se o test drive está sendo implantado corretamente.

   

Não exclua nenhuma instância de test drive provisionada para os clientes. O serviço de test drive vai limpar automaticamente esses grupos de recursos quando o cliente terminar.

Quando estiver confortável com sua oferta de visualização, é hora de entrar no ar! 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.

Conteúdo relacionado

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