O blog da AWS

Containerize sua aplicação ASP.NET legada em alguns cliques usando o AWS Migration Hub Orchestrator

Escrito por Neeraj Handa, arquiteto de soluções na Amazon Web Services.

Cada vez mais, os clientes estão adotando containers para fornecer um ambiente consistente e poderoso para que suas aplicações sejam executadas e escaladas com facilidade em qualquer lugar. Os serviços de containers da Amazon Web Services (AWS) facilitam o gerenciamento de sua infraestrutura subjacente para que você possa se concentrar na inovação.

Em 2020, a AWS lançou o AWS App2Container (A2C), uma ferramenta que ajuda os clientes a conteinerizar aplicações ASP.NET e Java legadas sem fazer nenhuma alteração no código. Embora o A2C seja uma ferramenta muito poderosa que fornece amplos recursos de personalização, os clientes têm solicitado uma experiência guiada para ajudá-los a conteinerizar e implantar suas aplicações no Amazon Elastic Container Service (Amazon ECS) sem a necessidade de baixar e instalar ferramentas adicionais, como o A2C.

O template de replataforma recém-lançado no AWS Migration Hub Orchestrator atende a essa necessidade. Agora, você pode mover para containers e implantar aplicações ASP.NET e Java no Amazon ECS com AWS Fargate, um mecanismo de computação serverless e pago conforme o uso para containers, em alguns cliques diretamente do AWS Management Console.

Neste blog post, abordaremos como conteinerizar e implantar uma aplicação ASP.NET executada em uma instância do Amazon Elastic Compute Cloud (Amazon EC2) para Microsoft Windows Server no Amazon ECS com AWS Fargate usando o AWS Migration Hub Orchestrator. Para mover para containers e implantar uma aplicação executada localmente no Amazon ECS com AWS Fargate, você pode usar o template de rehospedagem de aplicações no EC2 no AWS Migration Hub Orchestrator para rehospedar sua aplicação no Amazon EC2 e, em seguida, seguir este post para conteinerizar e implantar a aplicação no Amazon ECS com AWS Fargate.

Pré-requisitos

Para este tutorial, você deve ter os seguintes recursos provisionados:

Neste blog post, usaremos uma aplicação de código aberto do mundo real chamada nopCommerce. As versões atuais do nopCommerce são baseadas em ASP.NET Core. Como queremos nos concentrar em aplicações ASP.NET legadas criadas em .NET Framework, usaremos o nopCommerce versão 3.90, que é baseado em .NET Framework 4.5.1. A aplicação nopCommerce que estamos usando neste blog post está instalada em uma instância do Amazon EC2 executando Windows Server 2022, IIS 10 e .NET Framework 4.5.1.

Processo

Para começar a usar o AWS Migration Hub Orchestrator, acesse o console do AWS Migration Hub e escolha Workflow templates para criar um novo fluxo de trabalho, conforme mostrado na Figura 1.

Figura 1 — Workflow templates no console do AWS Migration Hub

Escolha o modelo de fluxo de trabalho Replatform applications to Amazon ECS e escolha Create Workflow (Figura 2). Esse modelo de fluxo de trabalho é um manual para executar o fluxo de trabalho de replataforma e inclui:

  • Etapas do processo de replataforma e suas dependências;
  • Serviços, soluções e scripts necessários para automatizar a etapa de replataforma; e
  • Parâmetros de entrada necessários, como máquina virtual de origem, nome da aplicação, configurações do container de destino e configurações do cluster de destino.

Figura 2 — Template de replatform applications para Amazon ECS

Para configurar seu fluxo de trabalho, forneça os seguintes detalhes (Figura 3):

  • Forneça um nome para seu fluxo de trabalho.
  • Selecione a região da AWS em que a aplicação a ser conteinerizada está sendo executada.
  • Selecione a instância do Amazon EC2 executando sua aplicação.
  • Selecione o bucket do Amazon S3 que o Migration Hub Orchestrator usará para armazenar artefatos da aplicação enquanto executa o fluxo de trabalho. Observe que o caminho do S3 para armazenar os artefatos da aplicação deve ter uma pasta com prefixo application-transformation. Um exemplo de caminho é s3://my-bucket/application-transformation-app1.
  • Opcionalmente, selecione a chave do AWS Key Management Service para criptografar os recursos usados por esse fluxo de trabalho.
  • Opcionalmente, forneça uma descrição e tags.

Figura 3 — Configure seu fluxo de trabalho

Escolha Next para prosseguir para a tela Step 3 Review and Submit. Nessa tela, revise sua configuração e selecione Create para criar o fluxo de trabalho. Levará alguns minutos para criar seu fluxo de trabalho.

Quando a criação do fluxo de trabalho estiver concluída, confirme se o Status do fluxo de trabalho está definido como Not started na lista de fluxos de trabalho, conforme mostrado na Figura 4.

Figura 4 — Selecione o fluxo de trabalho que você criou

Escolha seu fluxo de trabalho e clique em Run, conforme mostrado na Figura 5, para iniciar o processo passo a passo de analisar e armazenar sua aplicação em containers.

Figura 5 — Executar o fluxo de trabalho

O fluxo de trabalho consiste em três etapas. Vamos examinar cada uma.

Etapa 1 — Analyze

Nesta etapa, o Migration Hub Orchestrator descobre os sites do IIS instalados nas instâncias do Amazon EC2 que você seleciona ao configurar o fluxo de trabalho. Após a conclusão da descoberta, o status do fluxo de trabalho muda para User attention required, conforme mostrado na Figura 6.

Figura 6 — User attention required na Etapa 1 (Analyze)

Para continuar, selecione a etapa 1.b Select Applications for transformation and deployment. Em [Actions], [Chage status], escolha Completed. Consulte a Figura 7.

Change status to Completed on Step 1

Figura 7 — Alterar o status para Concluído na Etapa 1

Na caixa de diálogo exibida (Figura 8), selecione o site do IIS que hospeda a aplicação que você deseja mover para containers. Se você selecionar várias aplicações para armazenar em containers, a opção padrão é criar uma imagem de container por aplicação, o que é recomendado para a maioria dos casos. Para combinar várias aplicações em um container, selecione a opção correspondente.

Figura 8 — Selecione o site do IIS que hospeda sua aplicação

Etapa 2 — Transform

Nesta etapa, o Migration Hub Orchestrator empacota suas aplicações selecionadas em imagens de container, cria um repositório no Amazon Elastic Container Registry (Amazon ECR) para armazenar as imagens do container e envia as imagens para esse repositório. O Migration Hub Orchestrator armazena os artefatos usados para gerar as imagens do container no bucket do Amazon S3 que você configurou ao criar o fluxo de trabalho.

Essa é uma etapa automatizada e nenhuma ação manual é necessária. Dependendo do tamanho da aplicação, essa etapa pode levar até 30 minutos. Quando essa etapa for concluída, o status dessa etapa será alterado para Complete, conforme mostrado na Figura 9.

Figura 9 — Etapa 2 (Transform) no status Complete

Confirme se o Migration Hub Orchestrator criou um repositório privado no console do Amazon ECR com o mesmo nome da sua aplicação. Para este tutorial, o nome da nossa aplicação é iis-default-web-site-17a27788. Consulte a Figura 10.

Figura 10 — Imagem do container da aplicação no Amazon ECR

Etapa 3 — Deploy

Nesta etapa, o Migration Hub Orchestrator implantará a imagem do container em um cluster Amazon ECS existente que você pode configurar opcionalmente. Se você não configurar um cluster existente, o Migration Hub Orchestrator criará um cluster. Antes de continuar, confirme se o status da etapa 3.a Provide Amazon ECS deployment inputs é User attention required. Para configurar os parâmetros de implantação, selecione a etapa 3.a Provide Amazon ECS deployment inputs. Em [Actions], [Status], escolha Completed. Consulte a Figura 11.

Figura 11 — Alterar o status para Completed na Etapa 3 (Deploy)

Na caixa de diálogo que aparece (Figura 12), configure as seguintes entradas:

  • ID da VPC — ID da Amazon Virtual Private Cloud (VPC) na qual você deseja que o cluster do Amazon ECS seja implantado.
  • Nome do cluster ECS (opcional) — Selecione um cluster Amazon ECS existente para implantar.
  • ARN da IAM Role de task execution do ECS — Amazon Resource Name (ARN) para uma IAM Role de task execution do Amazon ECS.
  • ARN da task role do Amazon ECS (opcional) — ARN para uma função IAM da tarefa do Amazon ECS.
  • CPU (opcional) — Número de unidades de CPU a serem reservadas para o container.
  • Memória (opcional) — Quantidade de memória em GB a ser alocada ao container.

Figura 12 — Forneça entradas para implantação no Amazon ECS

Para continuar, escolha Confirm. O Migration Hub Orchestrator executará as seguintes ações:

  1. Se você não selecionou um cluster existente, o Migration Hub Orchestrator criará um cluster Amazon ECS na VPC que você forneceu com o AWS Fargate configurado como capacity provider.
  2. O Migration Hub Orchestrator criará uma task definition do Amazon ECS configurada com os valores fornecidos para a Task Execution IAM role, Task role, CPU, memória e o caminho da imagem do container armazenada no Amazon ECR.
  3. Para manter uma ou mais instâncias do seu container de aplicações em execução o tempo todo, o Migration Hub Orchestrator cria um serviço Amazon ECS.
  4. Para distribuir o tráfego uniformemente em vários containers em seu serviço, o Migration Hub Orchestrator cria um Application Load Balancer e o configura para enviar tráfego para seus containers das aplicações.

Essas ações podem levar até 30 minutos para serem concluídas. Depois de concluído, o status do fluxo de trabalho mudará para Complete, conforme mostrado na Figura 13.

Figura 13 — Fluxo de trabalho concluído

Caso sua aplicação use session state, observe que os containers foram projetados para serem efêmeros e podem ser interrompidos ou destruídos com mais frequência do que máquinas virtuais, como instâncias do Amazon EC2. Isso torna o session state muito mais difícil de manter dentro de um container. Considere armazenar o session state fora do seu container em um armazenamento de dados de alto desempenho, como Amazon ElastiCache ou Amazon DynamoDB.

Confirme se o Migration Hub Orchestrator criou um cluster do Amazon ECS no console do Amazon ECS, conforme mostrado na Figura 14.

Figura 14 — Cluster do Amazon ECS

Escolha o nome do cluster para ver os detalhes do mesmo. Na guia Services, confirme se há um serviço no status Active. Consulte a Figura 15.

Figura 15 — Serviço Amazon ECS

Escolha o nome do serviço para ver os detalhes do mesmo. Na guia Health and metrics, confirme se há um Application Load Balancer com 1 alvo íntegro. Escolha View load balancer para ver os detalhes do Application Load Balancer. Consulte a Figura 16.

Figura 16 — Status do Application Load Balancer

A página de detalhes do Application Load Balancer mostrará a VPC, as zonas de disponibilidade, o status e o nome DNS do balanceador de carga. Copie o nome DNS. Consulte a Figura 17.

Figura 17 — Nome DNS do Application Load Balancer

Cole o nome DNS na barra de endereço do navegador e confirme se você pode acessar sua aplicação, conforme mostrado na Figura 18.

Figura 18 — Aplicação em containers em execução no Amazon ECS

Limpeza

Para excluir os recursos criados neste blog post, filtre as stacks no console do AWS CloudFormation com base no nome da sua aplicação. Verifique se o botão de View nested está OFF e se o status do filtro está definido como Active. Para a stack resultante, escolha Excluir. Consulte a Figura 19.

Figura 19 — Exclua a stack do AWS CloudFormation

Conclusão

Neste blog post, você usou o AWS Migration Hub Orchestrator para conteinerizar e implantar uma aplicação ASP.NET diretamente do AWS Management Console com alguns cliques. O Migration Hub Orchestrator ajuda você a colocar em containers e implantar aplicações no Amazon ECS usando uma experiência simplificada e baseada na web, sem a necessidade de baixar e instalar ferramentas.

Para obter mais informações sobre a capacidade de conteinerização do Migration Hub Orchestrator, leia a documentação. Para uma experiência de conteinerização mais personalizada, confira o AWS App2Container. Para saber mais sobre a implantação de uma aplicação Windows no Amazon Elastic Kubernetes Service (Amazon EKS), confira este blog post.

A AWS tem significativamente mais serviços e mais recursos dentro desses serviços do que qualquer outro provedor de nuvem, tornando mais rápido, fácil e econômico mover suas aplicações existentes para a nuvem e criar praticamente qualquer coisa que você possa imaginar. Ofereça às suas aplicações Microsoft a infraestrutura de que eles precisam para gerar os resultados comerciais que você deseja. Visite nosso blogs .NET on AWS e AWS Databases para obter orientações e opções adicionais para suas cargas de trabalho Microsoft. Entre em contato conosco para iniciar sua jornada de migração e modernização hoje mesmo.

Esse artigo foi originalmente publicado em inglês no AWS Blog (link aqui).

Autor

     Neeraj Handa é arquiteto de soluções na Amazon Web Services. Ele é apaixonado pela arquitetura de aplicações e é especializado em ajudar os clientes a modernizar na AWS.

Tradutores/Revisores

Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 15 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias afim de ajudar os clientes em seus desafios diários.
                  Luciano Bernardes trabalha atualmente como Sr Solutions Architect na AWS, especializado em workloads Microsoft. Com 17 anos de experiência no mercado, trabalhou a maior parte em consultoria técnica especializada em Microsoft, em clientes de várias verticais, com demandas voltadas para infraestrutura on-premises e em nuvem. Como SA, trabalha próximo a clientes e parceiros de consultoria em U.S. e LATAM, para apoiá-los em tomadas de decisão e revisão de arquitetura de workoads Microsoft na nuvem AWS.