Refactor uma aplicação no local para uma aplicação web Serviço de Aplicações do Azure e um exemplo gerido pela SQL

Este artigo demonstra como a empresa fictícia Contoso refactoria uma aplicação Windows .NET de dois níveis que está a funcionar em máquinas virtuais VMware (VMs) como parte de uma migração para Azure. A equipa da Contoso migra a aplicação front-end VM para uma aplicação web Serviço de Aplicações do Azure. O artigo também mostra como Contoso migra a base de dados de aplicações para um SQL do Azure caso gerido.

A aplicação SmartHotel360 que utilizamos neste exemplo é fornecida como software de código aberto. Se quiser usá-lo para os seus próprios fins de teste, pode descarregá-lo do GitHub.

Impulsionadores de negócios

A equipa de líderes de TI da Contoso trabalhou de perto com parceiros comerciais para entender o que pretendem alcançar com a migração:

  • Dar resposta ao crescimento da empresa. O Contoso está a crescer e há pressão sobre os seus sistemas e infraestruturas no local.
  • Aumentar a eficiência. A Contoso precisa de remover procedimentos desnecessários e simplificar processos para desenvolvedores e utilizadores. A empresa precisa que as equipas de TI sejam rápidas e não desperdicem tempo ou dinheiro para responder mais rapidamente ao que os clientes pedem.
  • Aumentar a agilidade. As equipas de TI da Contoso precisam de ser mais reativas às necessidades da empresa. Deve ser capaz de reagir mais rapidamente do que as mudanças no mercado, para permitir o sucesso numa economia global. O tempo de reação não deve atrapalhá-lo, nem tornar-se um bloqueador de negócios.
  • Dimensionamento. À medida que os negócios crescem, as equipas de TI da Contoso têm de fornecer sistemas que possam crescer ao mesmo ritmo.
  • Reduzir custos. A Contoso quer minimizar os custos de licenciamento.

Objetivos de migração

Para ajudar a determinar o melhor método de migração, a equipa de nuvem contoso fixou os seguintes objetivos:

Requisitos Detalhes
Aplicação O pedido em Azure permanecerá tão crítico como é hoje no local.

Deve ter as mesmas capacidades de desempenho que tem atualmente no VMware.

A equipa não quer investir na candidatura. Por enquanto, os administradores simplesmente moverão a aplicação em segurança para a nuvem.

A equipa quer deixar de suportar o Windows Server 2008 R2, que a aplicação é atualmente executado.

A equipa quer ainda passar de SQL Server R2 de 2008 para uma plataforma moderna como base de dados de serviço (PaaS), o que irá minimizar a necessidade de gestão.

A Contoso quer tirar partido do Software Assurance e do seu investimento em licenciamento do SQL Server, nas situações em que for possível.

Adicionalmente, a Contoso quer mitigar o ponto único de falha na camada Web.
Limitações A aplicação consiste numa aplicação ASP.NET e num serviço da Windows Communication Foundation (WCF) que funciona no mesmo VM. Querem difundir estes componentes através de duas aplicações web usando o Serviço de Aplicações do Azure.
Azure O Contoso quer mudar a candidatura para o Azure, mas não o querem publicar em VMs. A Contoso quer utilizar os serviços PaaS do Azure para as camadas Web e de dados.
DevOps A Contoso quer mudar-se para um modelo DevOps que usa a Azure DevOps para as suas construções e lançar oleodutos.

Design de solução

Depois de fixar os seus objetivos e requisitos, a Contoso projeta e revê uma solução de implantação. Também identificam o processo de migração, incluindo os serviços Azure que usarão para a migração.

Aplicação atual

  • A aplicação SmartHotel360 no local é izada em dois VMs, WEBVM e SQLVM.
  • Os VMs estão localizados na versão 6.5 do anfitrião contosohost1.contoso.com VMware ESXi.
  • O ambiente VMware é gerido pelo vCenter Server 6.5 (vcenter.contoso.com), que funciona num VM.
  • A Contoso tem um datacenter no local (contoso-datacenter), com um controlador de domínio no local (contosodc1).
  • As VMs no local no datacenter da Contoso vão ser desativadas após a conclusão da migração.

