Migre do servidor de IBM WebSphere aplicativos para o Apache Tomcat na Amazon EC2 com o Auto Scaling - Recomendações da AWS

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Migre do servidor de IBM WebSphere aplicativos para o Apache Tomcat na Amazon EC2 com o Auto Scaling

Criado por Kevin Yung (AWS) e Afroz Khan () AWS

Tipo R: redefinir a plataforma

Origem: aplicativos

Alvo: Apache Tomcat em uma EC2 instância da Amazon com o Auto Scaling ativado

Criado por: AWS

Ambiente: PoC ou piloto

Tecnologias: aplicativos web e móveis; migração

Carga de trabalho: código aberto; IBM

AWSserviços: Amazon EC2

Resumo

Esse padrão fornece orientação para migrar um aplicativo Java do IBM WebSphere Application Server para o Apache Tomcat em uma EC2 instância do Amazon Elastic Compute Cloud (Amazon) com o Amazon Auto EC2 Scaling ativado. 

Ao usar esse padrão, você pode conseguir:

  • Uma redução nos custos de IBM licenciamento

  • Alta disponibilidade usando implantação Multi-AZ

  • Melhor resiliência de aplicativos com o Amazon EC2 Auto Scaling

Pré-requisitos e limitações

Pré-requisitos

  • Aplicativos Java (versão 7). x ou 8. x) deve ser desenvolvido em LAMP pilhas.

  • O estado de destino é hospedar aplicativos Java em hosts Linux. Esse padrão foi implementado com sucesso em um ambiente Red Hat Enterprise Linux (RHEL) 7. Outras distribuições Linux podem seguir esse padrão, mas a configuração da distribuição Apache Tomcat deve ser referenciada.

  • Você deve entender as dependências do aplicativo Java.

  • Você deve ter acesso ao código-fonte do aplicativo Java para fazer alterações.

Limitações e mudanças na redefinição da plataforma

  • Você deve compreender os componentes enterprise archive (EAR) e verificar se todas as bibliotecas estão empacotadas nos WAR arquivos de componentes da web. Você precisa configurar o WARplug-in Apache Maven e produzir artefatos de WAR arquivo.

  • Ao usar o Apache Tomcat 8, há um conflito conhecido entre o servlet-api.jar e os arquivos JAR integrados do pacote do aplicativo. Para resolver esse problema, exclua o servlet-api.jar do pacote do aplicativo.

  • Você deve configurar WEB - INF /resources localizado no caminho de classe da configuração do Apache Tomcat. Por padrão, as JAR bibliotecas não são carregadas no diretório. Como alternativa, você pode implantar todos os recursos em src/main/resources.

  • Verifique se há raízes de contexto de codificação rígida no aplicativo Java e atualize a nova raiz de contexto do Apache Tomcat.

  • Para definir as opções JVM de tempo de execução, você pode criar o arquivo de configuração setenv.sh na pasta bin do Apache Tomcat; por exemplo, JAVA _, JAVA _ OPTS HOME, etc.  

  • A autenticação é configurada no nível do contêiner e configurada como uma região nas configurações do Apache Tomcat. A autenticação é estabelecida para qualquer um dos três domínios a seguir: 

    • JDBCO Database Realm pesquisa usuários em um banco de dados relacional acessado pelo driverJDBC.

    • DataSource O Database Realm pesquisa usuários em um banco de dados que é acessado peloJNDI.

    • JNDIO Directory Realm pesquisa usuários no diretório Lightweight Directory Access Protocol (LDAP) que é acessado pelo JNDI provedor. As pesquisas exigem: 

      • LDAPdetalhes da conexão: base de pesquisa de usuário, filtro de pesquisa, base de função, filtro de função 

      • A principal JNDI região do diretório: conectaLDAP, autentica usuários e recupera todos os grupos dos quais um usuário é membro

  • Autorização: no caso de um contêiner com uma autorização baseada em funções que verifica as restrições de autorização em web.xml, os recursos da Web devem ser definidos e comparados às funções definidas nas restrições. Se LDAP não tiver mapeamento de função de grupo, você deverá definir o atributo < security-role-ref > em web.xml para obter o mapeamento de função de grupo. Para ver um exemplo de um documento de configuração, consulte a documentação da Oracle

  • Conexão de banco de dados: crie uma definição de recurso no Apache Tomcat com um endpoint URL do Amazon Relational Database Service (AmazonRDS) e detalhes da conexão. Atualize o código do aplicativo para fazer referência a DataSource usando JNDI lookup. Uma conexão de banco de dados existente definida em não WebSphere funcionaria, pois usa WebSphere os JNDI nomes. Você pode adicionar uma <resource-ref>entrada em web.xml com o JNDI nome e a definição do DataSource tipo. Para ver um exemplo de documento de configuração, consulte a documentação do Apache Tomcat.

  • Registro: por padrão, o Apache Tomcat faz o registro de logs no console ou em um arquivo de log. Você pode ativar o rastreamento em nível de domínio atualizando logging.properties (consulte Registro em log no Tomcat). Se você estiver usando o Apache Log4j para anexar registros em log a um arquivo, você deve baixar o tomcat-juli e adicioná-lo ao classpath.

  • Gerenciamento de sessão: Se você estiver retendo a IBM Web SEAL para balanceamento de carga de aplicativos e gerenciamento de sessões, nenhuma alteração será necessária. Se você estiver usando um Application Load Balancer ou Network Load Balancer AWS ativado para substituir IBM o componente SEAL Web, deverá configurar o gerenciamento de sessões usando uma instância da ElastiCache Amazon com um cluster Memcached e configurar o Apache Tomcat para usar o gerenciamento de sessões de código aberto. 

  • Se você estiver usando o proxy de SEAL encaminhamento IBM da Web, deverá configurar um novo Network Load Balancer ativado. AWS Use o IPs fornecido pelo Network Load Balancer para configurações de SEAL junção da Web.

  • SSLconfiguração: recomendamos que você use Secure Sockets Layer (SSL) para end-to-end comunicações. Para definir uma configuração de SSL servidor no Apache Tomcat, siga as instruções na documentação do Apache Tomcat. 

