DevSecOps

19 out, 2016

Migrando de VMs para containers

Publicidade

Juntamente com a crescente demanda em soluções de PaaS e DevOps, podemos notar um conjunto de barreiras de adoção para os proprietários de aplicativos legados hospedados dentro de VMs ou apenas em cima de servidores bare metal. A complexidade dos processos de decomposição e de migração é muitas vezes muito alto. Normalmente, os proprietários de aplicativos têm que redesenhar sua arquitetura de aplicação, a fim de se beneficiar das modernas soluções de PaaS e CaaS.

Neste artigo, vamos analisar os desafios específicos de migração de aplicativos legados Java que estão sendo executados dentro de VMs para plataformas baseadas em containers. E usando o exemplo do Oracle WebLogic Server, vamos mostrar os passos exatos do processo de decomposição e o resultado dessa migração.

Motivação de migração para containers

A virtualização de hardware foi um grande passo na hospedagem de aplicativos Java EE em comparação com a era do Bare Metal. Isso nos deu a capacidade de isolar vários aplicativos uns dos outros e utilizar o hardware de forma mais eficiente. No entanto, com Hypervisors, cada VM requer o seu próprio sistema operacional completo, TCP e pilhas do sistema de arquivos, que usam um poder significativo de processamento e memória da máquina host.

Cada VM tem uma quantidade fixa de RAM, e apenas alguns hypervisors podem redimensionar VMs durante a execução com uma ajuda de balão de memória que não é uma tarefa trivial. Como resultado, geralmente nós reservamos recursos em cada VM para mais escalonamento da aplicação. Esses recursos não são totalmente utilizados e, ao mesmo tempo, eles não podem ser compartilhados com outras aplicações, devido à falta de instâncias de isolamento adequadas dentro de uma VM.

containers-1

Containers promovem o desempenho e a utilização dos recursos pelo compartilhamento do kernel do sistema operacional, pilha TCP, sistema de arquivos e outros recursos do sistema da máquina host usando menos memória e sobrecarga da CPU.

Existem dois tipos de containers: container de aplicação e container de sistema. Normalmente, um container de aplicação é executado tão pouco quanto um único processo. E um container de sistema se comporta como um sistema operacional completo e pode executar todas as features de um sistema de inicialização completo como: systemd, SysVinit e openrc, que permitem gerar outros processos como OpenSSH, crond, SYSLOGD juntos dentro de um único container. Ambos os tipos de containers são úteis em casos diferentes e não desperdiçam RAM em processos de gestão redundantes, geralmente consomem menos memória RAM do que VM. No entanto, apenas com containers de sistema é possível a migração de aplicativos Java EE legados sem um massivo redesenho da aplicação.

Ao contrário de VMs, os limites de recursos em containers podem ser facilmente alterados nas instâncias em execução sem reinicialização. E os recursos que não são consumidos dentro dos limites das faixas são automaticamente compartilhados com outros containers em execução no mesmo nó de hardware.

containers-2

Os recursos que não são utilizados no hardware podem ser facilmente usados pelos containers existentes durante o escalonamento ou para novas cargas de trabalho de aplicações. Considerando o isolamento avançado de containers, diferentes tipos de aplicação podem ser executadas no mesmo nó de hardware sem influenciarem umas as outros. Isso permite aumentar a utilização dos recursos da infraestrutura existente de 3 a 10 vezes em média.

Além disso, os containers são muito úteis para os desenvolvedores que querem criar, empacotar e testar aplicações de forma ágil para acelerar os processos de desenvolvimento de aplicações e melhorar a escalabilidade de aplicações.

O que é decomposição?

A decomposição é uma parte essencial do processo de migração. Ela ajuda a dividir grandes aplicações de topologia monolítica em pequenas partes lógicas e trabalhar com elas de forma independente mais tarde.

Uma representação simples do processo de decomposição para a migração de VM aos containers é mostrada na figura abaixo.

containers-3

Executando aplicações legadas de Java em VM

Há um velho ditado no desenvolvimento de software: “software legado é ok. É apenas um software antigo que ainda funciona”. Então vamos ver mais precisamente como ele funciona com base no exemplo da Oracle WebLogic Server.

Estrutura da Oracle WebLogic Server na VM

WebLogic Server consiste em três tipos principais de instâncias necessárias para execução em VM:

  • Servidor de administração;
  • Gerenciador de nós;
  • Gerenciador de servidor.

Servidor de administração é o ponto central a partir do qual podemos configurar e gerenciar todos os recursos no cluster. Ele é ligado ao gerenciador de nós que são responsáveis pela adição e remoção das instâncias do gerenciador de servidor. Gerenciador de servidores hospedam aplicações web, EjBs, web services e outros recursos.

containers-4

Normalmente, cada VM hospeda um gerenciador de nós e vários gerenciadores de servidores, assim como um servidor de administração é usado para o gerenciamento de todas as instâncias através de muitas VMs. Uma descrição mais detalhada de cada componente pode ser encontrada na documentação oficial.

Escalonando WebLogic através das VMs

Agora vamos imaginar que temos um pico de tráfego e precisamos escalar o cluster. Para lidar com o aumento da carga, novos servidores de gerenciamento serão adicionados à VM até que o limite dos recursos seja alcançado (por exemplo, RAM).

containers-5

Mas o tráfego de entrada está crescendo e o número atual de instâncias gerenciamento de servidor não é suficiente para lidar com a carga, por isso precisamos adicionar uma nova VM para sermos capazes de escalar ainda mais a aplicação.