Solução proposta

  • Para o nível web da aplicação, a Contoso decidiu utilizar Serviço de Aplicações do Azure. Este serviço PaaS permite-lhes implementar a aplicação com apenas algumas alterações de configuração. O Contoso vai usar o Visual Studio para fazer a mudança, e vão implementar duas aplicações web, uma para o site e outra para o serviço WCF.
  • Para satisfazer os requisitos para um oleoduto DevOps, a Contoso utilizará a Azure DevOps para a gestão de códigos fonte com repos Git. Usarão construções automatizadas e libertarão para construir o código e implantá-lo para o Serviço de Aplicações do Azure.

Considerações sobre a base de dados

Como parte do processo de design de solução, a Contoso fez uma comparação de funcionalidades entre SQL do Azure Database e SQL Managed Instance. Decidiram utilizar SQL Managed Instance com base nas seguintes considerações:

  • SQL Managed Instance pretende entregar quase 100% de compatibilidade com a versão mais recente SQL Server no local. A Microsoft recomenda SQL Managed Instance para clientes que estão a executar SQL Server no local ou em infraestruturas como um VM de serviço (IaaS) que querem migrar as suas aplicações para um serviço totalmente gerido com alterações mínimas de design.
  • A Contoso está a planear migrar um grande número de aplicações de entradas para IaaS VMs. Muitos destes VMs são fornecidos por fornecedores de software independentes. A Contoso percebe que o uso de SQL Managed Instance ajudará a garantir a compatibilidade da base de dados para estas aplicações. Usarão SQL Managed Instance em vez de Base de Dados SQL, que pode não ser apoiada.
  • Contoso pode simplesmente fazer um elevador e transferir a migração para SQL Managed Instance usando o Azure Database Migration Service totalmente automatizado. Com este serviço, a Contoso pode reutilizá-lo para futuras migrações da base de dados.
  • SQL Managed Instance suporta SQL Server Agent, um componente importante da aplicação SmartHotel360. Contoso precisa desta compatibilidade; caso contrário, terão de redesenhar os planos de manutenção exigidos pela aplicação.
  • Com a Software Assurance, a Contoso pode trocar as suas licenças existentes por tarifas com desconto numa versão gerida pela SQL, utilizando o Benefício Híbrido do Azure para SQL Server. Isto permite que Contoso economize até 30 por cento usando SQL Managed Instance.
  • O exemplo gerido pelo SQL está totalmente contido na rede virtual, pelo que proporciona um maior isolamento e segurança aos dados de Contoso. Contoso pode obter os benefícios da nuvem pública, mantendo o ambiente isolado da internet pública.
  • SQL Managed Instance suporta muitas funcionalidades de segurança, incluindo máscara de dados sempre encriptada, dinâmica, segurança ao nível da linha e deteção de ameaças.

Análise da solução

Contoso avalia o seu design proposto reunindo uma lista de prós e contras, como mostra a seguinte tabela:

Consideração Detalhes
Vantagens O código de aplicação SmartHotel360 não requer alterações para a migração para a Azure.

A Contoso pode aproveitar o seu investimento em Software Assurance utilizando o Benefício Híbrido do Azure tanto para SQL Server como para o Windows Server.

Após a migração, o Windows Server 2008 R2 não terá de ser suportado. Para mais informações, consulte a Política de Ciclo de Vida da Microsoft.

Contoso pode configurar o nível web da aplicação com múltiplas instâncias, de modo que o nível web não é mais um único ponto de falha.

A base de dados deixará de depender do antigo SQL Server 2008 R2.

A Instância Gerida do SQL suporta os requisitos técnicos e os objetivos da Contoso.

A instância gerida pelo SQL proporcionará 100% de compatibilidade com a sua implementação atual, afastando-os do SQL Server R2 de 2008.

A Contoso pode aproveitar o seu investimento em Software Assurance e utilizar o Benefício Híbrido do Azure para SQL Server e Windows Server.

Podem reutilizar Azure Database Migration Service para migrações futuras adicionais.

O exemplo gerido pela SQL tem tolerância a falhas incorporadas que Contoso não precisa de configurar. Tal garante que a camada de dados já não é um ponto único de ativação pós-falha.
Desvantagens Serviço de Aplicações do Azure suporta apenas uma implementação de aplicação para cada aplicação web. Isto significa que duas aplicações web devem ser a provisionadas, uma para o site e outra para o serviço WCF.

Para o nível de dados, SQL Managed Instance pode não ser a melhor solução se a Contoso quiser personalizar o sistema operativo ou o servidor de base de dados, ou se pretender executar aplicações de terceiros juntamente com SQL Server. A execução do SQL Server numa VM IaaS pode oferecer esta flexibilidade.

