Provisionar e implantar microsserviços previsíveis no Azure

Este tutorial mostra como provisionar e implantar um aplicativo composto por microsserviços no Serviço de Aplicativo do Azure como uma única unidade e de maneira previsível usando modelos do grupo de recursos JSON e scripts do PowerShell.

Ao provisionar e implantar aplicativos em alta escala que são compostos por microsserviços totalmente separados, a repetitividade e a previsibilidade são essenciais para se obter êxito. Serviço de Aplicativo do Azure permite criar microsserviços que incluem aplicativos Web, back-ends móveis e aplicativos de API. O Azure Resource Manager permite gerenciar todos os microsserviços como uma unidade, juntamente com as dependências de recurso, como as configurações de controle do código-fonte e banco de dados. Agora, você também pode implantar esse aplicativo usando modelos JSON e scripts simples do PowerShell.

O que você fará

No tutorial, você implantará um aplicativo que inclui:

  • Dois aplicativos do Serviço de Aplicativo (isto é, dois microsserviços)
  • Um banco de dados SQL de back-end
  • Configurações do aplicativo, cadeias de conexão e controle do código-fonte
  • Application Insights, alertas, configurações de dimensionamento automático

Ferramentas que você utilizará

Neste tutorial, você utilizará as ferramentas a seguir. Como não se trata de uma discussão abrangente sobre ferramentas, escolherei o cenário de ponta a ponta e oferecerei uma breve introdução a respeito cada uma, indicando também onde você pode encontrar mais informações sobre ela.

Modelos do Gerenciador de Recursos do Azure (JSON)

Sempre que você cria um aplicativo no Serviço de Aplicativo do Azure, por exemplo, o Azure Resource Manager usa um modelo JSON para criar todo o grupo de recursos com os recursos do componente. Um modelo complexo do Azure Marketplace pode incluir o banco de dados, contas de armazenamento, o Plano do Serviço de Aplicativo, o próprio aplicativo, regras de alerta, configurações do aplicativo, configurações de dimensionamento automático e muito mais, e todos esses modelos estão disponíveis para você por meio do PowerShell. Para saber mais sobre os modelos do Azure Resource Manager, confira Criação de modelos do Azure Resource Manager

SDK do Azure para Visual Studio 2.6

O SDK mais recente contém melhorias para o suporte a modelos do Gerenciador de Recursos no editor JSON. Você pode usar isto para criar rapidamente um modelo de grupo de recursos do zero ou abrir um modelo do JSON existente (como um modelo baixado da galeria) para modificação, preencher o arquivo de parâmetros e até mesmo implantar o grupo de recursos diretamente de uma solução de Grupo de Recursos do Azure.

Para obter mais informações, consulte SDK do Azure para Visual Studio 2.6.

Azure PowerShell 0.8.0 ou posterior

A partir da versão 0.8.0, a instalação do Azure PowerShell inclui o módulo do Gerenciador de Recursos do Azure, além do módulo do Azure. Este novo módulo permite que você escreva script para implantação de grupos de recursos.

Para obter mais informações, consulte Usando o PowerShell do Azure com o Gerenciador de Recursos do Azure

Azure Resource Explorer

Essa ferramenta de visualização permite que você explore as definições de JSON de todos os grupos de recursos em sua assinatura e os recursos individuais. Na ferramenta, você pode editar as definições de JSON de um recurso, excluir uma hierarquia inteira de recursos e criar novos recursos. As informações prontamente disponíveis nesta ferramenta são muito úteis para a criação de modelos, pois mostram quais propriedades você precisa definir para um determinado tipo de recurso, os valores corretos etc. Você pode até mesmo criar seu grupo de recursos no portal do Azure e, em seguida, inspecionar suas definições de JSON na ferramenta do gerenciador como auxílio para a modelagem do grupo de recursos.

Botão Implantar no Azure

Se você usa GitHub para controle do código-fonte, você pode colocar um botão Implantar no Azure em seu arquivo LEIAME.MD, que permite uma implantação pronta para uso da interface do usuário para Azure. Embora seja possível fazê-lo para qualquer aplicativo simples, você pode estender isso para habilitar a implantação de um grupo de recursos inteiro, colocando um arquivo azuredeploy.json na raiz do repositório. Esse arquivo JSON, que contém o modelo de grupo de recursos, será usado pelo botão Implantar no Azure para criar o grupo de recursos. Para obter um exemplo, consulte a amostra ToDoApp , que você usará neste tutorial.