O fluxo clássico de escalonamento do WebLogic Server através de várias VMs contém três etapas:

  1. Providenciar uma nova VM com o template WebLogic Server pré-configurado;
  2. Iniciar um gerenciador de nós dentro da mais nova VM adicionada e conectá-lo ao servidor de administração;
  3. Adicionar um novo gerenciador de servidor para manipular uma parte da carga excessiva.

containers-6

Depois disso, o processo de escala repete, lançamos mais servidores gerenciados dentro da VM recentemente adicionada até atingirmos os limites dos recursos.

containers-7

Desvantagens de executar WebLogic em VMs

Executar a Oracle WebLogic é a uma abordagem muito ineficiente da utilização dos recursos; há vários pontos em que os recursos são desperdiçados ou não utilizados:

  • Cada VM requer o seu próprio sistema operacional completo, TCP e pilhas do sistema de arquivos, que usam um poder significativo de processamento e de memória da máquina host;
  • A alocação de recursos não é altamente granular, então mesmo que precisemos apenas de um servidor de gerenciamento adicional, em alguns casos teremos que provisionar uma VM integral;
  • Se ficarmos sem recursos em uma máquina virtual, temos que reiniciar toda a máquina virtual para adicionar núcleos de CPU extras ou apenas mais GBs de RAM;
  • Gerenciadores de nós, especificamente exigidos pela VM para adicionar ou remover servidores de gerenciamento, consomem recursos adicionais e criam complexidade extra nas configurações;
  • Executar instâncias na mesma VM pode influenciar um à outra, devido à falta de isolamento e prejudicar o desempenho de toda a aplicação. Pela mesma razão, não podemos misturar e combinar diferentes aplicações dentro de uma VM;
  • Portabilidade de VM é comumente limitada a um único fornecedor, por isso não pode ser um conjunto de problemas no caso de querermos migrar para outra nuvem;
  • Implementar e empacotar templates de fluxo CI/CD com VMs são processos lentos e complexos.

Migrando de VMs para containers

Nos dias de hoje, podemos encontrar muitos servidores de aplicação bons e frameworks que são projetados para serem executados como microservices em containers, como Spring Boot, WidFly Swarm, Payara Micro e outros. No entanto, há um conjunto de servidores projetados especificamente para rodar em VM, como o Oracle WebLogic Server, e a tarefa de migração para containers em tais instâncias é mais complexa. É por isso que gostaria de dar mais atenção a esse caso no nosso artigo.

Decomposição do WebLogic Server

Primeiro de tudo, precisamos preparar uma imagem do container com WebLogic Server. É uma tarefa fácil nos dias de hoje com a ajuda dos containers Docker (por exemplo, cheque o repositório oficial da Oracle).

Quando o Docker template está pronto, nós providenciamos cada instância dentro de um container isolado: um servidor de administração e o número necessário de servidores gerenciados.

Nesse ponto, podemos nos livrar do papel do gerenciador de nós, já que ele foi projetado como um agente de VM para adicionar e remover instâncias de servidor gerenciado.

Após a migração para containers, as instâncias de servidor gerenciado podem ser adicionadas/removidas automaticamente, assim como podem ser ligadas diretamente ao servidor de administração usando a plataforma de orquestração de container e um conjunto de scripts WSLT.

Como resultado, temos uma topologia muito mais simples do nosso Cluster Weblogic Server.

containers-8

Agora, o processo de escalonamento horizontal se tornou muito granular e suave, como um container pode ser facilmente clonado ou provisionado a partir do zero. Além disso, cada container pode ser escalonado cima e para baixo em tempo real e sem perda de atividade. Isso é muito mais preciso em comparação com as máquinas virtuais, visto que essa operação demora muito menos tempo quando comparada ao escalonamento de VMs.

Vantagens de executar WebLogic em Containers

Migrar para containers pode ser uma tarefa difícil, mas se você sabe como gerenciá-la, pode ganhar um conjunto de benefícios:

  • Reduzir o uso de recursos de sistema (processamento e memória) pela eliminação da necessidade do seu próprio SO, TCP e pilhas de arquivos de sistemas para cada container;
  • Simplificação do escalonamento horizontal pela remoção de instâncias de gerenciadores de nós da topologia do cluster;
  • Habilitação automática do escalonamento vertical usando as habilidades dos containers para compartilhar recursos não utilizados e ser facilmente redimensionado sem reinicialização;
  • Aumentar a utilização da infraestrutura pela hospedagem de diferentes aplicações dentro de um único servidor físico, já que as suas instâncias são isoladas dentro de containers separados;
  • Migrar entre fornecedores de nuvem, sem lock-in utilizando a portabilidade de containers;
  • Acelerar os processos de integração e entrega contínua usando uma ampla gama de ferramentas de DevOps projetadas especificamente para containers.

Uma abordagem semelhante pode ajudar a decompor outras camadas de aplicação ou pode ser aplicada a outros servidores de aplicação Java EE. E nos próximos artigos, iremos descrever como lidar com os dados após a decomposição e mostrar todo o processo em um exemplo específico.

Precisa de mais informações ou ajuda? Entre em contato, compartilhe seu caso de uso e experiência em decomposição de aplicações Java legadas e migração para outros containers.

***

Ruslan Synytsky faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://blog.jelastic.com/2016/10/11/migration-from-vms-to-containers/.