Arquitetura proposta

Diagrama da arquitetura proposta.

Processo de migração

  1. A Contoso prevê um SQL do Azure caso gerido e, em seguida, migra a base de dados SmartHotel360 para ele, utilizando Azure Database Migration Service.

  2. Contoso fornece e configura aplicações web e implementa a aplicação SmartHotel360 para as suas.

    Diagrama do processo de migração.

Serviços do Azure

Serviço Description Custo
Assistente de Migração do Serviço de Aplicações do Azure Um caminho livre e simples para migrar perfeitamente as aplicações web .NET do local para a nuvem com alterações mínimas a nenhuma codificação. É uma ferramenta transferível, gratuitamente.
Azure Database Migration Service Azure Database Migration Service permite a migração sem emenda de múltiplas fontes de base de dados para plataformas de dados Azure com tempo de inatividade mínimo. Conheça as regiões apoiadas e os preços Azure Database Migration Service.
Instância Gerida do SQL no Azure SQL Managed Instance é um serviço de base de dados gerido que representa uma SQL Server totalmente gerida em Azure. Utiliza o mesmo código que a última versão do Motor de Base de Dados do SQL Server e possui as mais recentes funcionalidades, melhorias de desempenho e patches de segurança. A utilização de um exemplo gerido pela SQL que funciona em Azure incorre em encargos baseados na capacidade. Saiba mais sobre SQL Managed Instance preços.
Serviço de Aplicações do Azure Ajuda a criar aplicações em nuvem poderosas que usam uma plataforma totalmente gerida. Os preços baseiam-se no tamanho, localização e duração de utilização. Saiba mais.
Pipelines do Azure Proporciona um gasoduto de integração contínua e de implantação contínua (CI/CD) para o desenvolvimento de aplicações. O oleoduto começa com um repositório git para a gestão do código de aplicação, um sistema de construção para a produção de pacotes e outros artefactos de construção, e um sistema de gestão de libertação para implementar alterações em ambientes dev, teste e produção.

Pré-requisitos

Para executar este cenário, Contoso deve cumprir os seguintes pré-requisitos:

Requisitos Detalhes
Assinatura Azure A Contoso criou subscrições anteriormente neste conjunto de artigos. Se não tiver uma subscrição do Azure, crie uma conta gratuita.

Se criar uma conta gratuita, será o administrador da sua subscrição e poderá executar todas as ações.

Se utilizar uma subscrição já existente e não for o administrador, terá de trabalhar com o mesmo para que lhe atribua as permissões Proprietário ou Contribuidor.
Infraestrutura do Azure A Contoso configurou a sua infraestrutura Azure conforme descrito em Infraestrutura do Azure para migração.

Passos do cenário

Veja a seguir como a Contoso vai executar a migração:

  • Passo 1: Avaliar e migrar as aplicações web.. Contoso usa a ferramenta Serviço de Aplicações do Azure Migration Assistant para executar verificações de compatibilidade pré-migração e migrar as suas aplicações web para Serviço de Aplicações do Azure.
  • Passo 2: Crie uma instância gerida pelo SQL. A Contoso necessita de uma instância gerida existente para a qual a base de dados do SQL Server no local será migrada.
  • Passo 3: Migrar através Azure Database Migration Service. Contoso migra a base de dados de aplicações através de Azure Database Migration Service.
  • Passo 4: Configurar Azure DevOps. Contoso cria um novo projeto Azure DevOps e importa o git repo.
  • Passo 5: Configurar as cordas de ligação. Contoso configura as cadeias de conexão para que a aplicação web de nível web, a aplicação web de serviço WCF e a instância gerida pelo SQL possam comunicar.
  • Passo 6: Configurar e soltar gasodutos em Azure DevOps. Como último passo, a Contoso cria oleodutos de construção e lançamento em Azure DevOps para criar a aplicação. Em seguida, a equipa implementa os gasodutos em duas aplicações web separadas.

Passo 1: Avaliar e migrar as aplicações web