Obter o modelo de grupo de recursos de exemplo

Agora vamos direto ao ponto.

  1. Navegue até o exemplo de Serviço de Aplicativo ToDoApp .

  2. Em readme.md, clique em Implantar no Azure.

  3. Você é levado para o site implantar-no-azure e solicitado a inserir parâmetros de implantação. Observe que a maioria dos campos é preenchida com o nome do repositório e algumas cadeias de caracteres aleatórias para você. Você pode alterar todos os campos se desejar, mas as únicas coisas que você precisa inserir são o logon administrativo do SQL Server e a senha; então, clique em Próximo.

    Shows the input deployment parameters on the deploy-to-azure site.

  4. Em seguida, clique em Implantar para iniciar o processo de implantação. Quando o processo for concluído, clique no link http://todoappXXXX.azurewebsites.net para procurar o aplicativo implantado.

    Shows your application's deployment process.

    A interface do usuário deve estar um pouco lenta quando você navega pela primeira vez por ela porque os aplicativos estão sendo iniciados, mas esteja convencido de que se trata de um aplicativo totalmente funcional.

  5. De volta à página Implantar, clique no link Gerenciar para ver o novo aplicativo no Portal do Azure.

  6. Na lista suspensa Essentials , clique no link grupo de recursos. Observe também que o aplicativo já está conectado ao repositório GitHub em Projeto Externo.

    Shows the Resource group link in the Essentials dropdown section.

  7. Na folha do grupo de recursos, observe que já existem dois aplicativos e um banco de dados SQL no grupo de recursos.

    Shows the resources available in your resource group.

Tudo o que você acabou de ver em poucos minutos é um aplicativo de dois microsserviços totalmente implantado, com todos os componentes, dependências, configurações, banco de dados e publicação contínua, configurado por uma orquestração automatizada no Gerenciador de Recursos do Azure. Tudo isso foi feito por duas coisas:

  • O botão Implantar no Azure
  • O arquivo azuredeploy.json na raiz do repositório

Você pode implantar esse mesmo aplicativo dezenas, centenas ou milhares de vezes e ter sempre exatamente a mesma configuração. A capacidade de repetição e a previsibilidade dessa abordagem permitem que você implante aplicativos de grande escala com facilidade e confiança.

Examinar (ou editar) AZUREDEPLOY.JSON

Agora vamos examinar como o repositório GitHub foi configurado. Você usará o editor de JSON no SDK do .NET do Azure, portanto, se você ainda não tiver instalado o SDK .NET do Azure 2.6, faça isso agora.

  1. Clone o repositório ToDoApp usando sua ferramenta git favorita. Na captura de tela abaixo, faço isso no Team Explorer no Visual Studio 2013.

    Shows how to use a git tool to clone the ToDoApp repository.

  2. Na raiz do repositório, abra azuredeploy.json no Visual Studio. Se você não vir o painel Estrutura de Tópicos JSON, precisará instalar o SDK .NET do Azure.

    Shows the JSON Outline pane in Visual Studio.

Não vou descrever todos os detalhes do formato JSON, mas a seção Mais Recursos contém links para aprender a linguagem de modelo de grupo de recursos. Aqui, eu vou mostrar a você recursos interessantes que podem ajudá-lo a começar a fazer seu próprio modelo personalizado para implantação do aplicativo.

Parâmetros

Dê uma olhada na seção de parâmetros para ver que a maioria desses parâmetros são aquilo que o botão Implantar no Azure solicita que você insira. O site por trás do botão Implantar no Azure preenche a Interface do Usuário de entrada, usando os parâmetros definidos em azuredeploy.json. Esses parâmetros são usados em todas as definições de recurso, como nomes de recurso, valores de propriedade, etc.

Recursos

No nó recursos, você pode ver que 4 recursos do nível mais alto estão definidos, incluindo uma instância do SQL Server, um plano do Serviço de Aplicativo e dois aplicativos.

Plano do Serviço de Aplicativo

Vamos começar com um recurso simples de nível raiz em JSON. Na Estrutura de Tópicos JSON, clique no plano de Serviço de Aplicativo chamado [hostingPlanName] para realçar o código do JSON correspondente.

Shows the [hostingPlanName] section of the JSON code.

Observe que o elemento type especifica a cadeia de caracteres em um plano do Serviço de Aplicativo (isso era chamado de farm de servidores, há muito tempo atrás) enquanto outros elementos e propriedades são preenchidos com os parâmetros definidos no arquivo JSON, sendo que este recurso não tem nenhum recurso aninhado.

