Refactor uma aplicação Linux utilizando Serviço de Aplicações do Azure, Gerente de Tráfego e Base de Dados do Azure para MySQL

Este artigo mostra como a empresa fictícia Contoso refactoria uma aplicação baseada em LÂMPADA de dois níveis, migrando-a de instalações para Azure usando Serviço de Aplicações do Azure com integração gitHub e Base de Dados do Azure para MySQL.

O osTicket, a aplicação de balcão de atendimento 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 a partir do repo osTicket em GitHub.

Impulsionadores de negócios

A equipa de liderança de TI tem trabalhado em estreita colaboração com parceiros de negócios para entender o que querem alcançar:

  • Dar resposta ao crescimento da empresa. A Contoso está a crescer e a mudar para novos mercados. Precisa de agentes de suporte ao cliente adicionais.
  • Dimensionamento. A solução deve ser compilada para que a Contoso possa adicionar mais agentes de suporte ao cliente à medida que os negócios são dimensionados.
  • Melhorar a resiliência. No passado, os problemas com o sistema afetavam apenas os utilizadores internos. Com o novo modelo de negócio, os utilizadores externos serão afetados, e a Contoso precisa sempre da aplicação em funcionamento.

Objetivos de migração

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

  • A aplicação deve ser dimensionada além da capacidade e do desempenho no local atuais. A Contoso está a mover a aplicação para tirar partido do dimensionamento a pedido do Azure.
  • A Contoso quer mover a base de código de aplicação para um gasoduto de entrega contínua. À medida que as alterações de candidatura são empurradas para o GitHub, a Contoso quer implementar essas alterações sem tarefas para o pessoal de operações.
  • A aplicação deve ser resiliente, com capacidades de crescimento e de saturação. A Contoso quer implementar a aplicação em duas regiões diferentes do Azure e instalá-la automaticamente.
  • A Contoso pretende minimizar as tarefas de administração da base de dados depois de a aplicação ser movida para a cloud.

Design de solução

Após definir as suas metas e os seus requisitos, a Contoso concebe e analisa uma solução de implementação, assim como identifica o processo de migração, incluindo os serviços do Azure que vão ser utilizado para a migração.

Arquitetura atual

  • A aplicação é hierárquica em duas máquinas virtuais (VMs) (OSTICKETWEB e OSTICKETMYSQL.
  • As VMs estão num anfitrião ESXi do VMware contosohost1.contoso.com (versão 6.5).
  • O ambiente do VMware é gerido pelo vCenter Server 6.5 (vcenter.contoso.com), em execução numa VM.
  • A Contoso tem um datacenter no local (contoso-datacenter), com um controlador de domínio no local (contosodc1).

Diagrama da arquitetura atual.

Arquitetura proposta

Eis a arquitetura proposta:

  • A aplicação OSTICKETWEB de nível web será migrada através da construção de uma aplicação web Serviço de Aplicações do Azure em duas regiões do Azure. A equipa contoso implementará Serviço de Aplicações do Azure para o Linux utilizando o contentor PHP 7.0 Docker.
  • O código de aplicação será transferido para o GitHub, e a aplicação web Serviço de Aplicações do Azure será configurada para entrega contínua com o GitHub.
  • Serviço de Aplicações do Azure serão implantados tanto na região primária (East US 2) como na região secundária (Central US).
  • O Azure Traffic Manager será criado em frente às duas aplicações web em ambas as regiões.
  • O Gestor de Tráfego será configurado em modo prioritário para forçar o tráfego através East US 2de .
  • Se o servidor de aplicações Azure entrar em East US 2 offline, os utilizadores podem aceder à aplicação falhada em Central US.
  • A base de dados de aplicações será migrada para o serviço Base de Dados do Azure para MySQL utilizando Azure Database Migration Service. Vai ser criada uma cópia de segurança localmente da base de dados no local, sendo depois restaurada diretamente para a Base de Dados do Azure para MySQL.
  • A base de dados residirá na região primária (East US 2) na sub-rede de base de dados (PROD-DB-EUS2) da rede de produção (VNET-PROD-EUS2).
  • Uma vez que estão a migrar uma carga de trabalho de produção, os recursos da Azure para a aplicação residirão no grupo ContosoRGde recursos de produção.
  • O recurso do Gestor de Tráfego será implantado no grupo ContosoInfraRGde recursos de infraestrutura da Contoso.
  • As VMs no local no datacenter da Contoso vão ser desativadas após a conclusão da migração.

Diagrama da arquitetura do cenário.

Processo de migração

Contoso completa o processo de migração da seguinte forma:

  1. Como primeiro passo, os administradores da Contoso criaram a infraestrutura Azure, incluindo o provisionamento Serviço de Aplicações do Azure, a criação de Gestores de Tráfego e o fornecimento de uma Base de Dados do Azure para MySQL instância.
  2. Depois de preparar a infraestrutura Azure, migram a base de dados utilizando Azure Database Migration Service.
  3. Depois de a base de dados estar em funcionamento em Azure, eles carregam um repositório privado GitHub para Serviço de Aplicações do Azure com entrega contínua, e carregam-no com a aplicação osTicket.
  4. No portal do Azure, carregam a aplicação do GitHub para o contentor Docker executando Serviço de Aplicações do Azure.
  5. Ajustam as definições de DNS e configuram a autoscalagem para a aplicação.

Diagrama do processo de migração de Contoso.

Serviços do Azure

Serviço Descrição Custo
Serviço de Aplicações do Azure O serviço executa e escala aplica aplicações usando a plataforma Azure como um serviço (PaaS) para websites. Os preços baseiam-se na dimensão das instâncias e nas características necessárias. Saiba mais.
Gestor de Tráfego do Azure Um equilibrador de carga que usa o Sistema de Nome de Domínio (DNS) para direcionar os utilizadores para o Azure ou para sites e serviços externos. Os preços baseiam-se no número de consultas de DNS recebidas e no número de pontos finais monitorizados. Saiba mais.
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. Saiba mais sobre as regiões suportadas e os preços do Database Migration Service.
Base de Dados do Azure para MySQL A base de dados baseia-se no motor de base de dados MySQL de código aberto. Fornece uma base de dados MySQL, totalmente gerida e pronta para a empresa, para o desenvolvimento e implementação de aplicações. Os preços baseiam-se nos requisitos de computação, armazenamento e backup. Saiba mais.

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

Aqui está o plano Contoso para completar a migração:

  • Passo 1: Provisão Serviço de Aplicações do Azure. Os administradores da Contoso vão aprovisionar as aplicações Web nas regiões primária e secundária.
  • Passo 2: Configurar o Gestor de Tráfego. Configuram o Gestor de Tráfego à frente das aplicações Web, para o encaminhamento e balanceamento de carga do tráfego.
  • Passo 3: Provisão Base de Dados do Azure para MySQL. No Azure, aprovisionam uma instância da Base de Dados do Azure para MySQL.
  • Passo 4: Migrar a base de dados. Migram a base de dados usando Azure Database Migration Service.
  • Passo 5: Instale o GitHub. Eles criaram um repositório gitHub local para os sites e código da aplicação.
  • Passo 6: Configurar as aplicações web. Configuram as aplicações web com os websites osTicket.

Passo 1: Serviço de Aplicações do Azure de provisão

Os administradores da Contoso disponibilizam duas aplicações web (uma em cada região) utilizando Serviço de Aplicações do Azure.

  1. Eles criam um recurso de aplicação web (osticket-eus2) na região primária (East US 2) via Azure Marketplace.

  2. Colocam o recurso no grupo ContosoRGde recursos de produção.

    Screenshot do painel web app para criar uma aplicação web em Linux.

  3. Criam um plano Serviço de Aplicações, APP-SVP-EUS2na região primária, e usam o tamanho padrão.

    Screenshot do painel do Plano nova-Serviço de Aplicações para criar um plano Serviço de Aplicações.

  4. Selecionam um SO Linux com uma pilha de tempo de execução PHP 7.0, que é um contentor do Docker.

    Screenshot do painel web app, com Linux OS, localização East US 2 e PHP 7.0 selecionados.

  5. Eles criam uma segunda aplicação web, osticket-cuse um plano Serviço de Aplicações do Azure para a Central US.

    Screenshot do painel web app, com Linux OS, localização central dos EUA e PHP 7.0 selecionados.

Precisa de mais ajuda?

Passo 2: Configurar gestor de tráfego

Os administradores da Contoso criaram o Traffic Manager para direcionar os pedidos de entrada web para as aplicações web que estão a ser executadas no nível web do osTicket.

  1. Em Azure Marketplace, criam um recurso de Gestor de Tráfego, osticket.trafficmanager.net. Eles usam o encaminhamento prioritário para que o East US 2 seja o local principal. Colocam o recurso no seu grupo de recursos de infraestrutura existente, ContosoInfraRG. Observe que o Gestor de Tráfego é global e não está vinculado a um local específico.

    Screenshot do painel de perfil do Gestor de Tráfego Create.

  2. Configuram o Gestor de Tráfego com pontos finais. Eles adicionam a aplicação web no East US 2 como o site principal, osticket-eus2e a aplicação web nos EUA central como o site secundário, osticket-cus.

    Screenshot do painel de ponto final add no Gestor de Tráfego.

  3. Depois de adicionarem os pontos finais, os administradores podem monitorizá-los.

    Screenshot do painel endpoints para monitorizar pontos finais no Traffic Manager.

Precisa de mais ajuda?

Passo 3: Base de Dados do Azure para MySQL de provisão

Os administradores de Contoso prevêem uma placa de base de dados MySQL na região primária, East US 2.

  1. No portal do Azure, criam um recurso de Base de Dados do Azure para MySQL.

    Screenshot do link Base de Dados do Azure para MySQL no portal do Azure.

  2. Acrescentam o nome contosoosticket da base de dados Azure. Eles adicionam a base de dados ao grupo ContosoRG de recursos de produção e, em seguida, especificam credenciais para ele.

  3. A base de dados MySQL no local é a versão 5.7, portanto, selecionam esta versão para compatibilidade. Utilizam os tamanhos padrão, que correspondem aos respetivos requisitos da base de dados.

    Screenshot do painel do Servidor MySQL, com a versão 5.7 selecionada.

  4. Para opções de redundância de reserva, selecionam Geo-Redundante. Esta opção permite-lhes restaurar a base de dados na sua região secundária (Eua Central) se ocorrer uma paragem. Só podem configurar esta opção quando forjam a base de dados.

    Screenshot do painel de opções de redundância de backup, com a opção Geo-Redundant selecionada.

  5. Configuram a segurança da ligação. Na base de dados, selecionam a segurança de Ligação e, em seguida, configuram regras de firewall para permitir que a base de dados aceda aos serviços Azure.

  6. Adicionam o endereço IP do cliente da estação de trabalho local aos endereços IP inicial e final. Tal permite que as aplicações Web acedam à base de dados MySQL, juntamente com o cliente da base de dados que está a realizar a migração.

    Screenshot do painel de segurança Connection, mostrando o acesso aos serviços Azure ligados e o endereço IP do cliente selecionado.

Passo 4: Migrar a base de dados

Existem várias formas de mover a base de dados MySQL. Cada opção requer que os administradores de Contoso criem uma Base de Dados do Azure para MySQL exemplo para o alvo. Depois de criarem o caso, podem migrar a base de dados utilizando um dos dois caminhos:

  • Passo 4a: Azure Database Migration Service
  • Passo 4b: MySQL Workbench backup e restauro

Passo 4a: Migrar a base de dados através de Azure Database Migration Service

Os administradores de Contoso migram a base de dados através de Azure Database Migration Service seguindo o tutorial de migração passo a passo. Podem realizar migrações online, offline e híbridas (pré-visualização) utilizando o MySQL 5.6 ou 5.7.

Nota

O MySQL 8.0 é suportado em Base de Dados do Azure para MySQL, mas a ferramenta Database Migration Service ainda não suporta esta versão.

Em resumo, Contoso faz o seguinte:

  • Asseguram que todos os pré-requisitos de migração são cumpridos:

    • A fonte do servidor de base de dados MySQL deve corresponder à versão que Base de Dados do Azure para MySQL suporta. Base de Dados do Azure para MySQL suporta a MySQL Community Edition, o motor de armazenamento InnoDB, e a migração através da fonte e do alvo com as mesmas versões.

    • Ativam o registo my.ini binário (Windows) ou my.cnf (Unix). Se não o fizer, causará o seguinte erro no Assistente de Migração:

      Error in binary logging. Variable binlog_row_image has value 'minimal'. Please change it to 'full'.

      Para obter mais informações, consulte opções e variáveis de registo binário na documentação MySQL.

    • O utilizador deve ter o ReplicationAdmin papel.

    • Migrar os esquemas de base de dados sem chaves e gatilhos estrangeiros.

  • Criam uma rede privada virtual (VPN) que liga via ExpressRoute ou VPN à rede de instalações.

  • Criam um Azure Database Migration Service exemplo com um SKU Premium que está ligado à rede virtual.

  • Garantem que Azure Database Migration Service podem aceder à base de dados MySQL através da rede virtual. Isto implica garantir que todas as portas de entrada são permitidas de Azure para MySQL ao nível da rede virtual, a VPN de rede e a máquina que hospeda o MySQL.

  • Executam a ferramenta Database Migration Service e depois fazem o seguinte:

    1. Crie um projeto de migração baseado no SKU Premium.

      Screenshot do painel de visão geral do MySQL, com uma mensagem a dizer que o serviço de migração foi criado com sucesso.

      Screenshot do painel de projeto de migração MySQL.

    2. Adicione uma fonte (base de dados no local).

      Screenshot do assistente de migração Adicione o painel de detalhes da fonte.

    3. Selecione um alvo.

      Screenshot do assistente de migração O painel de detalhes do alvo.

    4. Selecione as bases de dados para migrar.

      Screenshot do mapa do assistente de migração para o painel de bases de dados alvo.

    5. Configurar configurações avançadas.

      Screenshot do painel de configurações do assistente de migração.

    6. Inicie a replicação e resolva quaisquer erros.

      Screenshot do painel de detalhes do servidor.

    7. Execute o corte final.

      Screenshot do painel de detalhes do osTicket.

      Screenshot do painel de corte completo.

      Screenshot da tabela de estado das atividades de migração.

    8. Repor quaisquer chaves e gatilhos estrangeiros.

    9. Modifique as aplicações para utilizar a nova base de dados.

      Screenshot da tabela Atividades migratórias.

Passo 4b: Migrar a base de dados (Bancada MySQL)

  1. Os administradores contoso verificam os pré-requisitos e descarregam mySQL Workbench.

  2. Instalam o MySQL Workbench para Windows, de acordo com as instruções de instalação. A máquina onde instalam a bancada MySQL Workbench deve estar acessível ao osticketmysql VM e ao Azure através da internet.

  3. Na bancada MySQL Workbench, criam uma ligação MySQL a osticketmysql.

    Screenshot do painel de detalhes da ligação MySQL Workbench.

  4. Exportam a base de dados para osticket um ficheiro local autossuficiente.

    Screenshot do painel de exportação de dados da bancada mySQL.

  5. Depois de terem feito o back-base localmente, os administradores criam uma ligação com o Base de Dados do Azure para MySQL caso.

    O painel mySQL Workbench New Connection.

  6. Agora, podem importar (restaurar) a base de dados no Base de Dados do Azure para MySQL caso a partir do ficheiro autossuficiente. Um novo esquema, osticketé criado, por exemplo.

    Screenshot do painel de importação de dados mySQL Workbench.

  7. Depois de restaurarem os dados, os administradores podem questioná-lo usando a bancada MySQL Workbench. Os dados são apresentados no portal do Azure.

    Screenshot do portal do Azure, exibindo dados restaurados.

    Screenshot da lâmina das bases de dados MySQL, com uma seta apontando para a base de dados osTicket.

  8. Os administradores atualizam as informações da base de dados nas aplicações web. Na instância do MySQL, abrem as Cadeias de Ligação.

    Screenshot da ligação de cordas de ligação no exemplo MySQL.

  9. Na lista de cadeias de ligação, selecionam as definições da aplicação web e copiam-nas selecionando Click para copiar.

    Screenshot das definições de aplicações web no exemplo MySQL.

  10. Abrem um novo ficheiro no Bloco de Notas, colam-lhe a corda e atualizam a cadeia para combinar com a base de dados osTicket, a instância MySQL e as definições de credenciais.

    Screenshot da cadeia de ligação colada num ficheiro notepad.

  11. Podem verificar o nome do servidor e iniciar sômposições através do painel de visão geral para a instância MySQL no portal do Azure.

    Screenshot do painel de grupo de recursos, exibindo o nome do servidor e o nome da conta de administração do servidor.

Passo 5: Configurar o GitHub

Os administradores da Contoso criam um novo repo GitHub privado e estabelecem uma ligação à base de dados osTicket em Base de Dados do Azure para MySQL. Em seguida, carregam a aplicação Web no Serviço de Aplicações do Azure.

  1. Eles navegam para o software osTicket public GitHub repo e fork-lo para a conta Contoso GitHub.

    Screenshot da página de repo do GitHub, destacando o botão Fork.

  2. Depois de bifurccionar o repo, navegam na include pasta e selecionam o ost-config.php ficheiro.

    Screenshot do ficheiro PHP no GitHub.

  3. O ficheiro abre no navegador e editam-no.

    Screenshot do ícone de edição de ficheiro (lápis) no GitHub.

  4. No editor, os administradores atualizam os detalhes da base de dados, especificamente para DBHOST e DBUSER.

    Screenshot do painel de edição de ficheiros no GitHub.

  5. Cometem as mudanças.

    Screenshot realçando o botão Desativar alterações no painel de edição.

  6. Para cada aplicação web (osticket-eus2 eosticket-cus), no portal do Azure, selecionam as definições de Aplicação no painel esquerdo e modificam as definições.

    Screenshot realçando o link de definições de aplicação no portal do Azure.

  7. Introduzem a cadeia de ligação com o nome ostickete copiam a cadeia do Bloco de Notas para a área de valor. Selecionam MySQL na lista suspensa junta à cadeia e guardam as definições.

    Screenshot do painel de cordas Connection, realçando a cadeia de ligação osTicket.

Passo 6: Configurar as aplicações web

Como o passo final no processo de migração, os administradores da Contoso configuram as aplicações web com os websites osTicket.

  1. Na aplicação web primária, osticket-eus2abrem a opção de Implementação e, em seguida, definem a fonte para o GitHub.

    Screenshot do painel de opções de implementação, com GitHub selecionado como a fonte.

  2. Selecionam as opções de implementação.

    Screenshot dos detalhes da opção no painel de opções de implementação.

  3. Depois de definirem as opções, a configuração mostra como pendente no portal do Azure.

    Screenshot do painel de opções de implementação, mostrando um estado de site pendente.

  4. Após a configuração ser atualizada e a aplicação web osTicket é carregada do GitHub para o contentor Docker que executa o Serviço de Aplicações do Azure, o site mostra como Ativo.

    Screenshot do painel de opções de implementação.

  5. Repetem os passos anteriores para a aplicação web secundária, osticket-cus.

  6. Depois de o site ser configurado, este é acessível através do perfil do Gestor de Tráfego. O nome DNS é a nova localização da aplicação osTicket. Saiba mais.

    Screenshot do painel de perfil do Gestor de Tráfego, mostrando o nome DNS.

  7. Contoso quer usar um nome DNS que seja fácil de lembrar. No painel New Resource Record , eles criam um pseudónimo, um CNAME, e um nome de domínio totalmente qualificado, osticket.contoso.comque aponta para o nome de Gestor de Tráfego no DNS nos seus controladores de domínio.

    Screenshot do painel New Resource Record, exibindo o nome do pseudónimo e um ponteiro para o Traffic Manager.

  8. Configuram as osticket-eus2 aplicações e osticket-cus web para permitir os nomes de anfitriões personalizados.

    Screenshot do painel de nome de anfitrião do anúncio, realçando o botão Validate.

Configurar o dimensionamento automático

Finalmente, os administradores do Contoso configuraram um escalonamento automático para a aplicação. O dimensionamento automático garante que, à medida que os agentes utilizam a aplicação, as instâncias de aplicação aumentam e diminuem de acordo com as necessidades do negócio.

  1. Em Serviço de AplicaçõesAPP-SVP-EUS2, abrem a Unidade de Escala.

  2. Configuram uma nova definição de autoescala com uma única regra que aumenta a contagem de exemplos por uma quando o uso do CPU para a instância atual é superior a 70 por cento durante 10 minutos.

    Screenshot da página de definições de autoescala para a primeira região.

  3. Configuram a mesma definição APP-SVP-CUS para garantir que o mesmo comportamento se aplica se a aplicação falhar na região secundária. A única diferença é que eles definem a instância padrão para 1, porque isto é apenas para falhas.

    Screenshot da página de definições de autoescala para a segunda região.

Limpeza após a migração

Com a migração completa, a aplicação osTicket é refacizada para funcionar numa aplicação web Serviço de Aplicações do Azure com entrega contínua utilizando um repo GitHub privado. A candidatura decorre em duas regiões para aumentar a resiliência. A base de dados osTicket funciona em Base de Dados do Azure para MySQL após a migração para a plataforma PaaS.

Para limpar após a migração, Contoso faz o seguinte:

  • Retiram os VMware VM do inventário vCenter.
  • Retiram os VMs no local dos trabalhos de apoio locais.
  • Atualizam a documentação interna para mostrar novas localizações e endereços IP.
  • Revejam quaisquer recursos que interajam com os VMs no local e atualizam quaisquer definições ou documentação relevantes para refletir a nova configuração.
  • Reconfiguram a monitorização para apontar para o osticket.trafficmanager.net URL, para rastrear que a aplicação está em funcionamento.

Rever a implementação

Com a aplicação agora em curso, a Contoso precisa de operacionalizar e assegurar plenamente a sua nova infraestrutura.

Segurança

A equipa de segurança da Contoso revê o pedido para determinar quaisquer problemas de segurança. Eles identificam que a comunicação entre a aplicação osTicket e a instância da base de dados MySQL não está configurada para SSL. Fazem tudo isto para garantir que o tráfego da base de dados não pode ser pirateado. Saiba mais.

Cópias de segurança

  • As aplicações web osTicket não contêm dados do estado e, portanto, não requerem cópias de segurança.
  • A equipa do Contoso não precisa de configurar cópias de segurança para a base de dados. A Base de Dados do Azure para MySQL cria e armazena cópias de segurança do servidor automaticamente. A equipa optou por usar geo-redundância para a base de dados, por isso é resistente e pronto para a produção. As cópias de segurança podem ser usadas para restaurar o seu servidor a um ponto no tempo. Saiba mais.

Licenciamento e otimização de custos

  • Não há problemas de licenciamento para a implementação de PaaS.
  • A Contoso utilizará a Azure Cost Management + Billing para garantir que se mantenham dentro dos orçamentos estabelecidos pela sua liderança de TI.