Os administradores da Contoso avaliam e migram a sua aplicação web utilizando a ferramenta Serviço de Aplicações do Azure Migration Assistant. Eles usam o caminho de aprendizagem migração ASP.NET para Azure como um guia durante o processo. Em resumo, os administradores realizam as seguintes ações:

  • Eles usam a ferramenta de avaliação de migração Azure Serviço de Aplicações para avaliar quaisquer dependências entre as suas aplicações web e para determinar se existem incompatibilidades entre as suas aplicações web no local e o que é suportado em Serviço de Aplicações do Azure.

  • Descarregam o Serviço de Aplicações do Azure Assistente de Migração e inscrevem-se na sua conta Azure.

  • Eles escolhem uma subscrição, um grupo de recursos e o nome de domínio do site.

Passo 2: Criar uma instância gerida pela SQL

Para criar um SQL do Azure caso gerido, a Contoso precisa de uma sub-rede que satisfaça os seguintes requisitos:

  • A sub-rede tem de ser dedicada. Tem de estar vazia e não pode incluir qualquer outro serviço de cloud. A sub-rede não pode ser uma sub-rede de gateway.
  • Após a criação da instância gerida, a Contoso não deve adicionar recursos à sub-rede.
  • A sub-rede não pode ter um grupo de segurança de rede associado.
  • A sub-rede tem de ter uma tabela de rota definida pelo utilizador. A única rota atribuída deve ser 0.0.0.0/0 a internet do próximo salto.
  • Se for especificado um DNS personalizado opcional para a rede virtual, o endereço 168.63.129.16 IP virtual para as resoluções recursivas em Azure deve ser adicionado à lista. Saiba como configurar um DNS personalizado para uma SQL do Azure caso gerido.
  • sub-rede não pode ter um ponto final de serviço (armazenamento ou SQL) associado. Os pontos finais de serviço devem ser desativados na rede virtual.
  • A sub-rede tem de ter um mínimo de 16 endereços IP. Saiba como dimensionar a sub-rede de instância gerida.
  • No ambiente híbrido da Contoso, são necessárias definições de DNS personalizadas. A Contoso configura as definições de DNS para utilizar um ou mais dos servidores DNS do Azure da empresa. Saiba mais sobre a personalização do DNS.

Criar uma rede virtual para a instância gerida

Os administradores da Contoso configuram a rede virtual da seguinte forma:

  1. Criam uma nova rede virtual (VNET-SQLMI-EU2) na região primária (East US 2). Adiciona a rede virtual ao ContosoNetworkingRG grupo de recursos.

  2. Atribuem um espaço de endereço de 10.235.0.0/24. Asseguram que o intervalo não se sobrepõe a quaisquer outras redes na empresa.

  3. Adicionam duas sub-redes à rede:

    • SQLMI-DS-EUS2 (10.235.0.0/25).

    • SQLMI-SAW-EUS2 (10.235.0.128/29). Esta sub-rede é utilizada para anexar um diretório à instância gerida.

      Screenshot do painel de rede virtual Create para a instância gerida.

  4. Após serem implementadas a rede virtual e as sub-redes, fazem o peering das redes da seguinte forma:

    • Pares VNET-SQLMI-EUS2 com VNET-HUB-EUS2 (a rede virtual do hub para East US 2).

    • Pares VNET-SQLMI-EUS2 com VNET-PROD-EUS2 (a rede de produção).

      Screenshot das redes espreitadas.

  5. Personalizam as definições do DNS. As definições de DNS apontam primeiro para os controladores de domínio Azure de Contoso. O DNS do Azure é secundário. Os controladores de domínio do Azure da Contoso estão localizados com a seguir:

    • Localizada na PROD-DC-EUS2 sub-rede da rede de produção (VNET-PROD-EUS2) na East US 2 região.

    • CONTOSODC3 endereço: 10.245.42.4

    • CONTOSODC4 endereço: 10.245.42.5

    • Azure DNS resolver: 168.63.129.16

    Screenshot da lista de servidores DNS da rede.

Precisa de mais ajuda?

Configurar o encaminhamento

O caso gerido é colocado numa rede virtual privada. A Contoso precisa de uma tabela de rotas para a rede virtual comunicar com o serviço de gestão Azure. Se a rede virtual não puder comunicar com o serviço que a gere, a rede virtual ficará inacessível.

A Contoso considera os seguintes fatores:

  • A tabela de rotas contém um conjunto de regras (rotas) que especificam como os pacotes enviados a partir da instância gerida devem ser encaminhados na rede virtual.
  • A tabela de rotas está associada a sub-redes onde são implementadas instâncias geridas. Cada pacote que deixa uma sub-rede é tratado com base na tabela de rota associada.
  • Uma sub-rede pode ser associada a apenas uma tabela de rota.
  • Não existem custos adicionais para a criação de tabelas de rota no Microsoft Azure.

