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á.
Domínios técnicos
Esta seção fornece uma Visão geral dos principais domínios de tecnologia para conteinerização. O diagrama a seguir mostra a arquitetura de uma aplicação em Java EE tradicional.
O diagrama a seguir mostra a arquitetura de uma aplicação em Java EE conteinerizada.
1. Estado da sessão
Na maioria dos casos, as aplicações em Java EE armazenam os dados da sessão associados às solicitações do usuário, como cookies para servlets e sessões stateful do Enterprise Java Beans (EJB). Recomendamos evitar armazenar informações de estado na memória da máquina virtual Java (JVM) porque seu contêiner deve ser mantido stateless. Para obter mais informações sobre o princípio da descartabilidade, consulte Princípios do design de aplicações baseadas em contêineres
O mecanismo de replicação de memória pressupõe que um determinado conjunto de servidores sempre exista no cluster ou que um pequeno número de servidores ingresse ou saia do cluster. Isso é incompatível com um ambiente de contêiner. Por isso, recomendamos descartar o mecanismo de replicação de memória. Em um ambiente de contêiner, os servidores de aplicações são reimplantados quando uma nova versão da imagem do contêiner é criada. Ou seja, todos os dados de memória replicados também são apagados.
2. Agentes
Há vários processos de agentes em execução em um único servidor físico ou virtual que normalmente executam tarefas utilitárias e de automação, por exemplo:
-
Monitoramento: os ambientes tradicionais de aplicações em Java EE geralmente usam agentes dedicados para monitoramento. Esses agentes são responsáveis por monitorar a CPU do servidor, memória, uso do disco, utilização de memória dentro da JVM, mensagens de log e muito mais. No entanto, não é possível executar agentes de monitoramento diretamente em um ambiente de contêiner. Você deve substituir os agentes de monitoramento pelo mecanismo de monitoramento fornecido pela plataforma de contêineres, como Amazon CloudWatch e Amazon CloudWatch Logs.
-
Trabalhos (tarefas programadas): em ambientes tradicionais de aplicações em Java EE, o ambiente de execução de tarefas geralmente reside no mesmo servidor que o servidor de aplicações e é responsável por processos em lote de longa execução, além das solicitações do usuário. Por exemplo, o processo em lote gerenciado pelo controlador de tarefas acessa o banco de dados para recuperar dados e criar um relatório. Como essas várias workloads não podem coexistir em um ambiente de contêiner, é necessário criar o ambiente de execução de trabalhos e lotes separadamente do ambiente de contêiner.
-
Transferência de arquivos: os agentes de transferência de arquivos normalmente não são tão comuns em ambientes de aplicações em Java EE, mas, às vezes, são executados no mesmo sistema operacional com a aplicação em Java como um processo independente para trocar arquivos com aplicações externas. Por exemplo, os dados usados por outras aplicações são transferidos para um arquivo todos os dias e refletidos no banco de dados. Os agentes de transferência de arquivos não podem estar executando junto com contêineres. Eles devem ser executados em outro servidor que tenha acesso ao banco de dados e aos arquivos.
3. Servidores de aplicações
O desafio mais significativo na conteinerização é mudar os servidores de aplicações. Os servidores de aplicações tradicionais compatíveis com Java EE pressupõem um ambiente computacional estático. Consequentemente, eles podem não ser adequados para execução em um ambiente de contêiner. Ou seja, os servidores físicos ou virtuais são assumidos como a entidade do ambiente computacional para aplicações em Java EE. Por exemplo, servidores de aplicativos Java EE proprietários, como o IBM WebSphere Application Server (TWAs) tradicional e o Oracle WebLogic Server, têm seu próprio mecanismo de implantação de aplicativos.
A situação é diferente em um ambiente de contêiner. Nesse ambiente, os contêineres incluem um servidor de aplicações e um runtime com pacotes de criação de aplicações (por exemplo, arquivos .war e .jar) e são implantados em plataformas de contêineres, como Amazon ECS ou Amazon EKS. Recomendamos usar um mecanismo de plataforma de contêiner para implantar aplicações em ambientes. Os servidores de aplicações são frequentemente implantados com contêineres, portanto, eles devem ser pequenos (menos de 500 MB) e rápidos de iniciar. Para atender a esse requisito, talvez seja necessário mudar o servidor de aplicações tradicional e migrar para um servidor de aplicações mais compatível com contêineres. Isso pode exigir uma migração do IBM WebSphere Application Server para o IBM WebSphere Liberty ou JBoss Enterprise Application Platform (EAP) para o. WildFly
Recomendamos considerar os seguintes impactos que podem resultar da mudança do servidor de aplicações:
-
Injeção de configuração por meio de variáveis de ambiente (em contraste com as aplicações em Java EE tradicionais que armazenam configurações em um arquivo, como web.xml)
-
Compatibilidade com os recursos do Java EE
-
Versões do JVM
4. Armazenamento de arquivos
O armazenamento de arquivos mais comumente usado para aplicações em Java EE tradicionais é o sistema de arquivos local. Os casos de uso mais comuns incluem arquivos de log de aplicações, arquivos gerados por aplicações, como relatórios comerciais, e conteúdo enviado pelo usuário. Recomendamos evitar armazenar arquivos dentro do contêiner porque os contêineres são stateless, o que significa que os armazenamentos de arquivos precisam ser externalizados para conteinerização.
Considere as seguintes opções de conteinerização:
-
Amazon Elastic File System (Amazon EFS): o Amazon EFS é um serviço de NFS gerenciado que pode ser acessado a partir de contêineres. O Amazon EFS é integrado ao Amazon ECS e ao Amazon EKS. Se você usa o Amazon EFS, não precisa escrever scripts personalizados para montar volumes do EFS em seus contêineres. A primeira etapa dessa opção é listar sua aplicação todos os caminhos do sistema de arquivos que são usados para leitura ou gravação. Depois de identificar o caminho do sistema de arquivos a ser persistido, você poderá mapear o caminho do sistema de arquivos para um caminho de sistema de arquivos do EFS. Para obter mais informações, consulte Tutorial: Usar sistemas de arquivos do Amazon EFS com o Amazon ECS na documentação do Amazon ECS. Nem todos os caminhos precisam ser persistidos, especialmente os arquivos de log de aplicações. A maioria das aplicações corporativas grava arquivos de log em um sistema de arquivos local. Como parte do processo de conteinerização, recomendamos considerar alterar o destino do log para usar Standard Out e Standard Error. Isso permite que você capture toda a saída para o CloudWatch Logs sem gerenciar o tamanho e o desempenho do armazenamento de registros. Para obter mais informações sobre o login no Amazon ECS, consulte Usar o driver de log awslogs na documentação do Amazon ECS.
-
Amazon Simple Storage Service (Amazon S3): o Amazon S3 é mais barato que o Amazon EFS e oferece suporte a uma largura de banda maior do que o Amazon EFS, mas o Amazon S3 exige modificações mais amplas no código da aplicação que o Amazon EFS. Isso ocorre porque o Amazon S3 não é um sistema de arquivos.
5. Processo de compilação e implantação
O processo de conteinerização envolve a alteração e a extensão do processo de entrega da aplicação. Em ambientes tradicionais, o processo de entrega de aplicações envolve principalmente artefatos Java (por exemplo, arquivos .war e .ear). Em um ambiente de contêiner, a imagem do contêiner é a unidade de entrega. Além do processo de compilação de artefatos Java existentes, é necessário criar um processo para compilar e entregar contêineres do Docker. Para obter mais informações sobre o processo de pipeline, consulte Criar e implantar automaticamente um aplicativo Java no Amazon EKS usando um CI/CD pipeline na documentação de orientação AWS prescritiva.
6. Acesso ao banco de dados
Os contêineres tradicionais de aplicações geralmente são acompanhados pela migração dos bancos de dados. Para reduzir o risco de migração, recomendamos seguir a estratégia de migração para bancos de dados relacionais (orientação AWS prescritiva). Ambientes conteinerizados exigem configuração externalizada, incluindo strings de conexão de banco de dados. Você pode usar ferramentas como o Spring Cloud Config