Observação

Observe também que o valor de apiVersion informa ao Azure com qual versão da API REST usar a definição de recurso JSON, e ele pode afetar como o recurso deve ser formatado dentro do {}.

SQL Server

Em seguida, clique no recurso do SQL Server chamado SQLServer na Estrutura de Tópicos JSON.

Shows the SQL Server resource named SQLServer in the JSON Outline.

Observe o seguinte sobre o código JSON realçado:

  • O uso de parâmetros garante que os recursos criados sejam nomeados e configurados de modo que torne-os consistentes entre si.

  • O recurso SQLServer tem dois recursos aninhados, cada um com um valor diferente para type.

  • Os recursos aninhados dentro de “resources”: […], em que o banco de dados e as regras de firewall são definidas, têm um elemento dependsOn que especifica a ID de recurso do recurso SQLServer no nível de raiz. Isso informa ao Gerenciador de Recursos do Azure que, "antes de você criar esse recurso, o outro recurso já deve existir; e se o outro recurso estiver definido no modelo, crie-o primeiro".

    Observação

    Para obter informações detalhadas sobre como usar a função resourceId(), consulte Funções do Modelo do Azure Resource Manager.

  • O efeito do elemento dependsOn é que o Gerenciador de Recursos do Azure pode saber quais recursos podem ser criados em paralelo e quais recursos devem ser criados sequencialmente.

Aplicativo de Serviço de Aplicativo

Agora, vamos passar para os aplicativos em si, que são mais complicados. Clique no aplicativo [variables(‘apiSiteName’)] na estrutura de tópicos JSON para destacar seu código JSON. Você perceberá que as coisas estão ficando muito mais interessantes. Para esse fim, falarei sobre um dos recursos por vez:

Recurso raiz

O aplicativo depende de dois recursos diferentes. Isso significa que o Azure Resource Manager criará o aplicativo somente depois que ambos o plano do Serviço de Aplicativo e a instância do SQL Server forem criados.

Shows the app dependencies on the App Service plan and the SQL Server instance.

Configurações de aplicativo

As configurações do aplicativo também serão definidas como um recurso aninhado.

Shows the app settings defined as a nested resource in the JSON code.

No elemento properties para config/appsettings, você tem duas configurações de aplicativo no formato "<name>" : "<value>".

  • PROJECT é uma configuração KUDU que, em uma solução do Visual Studio com vários projetos, informa à implantação do Azure qual projeto usar. Mostrarei posteriormente como o controle do código-fonte está configurado, mas já que o código ToDoApp está em uma solução do Visual Studio com vários projetos, precisamos dessa configuração.
  • clientUrl é simplesmente um aplicativo de configuração que o código do aplicativo usa.
Cadeias de conexão

As cadeias de conexão também serão definidas como um recurso aninhado.

Shows how the connection strings are defined as a nested resource in the JSON code.

No elemento properties para config/connectionstrings, cada cadeia de conexão também é definida como um par nome:valor, com o formato específico de "<name>" : {"value": "…", "type": "…"}. Para o elemento type, os valores possíveis são MySql, SQLServer, SQLAzure e Custom.

Dica

Para obter uma lista definitiva dos tipos de cadeia de conexão, execute o seguinte comando no Azure PowerShell: [Enum]::GetNames("Microsoft.WindowsAzure.Commands.Utilities.Websites.Services.WebEntities.DatabaseType")

Controle do código-fonte

As configurações do controle do código-fonte também serão definidas como um recurso aninhado. O Gerenciador de Recursos do Azure usa esse recurso para configurar a publicação contínua (consulte a advertência sobre IsManualIntegration posteriormente) e também para iniciar a implantação do código do aplicativo automaticamente durante o processamento do arquivo JSON.

Shows how the source control settings are defined as a nested resource in the JSON code.

RepoUrl e branch devem ser bastante intuitivos e devem apontar para o repositório Git e o nome da ramificação por meio da qual publicar. Mais uma vez, estes são definidos pelos parâmetros de entrada.

Observe no elemento dependsOn que, além do recurso de aplicativo, sourcecontrols/web também depende de config/appsettings e config/connectionstrings. Isso ocorre porque quando sourcecontrols/web é configurado, o processo de implantação do Azure tentará automaticamente implantar, compilar e iniciar o código do aplicativo. Portanto, inserir essa dependência ajuda você a garantir que o aplicativo tenha acesso às configurações e cadeias de conexão necessárias do aplicativo antes de o código desse aplicativo ser executado.