Para configurar o encaminhamento, os administradores da Contoso fazem o seguinte:

  1. Criam uma tabela de rotas definida pelo utilizador no grupo de ContosoNetworkingRG recursos.

    Screenshot do painel de tabela de rota Create.

  2. Para cumprir os requisitos SQL Managed Instance, após a colocação da tabela de rotas (MIRouteTable) os administradores adicionam uma rota com um prefixo de endereço de 0.0.0.0/0. A opção Tipo do próximo salto é definida como Internet.

    Screenshot do painel de rota Adicionar para adicionar um prefixo de endereço.

  3. Associam a tabela de rotas à SQLMI-DB-EUS2 sub-rede (na VNET-SQLMI-EUS2 rede).

    Screenshot do painel de sub-redes Associado para encaminhamento da sub-rede da tabela.

Precisa de mais ajuda?

Saiba como configurar rotas para um caso gerido.

Criar uma instância gerida

Agora, os administradores da Contoso prevêem um SQL gerido por exemplo, fazendo o seguinte:

  1. Como o caso gerido serve uma aplicação de negócio, os administradores implantam o caso gerido na região primária da empresa (East US 2). Acrescentam a instância gerida ao ContosoRG grupo de recursos.

  2. Selecionam um escalação de preços, o cálculo do dimensionamento e o armazenamento da instância. Saiba mais sobre SQL Managed Instance preços.

    Screenshot do painel de SQL Managed Instance.

    Após a implementação da instância gerida, aparecem dois novos recursos no ContosoRG grupo de recursos:

    • O SQL geriu o exemplo.

    • Um cluster virtual, caso Contoso tenha múltiplas instâncias geridas.

      Screenshot de novos recursos no grupo de recursos ContosoRG.

Precisa de mais ajuda?

Saiba como providenciar um caso gerido.

Passo 3: Migrar através de Azure Database Migration Service

Os administradores de Contoso migram a instância gerida através de Azure Database Migration Service seguindo as instruções no tutorial de migração passo a passo. Podem realizar migrações online, offline e híbridas (pré-visualização).

Em resumo, os administradores de Contoso fazem o seguinte:

  • Criam um Azure Database Migration Service exemplo com um SKU Premium que está ligado à rede virtual.
  • Garantem que Database Migration Service podem aceder ao SQL Server remoto através da rede virtual. Isto implicaria garantir que todas as portas de entrada são permitidas de Azure para SQL Server ao nível da rede virtual, a VPN de rede e a máquina que acolhe SQL Server.
  • Configuram Azure Database Migration Service:
    • Criar um projeto de migração.
    • Adicione uma fonte (base de dados no local).
    • Selecione um alvo.
    • Selecione as bases de dados para migrar.
    • Configurar configurações avançadas.
    • Inicie a replicação.
    • Resolva os erros existentes.
    • Execute o corte final.

Passo 4: Configurar Azure DevOps

A Contoso tem de compilar a infraestrutura e os pipelines do DevOps para a aplicação. Para isso, os administradores da Contoso criam um novo projeto DevOps, importam o código e, em seguida, criam oleodutos de construção e libertação.

  1. Na conta Contoso Azure DevOps, eles criam um novo projeto, ContosoSmartHotelRefactore depois selecionam Git para controlo de versão.

    Screenshot do novo painel de projeto.

  2. Importam o git repo que detém atualmente o seu código de aplicação. Descarregam-no do repositório público do GitHub.

    Screenshot do painel de repositório De Importação a Git para especificar o tipo de origem e URL de clone.

  3. Ligam o Visual Studio ao repo e clonam o código à máquina de desenvolvimento utilizando o Team Explorer.

    Screenshot do painel de ligação a um painel de projeto.

  4. Abrem o ficheiro de solução para o pedido. A aplicação web e o serviço WCF têm projetos separados dentro do ficheiro.

    Screenshot de Explorador de Soluções, listando a aplicação web e os projetos de serviço WCF.

Passo 5: Configurar cordas de ligação

Os administradores do Contoso asseguram que as aplicações web e a base de dados podem comunicar entre si. Para isso, configuram as cadeia de ligação no código e nas aplicações Web.

  1. Na aplicação web para o serviço WCF, SHWCF-EUS2, em definições de Aplicação de Definições>, eles adicionam uma nova cadeia de conexão chamada .DefaultConnection

  2. Puxam o fio de ligação da SmartHotel-Registration base de dados e atualizam-no com as credenciais corretas.

    Screenshot do painel de definições de ligação.

  3. No Visual Studio, os administradores abrem o projeto a SmartHotel.Registration.wcf partir do ficheiro de solução. No projeto, atualizam a connectionStrings secção do web.config ficheiro com a cadeia de ligação.

    Screenshot da secção de conexãoStrings do ficheiro web.config no projeto SmartHotel.Registration.wcf.

  4. Alteram a client secção do web.config ficheiro para SmartHotel.Registration.Web indicar a nova localização do serviço WCF. Este é o URL da aplicação web WCF que acolhe o ponto final do serviço.

    Screenshot da secção de clientes do ficheiro web.config no projeto SmartHotel.Registration.wcf.

  5. Com as alterações de código agora em vigor, os administradores comprometem-se e sincronizam-nos utilizando o Team Explorer no Visual Studio.

Passo 6: Configurar e libertar gasodutos em Azure DevOps

Os administradores contoso agora configuram Azure DevOps para executar o processo de construção e lançamento.

  1. Em Azure DevOps, selecionam Build e lançam>novo oleoduto.

    Screenshot da nova ligação do gasoduto em Azure DevOps.

  2. Selecionam Repositório Git do Azure e o repositório relevante.

    Screenshot do botão Azure Repos Git e do repositório selecionado.

  3. Em Selecionar um modelo, selecionam o modelo ASP.NET para a compilação.

    Screenshot do painel de modelo Selecione um painel de modelo para selecionar o modelo de ASP.NET.

  4. Eles usam o nome ContosoSmartHotelRefactor-ASP.NET-CI para a construção e, em seguida, selecionam Save & Queue, que dá início à primeira construção.

    Screenshot do botão 'Guardar & a fila' para a construção.

  5. Selecionam o número de compilação para observação do processo. Depois de terminado, os administradores podem ver o feedback do processo, e eles selecionam Artefactos para rever os resultados da construção.

    Screenshot da página de construção e da ligação artefactos para rever os resultados da construção.

    O painel de exploradores de Artefactos abre-se e a pasta de queda apresenta os resultados da construção.

    • Os dois .zip ficheiros são os pacotes que contêm as aplicações.
    • Estes .zip ficheiros são utilizados no gasoduto de libertação para serem implantados para Serviço de Aplicações do Azure.

    Screenshot do painel de exploradores de artefactos.

  6. Selecionam Lançamentos>+ Novo oleoduto.

    Screenshot mostrando a nova ligação do gasoduto.

  7. Selecionam o modelo de implementação para o Serviço de Aplicações do Azure.

    Screenshot do modelo de implementação Serviço de Aplicações do Azure.

  8. Eles nomeiam o pipeline de libertação ContosoSmartHotel360Refactor e, na caixa de nomes de palco , especificam SHWCF-EUS2 como o nome da aplicação web WCF.

    Screenshot do nome artístico da aplicação web WCF.

  9. Nas fases, selecionam 1 trabalho, 1 tarefa para configurar a implementação do serviço WCF.

    Screenshot do trabalho 1, 1 opção de tarefa.

  10. Verificam se a subscrição é selecionada e autorizada e, em seguida, selecionam o nome do serviço de aplicações.

    Screenshot de selecionar o nome do serviço de aplicações.

  11. Na conduta, selecionam Artefactos, selecionam + Adicione um artefacto, selecione Build como o tipo de origem e, em seguida, construa com o ContosoSmarthotel360Refactor pipeline.

    Screenshot do botão Build no painel de artefactos Adicionar um artefacto.

  12. Para ativar o gatilho de implantação contínua, os administradores selecionam o ícone do relâmpago no artefacto.

    Screenshot do ícone do relâmpago no artefacto.

  13. Eles definem o gatilho de implementação contínua para Ativado.

    Screenshot mostrando o conjunto de gatilho de implementação contínua para Ativado.

  14. Os administradores voltam ao trabalho de fase 1, 1 tarefa e, em seguida, selecionam Implementar Serviço de Aplicações do Azure.

    Screenshot da opção de selecionar Implementar Serviço de Aplicações do Azure.

  15. Em Selecionar um ficheiro ou pasta, expandem a pasta drop , selecionam o SmartHotel.Registration.Wcf.zip ficheiro que foi criado durante a construção e, em seguida, selecionam Guardar.

    Screenshot do painel de ficheiros ou pasta selecione um painel de ficheiros ou pasta para selecionar o ficheiro WCF.

  16. Selecionam Fases de Pipeline> e, em seguida,selecionam + Adicionar para adicionar um ambiente para SHWEB-EUS2. Selecionam outra implementação do Serviço de Aplicações do Azure.

    Screenshot do trabalho 1, 1 link de tarefa para adicionar um ambiente.

  17. Repetem o processo para publicar o ficheiro da aplicação SmartHotel.Registration.Web.zip web para a aplicação web correta e, em seguida, selecionam Save.

    Screenshot do painel de ficheiros ou pasta selecione um painel de ficheiros ou pasta para selecionar o ficheiro Web.

    O gasoduto de desbloqueio é apresentado, como mostrado aqui:

    Screenshot do resumo do gasoduto de lançamento.

  18. Voltam a construir, selecionam Triggers e, em seguida, selecionam a caixa de verificação de integração contínua Enable . Esta ação permite que o gasoduto permita que, quando as alterações são comprometidas com o código, ocorram a construção e a libertação completas.

    Screenshot realçando a caixa de verificação de integração contínua Enable.

  19. Selecionam Save & Queue para executar o pipeline completo. É desencadeada uma nova construção, que por sua vez cria o primeiro lançamento da aplicação para o Serviço de Aplicações do Azure.

    Screenshot do botão Save & Queue.

  20. Os administradores da Contoso podem acompanhar o processo do pipeline de compilação e versão no Azure DevOps. Depois que a construção termina, o lançamento começa.

    Screenshot de construção e libertação.

  21. Após o fim do pipeline, ambos os sites foram implantados e a aplicação está a funcionar online.

    Screenshot mostrando que a aplicação está em funcionamento.

    A aplicação foi migrada com sucesso para Azure.

Limpe depois da migração

Após a migração, a equipa de Contoso completa as seguintes etapas de limpeza:

  • Retiram os VMs no local do inventário vCenter.
  • Retiram os VM dos trabalhos de apoio locais.
  • Atualizam a documentação interna para mostrar as novas localizações para a aplicação SmartHotel360. A documentação mostra a base de dados como executando no sql gerido instância, e a extremidade frontal como executando em duas aplicações web.
  • Eles analisam quaisquer recursos que interagem com os VMs desativados, e atualizam quaisquer configurações ou documentação relevantes para refletir a nova configuração.

Rever a implementação

Com os recursos agora migrados para Azure, a Contoso precisa de operacionalizar plenamente e ajudar a garantir a sua nova infraestrutura.

Segurança

  • Contoso ajuda a garantir que a sua nova SmartHotel-Registration base de dados é segura. Saiba mais.
  • Em particular, a Contoso atualiza as aplicações web para utilizar sSL com certificados.

Cópias de segurança

  • A equipa da Contoso revê os requisitos de backup para a base de dados em Azure SQL Managed Instance. Saiba mais.
  • Eles também aprendem sobre a gestão de Base de Dados SQL backups e restauros. Saiba mais sobre backups automáticos.
  • Consideram a aplicação de grupos de failover para fornecer o failover regional para a base de dados. Saiba mais.
  • Consideram a implementação da aplicação web na região principal (East US 2) e na região secundária (Central US) para resiliência. A equipa poderia configurar o Gestor de Tráfego para garantir o fracasso durante as paragens regionais.

Licenciamento e otimização de custos

  • Depois de todos os recursos serem mobilizados, a Contoso atribui tags Azure com base no seu planeamento de infraestruturas.
  • Todo o licenciamento é integrado no custo dos serviços PaaS que a Contoso está a consumir. Este custo é deduzido do Contrato Enterprise.
  • A Contoso utilizará a Azure Cost Management + Billing para garantir que se mantenham dentro dos orçamentos estabelecidos pela sua liderança de TI.

Conclusão

Neste artigo, a Contoso refactorizou a aplicação SmartHotel360 em Azure ao migrar a aplicação front-end VM para duas aplicações web Serviço de Aplicações do Azure. A base de dados de aplicações foi migrada para um SQL do Azure caso gerido.