Arquitetura

Pilha de tecnologia de origem

  • IBM WebSphere Servidor de aplicativos

Pilha de tecnologias de destino

  • A arquitetura usa o Elastic Load Balancing (versão 2). Se você estiver usando o IBM Web for Identify SEAL para gerenciamento e balanceamento de carga, poderá selecionar um Network Load Balancer AWS ativado para integrar com IBM o proxy reverso da SEAL Web.

  • Os aplicativos Java são implantados em um servidor de aplicativos Apache Tomcat, que é executado em uma EC2 instância em um grupo do Amazon Auto Scaling. EC2 Você pode configurar uma política de escalabilidade com base nas CloudWatch métricas da Amazon, como a CPU utilização. 

  • Se você estiver retirando o uso da IBM Web SEAL para balanceamento de carga, poderá usar o Amazon ElastiCache for Memcached para gerenciamento de sessões.

  • Para o banco de dados de back-end, você pode implantar o High Availability (Multi-AZ) para a Amazon RDS e selecionar um tipo de mecanismo de banco de dados.

Arquitetura de destino

Nuvem AWS architecture with VPC, two availability zones, load balancer, and database setup.

Ferramentas

Épicos

TarefaDescriçãoHabilidades necessárias
Crie uma nuvem privada virtual (VPC).
Crie sub-redes.
Crie tabelas de roteamento, se necessário.
Crie listas de controle de acesso à rede (ACLs).
Configure o AWS Direct Connect ou uma VPN conexão corporativa.
TarefaDescriçãoHabilidades necessárias
Refatore a configuração do Maven de compilação do aplicativo para gerar os WAR artefatos.
Refatore as fontes de dados de dependência do aplicativo no Apache Tomcat.
Refatore os códigos-fonte do aplicativo para usar JNDI nomes no Apache Tomcat.
Implante os WAR artefatos no Apache Tomcat.
Validações e testes completos do aplicativo.
TarefaDescriçãoHabilidades necessárias
Configure o firewall corporativo para permitir a conexão com os serviços de dependência.
Configure o firewall corporativo para permitir que o usuário final acesse o Elastic Load Balancing ativado. AWS
TarefaDescriçãoHabilidades necessárias
Crie e implante o aplicativo em uma EC2 instância.
Crie um cluster Amazon ElastiCache for Memcached para gerenciamento de sessões.
Crie uma instância Amazon RDS Multi-AZ para o banco de dados de back-end.
Crie SSL certificados e importe-os para o AWS Certificate Manager (ACM).
Instale SSL certificados em balanceadores de carga.
Instale SSL certificados para servidores Apache Tomcat.
Validações e testes completos do aplicativo.
TarefaDescriçãoHabilidades necessárias
Encerre a infraestrutura existente.
Restaure o banco de dados da produção para a AmazonRDS.
Corte o aplicativo fazendo DNS alterações.

Referências

Tutoriais e vídeos