Observação

Observe também que IsManualIntegration é definido como true. Esta propriedade é necessária neste tutorial porque, na verdade, você não tem o repositório GitHub e, portanto, não pode efetivamente conceder permissão ao Azure para configurar a publicação contínua por meio do ToDoApp (ou seja, enviar atualizações automáticas de repositório por push ao Azure). Você pode usar o valor padrão false para o repositório especificado somente se tiver configurado as credenciais do proprietário para o GitHub no Portal do Azure previamente. Em outras palavras, se você configurou o controle do código-fonte para GitHub ou BitBucket para qualquer aplicativo no Portal do Azure previamente, usando suas credenciais de usuário, então o Azure lembrará dessas credenciais e as utilizará sempre que você implantar qualquer aplicativo do GitHub ou BitBucket no futuro. No entanto, se você ainda não tiver feito isso, a implantação do modelo JSON falhará quando o Azure Resource Manager tentar definir configurações de controle do código-fonte do aplicativo, porque ele não poderá fazer logon no GitHub ou BitBucket com as credenciais do proprietário do repositório.

Comparar o modelo JSON com grupo de recursos implantado

Aqui, você pode percorrer todas as folhas do aplicativo no Portal do Azure, mas há outra ferramenta que é tão útil quanto esta, ou mais. Vá para a ferramenta de visualização Gerenciador de Recursos do Azure , que oferece uma representação JSON de todos os grupos de recursos em suas assinaturas, como eles existem realmente no back-end do Azure. Você também pode ver como a hierarquia JSON do grupo de recursos no Azure corresponde à hierarquia no arquivo de modelo que é usado para criá-la.

Por exemplo, quando vou para a ferramenta Gerenciador de Recursos do Azure e expando os nós no gerenciador, posso ver o grupo de recursos e os recursos de nível raiz que são coletados em seus respectivos tipos de recurso.

View the resource group and root-level resources in the expanded Azure Resources Explorer tool.

Se você acessar hierarquias mais baixas de um aplicativo, você deve ser capaz de ver os detalhes de configuração de aplicativo como a captura de tela a seguir:

Drill down to view the configuration details in the app.

Novamente, os recursos aninhados devem ter uma hierarquia muito semelhante àquela no seu arquivo de modelo JSON, e você verá as configurações do aplicativo, cadeias de conexão, etc., adequadamente refletidas no painel JSON. A ausência de configurações pode indicar um problema com o arquivo JSON, e pode ajudá-lo a solucionar problemas no arquivo de modelo JSON.

Implantar o modelo de grupo de recursos por conta própria

