O blog da AWS
AWS Application Migration Service: Por onde começar
Por Dimas Cañas e Angelica Ortega, Arquitetos de Soluções para Parceirias da AWS
O AWS Application Migration Service (também conhecido como AWS MGN) é um novo serviço lançado pela AWS baseado na estratégia de “Rehost”, parte da estrutura “6 R”, que definem as estratégias de migração mais comuns.
Essa estratégia de “Rehost”, também conhecida como “Lift & Shift”, visa hospedar aplicativos na AWS, sem mudanças significativas ou grandes mudanças; efetuando a migração de aplicativos de forma rápida, econômica e alinhada às metas de negócios.
Esta publicação explicará como usar o AWS MGN a partir da console, explicar sua operação e configuração. Um exemplo com um aplicativo de teste baseado em LAMP (Linux, Apache, MySQL e PHP) será usado como base para um guia de instalação básico e passo-a-passo como usar o AWS MGN.
Abaixo está um exemplo da arquitetura geral deste laboratório na Figura 1.
Figura 1. Arquitetura de teste.
Requisitos
- Uma conta da AWS: Se você não tiver uma conta da AWS, siga estas instruções para criar
Como isso funciona?
O AWS Application Migration Service (MGN) é um serviço de migração baseado no CloudEndure, e para usá-lo, precisamos instalar um agente de replicação da AWS. Durante a instalação do mesmo, podemos definir parâmetros de replicação, bem como configurações específicas para gerenciar a preparação de área que o CloudEndure utiliza para replicar servidores. Em seguida, adicionamos uma imagem com a definição de operação descrita acima na Figura 2.
Figura 2. Arquitetura do serviço de migração.
Permissões e instalação
Como primeira etapa, você deve garantir que a região em que você trabalhará tenha esse serviço ativado. Para obter essas informações consulte o site oficial do Application Migration Service, considere que este serviço estabelecerá comunicação via porta 443(HTTPS).
Primeiros passos com o AWS MGN
Comece este exercício prático, no qual você usará um aplicativo de teste LAMP. Para isso, o aplicativo disponível na seção “Application Framework” da documentação do CloudFormation será usado. Como você pode ver na Figura 3, é necessário executar uma pilha do CloudFormation na região do Oregon (us-west-2).
Figura 3. Aplicativo CloudFormation LAMP.
Antes de executar a pilha, é necessário ter um par de chaves a ser atribuído aos servidores a serem implantados pela pilha. Além disso, você deve fornecer valores para os parâmetros solicitados pela pilha, conforme mostrado na Figura 4.
Figura 4. Configurando a pilha.
Quando a execução estiver concluída, você poderá acessar o link do aplicativo implantado na seção “Saídas”, Figura 5.
Figura 5. Seção Saídas Cloudformation.
Para observar a operação da pilha lançada, você pode acessar o link marcado como WebsiteURL, o site será exibido como na Figura 6.
Figura 6. Stack LAMP lançado.
Agora vamos começar com o AWS Application Migration Service (MGN). Este exercício é baseado no guia de início do serviço.
Etapa 1: A primeira etapa de configuração para o serviço de migração de aplicativos é criar o modelo de configuração de replicação. Escolha “Get Started” na página inicial, conforme a Figura 7.
Figura 7. Guia de introdução do AWS Application Migration Service
Você será solicitado a criar o modelo de Configuração de Replicação na primeira vez que fizer login no Application Migration Service. Esse modelo determinará como a replicação de dados funcionará para cada servidor de origem recém-adicionado. No contexto deste teste, você pode usar os valores padrão (VPC padrão, sub-rede, etc.), descritos na Figura 8.
Figura 8. Modelo de configuração de replicação.
Se você quiser saber em detalhes cada um dos parâmetros de configuração, você pode selecionar o link “Info” em cada um deles.
Depois de configurar seu modelo, clique no botão laranja “Create Template”.
Etapa 2: Adicione os servidores de origem ao Migration Application Service, instalando o AWS Replication Agent neles. O agente pode ser instalado em servidores Linux e Windows.
Você precisa revisar os requisitos de instalação, neste caso específico, você deve:
- Gerar credenciais da AWS
- Instalar o Python no servidor de origem (Stack LAMP Web Server). Python 2 (2.4 ou superior) ou Python 3 (3.0 ou superior) é necessário.
Depois de atender aos requisitos de instalação, prossiga com o download do agente. O instalador do agente deve seguir o seguinte formato:
https://aws-application-migration-service – <region>.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py
Substitua <region> pela região da AWS na qual você deseja replicar (neste exemplo: us-west-2). Aqui está um exemplo do comando wget completo:
wget -O. /aws-replication-installer-init.py https://aws-application-migration-service-us-west-2.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py
Em seguida, execute o instalador:
sudo python3 aws-replication-installer-init.py
Você será solicitado a fornecer as credenciais que você criou no ponto a (aws-access-key-id, aws-secret-access-key), as credenciais criadas serão retiradas do download realizado e exibido como na Figura 9.
Figura 9. Configurações de credenciais.
Um instalado pelo agente poderá ver em alguns minutos, o servidor na seção “Servidores de origem”, figura 10.
Figura 10. Tela de servidores de origem.
Você deve esperar até que ele esteja no estado “Ready for Testing” antes de passar para a próxima etapa.
Etapa 3: Depois de adicionar seus servidores de origem ao console, você precisará definir as configurações de inicialização para cada servidor. A configuração de execução é um conjunto de instruções que determinam como uma instância será executada no ambiente Test ou Cutover, para cada servidor de origem na AWS. Você deve definir as configurações de execução antes de iniciar as instâncias.
Clique no servidor na lista “Servidores de origem” e selecione a item “Launch Settings”, figura 11.
Figura 11. Launch Settings.
Você pode usar as configurações padrão ou ajustar as configurações para atender às suas necessidades. Aqui você pode ver a configuração geral da versão e o modelo de inicialização do EC2. Clique no botão Edit para editar as configurações de versão ou Modify para editar o modelo de inicialização do EC2, Figura 12.
Figura 12. Editando e modificando configurações de inicialização.
Em nosso exemplo, você deve modificar o “EC2 Launch Template” para atualizar as opções que permitem atribuir um IP público e executar as instâncias no Security Group criado na pilha LAMP do nosso aplicativo de amostra (PHPHELLOWorldSample-WebServerSecurityGroup*), conforme mostrado nas Figuras 13 e 14. Isso permitirá o acesso ao novo servidor (migrado e lançado), publicamente e por meio do protocolo http na porta 80. Observação: Lembre-se de que esse ajuste se deve a um contexto de demonstração ou teste, um ambiente produtivo deve seguir as melhores práticas.
Figura 13. Ajuste o IP e o security group.
Figura 14. Atribuição do security group e IP público.
Para criar uma nova versão da configuração da versão, selecione “Create Launch Template”. Esta nova versão não será atribuída como a versão padrão, portanto, para os fins do exercício prático, você deve atualizá-la no console do EC2, Figura 15.
Figura 15. Configurar a versão do modelo.
Selecione a versão que você acabou de criar para ajustar as configurações de IP público e Security Group, Figura 16.
Figura 16. Configure a versão padrão.
Etapa 4: Depois de adicionar todos os servidores de origem e configurar suas configurações de inicialização, você estará pronto para executar uma instância de avaliação. É crucial testar a migração de seus servidores de origem para a AWS antes de iniciar uma transição. Ou seja, você precisa verificar se seus servidores de origem estão funcionando corretamente dentro do ambiente da AWS, Figura 17 e 18.
Figura 17. Lançamento de instâncias de teste.
Figura 18. Botão Iniciar.
Depois que o servidor de teste for iniciado, você poderá ver em alguns minutos no console do EC2, dois servidores adicionais, o servidor de replicação, responsável pela replicação do servidor de origem e um servidor sem um nome específico, representando o servidor migrado, como mostrado na Figura 19.
Figura 19. Instâncias no EC2.
Prossiga para acessar o novo servidor e usar informações de DNS públicas para provar que o servidor migrado e o aplicativo de teste estão disponíveis, como na Figura 20. Você deve seguir o seguinte formato http://ec2-NEW-PUBLIC-IP.us-west-2.compute.amazonaws.com
Figura 20. Obtenção de IP público.
Etapa 5: Depois de experimentar este ambiente de teste e iniciar o ambiente produtivo ou de transição (Cutover), selecione no menu “Test and Cutover”, a opção “Mark Server as Ready for Cutover””. Você pode ver que na opção de confirmação você pergunta se deseja encerrar automaticamente as instâncias executadas no processo de teste, conforme a figura 21.
Figura 21. Encerre instâncias executadas.
Você pode mover um servidor de origem por vez ou mover simultaneamente vários servidores de origem. Para cada servidor de origem, você será informado sobre o sucesso ou o fracasso da transição. Você deve selecionar a opção “Launch Cutover instances” no menu “Test and Cutover”, figura 22.
Figura 22. Opção “Reutover”.
Depois que o servidor de transição for iniciado, você poderá ver em alguns minutos no console do EC2, o novo servidor (neste exercício prático, sem um nome específico). Prossiga para acessar o novo servidor e use informações de DNS públicas para provar que o servidor migrado e o aplicativo de teste estão disponíveis. Você deve seguir o seguinte formato http://ec2-NEW-PUBLIC-IP.us-west-2.compute.amazonaws.com
Se você tiver terminado completamente sua migração e fez uma transição bem-sucedida, poderá concluir a transição. Isso alterará o estado do ciclo de vida da migração de seus servidores de origem para “Cutover Complete”, indicando que a substituição foi concluída e que a migração foi bem-sucedida. Além disso, isso interromperá a replicação de dados e fará com que todos os dados replicados sejam descartados. Além disso, todos os recursos da AWS usados para replicação de dados serão cancelados. Você precisa selecionar o servidor e, em seguida, no menu “Test and Cutover” e, em seguida, tomar a opção de “Finalize Cutover”, figura 23.
Figura 23. Opção final “Cutover.
Finalmente, para limpar o ambiente criado durante este exercício prático, basta remover os recursos associados ao servidor de transição da etapa anterior e remover a pilha criada para o aplicativo de teste no CloudFormation, Figura 24.
Figura 24. Apague a pilha no serviço Cloudformation.
NOTA. Considere que as etapas descritas acima são apenas para fins de demonstração, um ambiente de produção deve seguir as melhores práticas de segurança.
Conclusão:
O AWS Application Migration Service pode acelerar a migração de aplicativos para a AWS por meio da análise de aplicativos por meio de uma estratégia de “Rehost”, otimizando os custos e o tempo de migração, já que esse exercício não requer alterações substanciais nos aplicativos; esse serviço acrescenta ao conjunto de serviços oferecidos para acelere o dia da adoção da nuvem na AWS dentro da oferta do serviço de migração.
Recursos:
Serviço de migração de aplicativos da AWS
Este artigo foi traduzido do Blog da AWS em Espanhol.
Sobre os autores
Angelica Ortega é uma Business Partner Solutions Architect (PSA) focada em servir parceiros latino-americanos, é líder regional em programas como o APN Immersion Day e o APN Ambassador. Ele tem 18 anos de experiência no setor de Tecnologia da Informação. Ela foi arquiteta de soluções, especialista em nuvem, design de serviços gerenciados e desenvolvedora de soluções móveis.
Dimas Cañas é um arquiteto de soluções para parceiros de negócios do setor público do México. Ele tem 18 anos de experiência no setor de Tecnologia da Informação. Ele foi arquiteto de aplicativos, arquiteto de software e líder em transformação digital.
Sobre os revisores
Erico Penna é arquiteto de soluções para parceiros de negócios especializados em migração, é membro da Comunidade Técnica de Campo (TFC).
Javier Huerta é um arquiteto de soluções especializado em well-architected para a América Latina. Ele foi arquiteto de soluções, gerente de prestação de serviços, gerente de conformidade regulatória e diretor de inovação tecnológica com 25 anos de carreira profissional. Ele também é membro da Comunidade Técnica de Campo (TFC) da Media and Entertainment. No momento, você está pensando sobre qual será a próxima solução que você criará na AWS.