O botão Implantar no Azure é ótimo, mas só permite que você implante o modelo de grupo de recursos em azuredeploy.json se você já tiver enviado azuredeploy.json por push para o GitHub. O SDK .NET do Azure também fornece as ferramentas para implantar qualquer arquivo de modelo JSON diretamente do computador local. Para fazer isso, siga as etapas abaixo:

  1. No Visual Studio, clique em Arquivo>Novo>Projeto.

  2. Clique em Visual C#>Nuvem>Grupo de Recursos do Azure, em seguida, clique em OK.

    Create a new project as an Azure Resource Group in the Azure .NET SDK.

  3. Em Selecionar Modelo do Azure, selecione Modelo em Branco e clique em OK.

  4. Arraste azuredeploy.json para a pasta Modelo do novo projeto.

    Shows the result of dragging the azuredeploy.json file into the Template folder of your project.

  5. No Gerenciador de Soluções, abra o azuredeploy.json copiado.

  6. Apenas para fins de demonstração, vamos adicionar alguns recursos padrão do Application Insight em nosso arquivo JSON, clicando em Adicionar Recurso. Se estiver interessado apenas na implantação do arquivo JSON, vá direto para as etapas de implantação.

    Shows the Add Resource button you can use to add standard Application Insight resources to your JSON file.

  7. Selecione Application Insights para Aplicativos Web, certifique-se de que um aplicativo e um Plano do Serviço de Aplicativo existentes estão selecionados e, em seguida, clique em Adicionar.

    Shows the selection of Application Insights for Web Apps, Name, App Service Plan, and Web App.

    Você será capaz de ver vários recursos novos que, dependendo do recurso e do que ele faz, têm dependências no plano do Serviço de Aplicativo ou então no aplicativo. Esses recursos não estão habilitados segundo sua definição existente e você vai mudar isso.

    View the new resources that have dependencies on the App Service plan or app.

  8. Na estrutura de tópicos JSON, clique em appInsights AutoScale para destacar seu código JSON. Essa é a configuração de dimensionamento para seu plano do Serviço de Aplicativo.

  9. No código realçado JSON, localize as propriedades location e enabled e defina-as conforme mostrado abaixo.

    Shows the location and enabled properties in the appInsights AutoScale JSON code and the values you should set them to.

  10. Na estrutura de tópicos JSON, clique em CPUHigh appInsights para destacar seu código JSON. Este é um alerta.

  11. Localize as propriedades location e isEnabled e defina-as conforme mostrado abaixo. Faça o mesmo para os outros três alertas (lâmpadas roxas).

    Shows the location and isEnabled properties in the CPUHigh appInsights JSON code and the values you should set them to.

  12. Agora, você está pronto para implantar. Clique no projeto com o botão direito do mouse e selecione Implantar>New Implantarment.

    Shows how to deploy your new project.

  13. Faça logon na conta do Azure se ainda não fez isso.

  14. Selecione um grupo de recursos existente em sua assinatura ou crie um novo, selecione azuredeploy.json e, em seguida, clique em Editar parâmetros.

    Shows how to edit the parameters in the azuredeploy.json file.

    Agora você poderá editar todos os parâmetros definidos no arquivo de modelo em uma boa tabela. Parâmetros que definem padrões já terão seus valores padrão, enquanto parâmetros que definem uma lista de valores permitidos serão mostrados como listas suspensas.

    Shows parameters that define a list of allowed values as dropdown lists.

  15. Preencha todos os parâmetros vazios e use o Endereço de repositório do GitHub para ToDoApp na repoUrl. Em seguida, clique em Salvar.

    Shows the newly filled parameters for the azuredeploy.json file.

    Observação

    O dimensionamento automático é um recurso oferecido no patamar Standard ou mais alto, enquanto alertas de nível de plano são recursos oferecidos no patamar Básico ou superior; você precisará definir o parâmetro sku como Standard ou Premium para ver todos os seus novos recursos do App Insights se iluminarem.

  16. Clique em Implantar. Se você selecionou Salvar senhas, a senha será salva no arquivo de parâmetros em texto sem formatação. Caso contrário, será solicitado que você insira a senha do banco de dados durante o processo de implantação.

É isso! Agora, basta ir para o Portal do Azure e até a ferramenta Gerenciador de Recursos do Azure para ver os novos alertas e configurações de dimensionamento automático adicionados ao seu aplicativo JSON implantado.

As etapas cumpridas nesta seção realizaram principalmente o seguinte:

  1. Prepararam o arquivo de modelo
  2. Criaram um arquivo de parâmetros para acompanhar o arquivo de modelo
  3. Implantaram o arquivo de modelo juntamente com o arquivo de parâmetros

A última etapa é facilmente realizada por um cmdlet do PowerShell. Para ver o que o Visual Studio fez quando implantou seu aplicativo, abra Scripts\Deploy AzureResourceGroup.ps1. Há muito código lá, mas vou destacar todo o código relevante que necessário para implantar o arquivo de modelo com o arquivo de parâmetros.

Shows the pertinent code in the script that you need use to deploy the template file with the parameter file.

O último cmdlet, New-AzureResourceGroup, é o que executa efetivamente a ação. Tudo isso deve demonstrar a você que, com a ajuda de ferramentas, é relativamente fácil implantar seu aplicativo em nuvem de modo previsível. Sempre que você executar o cmdlet no mesmo modelo com o mesmo arquivo de parâmetros, você obterá o mesmo resultado.

Resumo

No DevOps, repetitividade e previsibilidade são essenciais para qualquer implantação bem-sucedida de um aplicativo composto por microsserviços de alta escala. Neste tutorial, você implantou um aplicativo de dois microsserviços no Azure como um único grupo de recursos usando o modelo do Gerenciador de Recursos do Azure. Espera-se que ele tenha dado a você o conhecimento necessário para iniciar a conversão de seu aplicativo do Azure em um modelo e possa ser provisionado e implantado de maneira previsível.

Mais recursos

Próximas etapas

Para saber mais sobre as propriedades e a sintaxe JSON de tipos de recursos implantados neste artigo, consulte: